If you are involved in developing digital products or businesses (be you an agile developer, big-company product manager or bootstrapping startup founder), you have probably heard of the minimum viable product (MVP) approach to product development and iteration. Eric Ries popularised the term as part of his “Lean Startup” movement, defining it thus:

The 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

Lean startup and MVP theory started as a response to the “big bang”, capital-intensive approach taken by many businesses (especially VC-backed startups and public companies) to developing new digital products. The observation underpinning MVP is that pre-guessing what customers will want and building a big bang product to meet all of those expectations is risky – because only by interacting with those customers can you really understand their needs and thus what your product should do. As the Prussian field marshal von Moltke put it first:

No plan survives contact with the enemy

The danger of the big bang approach, then, is that you discover your customers’ needs far too late: instead of steadily iterating a live minimum viable product towards optimal product-market fit, you are left needing to drastically re-build your product – often at great cost – to finally start meeting those customer needs that you just discovered.

At Keplar we are strong proponents of the data-driven, iterative approach designed around an initial minimum viable product. It’s certainly a methodology with strong opinions – and not always comfortable ones for clients grown used to the big bang approach promoted by full-service agencies and IT consultancies. But the fact is that those big bang projects often fail, and as a methodology which seeks to reduce capital expenditure and maximise the product’s customer appeal, the iterative MVP-based approach is an increasingly compelling one.

Where, however, we see a lot of room for confusion is in what actually constitutes “minimally viable”. Part of the problem here is that much of the thinking about MVP has come from lean startup practitioners who have a few traits in common:

1. They are often launching products into “blue ocean“ market spaces where no real competitors or proxies exist
2. They often have no prior expertise in the relevant sector (e.g. fashion, education) or function (e.g. analytics, online retailing)
3. As technologists they rarely have backgrounds in customer-facing roles
4. They are often planning to grow using fixed-cost marketing channels (word-of-mouth, viral features, SEO) rather than cost-per-user channels (SEM, display advertising, affiliates)

Taking all of these factors together, you can see why the minimum viable product for many startups is quite, well, minimal: there’s typically very little that the founders know (or can know) about the customer needs – and thus the product – before they launch. Furthermore, with a “blue ocean” product launch a startup isn’t too worried about disappointing customers with too little functionality – because some functionality is better than none. And finally, even if the initial launch product does prove a turn-off for some customers, the use of “lean” fixed-cost marketing channels means that there is no direct financial loss incurred from failed customer conversions or user churn.

For established, experienced businesses not launching into blue ocean markets, we believe that the minimum viable product is actually much closer to 70-80% of the hypothetical end product than it is to a lean startup’s 30-60% mark. This is because businesses such as these tend to diverge from lean startups on all four of the traits listed above:

1. Established businesses are rarely undertaking all-new, blue ocean product launches – instead, brand and product extensions, ”fast follower” copycat launches and new business models for existing products are the order of the day. In all of these scenarios, the company is competing with other players (and sometimes even with themselves) – so the launch product has got to pass the customer’s crucial “smell test”: is this product a credible alternative to the others on the market that I could use?  And if it doesn’t pass that test, then the company can’t start collecting the behavioural data from customers that it needs to iterate the product further
2. Established businesses typically have significant sectoral and/or functional expertise – and they can leverage this domain knowledge about their sector or function to significantly reduce the number of unknowns that require testing with the MVP. To take the example of an accounting software provider looking to launch a new hosted SaaS product: they already know exactly how the core product should work, so where they will need to iterate post-launch will be largely around pricing and the potential new SaaS-only functionalities (e.g. hosted backup, online collaboration)
3. Established businesses already have a good understanding of their customers’ needs – of course an established business has far less to discover about their customers’ met and unmet needs than a new market entrant; moreover their existing customer relationships often enable them to test customer attitudes to a potential new product prior even to designing the MVP
4. Established businesses will often put significant marketing spend behind the new product – to establish the new product in the market and acquire users, companies will often commit to a significant marketing spend on SEM, display advertising, affiliate marketing and similar. However if the MVP is too minimal and doesn’t pass the customer’s “smell test”, then that marketing spend is effectively wasted – and in fact might even translate into negative word-of-mouth for the company’s brand

Putting all of these reasons together, it is clear why for many companies the minimum viable product will actually be a semi-complete product requiring a considerable development effort. This MVP should not however be confused with the big bang approach, because there is always a gap in customer understanding which requires data-driven investigation and product iteration post-launch. And in fact the increased capital investment in bringing a 70-80% functional MVP to market makes the post-launch approach to iteration and optimisation even more important.

To summarise, at Keplar we believe that for many businesses operating in (or moving into) established markets, it makes more sense to design, build and launch a “Minimum Sticky Product”. We would define this “MSP” as follows:

The minimum sticky product is that version of a new product which allows a team to gain traction in a “red ocean” market and close the gap in customer understanding with the least effort

A minimum sticky product, then, is one which is just good enough that customers stick with it in the face of competent competitors – in other words a product that starts to get traction in the market, which collects that crucial behavioural data from customers and which can justify per-user acquisition marketing thanks to low initial churn. If you’re already building a minimum sticky product like this, let us know in the comments below!

If you are developing a new digital business or product and would like to talk further about designing, building and launching your “Minimum Sticky Product”, don’t hesitate to get in touch.