The Ultimate Guide To Building Your MVP
The ins and outs of building your MVP – definitions, best practices, guides, examples, common mistakes and everything in between.
Thanks to Sama and the OpenAI saga last week, my Twitter screen time has gone up 27%. Hope that ad rev share is paying dividends. P.S. Can we still call it Twitter?
Anyway, onto the reason why you’re reading this. This is my first product-related post as a product person. How exciting!
I’m going to go deep and cover a lot of ground. We’ll go through:
What an MVP is, and is not
Main MVP strategies
The 4 P’s of MVPPPP
The MVP approach
An MVP example (a lil’ bit of role-play)
Key considerations
Common mistakes, and how to avoid
Let’s get into it.
What is an MVP?
Everyone, and I mean everyone, has a slightly different idea of what an MVP is. So much so that the whole premise of it has kind of been lost in translation.
No, it’s not Lebron James.
A Minimum Viable Product (MVP) is a concept coined by Frank Robinson (SyncDev – not to be confused with the baseball manager) in the early 2000s – popularised by the notable Eric Ries (Lean Startup) and Steve Blank (Four Steps to Epiphany). It refers to the method or process of building “a version of a new product which allows a team to collect the maximum amount of validated learnings about customers with the least effort.”
In essence, you’re building something that will quickly tell you if you have something people want. Not just one someone, but many someones.
Founders often get this wrong and spend years polishing something too few people want.
Over the years, we’ve seen many adaptations… You’ll hear terms like Minimum Viable Product (MVP), Minimum Lovable Product (MLP), Minimum Marketable Product (MMP), Minimum Usable Product (MUP), Minimum Sellable Product (MSP), and so many more minimums.
Truth is, they’re just appropriations from people with different primary skill sets.
The concept of an MVP is simple.
Minimum: This means the smallest or least amount of effort.
Viable: This means something that can do the intended job successfully.
Product: This is the thing you are offering.
Viability is where the debate occurs, and is open to interpretation. This realistically comes down to your goals. Are you selling it? (rev gen) Are you showcasing it? (tech exploration) Or are you simply measuring demand? (user acquisition)
POC vs. Prototype vs. MVP
MVPs should not be confused with prototypes or Proof of Concepts (POC). There are some key differences that divide each into their own category with slightly different core goals. These are:
Proof of Concept (POC)
Designed to determine the technical feasibility of an idea or solution, by showcasing functionality. Often without an interface, any sort of baseline user experience, and often for unproven/uncertain parts of the product (e.g. linking multiple APIs). This helps you:
Verify the development approach
Check the feasibility of a complex technical solution (if applicable)
Define your solution’s limitations
Evaluate what resources you may need
Reduce the likelihood of failures during later development stages
Whilst not technical, I like to classify Vapourware and Landing Pages as a POC to determine demand without a product. Some may call this an MVP, but it’s a bit of a stretch in my opinion. Taking it at face value, you’re just proving a concept.
Prototype
Designed to articulate the user experience of the idea or solution, for the primary purpose of collecting early customer feedback and rapidly iterating on trivial and non-trivial details.
Less effort than an MVP, more effort than a POC. You can use tools like Figma, ProtoPie, Framer, Sketch, Webflow, InVision… the list goes on.
As part of your pre-MVP checklist, you should look to use a prototype for early-early customer exploration and feedback.
Minimum Viable Product (MVP)
Designed to attract early adopters and create a repeatable business loop or usable version of new technology, for the sole purpose of collecting feedback and iterating toward a specified position (revenue, acquisition, etc.).
Key MVP Strategies
There are two main approaches to building your MVP. These are:
1. Deep and narrow
You focus on one particular type of user, solve one pain point really well, and deliver lots of value within that one particular piece. Knowing full well that it’s missing core features and delivers a sub-par user experience in less important areas.
Optimizing for customer retention and advocacy, this strategy is often used by founders with deep market and customer expertise, having a strong grip on the problem their solution solves.
2. Wide and shallow
You focus on a broader group of users, solve a few core pieces to a satisfactory degree, and deliver just enough value to get the job done.
Optimizing for customer acquisition and exploration, this strategy is often used by founders seeking applications for emerging technology or exploring new markets where you are not a subject matter expert, and don’t have a clear understanding of the value proposition.
Note that this strategy is much harder and less efficient in most cases. You’re mostly better off taking a step back, interacting and learning from a niche persona, then building for them…
I can say without a doubt that it is more important to have a small number of users that love your product, over a larger number of users that like it.
The 4 P’s of MVP (MVPPPP?)
It’s important to recognize that an MVP is not just a product in most cases. Remember what I said about viability? It’s a means to validate a repeatable business loop for early-stage startups. Unless you’re exploring ground-breaking technology, this means incorporating a few more P’s.
A product alone, will not make your startup successful. You need to also understand who, what, how, and how much… so you have an actual business. Focus on one of each – you don’t have the time, capital, or resources to focus on multiple of each.
Persona
Who are you building for? Get incredibly specific about one exact persona. To the point where you know them like you know a partner. Then look at the regular niche behaviors they sit within. Generalizations among these niche behaviors are where you’ll identify super thoughtful features and value – this is the beating heart of building deep and narrow.
For example, if your users are writers, then having a dark-mode editor can be the difference in why they use your product over competitors. This is because a large majority spend hours writing (typing) at night and white screens strain your eyes.
You can most certainly expand outward into other niches and personas after really nailing one. In fact, it’s the best way to do it.
Product
What does it do? What is the key problem you’re focusing on and how are you solving it? Where do you sit in that user journey? Don’t try and solve everything at once, or the end-to-end journey. Rather, find that sweet spot of pain and value.
For example, a writer has two major pain points; struggling with promotion and writer’s block. They may pay to promote/advertise their writing, but they may not pay for an AI-writing solution to avoid writer’s block – because they value their creativity and style.
Pathway
How are you getting customers/users? If you build it they will not come. You’re not building the first baseball field in Iowa. You’re building another startup in the most dense founders-market history has ever seen.
You need to think about and focus on the ONE channel in which you’re finding and converting customers or users. This will often dictate MVP decisions – for example, self-service sign-ups, paywalls, or chat support.
Price
What does it cost? Is it free, access-based, or SaaS? What do other products in the industry cost? Don’t introduce tiers, credits, upgrades, and so on. Pick a price, make it simple, and more importantly be intentional.
Your pricing will change as time goes on.
What you can sacrifice in your MVP
There is a long list of specific things you can and should sacrifice when it comes to your MVP, but they’re also contextual to your product, industry, and user. So here are a couple of general principles:
Scaleable technology
Contrary to what your developers may say, you do not need a back-end with Amazon CDNs, load balancers, and Lambda’s. You do not need to modularize your infrastructure with micro-services. You do not need to account for scale. It’s overkill when you have little to no clue how many users or usage you may get.
Automation & workflows
“Do things that don’t scale” is a startup commandment for a couple of reasons; a) because you learn more about your user, and b) building and changing automations are costly. Until you identify the patterns, just do the things manually.
As you do it over and over, it becomes more and more unmanageable, then you can and should build it in to unlock scale.
Owned services/technology
If your product has payments in it, you do not need to “Build our own payment gateway because we can sell it as a separate product”. Your thing is either some sort of payment gateway or you should be using an existing plug-and-play solution on the market (e.g. Stripe).
Building in-house solutions comes at the scale phase when you’re optimizing revenue and it makes financial sense to make an investment to replace higher 3rd party costs.
Volume-specific features
Having a data-driven personalization engine as a unique selling proposition isn’t viable as an MVP. You simply don’t have the volume of data or usage to make that work from the get-go.
Future products or features
If you’ve ever said, “Let’s add this because it’ll come in handy when we {{some future thing}}” then take a step back. It’s both unnecessary and potentially dooming. You only have so much time, money, and energy. Adding in these ‘future features’ or even baseline infrastructure to support them is a waste. of. precious. time.
The visual appeal of your product, website, or brand
Okay, so this matters a little bit. As it’s increasingly hard to ‘stand out’ these days, and an appealing brand can help. But don’t go overboard developing a comprehensive brand and style with an external agency, or spend weeks refining. Just make sure it’s presentable and palatable and move on.
What you can’t sacrifice in your MVP
On the other side of things, there are a couple of things that you can’t sacrifice when it comes to your MVP. These are:
Basic analytics (a means to measure)
You absolutely need some way to measure and learn from your product performance. At an absolute minimum, you need to understand acquisition (sign-ups), retention (repeat usage), and churn (users that leave). On top of this, the more detailed you get with your analytics, the more understanding you’ll have of your product value and pitfalls.
Not much else…
No honestly, most things can be sacrificed. I like to ask myself the following questions:
“If I do this, what’s the best thing that can happen?”
“If I don’t do this, what’s the worst that can happen?”
“What may happen if I did it later?”
The MVP approach
Start with the research:
Look into potential customers – what they complain about online, where they congregate, repeat behaviors… get familiar. This will shape the product.
Check out the market – the size, the history, current news, and future trends/predictions. This will determine pricing, marketing, and growth opportunities.
Look at competitors – who are dominating the space and who are hanging on by a thread. Why? This will fill in market blanks and often influence product decisions.
Run an experiment, proof of concept, or walk through a prototype to measure demand, get early feedback, and determine MVP focus areas.
Determine the 4 P’s of your MVP – what product and you building for whom, where are they, and how much is it?
Build, measure, learn loop – get into a routine of shipping and iterating based on feedback or analytics.
Let’s put some of this into practice.
Let’s say your idea is to ‘Build the Netflix equivalent for indie films’
Let’s call it ‘Indieflix’ for lols.
The Problem
Indie filmmakers find it difficult to earn a living and get discovered.
The Solution
A Netflix-style platform where indie filmmakers can upload their independent films and earn a percentage from customer subscriptions – funneling 70% of SaaS revenue to filmmakers based on film performance and retaining 30% for the platform.
Before building, we would:
Reach out to indie filmmakers, validate their problems, and discover their needs:
Look into filmmaker Facebook and Reddit groups. For example, this group has 96k members. Then reach out to or survey members.
Explore the market opportunity and determine size (pro tip: use Semrush market explorer)
Look for and analyze competitors in the space (pro tip: use Semrush market explorer)
Okay, pre-MVP checklist done ✅
The MVP
So, how would you go about building your MVP, and launching? Let’s explore the four P’s and refine the idea a little.
The Persona
Who are we targetting specifically within indie filmmakers? It may seem like ‘indie filmmakers’ are an incredibly small and niche market, but within there are dozens of personas; hobbyists, students, b-grade producers, cinematographers, and so on. Within plenty of categories; documentaries, horror, action, and so forth.
In this example, we’ll focus on current, and recently graduated students in the documentaries sector… Because well, docos are very hot right now.
The Product
How might we build this platform as quickly, and as cheaply as possible? Leveraging no-code/low-code tools is a great place to start – even if it does not reflect your desired functionality 1:1.
In this example, we’ll use a template on Bubble, combined with Wistia to launch a Netflix alternative in a matter of hours and for about $100.
Set up Google Analytics for free.
That’s it, your product is ready to go.
The Pathway
How do we find customers? Given that Indieflix is a two-way platform, we need both filmmakers and consumers. They are both the same person early on – this is the beauty of early adopters… they produce and consume.
In this example, we’ll leverage Facebook groups and ads to market both sides of the equation. Because we have a deep understanding of an incredibly niche persona, we can target them with accuracy and empathy.
The Price
How much do we charge, or is it free? Given there are a number of streaming services, we can look at the average industry pricing and use that as a baseline to build out a financial model.
Netflix, Binge, Disney+ and Stan average $13-$22 per month.
In this example, we’re going to come in at the higher end (because we don’t have the luxury of volume) and it’ll really test the value hypothesis.
There we have it… we have an MVP for Indieflix from just a few hours of work.
Key lessons/considerations
Limit your MVP build to 4 weeks absolute max.
If your MVP isn’t seeing sufficient growth or performance (from effort), then it’s likely not valuable.
More features will NOT solve your value problem: A common situation founders see themselves in is building new features because of lack of traction/value, but keeping unused features because “It’s already there so we may as well keep it“. It’s not about the effort of removing, it’s about the cost of not moving on – maintenance, opportunity, complexity, and so on.
Your MVP needs to include your Unique Selling Proposition (USP) or Unique Value Proposition (UVP: This is that one thing you do differently.
Debate high urgency → high impact features, and scrap the rest – so you can clearly understand what is included in your MVP, what comes after, and what’s not worth it.
Common mistakes to avoid
Not solving a real problem:
And not just a problem you have – A problem many have. This is a surefire way to end up emotionally attached. Dogfooding your product can work, but there should still be a number of you using and driving the product forward.
Introducing scope creep:
Adding features before releasing. Remember, smaller scope = fewer variables = easier to identify value.
Letting UX designers determine the scope/product:
UX designers are focused on optimal user experience. They’re not well-versed in making product-related sacrifices (I’m an ex-UX designer so this cuts deep 🥲).
Not shipping fast enough:
Building and building and building in isolation or amongst your team, without getting customers in front of said changes.
Not including the customer:
Assumptions are great starting points, but it’s important you quickly validate these. The answer? Including customers/users every step of the way.
Catering to too many personas/customers:
Referencing the ‘deep & narrow’ approach, it’s incredibly hard to find value among a single persona, let alone a number of different ones.
Becoming emotionally attached to the product:
Stay focused on your vision or mission, and let your product be fluid with exactly how you get there. There’s never only one way to solve a problem, but I know it hurts when it’s not your way.
Building features or polishing a product no one (or few) wants:
Try not to focus on faint signals and the ‘what could be’ from a handful of users who aren’t paying users or raving fans. Be objective and realistic about where your product value lies.
Digging your heels in:
If you’re getting feedback about a particular problem, feature, or opportunity, try not to dig your heels in because you don’t feel the same way or have an otherwise optimistic opposing view.
No marketing efforts:
Little or no investment in ‘pathway’ and promotion will probably result in low user adoption rates, compromising the overall efficacy. A few posts from your social media won’t likely do it for you.
Focusing on the ‘minimum’, and not the ‘viable’:
Building something so small that it doesn’t even meet your goals/needs. Instead, have laser-focus on the ‘viable’, and figure out how to do it quickly.
There’s a longggg list of ‘common mistakes to avoid’ – I could do a whole post about it. But, let’s wrap this up, start a discussion thread and build on it.
🚨 ANNOUNCEMENT 🚨
Save the date!! Wednesday, Dec 6
Next week, I’ll be releasing the very first PTS podcast episode with Adam Cheyer – inventor of Siri. Adam joins me to talk about ‘picking the right idea at the right time’.
We walk through his strategies, frameworks, and learnings when it comes to building some of the world’s most notable products – Siri, Bixby, Change.org, Sentient, and recently Gameplanner.ai (sold to Airbnb for $200m).
My release schedule will also be changing slightly. I’ll alternate a newsletter essay and podcast episode each week.
Both will be released via my Substack. Make sure you’re subscribed to get notified.
If you enjoyed this or learned something, then please subscribe. If you know anybody that would get value from it, then please share. Your support goes a long way in helping me arm the next generation of founders with the tools to win.
How was this post?
Reply to this email with one of the following:
🔥 – I loved it!!
👍 – Good, not great
👎 – Could be better (let me know in your email)
For the love of startups,
Tim