{"id":15555,"date":"2022-12-27T18:18:56","date_gmt":"2022-12-27T15:18:56","guid":{"rendered":"https:\/\/railsware.com\/blog\/?p=15555"},"modified":"2026-02-24T13:30:14","modified_gmt":"2026-02-24T10:30:14","slug":"what-comes-after-an-mvp","status":"publish","type":"post","link":"https:\/\/railsware.com\/blog\/what-comes-after-an-mvp\/","title":{"rendered":"What to Do With Your Startup After an MVP"},"content":{"rendered":"\n
After launching an MVP, startups are often faced with a daunting question: \u2018Now what?\u2019 At Railsware, we\u2019ve spent the past 15 years refining our approach to product development and growth. So in this article, we\u2019ll share suggestions on what to do after you\u2019ve launched your MVP. We\u2019ll also explain how to measure its success using metrics and feedback indicators. But first, let\u2019s look at the reasons why every startup should build an MVP\u2026<\/div>\n\n\n
\n
\"\"<\/figure><\/div>\n\n\n

What is an MVP and why should you create one?<\/h2>\n\n\n\n

A minimum viable product (MVP) is a barebones version of your product, designed to satisfy the basic needs of your target audience.<\/p>\n\n\n\n

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<\/a> is the most efficient way to achieve two major startup objectives: establish a market presence and gather feedback from early adopters.<\/p>\n\n\n

\n
\"\"<\/a><\/figure><\/div>\n\n\n

Why it pays to start small<\/h3>\n\n\n\n

Every new enterprise is susceptible to running out of cash, building a product that nobody wants, or losing out to the competition. It\u2019s impossible to eliminate all risks in a startup environment, but there are some steps you can take to minimize the chance of failure.<\/p>\n\n\n\n

At Railsware, we leverage the Lean startup<\/a> agile approach<\/a> to give our products the best shot at success. We’ve based our data-driven development process<\/a> on Lean principles, and always start with the MVP, since it helps us:<\/p>\n\n\n\n

Find a product-market fit. <\/strong>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.<\/p>\n\n\n\n

Increase our speed to market.<\/strong> It’s much faster to build an MVP than a full-fledged product, thanks to the MVP\u2019s reduced scope and limited functionality. Starting small gives us a competitive advantage since we\u2019re not attempting to create a \u2018perfect\u2019 product from the outset. Depending on the project, we aim to launch a barebones solution in a matter of weeks\/months.<\/p>\n\n\n\n

Conserve limited resources. <\/strong>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\u2019ve 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.<\/p>\n\n\n\n

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.<\/p>\n\n\n\n

Here\u2019s what the new product development process<\/a> looks like at Railsware:<\/p>\n\n\n

\n
\"\"<\/figure><\/div>\n\n\n

But what does \u2018product growth\u2019 actually look like after the MVP stage? To understand how an MVP evolves into a full-fledged product, we must explore the latter\u2019s 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.<\/p>\n\n\n\n

Minimum Marketable Product (MMP)<\/h3>\n\n\n\n

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.<\/p>\n\n\n\n

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.<\/p>\n\n\n\n

Minimum Lovable Product (MLP)<\/h3>\n\n\n\n

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\u2019t 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.<\/p>\n\n\n\n

The MLP may include one or two new features requested by early adopters, and\/or improved functionality. At the very least, it\u2019s easy to use, has an impressive UI, and covers all of the users\u2019 pains.<\/p>\n\n\n\n

Unlike its variations, the MLP sets out to turn enthusiastic early adopters into loyal customers \u2014 especially in markets where competition is fierce. The \u2018cat food\u2019 analogy from Brian De Haaff, author of Lovability<\/em><\/a>, explains how the MVP falls short of the mark in this respect. He says \u201c(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.\u201d So, while the MVP gets the job done, the MLP hooks users and keeps them coming back for more.<\/p>\n\n\n

\n
\"\"<\/figure><\/div>\n\n\n

Practical steps to take after releasing an MVP<\/h2>\n\n\n\n

While it might be tempting to jump straight into MMP or MLP development after launching your MVP, we definitely don\u2019t recommend it. Now is the time to step back, review your progress, and take organized action to increase your MVP\u2019s chances of success.<\/p>\n\n\n\n

Here are some of our suggestions on what to do after launching your MVP\u2026<\/p>\n\n\n\n

Promote the MVP<\/h3>\n\n\n\n

Your target audience won\u2019t be able to test the product unless they know it exists. So let\u2019s look at some cost-effective ways to get eyes on your MVP, fast:<\/p>\n\n\n\n

    \n
  1. Launch on an enterprise marketplace. <\/strong>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<\/a> and TitanApps<\/a>) using this strategy.<\/li>\n\n\n\n
  2. Submit to startup platforms and deals websites. <\/strong>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.<\/li>\n\n\n\n
  3. Self-distribute via forums\/social media. <\/strong>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<\/a> is just one example of an entrepreneur who has mastered this approach to MVP promotion.<\/li>\n<\/ol>\n\n\n\n

    Gather user feedback<\/h3>\n\n\n\n

    After you\u2019ve promoted the product in the right channels and experienced some traction (ie. an increasing number of signups and active users) it\u2019s time to request feedback from early adopters.
    As you begin collecting user data through surveys and support channels, it\u2019s also wise to review your privacy practices – running a     GDPR audit<\/a> early on can help ensure you\u2019re handling feedback data in a compliant and transparent way.<\/p>\n\n\n\n

    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; it isn’t necessary to use enterprise help desk<\/a> software to get valuable feedback at this stage. 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 \u2014 but it doesn\u2019t give us the full picture. That\u2019s why we always conduct customer development interviews shortly after launching the MVP.<\/p>\n\n\n\n

    Conduct customer development interviews<\/h3>\n\n\n\n

    When it comes to learning more about the needs, motivations, and expectations of customers, nothing beats sitting down and talking to them. Customer development<\/a> or CustDev interviews are 1:1 online meetings between a product manager and an active user.<\/p>\n\n\n\n

    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.<\/p>\n\n\n\n

    An easy trick to maintain ongoing relationships is to share a smart business card<\/a> with participants, allowing them to easily access contact information, feedback forms, schedule future sessions, or join product update notifications.<\/p>\n\n\n\n

    Run a product discovery or BRIDGeS session<\/h3>\n\n\n\n

    Running additional product discovery<\/a> 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<\/a> framework for ideation and complex decision-making.<\/p>\n\n\n\n

    Sessions are typically held on virtual whiteboards (check out our FigJam template<\/a>), 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.<\/p>\n\n\n\n

    The Problem Space is where we dive deep into the problem context and start describing it in detail. Problem descriptors are categorized as so:<\/p>\n\n\n\n