Build the ugly version first

The word doing the damage is viable.

You proposed a small first version. Someone asked whether it would have sorting, because without sorting it is not really viable. Then filtering, because finance will ask. Then export. Six weeks later you are shipping the full thing and calling it an MVP, which is what almost always happens.

Nobody agrees what viable means, including the people who coined it

This is worth knowing, because the argument you keep losing is not winnable on that word.

Frank Robinson, who originated the term, meant a commercial object: “The MVP is the right-sized product for your company and your customer. It is big enough to cause adoption, satisfaction and sales, but not so big as to be bloated.” Something real, offered for sale. His complaint was feature count as a badge of honour: “Teams often brag, ‘We added 800 new features.’”

Eric Ries meant an instrument: “that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.” Learning, not sales. He is explicit that this is not what people hear: “MVP, despite the name, is not about creating minimal products,” and, drily, “In fact, MVP is quite annoying, because it imposes extra overhead.” He devotes a section of The Lean Startup to the collision, opening it: “One of the most vexing aspects of the minimum viable product is the challenge it poses to traditional notions of quality.”

Henrik Kniberg, who drew the MVP diagram everyone has copied, now recommends dropping the term entirely, because “your ‘viable’ is my ‘horrible’.” His replacement is an Earliest Usable Product, which he says is “far from done, and it might not be very likeable.”

Three primary sources, three incompatible definitions. If you are arguing about whether something is viable, you are not going to win, because your colleague is using a different word.

What they do agree on

Strip out the disagreement and one thing survives all three: a real person can finish a real task with it.

Not evaluate a mockup. Not see the shape. Finish the task, with their data, and get an answer they can act on.

That is a much better test than viable, because it is falsifiable. Marta either reconciled her numbers or she did not.

The move

Make everything the user does not touch as ugly as you can stand, and decide in advance the one dimension you will not compromise.

The second half is what stops this becoming an excuse. Ugly everywhere is not a strategy, it is a mess. You pick one property that is not allowed to be bad, name it before you start, and defend it when the schedule squeezes.

Daniel Ek’s version of this, about Spotify’s early years, is the clearest statement of the idea: the obsessive work on latency was, in his phrasing, the V in the MVP. Everything else could be embarrassing. If it was slow, there was no product.

UGLY ON PURPOSE                   NOT NEGOTIABLE

 no pagination, 40 rows max        the numbers are correct
 no empty state                    it never shows a stale figure
 no loading spinner                  without saying so
 dates typed in, no picker
 one hardcoded account list        ^ chosen before day one,
 browser default styling             written down, and defended
 no mobile layout                    when the week gets tight
 no export

 each of these is an afternoon     if this one breaks, there is
 to fix, later, if it matters      no product to be ugly

Write both columns down before you start. The left one protects you from scope, and the right one protects you from the version of this advice where ugly quietly becomes broken.

What it costs

Ugly gets judged, and often by people who will not read your caveat. A screenshot of the left column will circulate. Somebody senior will see the browser-default styling and conclude the team is sloppy. The mitigation is to say what it is every single time you show it, in the first sentence, and to never let it be seen without a human present to frame it.

And ugly things ship. This is the real hazard. You build the deliberately bad version, it works, somebody asks whether it can go out to five customers on Friday, and the temporary version becomes the permanent one with nobody deciding. The left column is only safe if you keep a written list of what is in it, which is the difference between a deliberate first version and technical debt you acquired by accident.

And some products have no ugly version. If you are shipping a payment flow or something a regulator reads, the not-negotiable column is most of the product and this move mostly does not apply. Say so rather than forcing it.

Try this week

Before you write any code on the next thing, make the two columns. Ten minutes, in the ticket.

The left column is everything you are deliberately doing badly. The right column has one item. If it has three, you have not chosen yet, and the schedule will choose for you in week two.

Then show the left column to whoever asked for the work, before you build it:

Here’s what I’m deliberately not doing in the first version, and the one thing I won’t compromise on. Anything in the first list you’d move to the second?

That conversation takes five minutes and it is the entire argument about scope, had once, in advance, instead of four times while you are trying to finish.