Image depicting a line moving across the screen over abstract mountainscape.
tl;dr
Today's Minimum Viable Product (MVP) is about iterating early to build the highest quality competitor to an existing idea, not validating a novel one. This journey involves refining early ideas to compete in an existing market, narrowing the target audience, strategically using a waitlist for feedback, and recognizing indicators of early product-market fit.
The minimum viable product, as many founders know it, doesn't reflect the reality of how products get built today.
Building something valuable is no longer about validating a novel idea as fast as possible. Instead, the modern MVP exercise is about building a version of an idea that is different from and better than what exists today. Most of us aren’t building for a net-new market. Rather, we’re finding opportunities to improve existing categories. We need an MVP concept that helps founders and product leaders iterate on their early ideas to compete in an existing market.
When we started to build our MVP for Linear, we spent a lot of time talking to users, narrowed our audience, and tested what we were building. And it taught us some important lessons about our product (and building great products in general).
Below, I’ll discuss why building in today’s market requires an updated concept of the MVP, the importance of narrowing who you’re building for, the power of strategically using your waitlist, and some indicators you’ll see when you’ve found early product market fit.
The MVP is a journey, not one moment in time
The MVP is no longer about getting to the destination of a validated idea as quickly as possible. It may have been back in 2011, but today, the concept of an MVP describes the journey to the highest-value product vs. a sprint to the first mile marker of development.
The MVP as a practice of building a hacky product as quickly and cheaply as possible to validate the product does no longer work. Many product categories are already saturated with a variety of alternatives, and to truly test the viability of any new idea you need to build something that is substantially better.
The MVP as we knew it before
In 2011, Eric Reis described the MVP in his book The Lean Startup as:
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.
He conveyed that if you have an idea and you don’t know if it will succeed at market, you need to quickly build something to validate it. This validation could take many forms, such as a prototype, pamphlets describing your idea, or a commitment form. This worked years ago when you needed quick validation for a novel idea or service concept and there weren't as many existing variations of that idea.
For example, Airbnb wanted to build a service that relied on people being comfortable spending the night at a stranger’s house. When they started in 2009, it wasn’t obvious if people were ready for this. Today, it’s obvious that it works, so they wouldn’t need to validate the idea. A similar analogy works for Lyft when they started exploring ridesharing as a concept.
The MVP as it exists today
The MVP as we knew it vs how it is today
Today, the MVP is no longer about validating a novel idea as quickly as possible. Rather, its aim is to create a compelling product that draws in the early users in order to gather feedback that you then use to sharpen the product into the best version of many.
If you look at successful companies that have been founded in the last eight years–Zoom, Slack, TikTok, Snowflake, Robinhood–you see examples not of novel ideas, but of these highly-refined ideas.
Since many of us are building in a crowded market, the bar for a competitive, public-ready MVP is much higher than the MVP for a novel idea, since users have options. To get to this high bar, we have to spend more time refining the initial version.
Note
The original MVP idea can still work if you’re in the fortunate position of creating a wholly new category of product or work with new technology platforms, but that becomes rarer and rarer as time goes on.
Founders and product leaders must refine their visions and audiences and relentlessly iterate based on user feedback to build great products. The MVP process then becomes a journey to figure out if there’s something in an existing category the market wants improved.
Let’s jump over the regular startup journey that you might take today when building a new product:
- You start with the idea on how you want to improve on existing products in a category.
- You build your first prototype.
- You iterate with your vision and based on feedback from early users.
- You get an inkling of product market fit and traction.
- Optional: You start fundraising (with demonstrable traction).
- Optional: You scale your team, improve the product, and go to market.
The winding journey from idea to product market fit
The role of the MVP journey is to demonstrate your idea has potential in the market, and – if you’re not bootstrapping the journey yourself – get your startup ready to raise funds. And you have to do this with limited resources.
The importance of narrowing your users
The first key lesson we learned during our MVP process was to scope down who we were building for as much as possible.
In today’s landscape, you’re likely competing against many other products. To win, you have to build a product that provides more value to your users than your competition does.
To be able to do this with limited resources, you must scope down your audience (and thus your ambitions) as much as possible to make competing easier, and aim to solve the problems of specific people.
When we started Linear, our vision was to become the standard of how software is built. This is not really something you can expect to do during your early startup journey, let alone in an MVP. But you should demonstrate you have the ability to achieve your bigger vision via your early bets. We chose to do this by focusing on IC’s at small startups. We started with the smallest atomic unit of work they actually needed help with: issue tracking.
Something that helped immensely was that we were our own ideal customer profile. We could build a product for ourselves. We knew we wanted our product to demonstrate three values:
- It should be as fast as possible (local data storage, no page reloads, available offline).
- It should be modern (keyboard shortcuts, command menu, contextual menus).
- It should be multiplayer (real-time sync and teammates presence).
Once we had built something for ourselves that we thought was valuable, we needed real user feedback. This is an extremely important step of the MVP journey—don’t underestimate it. Engage with users, have conversations with real people, gather their insights and evolve from it.
Tip
Don’t just ask your friends though. When we first started, I did this and my friend came back and said his current solution was fast enough, he didn’t need shortcuts, and he didn’t care about multiplayer.
The power of the waitlist
After the prototyping stage and getting some small group feedback from early users, you need to build awareness around your product to get a bigger pool of people interested in your product and ready to try it out. One way to achieve this is to build a waitlist of target users, invite them in small groups, learn from what they do with the product, interview them, and get feedback and insight into shortcomings.
The second lesson we learned: The waitlist is a great tool to maintain the narrow focus and bring in the right kind of early adopters.
How to build your waitlist
To build your pool of beta users to learn from, you need some mechanism for amassing a waitlist with a large variety of users or a smaller, targeted list with just the right people.
There are a few ways to go about this, but the quickest (if you’re able) is to leverage your social following. If you don’t already have a social platform to build from, partnering with leaders in your personal network, investors, and community influencers can help you reach the right people. The goal is to create a list of people who are interested in what you’re building, and who you can pressure test your product against to refine it into something great.
Remember, you’re likely not building a revolutionary or novel product. You’re unlikely to go viral with your announcement, so you need a network of people who understand the “why” behind your product to help spread the word to drive people to sign up. Any product category has many people who are frustrated with the existing tools or ways of working. Ideally you find and are able to reach out to those people.
How to use your waitlist to build a high-impact product
Draw from your waitlist over time to continuously refine your product before launch.
Once you have a bunch of people on your waitlist, you need to invite the right users at each stage of your iteration. You want to invite people who are likely to be happy with the limited set of features you’ve built so far. Otherwise, they’ll churn straight away and you’ll learn nothing.
To do this, we asked people a few basic questions when they signed up onto our waitlist:
- What’s the size of your company?
- What’s your role?
- What project management solution are you currently using?
- What version control system are you using?
- Why do you want to try Linear?
- What’s your pet peeve with current solutions?
We only had a GitHub integration to start, so we filtered the responses to make sure we were only inviting people who could actually use the product. We then handpicked founders of small companies with pet peeves we were already addressing. Founders are usually happy to chat and are also more forgiving if functionality is missing (if they believe in the direction of the product). This gave us a good initial user set that didn’t churn, and that we could have frequent conversations with to understand the shortcomings of our prototype.
Then, you start addressing the feedback of your early users and prioritize functionality accordingly. When your users stop asking for new features, this is a good indication it’s time to pull in more people from the waitlist and expand your target segment a bit as well.
From here, you repeat the cycle, inviting more users from new target audiences, learning from how they use the product, and incorporating their feedback. You effectively turn your waitlist into a more refined product that caters to an ever growing audience.
Indicators you’re ready for public launch
Knowing you’re ready to launch your product publicly comes down to testing user sentiment and trusting your gut.
Here are three ways to go about testing user sentiment:
- Meet with users via Slack, Zoom, or in person and figure out how happy they are
- Use a product-market fit questionnaire (and ask how they would feel if they suddenly couldn’t use your product tomorrow)
- Ask users to pay (the ultimate test)
To test willingness to pay, we started with a pay-if-you-want model. Users didn’t have to pay to use Linear during beta, but if they went into their settings, they found a “Friends of Linear” plan offering nothing more than our gratitude.
After using these methods for a year, we gained the confidence we needed to launch publicly (and then asked users to subscribe to a real paid plan).
Public launch and beyond
Once you’ve demonstrated value to and incorporated the feedback from your early users, you’re probably ready to open up access and launch publicly. You can continue to use this MVP journey model as your product grows to test new features and offering out with existing customers or new user segments.
To recap:
- Narrow down your initial audience and build for them: Figure out who you're building the product for and make the target audience as small as possible before expanding.
- Build and leverage your waitlist: The waitlist is the grinding stone with which you can sharpen your idea into something truly valuable that will succeed at market, so use it effectively.
- Trust your gut and validate demand with your users: Talk, talk, talk to your users and find out how invested in the product they are (and if they’d be willing to pay)
And, of course, I’m available on X @artman for questions and thoughts.