Decoding the Viability in MVP

Minimum Viable Product was perceived by agile/lean management champions like Frank Robinson, Steve Blank, and Eric Ries. The basic premise got acceptance with the agile process model of product lifecycle. Build fast, release fast mindset. There is always something in the market to test the market than hypothetical assumptions. We are talking about a decade of history from 2000–2010. In the past decade, there has been a plethora of jargon shopping in product definitions. Every management school of thought (not to be confused with academic management schools) is trying to pursue their value addition to the product definition. Their approach and arguments are all very relevant. But they are just fighting for the mindshare of the product and management leadership. Have you heard of these terminologies? Sales Ready Products (SRP), Minimum Marketable Product (MMP), Minimum Loveable Product (MLP), Minimum Delightful Product (MDP), Minimum Awesome Product (MAP), etc. You will see one or more of these definitions online if you Google around. And all of them are valuable in their own right, yet should we not focus on more fundamental principles than jargon shopping?

The RoI Conundrum

How many times have you heard in your professional career we had a great return on investment (ROI); we do not invest in that area as there is no ROI, etc.? Did you ever ask what is meant by RoI? There is a return for an investment, and someone has invested some funds. The return over investment ratio is ROI. No single ratio in management literature is an authoritative representation of ROI. ROI is a contextual ratio. Here are some scenarios.

• ROE — Return over Equity — If you are interested in stock markets, the return is profit after taxes (PAT) or the bottom line of the P/L statement, and the price of equity is the price of the outstanding shares in the market.
• ROA — Return over Asset — is an efficiency ratio used to assess how well the company utilizes its assets. Return is PAT, and Assets are the total assets.
• ROCE — Return over Capital Employed — is used to measure the efficiency of capital-intensive organizations where we want to assess the profitability irrespective of the investment being debt or equity. The return here is Profit Before Interest and Taxes (PBIT), and the Capital Employed = Assets — Current Liabilities.

One can be further creative in defining the ratios as the market value of assets vs. book value and calculate their ROI metrics. While these financial ratios are not essential to day-to-day PM function, the intent was to apprise the role of context in applying principles. For example, if you reuse a part of the old product that is written off in the books in your current product, you may not have to consider that as an investment as that is a sunk cost. Just like financial management principles like ROI have context, the Minimum Viable Product (MVP) is context-dependent.

The Minimum Viable Product (MVP)

The Minimum Viable Product (MVP) has three words fulfilling specific requirements.

• Product — In the previous five series article on “What is a product?”, we saw products provide differentiated value to a customer set with scale.
• Minimum — This essentially says just enough to have a stakeholder for the product development. The stakeholder need not be a customer.
• Viable — This is a term that is sensitive to the context. As the context changes, the definition of viability shifts, and so is our product definition.

The current article is about such context and the associated viability of products. Viability can change with product and organization lifecycle.

Concept Viability

Concept viability is the first phase of a project. Most of the time, we focus on only this aspect of MVP and get misdirected toward stating MVPs are not good enough. The concept can come from anyone in the organization. When an engineer is driving it, she may quickly put together a running demo and present it to a sponsor like a product manager or BU head for sponsorship. A product manager can propose a business case, a UI designer a UI mockup, or a strategy consultant a business proposal with business viability. Depending on the sponsor, you have a different MVP deliverable. Or, you work as a team and create a pitch for an investor with all the above components. You have a hypothetical customer in mind or a few early adopters who have given you some idea of what the product does. The scope is clearly to get the mindshare of the investor and not to sell this product in the market.

As a product team, you gather a customer requirement and consider it a use case fit for your product. Then you talk to a second customer and hear from him some orthogonal features and add to the product. You have two feature sets and are trying to sell them to a third potential customer. You name the product an over-encompassing name, but the industry has a well-defined category for such products. Suppose I developed an HTML viewer for a customer and called it a browser. Naturally, people will have expectations of its supporting the JavaScript, CSS, XML, etc. It can support protocols like HTTP, HTTPS, FTP, etc. Even if it was a minimal idea to render just HTML as an MVP, the expectation for everyone is a complete browser product. If you have built an MVP and are testing, focus on the customer set who can appreciate the features. Generalization can only give the product the wrong attention, leading to failure. In my example, I should have named the product an HTML viewer and focused only on a customer who can value such a feature. What if no one picked up the product? Wind up that MVP and try another one.

Competition Viability

Have you heard of Zeno’s paradox? Achilles, the fastest Greek runner, cannot reach Olympus as he has to cross the mid-point. If you start subdividing, you realize there are an infinite number of such mid-points. Hence, Achilles can never begin. Forget his reaching the destination. The other day, I read a research report from a group of student interns suggesting we will not be competitive as our feature set does not include the most common feature offered by other players in the space. Our fundamental value proposition was not to provide that feature as it was limiting and introduced a new set of features. MVPs are meant to understand the market and not to be competitive in selling to every competition out there. Secondly, to make an MVP feature-by-feature competitive, you should focus on building a feature-loaded product, which may take several years. MVPs are like the David. You do not take them to fight with the competitive Goliaths.
Rather than going head-on, introduce a flank attack with competition. Make the MVP with all those features that the competitor is not good at and provide minimal features surrounding it so that customer needs of a class of customers are met. Show the benefits rather than bringing the competitor into the discussion. Further on, if you have another product already in the market, use those benefits to offer the new MVP as an add-on.

Sales Viability

Sometimes, the products are liked by the customers when they use them. But, the sales cycle takes long. Each deal requires a lot of iterations, involves the technical sales team, the customer does not understand the product until they try a proof-of-concept, the sales team cannot explain the product, there is too much handwaving happening at the meetings, etc. The other day, I heard a marketing manager lamenting the most significant aspect of their product was the architecture. There was no way to explain these to the potential buyers. Come to think of it, does a customer care about the product architecture and will pay for it? Sales Ready Product is one concept where a lot of focus is on the customer’s primary use case, the demos created to address those, the customer interviewed for addressing her objections, etc. The idea is to ensure that the sales cycle is compressed. However, the primary question is, do you have a product or a collection of MVPs discussed across multiple customers? Secondly, designing a product for sales experience only does not lead to great products always. In a workflow product development, we created elaborate wizards to enter the customer data. It looked cool when the sales engineer presented it to the customer. However, when the customer in production wanted to enter data, he scanned a QR code. Where should we have focused more? Making products easy to sell is just one of many battles and not all of it. Third, do you have a representative sample? You have a prospect who wants to buy your product, but all the use cases you discuss with him are not where your product vision in the long run is directed. Will you spend the energy in aligning your demos to prospect’s use cases in a big way? You have two options: change the product vision or do not plan too long ahead with such a prospect. Both are perfectly viable options. What is not viable is, not to change the vision and support such a customer in the long run.

Life Cycle Viability

There is a general feeling that MVPs are for new products. What about the later versions of a product? Can you need an MVP for version 2.0 of the product? Think of Adobe or Microsoft deciding on taking Acrobat or Microsoft Office to the cloud. They already had a base of millions of users on desktops, and they could not have asked to move everyone to browser-based software from tomorrow. They could have done it, but they did not. And it is good that they did not. Every significant change to a customer experience leads to the customer looking for alternatives. Some customers leave the platform during these phases. Adobe’s PDF document creation and manipulation (Acrobat or today, known as Document Cloud) has five parts.

1. Creating PDF documents
2. Reading PDF documents
3. Manipulations of PDF documents.
4. Document workflows
5. Sharing of documents

Adobe Reader allows reading PDF documents for free. In 2008, Adobe made the PDF standard an ISO standard. So, they commoditized creation. The Acrobat product manipulates PDF documents and requires a lot of graphics and user manipulations, and moving that all to the browser may have been hard when the document cloud was perceived. Adobe took a step-by-step approach. They had created server products for document workflows and PDF creation. The Adobe Reader and Acrobat for PDF manipulation remain desktop software. Once they had server products for the creation, workflows, and sharing of documents, they could launch the document cloud product without a big-bang approach of moving everything to the cloud initiative. Introducing a small change for one small group of customers while the larger audience remained unaffected by incremental changes. Think of a scenario, when I see a link in the Adobe Reader to upload a Microsoft Word document to generate a PDF, it is just for a user who is not an Adobe Acrobat customer. If I click, I become a customer of Adobe Document Cloud. It does not affect the Adobe Acrobat customer at all. Microsoft did a very similar initiative for their Office 365 initiatives. Introducing incremental test MVPs as they took one market after the other into their larger product portfolio of Office 365. Compare this to Windows Vista and Adobe Indesign, which took over seven to eight years of development cycle. And, the initial versions of both the products were unsuccessful in attracting customers. Today in the cloud world, with incremental development they are consistently able to retain existing customers while addressing newer markets.

Timing an MVP

We know MVP is a tool to test the market, but when should you introduce it? The Practice of Product Management will introduce an MVP in two places.

1. When you are assessing the market to introduce a product.
2. When you are deciding on the features of the product.

You will do step 1 during the strategy phase and step 2 in the product vision phase. In the strategy phase, you assess all the five forces affecting your business. An introduction of MVP here will not only question the technical viability of the product but also talk about market dynamics like sales, marketing, customer, pricing, etc. Here, the question can be: are we equipped to introduce a product for this market? Let’s test it out with this MVP. When you have an MVP during the product vision phase, the questions are: we have these features, but will they be liked by the customers? The MVP is more of an add-on to the existing offering you have.

Conclusion

MVP is a very potent tool in product management. Used effectively, it can help understand the market, fail early, and take course-corrective action while not derailing the existing business. To effectively introduce the MVP, you need to assess what part of the business you are testing the viability of. Shopping for product definitions and stating MVP is not a good enough solution is a premature assessment of the effectiveness. We picked up a small subset of viability assessments in our examples. Explore further and add more cases as you will like. Please comment on how you assessed the viability of business cases in your organizations using MVPs.

Note: Sambit Kumar Dash is a founding director of Lenatics Solutions Pvt Ltd, which provides product management services to businesses for Sustained Competitive Advantage. You can reach him at: sambit@lenatics.in