A minimum viable product is not always a startup’s most valuable player "Product people - Product managers, product designers, UX designers, UX researchers, Business analysts, developers, makers & entrepreneurs July 07 2022 False Case Study, Guest Post, Minimum Viable Product, Mind the Product Mind the Product Ltd 1058 Ideas,Inspiration,Concepts,With,Rocket,Lightbulb,On,Blue,Background.business,Start Product Management 4.232

A minimum viable product is not always a startup’s most valuable player

BY ON

A common startup practice is to first create a minimum viable product (MVP). Widely considered the best first step toward proving a product, an MVP allows a startup to get an initial product version to market quickly and solicit early access customer feedback for improvement before launching the product. With an MVP, a startup can focus on the product’s unique selling proposition (USP) and build around it.

Rocketlane took a different path. We did not build an MVP but waited until the product felt full-featured and mature before engaging with potential customers and asking them to try it and provide input. You may want to consider this approach as you evaluate various ways to bring your product to market. In this post, we’ll explain why.

Why break the mould?

An MVP works well when building an entirely new product for a new space, and for simple point solutions for small customers. However, if a product is to replace mature horizontal products with purpose-built solutions, the product won’t be successful starting as an MVP — more so if the product is a unification play, replacing a set of siloed horizontal tools.

The Meaning of MVP – Correcting Common Misconceptions

The key pillars of our product story are its “all in one” and “unification” capabilities — bringing together tasks, project reports, meeting notes, live document collaboration, and workflows in a tightly coupled experience. We needed to embed all those components into our very first product version and deliver a product with a significant breadth of capabilities on day one. To get traction, a product that promises an all-in-one experience must do at least 80% of what each of the horizontal solutions does; the product should first have all of its core capabilities in place and then include a layer of innovation on top.

Distractions and detours

If you’re building an all-in-one product replacing several established, siloed tools, it’s also not a good idea to develop and launch each module sequentially as an MVP. If you give one module or one part of your solution to your potential customers to test, they will provide feedback to improve that one part, which could cause you to lose focus on your complete solution. Say you were to go further and actually launch one part of your product as an MVP, then the entire market could be providing similar feedback and causing you even more to lose focus on your broader vision. You also would be launching an MVP that probably doesn’t yet compete for feature-for-feature with one of the established, siloed solutions you want to replace, which may result in more mixed reviews than you otherwise would receive if you had waited to deliver on your complete vision.

Another risk of launching or engaging potential customers with an MVP module of your product and following their vision for that module is it could end up looking like other products already in the market, since they’re comparing each module to other siloed solutions they use or know.

It’s better to allocate time and resources for customer review and feedback on specific modules and features after delivering on the complete vision and differentiation.

Building in time while building a product

Another reason to involve potential customers late in the development phase is that customers judge based on agility and shipping speed. While building the foundation of a product, customers possibly wouldn’t perceive meaningful monthly progress. Rather than involving potential customers in the early stages and risking disillusionment, it’s better to wait until the final months before launch. Once you have a good product that feels 80% there, it shouldn’t be difficult to engage potential customers to try it for a few teams and use cases and then rapidly iterate with them to reach product/market fit (PMF).

Showcasing a nearly completed new product to potential customers also ensures they don’t need to imagine what it will be in the future; they already see it working successfully based on your vision and can better comprehend that value. Ideally, potential customers also would see there is no other equivalent product in the market and nowhere else to go; when they use the product based on your complete vision, they also should envision how it could help them. MVP or EVP: Which is the Best Option for Your Startup?

Managing risk

Involving potential customers late in the development phase does include the risk of building too much without validating it. The risk increases with the breadth and complexity of the product. Even if you have experience building products and know the direction, the asks from customers and what they can and can’t live without, it’s best to engage a panel of reviewers, not necessarily potential customers, who are interested in your vision. Starting from the design phase, you can show them mockups of what your complete product will be. This way, you will have a stream of feedback from the mockup demos even while the product is being built, which will help reduce risk.

Selling the vision

You may need to educate investors and employees about your mature-product approach. Both groups may be more exposed to the MVP approach and may question waiting to engage potential customers until late in the development phase. You can manage this with regular meetings where you present progress and answer questions. You also could distribute a written memo to both groups, which would be a good exercise for you to crystallize your thinking and for both groups to have a reference document.

A mature product is the most viable product

There is more than one way to build a product, especially for horizontal, competitive categories. Instead of building an MVP, you may want to build a product with more maturity and breadth with a few key innovative experiences that serve as your USPs and illustrate why your product is best for certain use cases. If you engage potential customers when the product feels mature, they will understand why they should align with you, and you will not sacrifice on the differentiation that you are bringing to market.

There’s more where that came from. Access more great content on Mind the Product!

 

A common startup practice is to first create a minimum viable product (MVP). Widely considered the best first step toward proving a product, an MVP allows a startup to get an initial product version to market quickly and solicit early access customer feedback for improvement before launching the product. With an MVP, a startup can focus on the product’s unique selling proposition (USP) and build around it. Rocketlane took a different path. We did not build an MVP but waited until the product felt full-featured and mature before engaging with potential customers and asking them to try it and provide input. You may want to consider this approach as you evaluate various ways to bring your product to market. In this post, we’ll explain why.

Why break the mould?

An MVP works well when building an entirely new product for a new space, and for simple point solutions for small customers. However, if a product is to replace mature horizontal products with purpose-built solutions, the product won’t be successful starting as an MVP — more so if the product is a unification play, replacing a set of siloed horizontal tools.

The Meaning of MVP – Correcting Common Misconceptions

The key pillars of our product story are its "all in one" and "unification" capabilities — bringing together tasks, project reports, meeting notes, live document collaboration, and workflows in a tightly coupled experience. We needed to embed all those components into our very first product version and deliver a product with a significant breadth of capabilities on day one. To get traction, a product that promises an all-in-one experience must do at least 80% of what each of the horizontal solutions does; the product should first have all of its core capabilities in place and then include a layer of innovation on top.

Distractions and detours

If you’re building an all-in-one product replacing several established, siloed tools, it’s also not a good idea to develop and launch each module sequentially as an MVP. If you give one module or one part of your solution to your potential customers to test, they will provide feedback to improve that one part, which could cause you to lose focus on your complete solution. Say you were to go further and actually launch one part of your product as an MVP, then the entire market could be providing similar feedback and causing you even more to lose focus on your broader vision. You also would be launching an MVP that probably doesn’t yet compete for feature-for-feature with one of the established, siloed solutions you want to replace, which may result in more mixed reviews than you otherwise would receive if you had waited to deliver on your complete vision. Another risk of launching or engaging potential customers with an MVP module of your product and following their vision for that module is it could end up looking like other products already in the market, since they’re comparing each module to other siloed solutions they use or know. It’s better to allocate time and resources for customer review and feedback on specific modules and features after delivering on the complete vision and differentiation.

Building in time while building a product

Another reason to involve potential customers late in the development phase is that customers judge based on agility and shipping speed. While building the foundation of a product, customers possibly wouldn’t perceive meaningful monthly progress. Rather than involving potential customers in the early stages and risking disillusionment, it’s better to wait until the final months before launch. Once you have a good product that feels 80% there, it shouldn’t be difficult to engage potential customers to try it for a few teams and use cases and then rapidly iterate with them to reach product/market fit (PMF). Showcasing a nearly completed new product to potential customers also ensures they don’t need to imagine what it will be in the future; they already see it working successfully based on your vision and can better comprehend that value. Ideally, potential customers also would see there is no other equivalent product in the market and nowhere else to go; when they use the product based on your complete vision, they also should envision how it could help them. MVP or EVP: Which is the Best Option for Your Startup?

Managing risk

Involving potential customers late in the development phase does include the risk of building too much without validating it. The risk increases with the breadth and complexity of the product. Even if you have experience building products and know the direction, the asks from customers and what they can and can’t live without, it’s best to engage a panel of reviewers, not necessarily potential customers, who are interested in your vision. Starting from the design phase, you can show them mockups of what your complete product will be. This way, you will have a stream of feedback from the mockup demos even while the product is being built, which will help reduce risk.

Selling the vision

You may need to educate investors and employees about your mature-product approach. Both groups may be more exposed to the MVP approach and may question waiting to engage potential customers until late in the development phase. You can manage this with regular meetings where you present progress and answer questions. You also could distribute a written memo to both groups, which would be a good exercise for you to crystallize your thinking and for both groups to have a reference document.

A mature product is the most viable product

There is more than one way to build a product, especially for horizontal, competitive categories. Instead of building an MVP, you may want to build a product with more maturity and breadth with a few key innovative experiences that serve as your USPs and illustrate why your product is best for certain use cases. If you engage potential customers when the product feels mature, they will understand why they should align with you, and you will not sacrifice on the differentiation that you are bringing to market.

There's more where that came from. Access more great content on Mind the Product!

 

One thought on “A minimum viable product is not always a startup’s most valuable player

  1. Hello Sri, first of all thanks for sharing your experience with us. Secondly, I like to ask you to go deeper into how is the entire process you applied.
    The reason I am asking is because these days we have discussed it internally if we are using Agile properly or are we a little waterfall-ish when we build a new module.
    A little bit of context: we have a SaaS with 3 modules, each has is own price, and our strategy is to develop more modules for the same industries that we cover pretty well and also open new ones.
    In short our process is more or less like this: strategy team decides which module is next, the BA is gathering specs, creates diagrams, we discuss the flows and focus on the happy path and other main scenarios, after a round of updates we also have few wireframes and when those get the OK then the designer creates the mockups which are again discussed and updated (we present to different stakeholders like sales team because they are very close to the users and competition). Some of the features are marked as good to have and are not described in detail. Next we hold a meeting with the Dev & QA teams to present the new module and gather more feedback on what is very “expansive” as dev time, what can be done quickly, if is aligned with our core, etc. Then there are few updates if necessary and a splitting is hold to create User Stories. When the dev team, part of it, is available they start working on it and we test it as soon as possible. Another 3 months later we have a release. *Other presentations and activities are done in this period that help us promote and presell.
    All the progress can take around 6 months.
    Can we do it faster? Yes but we reach the same conclusion as yours and not only because of clients comparing us to competitors but also because it helps the Dev team to know the vision and create an architecture that is capable for building on top of what is released.

    Will be great if you could share some insights that work for you or you might think will helps us. Cheers!

Leave a Reply

Your email address will not be published.