ROSL100: Is your Minimum Viable Product (MVP) actually just Minimum Product (MP)?

ROSL100: Reflections on Startup Life, Week 100

Since launch, Alex and I have always considered ourselves fairly lean minded (as in “lean startup methodology”). It’s not been a formal thing for us — we don’t really think about it that much, in the same way we don’t really think about breathing. It’s just what we do (which is not to say we are experts — a heart and lung doctor is probably an expert on breathing, I just breath). Some of that is driven by a natural resource constraint, some of it from experience gained in the last 24 months; we’ve become very good at kicking the tires on ideas quickly (or in Lean speak “Minimum Viable Product”).

But are we really doing it?

Last week I sat down as a mentor with PushStart and enjoyed chatting with other entrepreneurs that were earlier in their cycle than us about what they should be doing. The common thread was generally “market test your idea — get out a minimum viable product”.

As an example (without naming names or ideas), one person has an interesting idea for automating an expert skill for a particular industry niche. While he’d chatted to quite a few people in the field, the thing he really needed to do in my opinion was to validate that people would actually pay for the idea (everyone is quick to say “that’s nice”). Because he’s automating his skill, the easiest test of this would be to just find a customer willing to pay for him to apply his skill manually (but at the discount price).

He’s also has a core assumption which is that by applying his skill to the task you’ll get a better outcome. Manually testing his concept provides a nice proof point because it’s possible in this instance to A/B test the return against the industry norm.

Before writing (or paying for) any code, simply testing it like this proves two fundamentals of his business idea very quickly:

1. Will someone pay for it?
2. If they do, do they get a better outcome?

The objection to this which is pretty standard, is “but that’s not what I’m doing”. In this case, he’s not actually selling his personal skill, but rather the “automated” version of it. My feedback on this was simply to think of it like a series of hurdles to the final outcome.

If you can’t clear the first hurdle (selling your expert manual skill for the discount automated price) why do you think that people will suddenly start paying when you’ve spent all that money on automating it (on the assumption that the manual skill is probably of high or higher quality). Equally, if the core assumption is that this new approach is better, you’d better prove that in the market very quickly.

I then went on to say that of course once that’s proven, you’ll lift the bar. Each hurdle gets harder to jump. We shouldn’t confuse this very early minimal prototype with the actual product.

One of the reasons I love mentoring is that I learn as much from it as the people I mentor.

Have we been lifting the bar on our ideas? With the latest release of http://trunk.ly we’ve realised that actually for a while the answer was no.

For the last few months before this latest release we’d actually been delivering a “minimum” product, not a “minimum viable product”. We hadn’t adequately scaled our definition of an MVP as we’ve acquired customers. In many ways we were still behaving like we had a few hundred users.

That picture is from this post http://radoff.com/blog/2010/05/04/minimum-viable-product-rant/ and I realise (as is always the case on the Internet) that I’m not the first to reach this point! In fact that’s an excellent read… the key point is this:

The goal of a startup is to find the sweet-spot where minimum product and viable product meet–get people to fall in love with you. Over time, you listen to your customers, make improvements and raise the bar on what viable means–making it more expensive for competitors to jump in.

As your product grows, what constitutes an MVP needs to grow with it. Yes, you can still probably get away with things like links that go nowhere and measure clicks to test if users want features, but if you chose to deliver the feature, it has to match the user expectations that are dictated by the lifecycle of your product.

MVP is a valuable tool and something we still live by. But we’ve realised two important lessons.

1. You don’t have to be Feature Rich, but you do have to be Feature Perfect (if you’re going to do it, do it right).
2. The definition of Feature Perfect grows with every new user. Mockups are great for users 1–10, but won’t get you to user 10,000. In the same way, a poor UX might get you a few thousand users, but won’t get you the growth you need to get to 10’s of thousands.

To finish on a positive note, we’ve caught up, we’ve addressed it and our Feature completeness does more or less match where we are at and we’re reaping the benefits with better user satisfaction, better feedback and higher growth. And we’ll keep iterating and doing more. The question is simply how many more users might we have if we’d done this sooner?

My reflection for you — ask yourself, are you delivering MVP or have you slipped into delivering MP only?