Actionable steps on how to build an MVP in 2021
I have a great idea! Is one of the expressions I often hear from early-stage startup founders, yet how to implement it and become successful is still a mystery to many.
Some of the most commonly asked questions by entrepreneurs when building an MVP are, where do I start? How do I test my business assumptions? How do I get feedback from my customers and how do I validate my product?
The following is a list of actionable steps on how to get started building an MVP.
Pre-flight checklist 🛫
Build, Measure and Learn
The core principle of lean startup methodology is the build measure learn cycle. Here we iterate on a version of the product that has just enough features to satisfy early customers needs and at the same time, provide rapid feedback. This feedback can be used to validate (or invalidate) assumptions, learn what users actually want, and build future iterations of your product that better serve your customers.
MVP is not a product, but a process
An MVP is an iterative process that you repeat over and over again. Identify your core business assumption and find the smallest possible experiment to test that assumption. Then use the results of the experiment to course correct.
No MVP journey is the same
Building an MVP is not a clearcut path of linear progression. Typically it becomes a winding path filled with rapid product iterations and pivots based on customer feedback, to narrow in on product-market fit.
Starting point 🏁
The first step for any entrepreneur is coming up with an idea that you want to test. The key step here is taking the idea or business hypothesis from your head and into a tangible format so that you can communicate it with others.
There are various well-known methods for doing this, such as the Lean Canvas which is a 1-page business plan template that helps you to quickly deconstruct your idea into its key assumptions.
Another option is the Design Sprint process developed by Google Ventures which is a five-day process for answering critical business questions through design, prototyping, and testing ideas with customers.
There are already tonnes of good articles about these methods on the internet so I won’t go into depth on them but will put some links at the bottom.
The key part of this exercise is to narrow in on the problem/solution fit. Then set up customer interviews to validate your customer and problem assumptions.
Only once this has been done should you think about crafting the first iteration of your MVP.
Now we are ready to push forward with the MVP following the Build, Measure, and Learn cycle.
In the build phase, the startup’s goal is to build the bare minimum product that will allow them to validate the market and test key assumptions.
Design the experiment
Firstly, identify what problem you are trying to solve and how will this address your customer’s pain points. Then, map out the user journey and user stories. Focus on serving one target audience and solving one user pain point.
Work out what user data you need to collect. Such as did a user complete a certain action, or what kind of feedback do they give. You want to be able to track customer behaviour flow showing how far they progressed with your product and if they completed a key action, such as making a payment.
Ruthlessly prioritise the features that you want your MVP to have. Ask yourself, which single-action do you want your users to accomplish through the product? Then determine which features are “must-haves”, and which are “nice-to-have”.
Build the experiment
Next, go ahead and build it. For the first iterations of the MVP, you want to take a flexible, low tech or no-code approach.
Think landing pages or simple websites that you create using a drag and drop website builder, or clickable UI mockups that a freelance designer can quickly make for you, or an email list or blog is another great example. There are a number of great resources on no-code MVPs, see the bottom of the article for links.
Fundamentally, it needs to be something that you can build in a matter of hours or days, not weeks or months.
Run the experiment
This is where you get the MVP in front of a cohort of actual users and begin to collect data.
The way you find early users depends on what type of product or industry you’re in. If it is B2B, then Linkedin outreach is a good place. If it is B2C, then Facebook groups and Twitter are good starting points.
In the early iterations, it’s often best to focus more on qualitative feedback, than quantitative metrics. Spend time meeting end-users, watching how they use the product and where they get stuck and if it actually solves the problem.
Next, the startup needs to understand the results of the experiment and determine how successful it was. It’s unlikely that you will have an extensive data set to begin with, but it should be enough to measure what happened.
Carefully analyse the data from the experiment and ask important questions, such as did users successfully understand the product, did they complete a given action, did it solve a problem for them? What were the pain points in the product?
It is also possible to include various techniques for speeding up the measurement process, such as A/B testing or split tests. However, these kinds of techniques are best reserved for when you’ve been through the BLM cycle a few times and have enough users to make the measurement process more quantitative.
Finally, the most important stage. Based on the measurements, you need to now determine if you should “persevere” or “pivot”.
If the cycle went well and the product received good feedback then it is likely that you are on the right track and should “persevere” with a further iteration where you further refine the MVP.
If however, the product has not been widely received by the market or does not seem to solve a big enough problem for the customer, it might be that some of your underlying assumptions are not quite right and it’s time to consider a pivot and modify the experiment.
Once you’ve been through a Build, Measure, Learn cycle, repeat with a new cohort of users. Your MVP will need to start to become smarter and more sophisticated with each iteration. If you started with a no-code approach then it won’t be long before you outgrow the capabilities of your chosen tools and need to move to a custom software solution.
Following this process will hopefully help you find product-market fit faster but it is rarely an easy ride.
Illustrative Example of this in practice
Here is a worked example that mirrors some MVPs I have built in the past (with some detail redacted for the sake of brevity).
The no-code MVP
I recently worked with a health tech startup, where the ultimate vision was a health platform to enable Physios to diagnose and prescribe treatment plans for patients.
When scoping out the way forward, we narrowed in on a specific use case of lower back pain. Working with the founder (who was a Physiotherapist) we created a short programme of physiotherapy exercises. Alongside this, we used Google Forms to distribute the videos and record which ones the patient was able to complete. We used a simple automated email system to send users their exercises for each day over a period of a few weeks.
We distributed these to a small cohort of around 10–20 test users that we knew were suffering from lower back pain. We stayed in communication with these early users throughout this process, recording their feedback while being careful not to invalidate the experiment by asking leading questions (i.e. response bias).
A lot of the feedback was promising and we noticed that many users would flag up similar issues which we would respond to in the next iteration.
After a few more BML iterations of the MVP in this form, we decided it was time to build a more sophisticated software solution that took the form of a mobile app.
We spec’d out what a ruthlessly lightweight version of the product would look like as a mobile app, firstly running UI mockups by a small set of users. Then in the next cycle, we rapidly put together the first software iteration that had a small but well-considered feature set, consisting of; user login, view today’s exercise, record today’s progress and daily push notification. That was all we needed to test at that moment in time.
We chose to use Flutter, a cross-platform mobile app development kit, which allowed us to quickly build the app and reduce the time to market, even though it might not be the tech stack we use longer term.
This followed the same method as before however, we were able to get a bit smarter with how we record user actions using third party analytic tools and as the MVP was now more automated, we could distribute it to a larger user basis.
This allowed us to really hone in on the core features and value proposition that was most important to the users. Furthermore, now having in place this iterative framework we were able to start rolling out and testing other key features such as a payment mechanism to work out how to monetise the product.
Now you’re all set to build an MVP! 🚀
Let me know how you found this article or how you built your MVP in the comments below, and as always, good luck with your startup.
I offer consultancy and pro-bono advice to startups and scaleups. You can find out more about me and contact me here mikesmales.com
Finally, let me know what startup topic you would like me to write about next.
The hottest email list in Silicon Valley, Andrew Askins
The Design Sprint, Google Ventures
A No Code App Development & Launch Plan That Works, Coaching No Code Apps
Cohort Analysis: Beginners Guide to Improving Retention, Pushpa Makhija