After the Definition of your Minimum Viable Product

After defining your Minimum Viable Product (see the previous post of this blog) the next steps are actually develop and validate it.

What features need to be provided for the Early Adopters start using your product?

As an example, here are the User Stories for LiveSource's Minimum Viable Product:


MVP 1:  LiveSource is a web Toolkit that loads the source code of your software and generates an easy to read version of it, understandable for the whole development team including by non-programmers.


Stories: 

• "As a User, I want to view a list of all my projects."
• "As a User, I want to view a list of all the source code files of each one of my projects."
• "As a User, I want to view an easy-to-read version of each source code file."

LiveSource is a very big and complex project, but as you can see, there is only three User Stories in the first MVP  This is exactly how a Lean development is supposed to be: start small, eliminate waste, deliver fast, etc.

Also with the User Stories list, it is important to have a draft of the user interface. Could be something very simple, in a piece of paper, or a picture of a drawing. We call that a Low Fidelity Prototype.

Figure 1: Low Fidelity Prototype for the LiveSource MVP

At this point, I am already developing using some Agile techniques. We can start planning a Sprint here, defining a Product Backlog, estimating, prioritizing, etc.

To be simple, for the first release of the MVP we don't need a login page and we don't even need a database. We will extract all the file contents from a remote repository, like Git or Subversion for example.

For now, lets include the three stories in a first Sprint and lets describe all the necessary tasks to implement these stories.

User Interface tasks:

• List all the projects available in a web page.
• When the user clicks on a project, the system shows all the files stored in the remote repository for this project.
• When the user clicks on a file, the system shows the easy-to-ready version of the source code of this file.

Server side tasks:

• Connect with the remote file repository of a particular project.
• Load a list of the files available at the remote repository of a particular project.
• Load the source content of a particular file of a particular project in the remote repository.
• Extract from the source code all the code documentation available.

I can add some Spikes to this list, for example a task to study some API's to connect with remote file repositories, or another task to study how to extract documentation from a source code. Any of these tasks could take a lot of work hours. But I will not add them to my task list right now because I already explored all these topics before when I was researching the viability of my project and they are working very well on my prototype already.

Next step is distribute the tasks over your development team. Let the programmers choose what they can implement and when they can commit themselves for a delivery.

While you are implementing your MVP, try to make it as independent as possible. When new features start to come, try to not just add them up to your MVP, instead, try to create a new MVP that are as much  independent as possible from each other.

Also, while implementing your MVP you can keep asking your early adopters for feedback, input some real data and do Usability Tests. As soon you start having feedback as better.

At the end of the implementation, you should have your early adopters already using your MVP or ready to start using it.

The main point of this post is: Don't start a new MVP while your early adopters are not already using the MVP's you have developed. There is a lot to adjust as soon as you start receiving your customers feedback, this adjustments are most of time much more important than new features.

The good time to start developing new features is when you already have 40% of your users saying that they will be "Very Disappointed" if they no longer can use your product. We call that a Product/Market Fit.

If you are not reaching your Product/Market Fit, you should start the whole customer development process again. Go back to the prototype stage and listen more to your early adopters. Find out what are the reasons they have to use or not your product, and adjust your MVP until you get Product/Market Fit.

It is really not easy to get to this point. You need to be very determined and normally takes a lot of iterations to be ready to scale. The path described here is a good starting point for you to succeed.