The Structured Process Behind Developing a Successful MVP

You’re here so that means you’re considering a lean approach to develop your MVP. That’s a great first step.

But lean product development methodologies alone won’t cut it into today’s entrepreneurial landscape.

I know this because over the last ten years I’ve built my own startup (which crashed and burned), worked on dozens of MVPs with Altar.io and witnessed hundreds of other founder stories.

The hard truth is, building a successful MVP is not as simple as coming up with an idea and taking it to a team of developers or a software development company.

Before writing a line of code, you need to make everything you can to reduce the risk of that product becoming a part of the:

• 42% of startups that fail because of no market need;
• 19% that get outcompeted;
• 17% that fail because they build a user-unfriendly product;
• 13% who mistimed their product;

…you see what I mean.

A great idea is a good start, but if you want to have any chance of succeeding, it’s vital that you focus on the product from a business standpoint.

That usually starts with thorough research, from numbers on the market to competitor benchmarks or any other information that can help you turn your vision into a rock-solid value proposition.

From there, you set the main assumptions to prove and outline the journey your users will take through your product.

At this point, you’ll have all the information you need to create the ultimate list of User Stories and features necessary to prove the main assumptions in a Minimum Viable Product (MVP) or Proof of Concept (POC).

At Altar.io we call this The Product Scope.

In this article, I’m going to give you the full process, step-by-step, starting with defining your stakeholders, and finding your value proposition.

Contents

1. Step One: Define Your Stakeholders & Discover Your Value Proposition
2. Step Two: Deconstructing Your Elevator Pitch to Discover the Main Assumptions to Validate
3. Step Three: User Stories & Feature List
4. Other MVP FAQs

Step One: Define Your Stakeholders & Discover Your Value Proposition

Before building your MVP, you need to first do some good, old fashioned research.

Start by, asking yourself:

“What is the problem/pain we’re trying to solve with our product?”

The answer to this question should always be at the front of your mind as you move through the process.

Therefore, keeping that in mind, the next question is:

“Who is your main target? Define all stakeholders involved in your product”

Get to know them in terms of demographics, psychology and behaviour in the observed context.

Later on in the process, it’ll be time to build UX personas for your stakeholders, but we’ll get to that.

With your detailed list of target stakeholders in hand, and knowing exactly what the problem is that affects them, the next question you need to look at is:

“How do my stakeholders deal with this problem today? Carry out a competitor benchmark.”

Let’s take Spotify as an example here. Before Spotify existed their stakeholders had three options when it came to listening to their favourite music. They could:

• Buy it from iTunes
• Buy CDs
• Download it illegally using piracy (At a time where piracy was at its peak)

It’s imperative that, before you enter the market, you look and who is already in your space. List your competitors, including their strengths, weaknesses and positioning. Also, you might learn something you can adopt from them. As Pablo Picasso said, “Lesser artists borrow; great artists steal.”

Then, the final question in step one becomes:

“Why is our solution 10x better than the current market solutions?”

Here, you should define what differentiates you from the competition/existing alternatives for your stakeholders. A.k.a your Unique Value Proposition.

Let’s again take Spotify as an example. Their value proposition is to give the user the feeling that they had “all the worlds music on their hard drive” founder Daniel Ek believed if he could do this he could “build something better than piracy.”

And on paper, it was a better option (for all stakeholders) when compared with illegally downloading music as:

• Artists still make money from customers streaming songs;
• The playback quality is better and faster than illegal downloads; and well, it’s legal.

They were a better option than buying CDs or buying from iTunes (the only other options at the time) as:

• Instead of buying an album at around $10 each you had access to millions of songs at $10 a month.
• You could listen instantly on the device of your choice, as opposed to:

1. Waiting for it to download via iTunes
2. Going to the record store, buying the CD, uploading it to your computer and syncing it with a portable device.

With that in mind, once you have your Unique Value Proposition, it’s time to wrap up everything from Step One in a comprehensive, crystal clear, product-centric elevator pitch.

It should look something like this (feel free to use this as a template):

We’ve created [name of our Product] for [our stakeholders] who [state the problem/pain they’re facing]. This product will solve the problem by [state your product’s key benefit]. Unlike [the current market alternatives/competitors] our product will [explain how your product differentiates you from your existing competition].

If any aspect of your elevator pitch is unclear, head back to the beginning of Step One. Otherwise, let’s move onto Step Two: deconstructing your Elevator Pitch and setting your Main Assumptions.

Step Two: Deconstructing Your Elevator Pitch to Discover the Main Assumptions to Validate

Once you have a rock-solid value proposition and a crystal clear product elevator pitch, it’s time to set the main assumptions you need to validate.

Looking closely at your elevator pitch, you need to work out:

• Which of your assumptions can be validated with research
• Which features need to be built into your MVP to validate any assumptions that can’t be validated with research.

So, let’s say that your first assumption is that users are really facing a problem/pain (for this example let’s call it “Pain X”.)

The first assumption you need to validate is whether or not this is a real, tangible pain point. More often than not this assumption can be validated with research, e.g.:

“We know that Pain X is an issue for [name of your target stakeholders] because firstly we’ve seen competitors in the market attempting to solve this problem.”

Taking this example one step further, let’s say that the next assumption you need to validate is that your solution to Pain X is better than your target stakeholders current solution.

This assumption can’t be proven by research alone, you need to test within your MVP and measure this with KPIs e.g.:

“Although users are already solving the problem with [competitor’s solution], we believe this is outdated and inefficient. We propose that [our solution] is a better way to solve Pain X. We intend to prove this by building an MVP and measuring the adoption and retention ratio”.

However, assumptions aren’t just relevant to the end-users, but other stakeholders in the process. For example, Spotify needed to convince record labels to give them the rights to the music. Which, at a time when piracy and digital music platforms were the enemies of the industry, this was a battle for Spotify.

Spotify’s founder, Daniel Ek, was convinced that he had a solution to convince them to come on board:

“Up until that point, Napster and alike simply hadn’t shared their revenues. I was sure we could work out a straightforward revenue share with the record labels.”

It turned out it wasn’t that simple. The record labels still saw digital music platforms, like Napster, as the enemy. They simply didn’t trust Spotify.

Simply put, without industry involvement, Spotify could never exist.

Daniel had to de-risk the opportunity for the record labels, by guaranteeing them a year’s worth of revenue. He took a painful short term loss to earn their trust and set himself up for the long term win.

So, keep in mind as you build your list of assumptions, that some have to be tackled before you build your MVP and that direct users aren’t the only stakeholders you should be focusing on.

Once you have the list of assumptions you need to prove with an MVP, it’s time to move on to creating your user stories & building your feature list.

Step Three: User Stories & Feature List

At this stage, you’re nearly ready to begin your MVP development process.

There are two critical aspects, however, that are yet to be completed. Creating your MVP user stories and building your final list of MVP features.

Let’s start with the all-important user stories.

How to Write User Stories

A user story is an explanation of the journey through your product from the perspective of your stakeholder. It’s the most granular description of how a product works. User stories are a great way of showing how a software feature will provide value to your stakeholders. Also, they will keep your team focused on developing a user-centric product that actually solves their problem.

Let’s create a few simple user stories based on our previous example, Spotify.

Login

As an unregistered user:

• I want to sign up with Facebook, Google or email & password
• If I sign up with email I want to insert my password into two separate fields to ensure they match
• I want my password to be secure, therefore must contain at least 8 characters and at least one number and special character.

As a registered user:

• I can log in using Facebook, Google or email & password.
• If I forget my password I want to be able to click on a “Forgot my Password” link.
• Once I’ve clicked on this link I want to insert my email and receive a link that redirects me to an app window that allows me to enter a new password into two separate fields to ensure they match.
• I want the system to store my new password once I click OK (if passwords match).

Playback

As a user I want to:

• See the title of the track I’m listening to and the artist name
• Have the ability to play and pause the music
• Be able to skip to the previous or next track
• If it’s the last song on the list, it repeats, the music doesn’t stop
• Increase or decrease the volume
• Shuffle or repeat tracks
• Exit the playback window and return the music in a list view.

Once you have created your user stories, it’s time to move onto your feature list.

Your MVP Feature List

Using your User Stories, create a list of features that you would like to have in your product.

Then, put your features on one side and place your assumptions on the other. For each feature ask yourself:

“Is this feature vital to prove any of the assumptions?”

If it’s mandatory to prove one of your assumptions, it gets built into your MVP.

If not, leave it out and revisit it later when it’s time to iterate your product.

Let’s go back to our example of Spotify once more, taking into account the Playback user story I created. As a music streaming service, the ability to playback should be considered an essential aspect. There are features that are nice to have but aren’t mandatory. For example, displaying the lyrics to the song. On the other hand, other features are essential, such as:

Playback Feature List

• Artist & Song information
• Play/Pause Button
• Skip forward button
• Skip back button
• Volume change buttons/slider
• Shuffle button
• Repeat button

Once you have defined the essential features needed to showcase your value proposition, you’re ready to move onto the development stage of building your MVP.

Wrapping Up

By following this process you will ensure you’re building an MVP that focuses on solving your stakeholder’s problem. You need to ensure you demonstrate value to your users with your MVP, or they simply won’t adopt it.

For any other questions about the MVP process, feel free to drop me a message. Alternatively, see the MVP FAQs section below.

Good luck & thanks for reading.

Other MVP FAQs

How Much Does it Cost to Build an MVP?

The average good-quality MVP costs anywhere between $40,000-$80,000 depending on whether you build an MVP with an agency or hire your own team of developers.

How Long Does it Take to Build an MVP?

The short answer is that, in my experience working with dozens of startups at Altar.io, it shouldn’t take more than three to four months to build an MVP.

That being said, the time it takes to build an MVP can vary depending on the industry you’re tackling and the features you need to prove your assumptions.

To better answer this question, my content team and I recently surveyed 45 MVPs to see:

Check out the infographic below for more info. You can also find the full results of the research here.

What Comes After an MVP?

After you’ve launched your MVP, it’s time to employ the Build, Measure, Learn cycle.

Once your Minimum Viable Product is out in the wild, it’s time to gather user feedback (Measure).

With that user feedback, go back to your product scope: your MVP’s stakeholder analysis, user stories, UX/UI and feature list. Use it to discover improvements you can make to your product (Learn).

Then, implement those improvements in your product (Build).

Then, go back to the beginning and start again. Continuously iterate your MVP to create your fully-fledged product. In doing so, you’ll have built a user-centric product that’s the best solution on the market.

How do I Find Early-Adopters for my MVP?

Landing pages, videos, social media ads, TV ads, snail mail, PR stunts, a partnership with a manufacturer. Your options are endless depending on the resources you have.

Choosing the ones that’ll work for you is all about one, non-optional task: getting to know your customers.

Thanks for reading!