45: Three ways you’re DEFINITELY doing MVPs wrong

I’m writing about one hundred things I’ve learned as a product manager.

If one were to heft a half-brick down Old Street in London, there would be high probability of hitting someone currently engaged in building a minimum viable product (MVP) of some sort or another. There’s also almost as high a probability that they’re doing it wrong.  Allow me to explain.

1. The clue’s in the name, people #

What part of minimum breeds such confusion? Minimum means the least amount – of features, time, effort – but still has to be viable – to perform its intended function for the user. As Adam Berrey, author of Startup Blender neatly puts it:

One of the temptations with the MVP approach is to build a bridge that only goes halfway across a ravine and then to ship it so you can get iterative feedback. The feedback amounts to “this bridge sucks” even if a bridge across a ravine is a brilliant idea.

Bridge v1.0 may be rickety with ropes for handrails and only able to support three people at a time, but it just about does the job. You can worry about increasing the stability and the number of users in Bridge v2.0. Cars and toll booths are on the ‘later’ part of the roadmap.

It can be difficult to be objective about what minimum looks like for your product. If you’re finding it tricky to decide what’s most important, focus in on the needs of your primary user. You need to solve one, specific problem for them completely, and no more.

If you’re finding it difficult to decide what’s most important to your users, you could be looking at too wide an audience. Can you narrow down your focus to a smaller, more specific niche with fewer needs?

Perhaps you’re still using intuition and guesswork – although it won’t feel that way to you – to decide the scope of your MVP. If this is you, stop, go find some users and gather hard evidence that the problem you’re trying to solve really matters to them. There’s no point in building Bridge v1.0 if nobody needs to cross the ravine in the first place.

2. Viable also means commercially viable

Your MVP is an advanced test of whether you’ve reached product/market fit, and you’ll know you’re there when people are happy and willing to part with hard cash for your product. If your MVP’s not of sufficient quality for someone to pay for it, it’s not viable yet.

Don’t forget all that discovery and validation you need to do before you get to MVP stage. You need to figure out what the problem is, who has it, and whether they care enough about it before you jump into trying to solve it with a MVP. Similarly, you might need to experiment with specific aspects of the product in prototype stage before you commit to building something and trying to sell it.

Head of Google X Tom Chi spoke at Mind The Product Conference a couple of years ago and described how he knocked together a quick prototype of Glass in a couple of hours using some wire and modelling putty. Before launching into a complex build, he wanted to test how much weight the ears and nose could support comfortably. He learned that the bridge of the nose can support more weight than the ears, which is why his team designed Glass nose-heavy. He also didn’t call his wire-and-putty prototype a MVP and attempt to sell it later that afternoon.

If you’re dead-set on jumping straight into a MVP before you’ve done any discovery or tested any basic prototypes, let me save you some bother. Just send me your life savings or seed funding now, so at least you’ll save your time, if nothing else. I promise I’ll invest your money wisely.

3. Who said MVPs have to be code? #

So many apps these days are automating real-world services. Uber is the digital equivalent of your PA or your hotel’s concierge hailing a cab for you. Tinder is the digital equivalent of your well-connected BFF who repeatedly pimps mutual friends to you.

What people tend to forget is that if the underlying service concept is flawed, turning it into an app is not going to suddenly make it succeed. In these situations consider using a concierge MVP: run the service manually using a phone and spreadsheet (or whatever) to establish whether the concept works, then automate it in an app once you’re confident it’s worth the investment.

Remember that people don’t use the app primarily because it’s an app – they use it because it allows them to achieve their goal more conveniently, quickly, easily, cheaply or at greater scale, whether that goal’s finding a cab right now or hooking up with someone purely on the basis of their looks. (Tut. You shallow so-and-sos.)

Parting Shot #

Whether you’re a developer-designer capable of throwing together functional prototypes in a matter of minutes, or considering spending months building your MVP in secret, take a little time first to figure out whose problem you’re trying to solve and whether they care. It could save you making an expensive mistake.

2 thoughts on “45: Three ways you’re DEFINITELY doing MVPs wrong

  1. Great post! A lot of companies lose track of what makes a product “viable” to their customers, and as a result they release something that doesn’t meet their customer’s minimum requirements.

    It’s key that you find out what your customers would consider an MVP – if it’s coming from someone within your company, it’s quite likely to be incorrect!

    • Thanks Chris, glad you enjoyed the article. When thinking about ‘minimum’ and ‘viable’, you have to set the bar for your MVP in terms of what your user and market research has uncovered, reading between the lines of what your customers are asking you for. You’ll know you’ve got ‘viable’ right when your users grab the product out of your hand and can’t see themselves being happy working in the old way now that they’ve seen your way of doing things.

      If it’s not immediately clear from your research at the outset what the smallest, cheapest, quickest thing is to satisfy at least one user need, then you can also figure it out as you go along. Achieving ‘minimal’ comes from having small enough increments between iterations of your product. Make your product in increments that are too large and you’ll probably overshoot and build too much. Smaller increments will allow you to ask, “Is this enough?” at every stage, so you’ll have more chances to spot when your product has switched from being ‘not viable enough’ to ‘viable’.

Agree? Disagree? Join the conversation: