Startup MVP (Minimum Viable Product) – A Complete Guide with a Cheat Sheet
Share The Love!
Pencil drawing of Don Quixote

“People think focus means saying yes to the thing you’ve got to focus on. But that’s not what it means at all. It means saying no to the hundred other good ideas.”

— Steve Jobs

No one could have ever said it better than Steve Jobs.


As a Startup Founder your enthusiasm is at its peak. And understandably so. You want to do everything that can boost the chances of your Startup reaching heights. Every new day brings a new idea into your mind. And along with it comes the urge to run to your development team and tell them to incorporate it ASAP.

Somewhere, you need to apply the brakes.

It is fine to list every new feature that comes to your mind. I often find myself noting down the best idea in Evernote while I’m travelling. But it is in your interest to weigh its relevance to the Minimum Viable Product (hereafter referred to as MVP) and then walk upto to your development team and ask them how they can fit it in.


What is this MVP anyway?

MVP is a term which originated in the Lean Startup concept created by Eric Ries.

In simple terms if we understand the 3 words that it is constituted of, it means, the Minimalistic version of the Product that represents your Startup Idea which is Viable to satisfy the core pain point of your customers in a satisfactory way.

In more simpler terms, just create that version of your product that is enough to represent your Startup Idea and reduces your Go-To-Market time. The smaller your Go-To-Market time, the faster you get validation for your Startup.



How does MVP make your product development Agile?

Agile is another buzz word you hear in relation to product development.

Being agile in the real sense of the word, means being quick.

And when we talk about agility in Product Development, what it means is delivering quick small versions of your product (which make sense), testing them and then thinking what should be the next feature that should be lined up in the product backlog.

So, if you focus on building the MVP first you are actually following agile principles since you are creating a bare minimum version of your product and then leaving the rest of the features to come up in iterations.



Pain-Feature-Gain

When you talk about Product Development, Steve Jobs plays on your mind. And so rightfully he said “You’ve got to start with the customer experience and work back towards the technology – Not the other way around”

Your MVP is not going to strike you as a sudden realisation out-of-the-blue. It has to be planned on the basis of the customers and their experience related to your product.

It has to start with you working out a Mind Map (another blog coming up on this soon) of all the entities in your Product Ecosystem. It involves the customer, it involves you as the admin, maybe your support staff and so on and so forth. Basically, it involves identifying each entity that will interact with your product.

Focus on the customer now. And see, what are the various ways in which he/she would interact with your product. A very good strategy to do this is the Pain-Feature-Gain method.

For example, a Pain point for a customer would be to talk to an expert. The Feature that you could provide to satisfy the customer is Book an Appointment. The Gain for the customer would be that they are able to talk to an expert.

Now follow this step-by-step process and your MVP will be in front of you in no time.

  • List out all such Pain-Feature-Gain combos that come to your mind.
  • Once that is done, write Must-Have / Nice-to-Have beside each of them.
  • Take the Must-Haves on top in Version 1 of your Product Release.
  • Take the Nice-to-Haves in the later versions.

There! Your Version 1 release is your MVP.

A note of caution here. Stop the urge to mark everything as Must-Have!



Product Release Estimation

Software Developers are a cursed lot. When nothing else works, curse the software developer for not creating the product well and creating it on time.

I was one, so I know what pain we go through!

There has to be a calculated approach to deciding how much time the MVP (or for that matter even future releases) are going to take. So, that the Founder and his development team are all at one page at all times rather than haggling on development features and timelines.

If the product backlog is clear there is definitely a mathematical approach to deciding how much approximate time it will take to complete the backlog.

The elements of product development to be considered in order to estimate timelines :

  • Pre-Development : Product Architecture, Epics, User Stories. These are nothing else but your Feature list broken up into actionable elements. The longer that the developers spend time on this, the better will the estimation be
  • UI/UX : There are 2 aspects that developers consider here. Look and Feel and Navigability. This is not a compulsory pre-requisite to Business Logic Development mentioned below. But if this can be done before hand, it gives much more clarity to the pipeline
  • Business Logic Development : This is the heart of the development which is undertaken by the core Software Development Team
  • Unit, System and Integration Testing : This is the evaluation of correctness of each feature developed. This is done by the Quality Assurance Team. After this is done, some time is given to the development to correct any issues and suggestions that come up.
  • Product Owner Testing : This is the evaluation of correctness done by the Project Manager. And here’s the catch in this case. In case of small teams, sometimes you as the Founder are expected to play the role of the Product Owner. At this stage, all small bugs are expected to be solved, the app is just tested for functionality correctness. After this is done, some time is given again to the development to correct any issues and suggestions that come up.

As a founder, this may seem a little technical in nature. You are not supposed to know the core technology aspects of software development. But you need to know the phases so that you can understand the estimations given and arrive at a common ground.

The final aim is to ensure your MVP and all the future versions of the product are released in time so that your Go-To-Market is reduced and you can get quick validation of your Startup Idea.


MVP Example

Adam’s Startup Idea is an Interior Design App.

He has identified his Target Customer as Eve who is a 30 year old working woman. She has decided to revamp the interior design of her house.

Adam contacts Eve and this is what she says are her pain points :

  • There is so much to address w.r.t all the rooms of her home, that she is not able to organise things and it is becoming overwhelming.
  • She has got multiple quotations from vendors and she does not know whom to choose
  • If she could visualise the design before she gives a go-ahead it would be great.

Adam lists the above requirements in a Pain-Feature-Gain format

PAINFEATUREGAINMUST-HAVE / NICE-TO-HAVE
OverwhelmingOrganising elements of work by room e.g. set  up a lounger in the dining area
Organising elements of work by category of work e.g. civil, electric, carpentry etc
Systematically identify and tackleMust-Have
Multiple QuotationsCompare QuotationsNeat comparison table with each element compared to pick the best oneMust-Have
Be able to see before decidingVisualise DesignCan take an informed call after design is presented in a tangible formatNice-To-Have

Once this is done, Adam clearly knows that the first 2 features are such that the product would not make any sense, till they are done. His MVP is right there.

Adam now goes to his development team who estimates Pre-Development, UI/UX, Business Logic and Testing timelines and comes up with a clear date as to when he can plan his Launch.


Hope I could throw some light on MVP and its importance. And more importantly if I could solve the age-old war between Founder and Developer in relation to Product Development Estimates, I think this blog has made its mark! If you can add value to this in the comments section, my readers and I would be greatly obliged!


A Fill-In-The-Blanks Template to identify your Startup MVP and speed up Launch

Check out the Product Release Plan Template

An Easy-To-Use Template where you can just Fill in the Product Features you desire in order of priority. Based on a logical calculated approach, not only can you make a decision on the MVP (Minimum Viable Product) but also get an idea of the Release Date, thereby giving you a clear idea of your Go-To-Market Timeline

This is what you get :

  • List desired product features in order of priority
  • Get an estimate from your Product Development team about the number of days it would take to complete each feature
  • Get an idea about Pre-Development activities like Product Architecture
  • Get a clear picture about delivery date for UI Prototype so that you can have First Level PoC (Proof Of Concept)
  • Include time for Product Owner Testing and recommended changes after that
  • Modify any value anywhere and final values are modified automatically since they are purely formula based