When starting a software company and building the very first version of the application (known as Minimum Viable Product or MVP), your business has the highest chances of failure.

A startup can fail for any reason. Your goal as a founder is to minimize risks and tolerate a level of ambiguity as you build your company. This balance becomes easier the longer your business survives. Although, it’s actually never easy, so let’s say less difficult instead.

Before you can build a company, you have to build a product. But how much of the product should you initially build, and in what order? This is why the term “minimum viable product” exists in startup and software culture. Founders consistently struggle to decide how much of their early product to launch and often build too much.

Most businesses fail within their first year. Not spectacularly, but by fading quietly as they focus on the wrong success metrics and features. At Lightmatter, we’ve partnered with dozens of founders to create their MVP. Some have been successful, but many haven’t. Having been through the discovery, design, development, and launch of products with founders enough times, we’ve noticed patterns emerge from the ideas that turn into a successful business.

Below are insights to consider before, during, and after building an MVP.


Pre-MVP: Confirming Product Market Fit

Some founders build startups to solve their own needs, which is a great signal for success. But many don’t - they build software to solve someone else’s problem without data to show that a problem even exists.You’d be surprised how many founders decide to invest hundreds of thousands of dollars (usually of other people’s money) into building a software product where the core problem hasn’t been validated or even identified.

Founders with just an idea and no proof do not need to build an MVP. Instead, they need to create what we describe as a “Product Not Included” MVP.

Rather than building the first version of their software product, founders should build to test just the idea of their product. We call this a Product Discovery Sprint at Lightmatter. You also might hear it called a Product Research Sprint or a Product Design Sprint. Regardless of the name, there are two goals of this Sprint: confirming the assumed problem exists, and validating if users will pay for it to be solved with the solution you’re building.

To do this, use a mix of surveys, competitive research, and low-code and no-code tools to create a data argument validating the problem and solution. As a founder at this stage, you should only be focused on finding a signal. You need to identify if what you’re offering is valuable to users. You should not worry about your logo, brand, company name, copywriting, marketing, or anything even remotely related to technology platforms.

This can be accomplished with a combination of the following, depending on the type of product:

  • Survey the target audience by asking questions about the problems experienced, preferred solutions, and willingness to pay through a mix of written, audio, and video recordings.
  • If selling a physical good, create a landing page that allows consumers to pre-purchase the product before it’s actually assembled.
  • If selling software, build a signup page as a waitlist for beta testers to try your product. You can A/B test planned features, landing pages, prices, etc.
  • Leverage no-code and low-code tools like Slack, email newsletters, Zapier, Twitter, Webflow, and out-of-the-box community platforms to grow a niche community and build an audience around the problem you’re solving to help validate product ideas and solutions. Reddit, Hacker News, Facebook Groups and other Q&A online forums are great places to find and build these communities.

greg_isenberg.png


All of these experiments will communicate demand or a lack of it. In every instance, the product of the Minimum Viable Product does not actually exist yet. And like Greg Isenberg notes, there are opportunities in plain sight if you know where to research. At this stage, it’s all about finding out if your startup idea has legs to stand on.


MVP: It’s Time To Build (But Less)

Only after you have data to backup your idea should you start building your product. But be careful about how much you create. While first impressions of your product are important, this shouldn’t be your ideal version to launch with. In fact, it should have a lot less. You should feel angst about everything that’s missing from it.

The objective of an MVP is to build the minimum product necessary to solve the user’s problem - not one that is beautiful or perfect.

For example, take a look at the landing pages of these 4 companies. They’re Twitter, Airbnb, and Uber, and Facebook if you can’t tell. Granted, web UX and UI were very different in the mid 2000's, but all launched with a fraction of the features you’d expect these billion dollar companies to have first started with.


mvps.png




However, if you’ve completed a strong Product Discovery Sprint and have compelling data on what the user wants, you can build a MVP with more polish and thought put into the design. Don’t confuse a well designed (UX and UI) product with the number of product features you’re offering in the MVP though. Founders usually mistakenly believe two things at this stage:

  1. Users won’t pay for or use their product without a “complete” set of product features.

  2. More time is needed to perfect the aesthetics, functionality, and overall quality of their product before launching.

Sometimes these fears come from a misunderstanding of one’s audience. Rather than creating a product that does 1 thing well for 100 users, the founder wants to create a product that does 3 or 4 things kind-of-well for 1000 users. Or the founder is unsure which direction the product will take and wants to hedge the product with multiple features.

Our advice here is...well...it’s messy. We’ve seen founders start their company and succeed by focusing on just one core feature or workflow, as well as by building many features for a product.

Some companies even pivot to an entirely different business. The founding story of Slack highlights this best. Slack began as an internal chat tool for Tiny Speck, a company Stewart Butterfield was building that developed online games. After launch of their premier game, Glitch, in late 2011 and its failure to attract a large enough audience and players, Glitch closed down. Tinyspeck, however, continued developing a custom-built chat tool to allow their team to communicate remotely while spread across multiple time zones. By May 2013, Tinyspeck had 45 companies trialing the product called Slack, or a “Searchable Log of All Communication and Knowledge.”

Rather than prescribing a solution as to which approach is best, we’d rather offer a heuristic: assume you’re launching with too much. If you’re building just one feature, build a simpler version of it. If you’re building a few, eliminate one or two and launch sooner.

For whichever option you take, it’s important to keep in mind the following: don’t worry about the technical choices that make up your actual product yet. There’s no perfect programming language or framework that is going to make or break your business at this stage. Rather, you should be more concerned about the quality of code than the tools being used to write that code. Even though a MVP is still the very first version of your product, it still needs to work. And poorly structured code without tests, documentation, and with hard coded variables can disrupt the experience of your first users.

At this phase, it’s most important that you confirm the product you built is the right solution for the user’s problems and receive this feedback as early as possible.

Post-MVP: Matching And Measuring

After you launch an MVP, it’s critical to amplify and measure the signal you’ve found with your users. This phase has the most distractions, and founders can mistakenly focus on the wrong metrics, process, and feedback from users. In doing so, they continue to develop a product users like, but one that doesn’t actually capture the value it creates for its users. Well known examples include companies like Twitter, where despite being one of the most effective distributors of information their largest source of income is only through ad revenue since the product is free to use.

In our experience, the most successful founders are able to:

  1. Transition the MVP to a more polished product that introduces new features without distracting users from the core offering.
  2. Balance conflicting user feedback with their own long-term vision of the company to create a loved product in a way users don’t expect.

Let’s break each of these down further.

If you built the MVP properly, your product should not have the best UX or UI just yet. In fact, a lot should be missing. Maybe you haven’t included a settings page for users given the beta test is limited to 100 users and all updates can be made manually by an admin. Or maybe you decided to only build 1 side of a 2-sided marketplace. For example, you may have built a niche jobs board website and are manually curating the jobs presented to site visitors instead of letting employers post their own.

After the MVP, it’s time to round out the product and slowly introduce the features you wanted to include in that first version but didn’t. Updates can be to the application UX and UI, the company brand, the product features, or even the company name itself. To do this, make a prioritized list of all the features and meet with your design and development teams to identify the difficulty and impact of each of these changes.

Then, schedule this work with your team, but remember to leave time for unplanned tasks. Most founders don’t budget time for what we call “emergent” work. This is time reserved for bug fixing, tasks taking longer than expected, and unexpected software, design, or team issues.

As you layer in these changes over the coming weeks, you’ll receive feedback from users and your team. The best founders can process this feedback and balance it with the long-term vision of the company they’d like to build. They know that if they don’t listen to users at all, their product will fail. But they can’t fully bend to their user’s wishes, or the product will be too niche or customized for that one specific customer persona. Feedback is only helpful unless it’s measured, which can easily distract a founder and pull their focus in the wrong direction. When do you listen to yourself versus your users?

There’s a frequently referenced public debate about how to frame this discussion: should founders build products that users want and love, or should they build a product the users are going to want? How do you balance the practicality of an immediate solution with the vision of a future product that you have as a founder?

The right strategy is to listen to your users and build a product they love but in a way they didn’t expect. Surprise and delight of a product weigh heavily in the unconscious minds of most consumers. Lean into the data and feedback you receive from users, and use that to build an experience they didn’t know they wanted. The thought of sleeping in a stranger’s house (Airbnb) or getting into a stranger’s car (Uber) both seem unusual at first, but the right brand, product, and experience can unlock revenue in the places least expected. Your company is still in its earliest stages, and with this advantage you can take small risks to pivot and adjust the product to it’s ideal version.


Launch Sooner, Launch Simple

The most important, and also the most difficult, startup advice to follow is to keep things simple. When building the first version of your product, keep in mind the following:

  • Learn about your audience first through a data driven approach rather than with anecdotes or personal experiences. Be ready to have your own assumptions challenged. Your first actions should be to validate both that a problem exists and potential solutions for it.
  • Understand that to build and launch a Minimum Viable Product, it needs to be minimum but viable. You can build a few features and experiment, or just one really well, but remember to build less than expected so you can launch and measure the results sooner.
  • Polish your product after you launch, and slowly introduce new and better features to amplify the signal you’ve hopefully found. Balance the long-term vision of the company along with the immediate, practical feedback you receive from users.

Don’t be afraid to deviate from any advice you receive either, even this. The most promising startups are ones that don’t always follow traditional advice. Being equipped with it just gives you a head start.