As per the last time we spoke, your MVP is a big deal. It’s not the first thing in the process (that would be learn), it’s not the prototype and it’s not a mini-version of the final product.
It’s a product for testing your hypothesis.
There’s some arguing within the lean camp about what constitutes an MVP. Some say it can be anything — even a landing page . Others say, hell no! it’s gotta be a product . We shrug our shoulders. It’s arguing over semantics, because Steve Blanks says every hypothesis needs its own MVP .
It’s that first MVP that gets ya. That’s the one that has the power to grow or utterly crush any hypothesis. Which — let’s be honest — is a little intimidating. The good news is that once the MVP is built, your learning amps up tremendously and things begin to look a wee bit clearer.
Some lean entrepreneurs will tell you that your first MVP should tackle a risky assumption . In fact, they advise, try to make the MVP fail (“fail fast, fail often”). This way you minimize waste and if it succeeds, you’ve passed a major hurdle. Others will tell you that your first MVP needs a killer feature or it ain’t jack. Both suggestions are good, but again, semantics.
The lean process never endorses failing for failure’s sake . It’s all about validated learning. The only caveat would be that if you are destined to fail, despite working smart, then failure in 3 months is better than 3 years. As for killer features, lean is agnostic to coolness andtechnology. If it takes adding X,Y, Z features to your product in order to test a hypothesis, then that’s what it takes. But if you discover that you can test the same hypothesis with an etch-a-sketch , do that. Killer featured be damned.
Working beyond what’s required to start learning is a big fat waste of time!
Your first MVP is a reflection of how well you’ve understood the customer’s problem. To avoid waste, hold off building until you can answer these questions:
What am I testing? — that is, what’s my hypothesis? Ideally, for your first MVP, the hypothesis should fit into a single question (e.g., “Would insurance companies pay us to manage their benefits?”). The answer to your hypothesis should be simple as well (e.g., yes/no, black/white, up/down).
You might find Amazon’s “trick” for product development helpful for framing your hypothesis. Here’s how it works. The product manager writes a mock press release about whatever cool new idea the team decides on. He or she will then iterate on paper until the benefits of this new product are succinct and exciting. The mock-up is then tested with real customers to gauge their reactions.
Now, if you’ve read more than a few corporate press releases, you know how utterly forgettable most of them are. They suck! But if you do like Amazon does with press releases (write an awesome grabber headline, addressed to the market you’ve researched, and fill the body with benefits), you’ll come up with a lot of cool features from which to work backwards. The end of the road is the first hypothesis you test.
How will I measure it? — that is, which metric you use. If your customers use your product as expected, this shouldn’t be hard to figure out. To minimize the risk of user malfunction with your first MVP, ask yourself these three questions :
What business am I in?
What stage am I in?
Who is my customer?
Of course, in the startup world, stuff happens, and your customers might do things with your product that you never accounted for. Don’t kick yourself… it’s all good if you learn something from it.
What will determine success? — speed is a major component in lean methodology. You want to run through the learn-build-measure loop as often as possible until you’ve achieved product market fit.
So, with your first MVP, you’ve gotta draw a line in the sand. Once you’ve answered your hypothesis with a “yes” or other affirmation, move on to the next test. Time is money and you either make it to product market fit or you die on the vine.
What will determine failure? — sometimes even entrepreneurs with steel backbones and the drive of a horse crumble in the face of a failed hypothesis. ”Let’s just give it more time.” “We need a bigger sample size.” “We need to market it better.”
If your product has any chance for success, you’ve gotta be ready to accept failure. Dust yourself off and move on to the next hypothesis.
Can I explain my user stories in one sentence? — if you can’t, you’ll be tempted to build too much. That makes a lot of MVPs … umm, not viable. The structure for a user story goes, “As a <user type>, I want to <action> so that I can <achieve this result>.
If you find it hard to put user stories into simple sentences, try creating a story map . You can generate one by defining your goal for the product and the steps needed to achieve the goal. You add features for every step in the workflow. Once you’ve done that, prioritize the features. Slice off the top layer of the map (the workflow runs left to right), and shazam! there’s your MVP.
Can I explain what I know about a market or problem in one sentence? — this is a problem for entrepreneurs with expert knowledge of the market they’re working in. They might be tempted to build too much in that first MVP because they think everyone else in their market is exactly like them. The key to avoiding overbuilding is clarity. If you know your $h*!, then you should be able to explain in child’s terms what problem your MVP is solving for.
Would someone pay for this? – In this age of companies with no revenue stream or profit valued in the gazillions, asking yourself whether someone would pay for your MVP probably sounds like an irrelevant question. “Who cares if they won’t gimme money for it now, they WILL in the future.”
But this type of thinking goes against the “V” in MVP. Your first product is supposed to viable from a business perspective. Which, funny enough, seems to answer the previous argument about the MVP definition (i.e., would anybody pay for a landing page?), but I won’t go there. I don’t wanna get my ass kicked by any Buffer groupies.
Anyway, Steve Blank (what, him again?) said a startup is a temporary organization designed to search for a repeatable and scalable business model . I don’t want to mention any names ( Reddit ), but if you’re not thinking soberly about market with that first MVP, you might never get it right.
So working through the business model canvas with money on your mind is a great way to choose your first hypothesis/MVP:
value proposition
customer segments
distribution channels
customer relationships
revenue streams
activities
resources
partners
cost structure
Look, startups are confused places. Nobody can tell you what your first MVP should be precisely because they don’t know what you know. That’s why you should be wary about “hacks,” best practices, and origin stories. Even if everything you read about other companies is true — and not exaggerated for drama’s sake — your situation is at least slightly different.
Suppose while building your MVP that you’ve discovered that you’re not really a startup? You’re actually a “regular” business for which there’s already an existing market and solution. It happens. Does that mean you’ve failed? Should you be upset about the wasted time, effort, and money?
Uh uh. You should celebrate! It shows that you really DID learn, discover and think through the problems starting from your customer’s vantage point. The world would be a better place if everyone were so diligent!
At New Haircut, we design and develop web & mobile apps your customer will value, and ultimately, pay for. Give us a shout if you’ve got a hypothesis in need of being vetted and MVP’d.