Product management professionals are always looking for a way to get to market faster. One common-sense way to do this is to build less prior to market launch. So what’s the least you can possibly build?
Minimum Viable Product.
In the lean startup world, minimum viable product is the smallest possible product built to test a hypothesis and to achieve “validated learning.” If the experiment is to test conversion rate on a landing page, the landing page would qualify as an MVP. But no-one is paying you for a landing page. As a commercial product, a landing page is not viable. Marty Cagan writes:
I refer to that that as an “MVP Test” so that people don’t confuse an experiment with a product.
A more “viable” interpretation of MVP is a very narrow product that solves a specific problem really really well. An example I think of in this category is Dropbox. Dropbox solves the problem of sharing files across machines really well, and is viable commercially as a product consumers will purchase, but requires additional features to fit into the enterprise. Dropbox launched Dropbox for Business to address these needs.
What about Minimum Marketable Featureset?
How well do you have to solve the problems you’ve identified? This is a solution space question, not as relevant for the problem space.
An interpretation of MVP I’ve seen frequently is the smallest collection of features to satisfy the happy path. This often is enough to demonstrate the product to prospects and to install it, but may lack some of the administrative capabilities and exception handling that a client might expect in a robust product.
This is a challenge entering an established space within enterprise software. Enterprise buyers frequently purchase from a feature checklist known as a Request For Proposal (RFP). RFPs are written to ensure the enterprise addresses all the needs of all the stakeholders in the purchase. How will your offering stack up if you respond to an RFP with the limited set of features in your narrow MVP?
It’s difficult to identify and isolate market problems that people will pay to have solved, but that’s not all there is to product management. Thinking of the solution space, they’ll only pay you if the product you offer solves enough of their problem(s), and solves them well enough.
People don’t want to buy a product that doesn’t solve their problem. So should you talk about where your product is going, or what it does now?
Another way of asking is: how much of the problem do you need to solve, and how well, for that solution to qualify as “enough” to your buyer? Perhaps the answer to this question is what defines “viable.”
How much is Minimum in the Enterprise?
As Eric Reis states, “probably much more minimum than you think!” Jesus Rodriguez put this differently: “The Enterprise Minimum Viable Product: Focus on Viable Instead of Minimum.”
If at all possible, create your own product category. If you’re going into a crowded space with existing vendors, there are RFPs and expectations. If you’re creating the first widget of its kind, while there are always substitutes, there aren’t as many expectations about what your widget will do. You can define what that entire kind of product does.
Most companies can’t or won’t do this.
If you’re going to market in an established space, you may be able to sell a differentiated product to early adopters, without adding many of the frills. But to gain market share among the early majority, you’ll need enough features that the early adopters will provide enthusiastic recommendations of your product, and you’ll need enough functionality to meet expectations about the “table stakes” features–things a product in that category couldn’t possibly not have.
Minimally Robust Product
I perceive a continuum. On one hand, the mere ability to conduct an experiment is the least possible “product” one could build, but is so minimal that it’s not sold or bought. On the opposite extreme, is the product with every possible feature and is fully “done” (impossible, of course).
In a mature product space, to appeal to early and late majority buyers and to achieve satisfaction, I propose that you must reach past “minimum marketable” and “minimum viable” and reach what I call “minimally robust.” Criteria for this might include:
- It has to solve key problems, well.
- It must meet the basic needs that buyers won’t voice, because they’d never assume a product wouldn’t solve them.
- It must be stable, implementable and administerable.
Identifying the features that meet those criteria is the fun part! It’s different in every product category. You’ll need to talk to people.
Where to Go from Here?
Once you have a product in market, how do you prioritize what to build next? Here are a few questions to ponder:
- What features will impact the highest percentage of your product’s client base?
- What features will help your implementations and support teams from an operational standpoint?
- What features might help you solidify a narrower path through your product, that can address a more granluar problem that people will pay to solve?
- Are the features your clients are asking for all over the map or targeted in certain area(s)?
- Are the features your clients are asking for validating your vision for the product or suggesting a different direction?
There are plenty of questions to think about, but the first one to solve is how deep and wide you need to go before putting a product in a paying client’s hands.Share this: