I once had a client four months into an MVP project when, during a meeting, we discovered half the team didn’t know what an MVP was, or even what the initials stood for. This is a guide to help non-startup companies align on doing MVP and reaping the benefits of it.
Before going any further, two quick things:
- I bear some responsibility for letting things get to that state. Reminding people of new concepts is a critical part of helping teams tackle new challenges.
- Teams and companies need to make sure they’re creating cultures where people are allowed to say “I don’t know” and “what is that” and “I hear you saying words, but I still don’t know what we’re talking about.”
That said, it’s a good reminder that many of the groovy startup words out there today sound so good that people will embrace them before they fully understand the underlying concepts – or the hard work that go with them. Think about it – who doesn’t want to be agile and lean? Would anyone ever choose clumsy and flabby? While it’s great to have power words that convey benefits so clearly, the power of those words glosses right over the embodied complexity.
This problem is exacerbated by the fact that most MVP/Agile/Lean material is written and taught by and for start-up folks. These are bright, talented people, to be sure, but they’re usually insufficiently aware of the challenges that existing enterprises face:
- an existing customer base that must be provided for
- existing work processes that have been optimized for a different business
- incentives that don’t support innovation, moving fast, or breaking things
So, here’s a quick guide to MVP, the “minimum viable product” approach that is too often too quickly celebrated and often fatally misapplied.
Defining MVP
It’s really valuable to work with tight, but rich, definitions of complex concepts. Eric Reis’s definition of MVP is a great start:
“A Minimum Viable Product is that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.”
The driving force behind Reis’s lean movement is to make sure start-ups don’t run out of resources before they know what customers want. Build as little as possible against what you know, learn what you don’t, and have resources left for the inevitable adjustments or pivots. This is even more crucial for already operating businesses, since their resources are considerably less flexible than startups: 1) they have precise and hard to change budgets; 2) staff are allocated against many more projects and initiatives than start-ups; 3) most staff aren’t up for 100 hour weeks fueled by take-out and soda.
So this is a great definition but has two critical but easily overlooked concepts: (1) be fanatical about building as little as you can to (2) learn as much as possible. Steve Jobs’s line about focus is as equally important as any definition of MVP:
“People think focus means saying yes to the thing you’ve got to focus on. But that’s not what it means at all. It means saying no to the hundred other good ideas that there are. You have to pick carefully.”
And this is where enterprises struggle with MVP. Saying no is always the hard part of a project. For enterprises, where mounting big initiatives takes a lot of work and there’s a natural desire to “only do this once”, it’s almost completely counter-intuitive. Saying no requires nerve in the face of uncertainty, ruthless killing of darlings, and courage despite the lack of visibility into what is possible next year.
To help manage this, in longer MVP workshops, we work through three categories of features that any product or service needs to consider:
Column A is the essence of what the minimum offering of an MVP should be. Column C – because you haven’t thought of it, or you’re aware that you can’t achieve it – is a mercy. You can take that stuff off the table with little fuss. It’s important to bring it into the conversation, though, as a reminder that you always want to have resources available for opportunities that arise – a new idea, a better technology, something the competition has and is quickly becoming table stakes.
Column B is the place where companies – start-ups and existing companies alike – fail. Every dollar and minute of attention spent in column B – stuff that you aren’t absolutely required to do – comes at the direct expense of: 1) making items in column A better or, 2) what you can do after launch. You shouldn’t/can’t/mustn’t do column B things, but groups invariably struggle with not doing them. Often people will struggle to make the case that they belong in Column A.
So the key challenge of a well-executed MVP at an existing company is to make column A as small as possible, and make column B as big as possible.
To shrink Column A we suggest that teams list all the features and ideas under consideration and ask the following questions:
- Is it possible to delay this feature? Can we envision an end user having a valuable experience without it? (Think of a commerce experience, where many items are not deferrable: cart, catalog, checkout, customer service, etc. Notice also that we say valuable experience – we’re not asking for subjective assessments of “good”, “first-in-class”, “kick ass”, or “crushing” it – we’re asking if we need that feature to provide real value.)
- Is there a real risk of not doing this feature until a later date? Will we lose customers by not having it? Will a competitor steal customers by offering it before we do?
- How quickly can we create that feature if we delay launching but it turns out we need it?
Question #1 should be a straightforward question, but there are genuine grey areas where it’s hard to make a call. It gets even harder if you have team members, or senior leadership, who is attached to or perceived as attached to a particular feature or idea. Teams should push hard on the core benefit of deferring a feature or idea: it leaves you resources for improving the product after launch and after you get real feedback from your market.
Questions #2 and #3 are designed to help people get comfortable with saying no. The FOMO on a feature can induce genuine panic and real queasiness. These questions help people see that the business won’t fail if you have to add something back in, and that you can do so within a reasonable period of time. This should help move a lot of items to column B.
To operationalize this, dig out the Post-Its (big ones, so you can capture comments and put labels on them) and start working through what you have to do (which are in MVP) and what you could do (which are out). Use the questions above so you have contingencies for the deferred ideas. Then and people can get good nights’ sleep and focus on making the have to dos truly great.
There’s a lot more to cover in MVP, but this should be helpful in really sticking to the M.