So what exactly is MVP?

Depending on the context of the project, two definitions may describe best what MVP actually stands for. First one was created by Eric Ries, founder of the Lean Startup methodology.

“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.”

The above definition is focused on validated learning: a build, measure and learn feedback loop. Its main message is that we should build a product with the least amount of effort possible and gather users feedback. It's usually the case for start-ups without a verified business model or idea. This is not typically the case for an established business, where usually we know what we are building, who are our customers and may already have a working product in place. That said, the above definition misses one important factor.

Here is the second definition by Ash Maurya, author of the book Running Lean.

“A Minimum Viable Product is the smallest thing you can build that delivers customer value”

A combination of those two statements gives us an MVP definition for software development projects

• It should focus on delivering customer value
• It should require the least amount of effort possible
• It should allow learning from your customers’ feedback

Why would you want to define your MVP in the first place?

Firstly, there is always a budget a project must fit. Defining the cost of the scope will let you choose what can be afforded in the MVP and what can wait for future product versions.

Secondly, you want to consider a release timeline. It might be dependent on business opportunities, fixed availability dates, or just making sure you are ahead of the curve. Time available to develop the product will impact how much you will be able to deliver.

Thirdly, and most importantly, you want to focus on the scope of your product and the feature set that will deliver value to your customers. Product backlogs tend to grow really fast and all of the items seem to be important at first. It is often a difficult process to prioritize the tasks when they all seem crucial.

Defining a Minimum Viable Product - where to start?

Despite whether you are creating a product for your own firm, you are the project sponsor, or you are developing the product for another company, there are a few essential questions that need to be answered in terms of defining MVP scope.

First, you need to understand the overall business context. From the beginning, you should have a high-level approach for:

• What problem will you solve with your product? (suggested reading - “Jobs to be done” approach)
• Who are your customers?
• What key activities or resources do you need to deliver the value?

A rather easy and transparent tool to summarize the above points (and more) is the “Business Model Canvas”. Completing this exercise will allow you to define what are the most important drivers for your product and what are the dependencies that have to be taken into account while defining MVP scope.

If you decide to use the Business Model Canvas for your business case definition, remember that it is not static and will evolve during product development.

Once you know the business context and product focus, confirm this with your stakeholders. Similarly, if the product design process has already started, show any mockups or prototypes to your stakeholders and gather feedback. Nothing beats quality feedback direct from your stakeholders and users.

Getting down to the feature level

Information gathered earlier in the product development process allows to take the next step and define the features that might be part of our product, regardless if they will be part of the MVP or not. Personally, I recommend either of the two techniques briefly described below to define the initial scope.

User story mapping

The basis of this technique is to look at the application from the user perspective. The process starts with listing the features and then defining them with user stories (e.g. As a user I want to log in to the application using username and password).

Features and associated user stories should create a grid which would later allow us to prioritize particular items. Once the features and user stories are defined, arrange them into a user journey. Your outcome will look something like this:

Looking at the flow from the user perspective usually reveals much more than just brainstorming “what we should have in the app”.

Event storming

This might look similar to the User Story mapping technique but the results of performing this exercise may be different, if not to say better. Event Storming is always carried out in the form of a workshop. To start you will need a big room with empty walls, a lot of post-it notes and most importantly a group of people with the most knowledge about the product to be delivered. If possible it should be developers, architects, designers, analysts, business decision makers, etc.  You want to get as much context as possible.

Everyone starts by writing down events that are taking place and/or will take place in the system. They should be small enough to easily fit on the post-it note (so the granularity is quite high). Participants should not communicate with each other and place the stickers on their own. You should end up with something like this:

The next step is to start going through the defined events and to divide them into processes or use cases. If needed, you should add additional process steps along the way. Also, it is a good practice to highlight actors, risks, external dependencies, etc. with other sticker colors (consistent among all processes). As a result, we should end up with an outline of our system, important processes (features), and internal and external dependencies. Here is how the result might look like:

To sum up, Event Storming allows to quickly gather knowledge from different areas of interests and put them together into the processes/features to be developed. In doing so we can specify dependencies and connections between them which will affect our scope and timeline. Additionally, this exercise allows us to verify the importance of particulate flows and prioritize or deprioritize them.

Scope prioritization

Project constraints

So once we know what value we want to deliver, what problem we would like to solve, and what features to include, we need to prioritize the items for MVP.

In order to do that, all listed features and associated tasks should be estimated (preferably by the team that will carry out the work) in hours or days. Another important thing to take into account is all of the project overheads: meetings, fixing bugs, documentation, etc. Excluding such items will surely lead to project delays or scope cuts.

The next step would be finding out what are the MVP delivery constraints:

• Budget - how much money we can spend on the development team
• Time until when the product should be available
• Team - who is available to perform planned work (developers, project/product managers, QA specialists, designers, analysts, etc.)

By having all this information, we can combine our project scope, team capacity, and the timeline to deliver a successful MVP.

Prioritization

Once we know the constraints and cost estimates of each feature, we can move to prioritization.

A helpful and straightforward method we use to set project priorities is the MoSCoW technique. According to this approach, features and tasks should be divided to:

Once we assign a priority, we should verify if can we fit that many items into the MVP scope? Do we have room for other items? Based on those questions we’ll decide whether we will complete only “must haves” or if we can include some of the “should haves”. Usually, during the first iteration of this exercise, too many items are must-haves. This is quickly verified when we compare the cost estimates for must do’s against the budget. This inevitably leads to deprioritization.

Clearly stating your priorities and what you plan to deliver is essential for the creation of a good MVP. Define your scope of must-haves to give your software development team the right thing to focus on. Make this transparent to your stakeholders so they can anticipate what will and will not be included in the MVP.

Don’t get me wrong, since we are mostly working on Agile projects, new things will come up every now and then. The planned scope should be inspected regularly and modified if some items become obsolete or there are new important ones. In this case, you have your MVP scope estimated and priorities set. You can quite easily make trade-offs since you know the effort of the already planned work and to be added tasks. Modification of the MVP is not unwanted - it is to be expected.

What’s not an MVP

There is a common misunderstanding of the term MVP, that this is a piece of software delivered with low effort without considering usability, quality or design. Since it is a minimum viable product, we should cut corners whenever we can, right? Absolutely not!

What’s the goal of MVP? To deliver value to the customer in the shortest amount of time and effort possible and gather their feedback to further improve. That can’t be done if our product is not usable and doesn’t reflect the actual end result (even if basic). We should think of an MVP as a core product that might get some tweaks and will be extended in many ways - but it is still a core product that is stable and reliable.

Lean Startup and MVP

Although the definition and creation of the MVP are important in most software development environments, its value is noticeable in particular for Startups cases. A methodology which strongly refers to the creation of Minimum Viable Product is called Lean Startup.

There are many aspects of the Lean Startup methodology, but I would like to highlight one of them: minimizing the total time through the loop. Nowadays it’s crucial to deliver your product to the customers as fast as possible. Often the first competitor gains the biggest market share. Secondly, the faster you deliver your product, the faster you can start validating your assumptions with users. Lastly, gathering user feedback is crucial for improvements. The shorter the time between MVP and deploying changes based on feedback, the faster you can revalidate and re-assess.

One thing to note is that Lean startup is not an alternative to Agile approaches - it might be a complementary part of e.g. Scrum, even if not mentioned in Scrum Guide.

Summary

So now you know what MVP is, why and how to create it. You should always make sure that your product is created for the end users - it’s them who will use your product or won’t - which is a line between success and failure. Make sure they have a big impact on your creation!

‍