After launching an MVP, startups are often faced with a daunting question: ‘Now what?’ At Railsware, we’ve spent the past 15 years refining our approach to product development and growth. So in this article, we’ll share suggestions on what to do after you’ve launched your MVP. We’ll also explain how to measure its success using metrics and feedback indicators. But first, let’s look at the reasons why every startup should build an MVP…
What is an MVP and why should you create one?
A minimum viable product (MVP) is a barebones version of your product, designed to satisfy the basic needs of your target audience.
Defined by its skeletal feature set and limited functionality, the purpose of an MVP is to help you find a product-market fit. In our experience, building an MVP is the most efficient way to achieve two major startup objectives: establish a market presence and gather feedback from early adopters.
Why it pays to start small
Every new enterprise is susceptible to running out of cash, building a product that nobody wants, or losing out to the competition. It’s impossible to eliminate all risks in a startup environment, but there are some steps you can take to minimize the chance of failure.
At Railsware, we leverage the Lean startup agile approach to give our products the best shot at success. We always start with the MVP, since it helps us:
Find a product-market fit. The size and simplicity of the MVP make it ideal for testing assumptions about user problems and user experience. It enables us to stay flexible and adapt our solution to user needs early in the product development process.
Increase our speed to market. It’s much faster to build an MVP than a full-fledged product, thanks to the MVP’s reduced scope and limited functionality. Starting small gives us a competitive advantage since we’re not attempting to create a ‘perfect’ product from the outset. Depending on the project, we aim to launch a barebones solution in a matter of weeks/months.
Conserve limited resources. Creating an MVP is a cost-effective way to test product hypotheses. It prevents us from investing too much time, effort, and capital into the solution before we’ve confirmed whether people want it. For reference, we typically spend about 30-50% of our overall budget on developing the MVP and save the rest for further development and promotional efforts.
Our product team at the MVP stage typically consists of a product manager, product designer(s), and a small group of developers. For specific challenges, it can be enhanced with data analysis, quality assurance, and marketing specialists. The team gradually expands as we move beyond MVP testing and start growing the product.
Here’s what the product development process looks like at Railsware:
But what does ‘product growth’ actually look like after the MVP stage? To understand how an MVP evolves into a full-fledged product, we must explore the latter’s two most common variations: minimum marketable product and minimum lovable product. Although these concepts are sometimes used to replace the MVP entirely, we actually consider them to be the next steps in the product pipeline.
Minimum Marketable Product (MMP)
The MMP is a bare-bones version of your product that is good enough to attract paid users. It includes key changes or additions which have been implemented based on feedback from the MVP stage. More often than not, the MVP serves as the foundation of the MMP.
If the MVP is a stripped-down representation of your product idea, the MMP is its savvier, more confident cousin. It may have increased stability and functionality, but most importantly, the MMP has a billing system. This payment functionality is essential for testing whether or not users are ready to pay for your product. You can start offering discounts to early adopters or running A/B tests on your target audience to check how much they are willing to pay for your solution.
Minimum Lovable Product (MLP)
As the name suggests, the goal of the MLP is to give your target audience a product that combines lovable (minimum) features with an enjoyable UX. While it doesn’t have all the bells and whistles of a full-fledged product, the MLP has a strong value proposition and fewer kinks than its MVP/MMP predecessors.
The MLP may include one or two new features requested by early adopters, and/or improved functionality. At the very least, it’s easy to use, has an impressive UI, and covers all of the users’ pains.
Unlike its variations, the MLP sets out to turn enthusiastic early adopters into loyal customers — especially in markets where competition is fierce. The ‘cat food’ analogy from Brian De Haaff, author of Lovability, explains how the MVP falls short of the mark in this respect. He says “(although) you could eat a can of cat food if you really had to, it is unlikely you would be clamoring for a second serving.” So, while the MVP gets the job done, the MLP hooks users and keeps them coming back for more.
Practical steps to take after releasing an MVP
While it might be tempting to jump straight into MMP or MLP development after launching your MVP, we definitely don’t recommend it. Now is the time to step back, review your progress, and take organized action to increase your MVP’s chances of success.
Here are some of our suggestions on what to do after launching your MVP…
Promote the MVP
Your target audience won’t be able to test the product unless they know it exists. So let’s look at some cost-effective ways to get eyes on your MVP, fast:
Launch on an enterprise marketplace. If it makes sense to release your MVP as an add-on, then marketplaces such as Atlassian, Microsoft Azure, or Google Workspace Marketplace are excellent springboards. They lend your solution credibility, come with a built-in audience, and allow you to quickly monetize. In fact, we grew two of our own startups (Coupler.io and Smart Checklist) using this strategy.
Submit to startup platforms and deals websites. Listing your MVP on platforms like Appsumo or Product Hunt is one of the best ways to reach a SaaS-oriented audience. Users of these platforms are more likely to fall into the innovator customer segment; they are more open to experimenting with new products and are more forgiving of bugs and kinks.
Self-distribute via forums/social media. Suggest your product in Hacker News/Reddit/Quora comment threads where people are experiencing a problem your MVP can solve. Founders or product owners with large social media followings can also benefit from sharing the product (and requesting feedback) on channels like Twitter/LinkedIn. Pieter Levels is just one example of an entrepreneur who has mastered this approach to MVP promotion.
Gather user feedback
After you’ve promoted the product in the right channels and experienced some traction (ie. an increasing number of signups and active users) it’s time to request feedback from early adopters.
The goal is to find out what their pain points are as quickly as possible and start using that data to inform iterations on the product. We collect this information via surveys, customer support interactions, and online forums. For example, when we were testing assumptions about our product Mailtrap, we used tools such as Typeform, Twitter, and UserVoice to gather feedback. Overall, this helps us pinpoint what customers like and dislike, and what they want to see — but it doesn’t give us the full picture. That’s why we always conduct customer development interviews shortly after launching the MVP.
Conduct customer development interviews
When it comes to learning more about the needs, motivations, and expectations of customers, nothing beats sitting down and talking to them. Customer development or CustDev interviews are 1:1 online meetings between a product manager and an active user.
During those sessions (which last anywhere from 30 minutes to 1 hour) we ask customers open-ended questions about their interactions with our MVP, such as their impression of the user experience or what kind of functionality they feel is missing. We take detailed notes and combine our interview findings into a spreadsheet. Analyzing correlations in the responses helps us figure out what to improve, what to drop, and which direction will bring us closer to a product-market fit.
Run a product discovery or BRIDGeS session
Running additional product discovery sessions allows you to gather ideas for new features, analyze potential risks, refine your product vision, and prepare for product growth. At Railsware, we use the BRIDGeS framework for ideation and complex decision-making.
Sessions are typically held on virtual whiteboards (check out our FigJam template), where we use colored cards to denote Subjects (can be a user, role, strategy, etc.) and describe the problem through Benefits, Risks, Issues, Domain knowledge, and Goals. Between 2 to 8 people take part in a session, including the product owner, members of the development and design teams, and industry experts/potential users. We divide the board into two parts – Problem Space and Solution Space – and kick off a session in the former.
The Problem Space is where we dive deep into the problem context and start describing it in detail. Problem descriptors are categorized as so:
Benefits: The value a subject can derive from the future solution. Indicate with green cards.
Risks: Issues that a subject may face in the future. Indicate with yellow cards.
Issues: Existing problems that a subject is/will be affected by. Indicate with red cards.
Domain Knowledge: Any information that helps provide context; things to keep in mind. Indicate with violet cards.
Goals: The expected outcome of the future solution. Indicate with blue cards.
To demonstrate what the Problem Space looks like in practice, let’s take Uber as an example (imagining that it doesn’t exist yet). In the visualization below, Uber has three subjects or beneficiaries: the Driver, the Passenger, and the company itself. Problem descriptors have already been prioritized using the MoSCoW framework (more on that later).
After prioritization, the next step is to move into the Solution Space. This is where we come up with high-level solution variations for each subject and break them down into epics and nested tasks. They should be color-coded but don’t need to conform to the previous theme. Using the Uber example, here’s what the space might look like when we’re exploring the Mobile App solution variation:
Afterward, we create a product roadmap using the epics and tasks defined in the Solution Space. This helps us stay on track as we continue to plan and work on future product iterations. So, by the end of a session, our team has a solid idea of how to move forward (whether that’s getting to work on a new feature[s], adjusting the MVP pricing model, or launching a new promotional campaign).
Prioritize features
Product discovery, feedback, and customer development usually provide us with several ideas for possible features. However, not all of those features have the potential to add real value to the product. Nor will we have the time and resources to build all of them. In the words of The Lean Startup author, Eric Ries, value is ‘providing benefit to the customer; anything else is waste.’
So when it comes to making product improvements, it’s crucial to prioritize features according to customers’ needs (while keeping in mind your team’s capacity to execute them). We recommend using the MoSCoW prioritization technique to prioritize features during early product development as well as throughout the entire product lifecycle.
The letters in MoSCoW (except the o’s) stand for Must, Should, Could, and Won’t. When prioritizing features, we separate the must-haves from the nice-to-haves by assigning a term to each one. Here’s what they denote:
Must – Project cannot do without them
Should – Required in the long run
Could – Low-cost tweaking
Won’t – Get back to them on better days
This framework helps us quickly narrow down the product backlog and focus on building features that provide genuine value to customers.
Build a product roadmap
If you don’t already have a product development roadmap, now’s the time to build one. Having a strategic plan in place will ensure that your engineering, design, and marketing efforts stay aligned with your startup objectives. At Railsware, we typically use the aforementioned BRIDGeS framework to generate roadmaps before and after MVP release. It lets us break down solutions into epics and nested tasks, and quickly transform them into a roadmap or implementation plan.
How to measure the success of your MVP
How do you know if your MVP has succeeded or failed? While there’s no straightforward answer to this question, we use a combination of analytics and feedback to understand how well our product has performed.
The importance of analytics dashboards
Without a product dashboard, it’s virtually impossible to track, quantify, or take reasonable action on the data you are receiving. That’s why before launching an MVP, we recommend choosing your product metrics carefully and building a dashboard around them.
After product launch, the dashboard becomes one of the most important tools at our disposal. It lets us examine how users are interacting with our MVP so we can make data-driven decisions when iterating on the product. The dashboard also enables us to catch changes in user behavior (e.g. sudden increase in churn, decrease in users activating their accounts) and investigate those issues before they blow up. Ideally, every product manager/startup founder should book time in their calendars daily/weekly to review the dashboard and gather insights.
Key startup metrics
When choosing startup metrics at Railsware, our product managers often leverage the AARRR or ‘pirate metrics’ framework. AARRR (which stands for Acquisition, Activation, Retention, Referral, and Revenue) is useful for checking how users are engaging with your MVP at every stage of the conversion funnel.
Since an MVP isn’t a full-featured product, we must adjust the conversion funnel (and AARRR framework) to reflect this. For instance, Revenue metrics aren’t relevant for all types of MVPs i.e. those that haven’t been monetized yet. Meanwhile, Referral usually comes into play at the MLP stage, since emotionally engaged customers are more likely to join referral programs.
On that note, here are a few important metrics to track when measuring the success of your MVP. The table includes elements of the AARRR framework and other vital metrics.
| Metric | What it tells you |
| Acquisition | The number of people who were drawn to your product via promotional efforts. A high acquisition rate indicates that people are interested in what your MVP has to offer. |
| Customer acquisition cost (CAC) | How much it costs to acquire a new customer. High CAC might indicate that one or more of your promotional efforts aren’t sustainable. |
| Activation | The number of signups your product has received. It can also refer to the number of people who have actually started using the product. |
| Retention | The number of users who remain active after signup. A steady retention rate indicates that user engagement is high and your MVP already brings value to customers. |
| Churn | The number of people who stop using your product. Like retention, a low churn rate indicates that your product delivers a valuable user experience. A high churn rate might indicate that something is missing. |
| MRR | Stands for monthly recurring revenue. It’s unlikely that MRR will be high at the MVP stage since it’s a fledgling product, but over time, it’s a good indicator of how well your product is performing on the market. |
Feedback as a metric
As we previously discussed, feedback is an extremely important part of MVP validation. Dashboards can only tell us so much about the overall health of our product, which is why we consider customer input to be an essential metric.
Let’s take one of our products, Mailtrap, as an example. Mailtrap is email delivery platform that allows software developers to test and send emails. Ever since we released the MVP several years ago, user feedback has helped the Mailtrap team iterate effectively and carve out new directions for growth.
Some examples of that feedback are “Would it be possible to have an email address for each testing inbox in Mailtrap?” or “Would you consider adding a way to configure hard and soft bounces?” Suggestions like these show that users truly engage with the platform and are interested in what else Mailtrap might offer. While the team has been careful not to implement all pieces of feedback, they continue to pay close attention to requests from the development community — and overall, this ‘feedback as a metric’ focus has paid off.
For more on startup metrics, check out our full guide on how to choose the best metrics for your business.
Avoid vanity metrics
One of the biggest mistakes you can make while measuring the success of your MVP is paying attention to vanity metrics i.e. numbers that make you look good but don’t represent the truth about your product’s health. Examples are social media followers, site impressions, number of downloads, site views, and so on. Sure, these statistics can be helpful for getting the full picture of how well your MVP is performing on the market. Just don’t place too much faith in them.
Developing products after the MVP stage – Railsware experience
Here are just a couple of times when we grew a product beyond the MVP stage…
Coupler.io example
The MVP of our data integration tool, Coupler.io, hardly resembles the present-day version of the product. Coupler.io began as a simple Airtable to Google Sheets data importer (Gsheets add-on) that our team built for internal use only. As our needs expanded, the product grew into an ‘anything’ importer.
Following extensive market research and customer development, we decided to release Coupler.io as a standalone product. At that point, it was marketable and already had a core function — to facilitate data imports from apps like Airtable/Jira/Pipedrive to Google Sheets. In the two years since its launch, Coupler.io has grown into a full-fledged data management platform. Our product now supports 93 integrations and is trusted by companies such as Uber, WeWork, and Air Asia.
Tradezella example
Another example is Tradezella, an all-in-one trading journal founded by Umar Ashraf.
In the beginning, Umar cooperated with two external teams in order to create a functional product. However, the first rendition of Tradezella fell way short of his expectations. The product was unstable, had poor UX, and was missing crucial functionality. When Tradezella became a client of ours, we got to work refactoring the code, redesigning the UI/UX, and improving the product’s stability and performance.
The resulting MVP attracted scores of new users to the platform. Since then, we have worked closely with Umar to grow Tradezella into an MLP. We’ve gathered tons of user feedback and created new features, such as Replay, Zella Notebook, and Zella University, based on those validated learnings. The product now has enough features and functionality to wow early adopters.
Final Remarks
There’s no secret formula on how to grow an MVP into a unicorn. Most of the time, startups have to rely on tried-and-tested approaches to increase the likelihood that their product will reach a product-market fit. As we explained, building an MMP or MLP on top of an MVP is a strategic way to iterate on your product and grow a reliable user base. Meanwhile, promoting your MVP, systemically gathering feedback, conducting customer development, prioritizing features, and building a product development roadmap are just some of the steps that you can take to boost your MVP’s chances of success.
Thanks for reading!! :) This article was originally posted on Railsware's blog!