Author: Thiyagarajan M

You may find it useful to read the previous post on importance of ambiguity tolerance and questioning for an engineer transitioning to a product guy before reading this post.

When I was first tasked with writing new features for an existing product that contained thousands of lines of code I earnestly started reading through the documentation & code to understand how it is structured and to figure out the APIs to use. My then engineering mentor said to me

” Reading through the documentation & code you will spend days or even weeks forming mental model which you will learn may not be accurate as you implement your code later on, leading to a lot of wastage of time and redoing.  Instead setup your environment, load the code inside a debugger, put a breakpoint and run it through. If there are specific areas you want to learn  then ‘step in’ to that function. This way you will learn about it faster, more accurately and spend less time redoing “

I found this advice to be a great insight and I think it extends in many places.

As a product startup one always start with an idea and then forms mental models around that (business plan or business case studies) and then build things based on these models to later realize they were not accurate thus wasting a lot of time. In the harsh world of startups you don’t get another chance to re-write.

You have to know very early if your idea will work before you can commit a lot resources on it. Things that determine if your idea works are some of the following –

Will it be adopted by users,

Will it talked about to friends,

Will it paid for by someone,

Or even celebrated & craved.

Essentially will it create the impact for you and the world that you dream it will.

MVP – your Idea Debugger

To know if your idea will work you should run it through a debugger that can tell you that the logic of idea will lead to its intended impact.

Enter the Minimum Viable Product (MVP), a term first coined by Frank Robinson and further popularized by Eric Ries.  Today it is a term that is quite loosely & liberally used and at times even abused.  MVP is a misnomer in the sense it is not the stripped version of the product but it is really a tool about learning & risk reduction around customer & market.  It is employed to uncover critical learning of your idea.  MVP is best thought of as the debugger of your product idea.

Before we start getting into the details of an MVP, let’s examine the anatomy of an idea first

Idea Anatomy

An Idea consists of the following elements

Vision – A new state of the world that will be in place if the idea becomes successful.

Problem – A friction that is coming in the way of job that a beneficiary is trying to get done

Solution – A proposed alternative for removing the friction

Beneficiary (also called as Customer* or a User**) – Someone who is going to benefit from the idea

* Customer is one who writes the cheque for the service consumed.
**User is someone who uses the product or service

 

Example:

Let us take an example to illustrate. Suppose you came up with an idea for creating a mobile SariApp that shows how to drape a sari.  It could be dissected the following way.

SariApp Vision:  More women in the world  in touch with their Indian traditions (or traditional Indian dressing)

SariApp Problem:  Would like to wear a sari for attending an Indian function but have no past experience or knowledge of draping a sari.

SariApp Solution:  A screen by screen illustration of each step of sari draping.

SariApp Beneficiaries (customer):  Women who have been fascinated by this Indian dress or those who who grew up outside of India never bought a sari before.

Once you do this you realize that problem, solution & beneficiaries are all at best guesses or assumptions that you make.  The task of debugging your idea thus becomes one of converting each of these guesses into verifiable facts that either proves or disproves them.

How MVP clarifies Idea logic

After you list down the things that are big unknowns in your idea you build something minimal (your MVP) to question it. The interesting thing about the MVP is that you have to build one for every idea, the same debugger can’t be used for every idea and the same learning does not apply everywhere. You could design an MVP to test or uncover learning one element or combination of elements (about just problem or combination of problem/solution/customer segment in the idea).

An example of an MVP for the above SariApp could be a simple landing page that articulates clearly the problem statement, the solution and call to action (such as leaving an email address to get contacted when solution becomes ready). Responses from traffic directed to the landing page  will  help learn about the merit of the problem/solution. If there are high number of clicks on your landing page but very few clicks on call to action a most likely interpretation of that could be those who visited care about the problem but not the solution. If the visits itself was very few then it is most likely they don’t care about the problem itself as you have stated it and so on and so forth.

Few things to keep in mind

The fidelity of the MVP is very important aspect to note which describes the minimum-ness of the MVP and plays a key role (see diagram) on the learning and how fast you get it. You have to start with testing the value proposition (a concise statement of problem & solution together) of the idea and increase the fidelity to learn more.

 In most cases MVP mostly tells what does not work rather than what works or even why it works. One has to iterate over changing the MVP and increasing the fidelity of it.

So what are the debuggers (MVP) you have built for your idea?

In the next post we will look at “Four critical stages of Product Startup Fitness”