Product development musings:
Being in London you often speak to people about their new web startup ideas. Often these are early stage and out of interest I ask about their MVP (minimum viable product).
When their MVP has not yet been defined there is often some confusion about what it might look like, and too often the MVP is the fully blown, all singing, all dancing solution, essentially every idea the team has come up with, i.e. far from the MVP.
There is a lot of information on the web about the definition of MVP and I am not going to rehash it. I personally prefer Marty Cagan's description of MVP:
people choose to use it or buy it; people can figure out how to use it; and we can deliver it when we need it with the resources available – also known as valuable, usable and feasible.
With these words in mind, all those extra customer facing bells and whistles (features) on the wireframes seem less and less important (anything retained must somehow be critical to the above). Using a very ruthless mindset one will often find that a large percentage of what was originally wanted is not MVP and many things that one didn't think about are.
This got me thinking: if Mangrove Root was ever involved in defining a MVP with a client how might I encourage them to be more strict about their definition.
Ideally before starting the following, some tests and market research would have already been done to validate your idea. Maybe, for example, an 'MVP Test' as Marty describes them or something more in line with Eric Ries definition of MVP of
allows a team to collect the maximum amount of validated learning about customers with the least effort
You can't make "people choose to use it" if they definitely don't want it!
There is nothing new or clever here, it is really just a proposal to force more structured doing.
It seems reasonable that defining a MVP should be a process which is time constrained, (you can't sit around thinking all day, you need to get doing!) and naturally it is important that the execution of the MVP should also be time constrained. The MVP of each new business will invariably vary massively in requirements and thus the time scales would need to scale accordingly, but for most small new startups (say marketplaces) I believe this could work.
- Get together the minimum viable set of people (say the founders, head of product, the head of Ops and a tech person) for your business to have a holistic view of the business.
- In only 1 day define the MVP.
- The goals are to define what is needed to meet the description of MVP as above.
- Every person in the group brings to the table what they think is absolutely critical to the viability of the product. They should be prepared in advance.
- The tech representative also provides the necessary feasibility and estimation of implementation time. Of course estimates maybe wildly off so it is imperative to be conservative.
- The MVP must be defined such that it can be delivered in exactly 2 weeks from the end of the meeting.
- This doesn't mean hire many more resources to force the deliverable, it should be estimated on the assumption of say 2 developers, 1 designer/UX, and the remaining team as described above. Remember this is not just 2 weeks of developer time, this is 2 weeks of everyones time. Hence the more solutions which require no coding or other domain knowledge, the better.
- When I say deliver, I mean also launch. No weeks of 'stealth mode' post MVP completion. Do it and get it out there.
The most important thing of the time constraints is that it will force the most critical features for each core business area to bubble to the surface. It is too easy to forget that the MVP is not just a 'minimal' solution but must also be 'viable'. If you have an extremely manual and Ops heavy product, maybe the the MVP must also include tools to help them do their job efficiently?
The resource constraints also put you under pressure to find clever and low cost (in time and money) solutions to getting the MVP ready, for example see how OpenDesk are using Podio to deliver their MVP.