In August 1628, Swedish warship Vasa set sails and left Stockholm for its maiden voyage only to founder after sailing one kilometre, killing 30 souls. It had taken two years to build and was heeled over by a light breeze, being too top-heavy. The project was ambitious, to begin with, and there has been speculation about whether the initial plans were modified to add more features on the fly.
I have a track record of pissing off salesmen in the company I work in. I've done this by telling a potential customer that they should actually scope down their idea and release an MVP (Minimum Viable Product) first. I get it — to a sales-person, this might sound like throwing money away.
Obviously, I disagree. Small iterations just make so much more sense business-wise, and they are also easier to implement. This means reaching deadlines, manageable expectations and faster go-live and user feedback. In other words, higher customer satisfaction. Which leads to better and longer lasting customer relationships.
Below is a brilliant image of the MVP approach by Henrik Kniberg.
This image has received a lot of criticism too. I've heard comments like “sometimes a skateboard just won't do, you need a car.” They are right, sort of — the example only works if the business problem is about moving people from one location to another. But if it is, it really captures the essence of MVP thinking.
Let's say each iteration takes one month to build. This means that in the not like this example the person is still in the original location and the like this guy is far, far ahead after 1 month of skateboarding, 1 month of scootering, 1 month of cycling and 1 month of motorbiking. I think you want to be that guy, way ahead of your competitors.
Another detail that is often missed from the picture is that the two cars on the last stage look different: The other one is a 4-seat family car and the other one a 2-seat convertible sports car. This is because at stage 0 when they planned the whole thing, they didn't know how many people they need to transport. So to be on the safe side, they decided to have seats for four people, even though they knew that in the first phase they only needed to transport one person.
In the second example, they acted based on the data at hand: Build a minimum viable means of transportation for one person. At some point, they needed a seat for the second person, which was possible in stage 4 or 5. So not only the like this people are far ahead, they also have a better car for their needs.
Other people don't like the MVP approach, because they, in their words, don't want to release crappy products. This is a common misinterpretation, which I think is brilliantly corrected by the image below (compliments to Aarron Walter).
The idea is not to implement features half-assed — the idea is to release fewer features and more often. While you should always aim for success, if you fail, this way you'll fail fast and can correct your mistake in the next iteration. Warship Vasa would have, mildly put, benefited about this approach. Starting with fewer cannons and other top-heavy features would've most likely revealed the ship's lack of initial stability without a total disaster.
While you might be nodding in agreement right now, this is very hard to do in practice, especially in large organizations that are used to the waterfall model. It's also hard if the product has several stakeholders, each thinking their business need is more important than the others. It requires some hard decisions on prioritization and in some cases splitting one product into two.
There's an old saying about customers knowing what they want but not what they need. Same applies to stakeholders. The hard part is to steer the focus away from the how (buttons and features) to the what (business needs). Once those are clear, the implementation should be relatively easy for a digital product studio.
Don't go waterfall.