[Editor's Note: We're excited to share this article from Women in Product, originally published on their blog.]

How do I know when Minimum Viable Product has reached Minimum Marketable Product? I struggle with determining when to cut scope and ship. What can I do to ship with confidence?

Answer from Dani Renaud, Product Strategist and CSPO at Cherwell Software

Being in product is a tough gig — we have to figure out if our product goals are too much or too little, when to stop developing, or when to go forward. So when is “enough” enough?

When you begin development, your product will typically provide a basic set of features to meet a need. These requirements can easily be considered MVP or minimum viable product, but how do you get to MMP, the minimum marketable product?

MVPs are your iterations towards a product that is the smallest feature set that meets your users’ needs and one with which you feel confident making a marketing splash (MMP).

Getting to your MVP

Let’s use an ice cream machine as an example: As a restaurant owner, I’d like to sell ice cream so that my patrons can enjoy dessert after their meal.

You’ve decided to fill this need through the use of an ice cream machine. Here are the requirements:

• It needs to keep the ice cream cold.
• It needs to hold enough ice cream to serve fifty customers.
• It needs to easily dispense ice cream into a cup or cone for fast delivery.

Easy enough! As you and your team run through a sticky-note exercise, you uncover some great possible additions. For example:

• It has space for three different types of ice cream.
• Users can adjust the temperature.
• It can dispense ice cream via a button or a lever.
• It can hold toppings that users can add to their ice cream.

The first three requirements meet the basic need, but you know that users will likely need more than just those three for your ice cream machine to be competitive. You also feel that storing your own toppings might be too much, but you’re not certain of this.

You dig in further with your team and find that making the temperature adjustable is a small scope increase and absolutely worth the payoff at product launch, so you add this to your requirements. The lever turns out to be a much quicker implementation, so to help cut some of the time you’ve added with the temperature feature, you decide to skip the button. The UX team feels that the toppings would be a great experience, but this will drastically change the design. You feel it adds complexity and development time, so you have chosen to skip the toppings for now.

Congratulations! You just went through your first pass at defining your MVP. It was an internal iteration, but it helped clarify some things. This is what you’ve chosen as your ice cream machine’s feature set:

• It has an adjustable temperature for different ice cream mixtures which need different temperatures.
• It holds two gallons of ice cream (to serve fifty people, one scoop per person).
• It uses a lever to dispense the ice cream.

Getting to your MMP

The next step is to complete a soft launch and see how your users feel about your new product. This step can be achieved through user testing, a beta release, a limited launch, or an iterative first launch. The important thing here is that you follow a process that works for you and your team. If you need to go to market quickly, then consider a limited launch. If you have some time, conducting user testing is ideal.

While you can run these tests with a fully working product, it’s also acceptable to use wireframes, mock designs, or even just a sticky-note exercise. The more agile the shop, the smaller your test design needs to be so you can gather feedback to iterate on your idea. Netflix, for example, is constantly iterating and testing on various users in their production product.

At this point, you’ve taken the finalized requirements above and built a prototype that you’re now testing with your chosen group of users. You’ve gathered from user feedback that they dislike the lever, as it doesn’t allow for a consistent “pour” of ice cream. A button will allow for more precision. 

Your users feel two gallons (at one scoop per person) is good enough for fifty people, so there is no current need to increase the size of the tank. No one has even brought up the fact that storing toppings is necessary, so you feel comfortable having removed that from your MVP. The user group feels as though your product is similar to other products on the market, and they’re generally happy.

Now you head back to development and talk this over with the team. You all discuss the data and decide to fix the lever issue with a button. That change addresses the main concern, but you want your product to stand out, not blend into the market. More research shows that while everyone is satisfied with your basic features, no one else is offering a product that holds more than one type of ice cream.

So after further discussion, your team arrives at your target MMP:

• It has an adjustable temperature to keep the ice cream mushy enough to serve soft, but not dripping or frozen through.
• It has two one-gallon chambers for the ice cream.
• It can dispense two different types of ice cream.
• It uses a button to dispense the ice cream so the user can control consistency.

In some cases, you’ve reached the end of the process and have found your MMP. In other cases, you’ll realize you need to do this refinement step many more times. For example, you could discover after fixing the button problem that there are other issues or needs.

You’ll know you’ve found your MMP when you have identified the smallest set of features that your users will be satisfied with and you’ve created a product that can stand out in the marketplace by identifying a differentiator. Your product reached MMP because you took the time to test the idea both internally and externally. 

By building a prototype to conduct the tests instead of going directly to a full-fledged product release, you saved valuable time and money and were able to test the product’s viability before it ever went to market. You now have confidence that it not only fills the need, it is also competitive and can create some buzz.

Don’t be surprised if you find yourself thinking that your MMP isn’t enough. The last feature you cut will always be the hardest one to let go.

In Summary

Let’s recap the steps so you can apply this approach to your product. A lot of the steps described above are part of a typical scrum process, but it works well anywhere.

• Identify the need. Start by proposing a product idea for a need on which you’ve done a great deal of research.
• Decide on the initial feature set. Take that idea to your team and let them poke holes; you can do this with a sticky-note exercise or just a discussion. Trello or StoriesOnBoard are great for remote teams. Walk through the usage of that product to confirm your initial feature set. Does it still make sense or do you need to modify it?
• Get development estimates. Once you have your initial feature set, get some development estimates. Does the time and cost to develop still make sense? Modify again if needed.
• Get user feedback. When you have a scope you feel works with your time and resource constraints, take your show on the road. Call up some customers you have a strong user testing relationship with, talk to your customer advisory board, or just walk over to people in your organization who don’t typically use the product. Do some user testing with them, let them poke more holes in your plan.
• Refine, then repeat. Use the feedback from testing to help finalize your requirements — you can rinse and repeat the process as many times as you feel necessary. Cut out all the extra features that are nice-to-haves and prioritize features that meet the customer or user need that you’ve described which will set your product apart. In the end, you’ll arrive at a better feature set.

A final note: Don’t be surprised if you find yourself thinking that your MMP isn’t enough. The last feature you cut will always be the hardest one to let go. No one can completely define the MMP for you. It’s a feeling you get when you’ve cut enough scope but still managed to retain enough features to provide a fantastic user experience.

Answer from Lilia Gorbachik, Product Manager at Intermedia

If you are not sure if your MVP has reached MMP, it’s best to start at the beginning.

• MVP is Minimum Viable Product — the first product you could give your customers to try, which allows you to gather feedback so you can move forward or change your approach. To quickly check for MVP, ask: Did I do the right thing? Did I create the most straightforward solution for a real customer’s pain?
• MMP is Minimum Marketable Product — the product you can market and sell. To quickly check for MMP, ask: Did I bring enough value to make the product attractive to customers? Did I bring enough value to sell the product?

Could the MVP also be the MMP at the same time? It is possible, but in most cases, you iterate through several MVP versions before you reach MMP.

How do I achieve MVP?

To understand how to reach MVP, ask yourself: What kind of MVP will I market and launch?

• Is your MVP a new product for a new market? If you’re entering a new market, you need market research. Find your potential customers in whatever place they’re at. They could be in physical places like conferences, meetups, or industry training. They also could be in a virtual place, like a forum for real estate agents in Miami, or a Facebook group for mothers of twins in the Bay Area.
  
  When you find the right place, don’t just start pitching your idea. Instead, observe, listen, meet experts, and ask questions about their work and their lives. Gather information that would help you understand the motivations, values, and pain points of this group. Gain trust. Only after doing so would you proceed with sketches, manual processes, and prototype testing.
  
  Do not ask, “Do you like the product?” Instead, try questions like: “Would you pay me $10 for this product?” and “Would this product replace your current solution or solve your issue?”
• Is your MVP a new product for your current market? A new product is easier to launch if it is intended for your company’s main market segment. Use your data and knowledge of existing customers from the very beginning.
  
  Make an assumption, and then survey your existing customers to confirm or disprove it. If your assumption is true, then start interviewing your existing customers. This approach will save you a lot of time, effort, and money.
• Is your MVP a free feature inside a monthly or yearly subscription?This is the most simple scenario. Your MVP could be very close to MMP. Also, it is possible to leave the feature half-automated.
  
  For example, you could say that in order to perform a rare workflow, your customer needs to call the support team. It is easier to market a free feature inside a subscription, especially if the subscription includes a large list of features, not just two or three.
• Is your MVP a chargeable feature inside a subscription? It is easier to up-sell to an existing customer than it is to acquire a new one. When you provide enough value to your existing customer, she is more likely to buy your new feature. If you don’t have enough sales after launch, you will likely need to revise either the feature itself, or assess its price and positioning.

How do I know when I’ve achieved MMP?

Once you are confident that you’ve achieved a Minimum Viable Product, it’s time to confirm your Minimum Marketable Product.

To confirm that you have an MVP that evaluates as an MMP, ask yourself these questions:

• Is it clear to my customers which pain the product fixes?
• Do I have a story to tell?
• Does my MVP solve the general issue, or would the incompleteness of the solution create even more pain?
• Will customers shift gears to my product and change their daily routine?
• Do I know how my customers will migrate to my product, and how much said migration would cost? Do I need to provide data migration tools so my customers won’t have to create everything from scratch?
• Would customers pay for my MVP?

If you know at least the answers to these questions, then you are on the right path. If you have mainly “Yes” answers and you know how your customers will migrate from their current solution to your product, then you are ready to do a pre-launch test of the product.

How do I test my MMP?

A pre-launch test is an optional step that can help you make a final launch decision. You can think of it as an additional phase to your launch, like beta testing. Beta testing is a great tool not only for identifying product improvements, but also for testing the MVP and MMP scope and launch process within your customer base. If it’s a new product, then a beta test is a must. If it’s a small feature and setting up a beta test is expensive, then it is possible to skip this phase.

To test your MMP:

• Create a marketing message for your target audience. How does your message differ from those of competitors?
• Come up with pricing and packaging options that reflect your marketing message.
• Create a pre-order page to test your pricing, packaging, and marketing message. These pricing models and test results will provide the data for later decisions — both how to market and which price is competitive at an early stage.
• Consider offering a discount at this stage to attract your beta-test customers. Let customers vote for your MVP by spending their dollars.
• Set up easy feedback mechanisms. Aggregate and analyze the data. Feedback could be in the form of ratings or Net Promoter Scores (“Please rate our application from 1 to 10”). It could be a survey after onboarding. It could be an email that you send seeking feedback.
• Don’t forget to thank and reward your customers for their feedback.

Finally, don’t be afraid to show an early version to your beta customers, ask questions, and perform experiments. And consider this great reminder:

If you’re not embarrassed by the first version of your product, you’ve launched too late. — Reid Hoffman, co-founder of LinkedIn

Thank you to Allegra Bishop for editing this piece and to Merci Victoria Grace for allowing us to cross-post this article.