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!
- Build Better Products With Effective MVPs
- Getting the max from an MVP – Dan Olsen
- Understand your application’s feature set maturity
Comments 1