“I love the idea. Let me know when the product is ready, and I will buy it.”
—Your customer
For many product teams, that sentence sounds really good. The team feels that it validates their assumption, and it encourages them to continue building the product.
But that feeling can be deceptive, because you have little evidence that it’s actually true. You don’t know if your product will generate revenue, if your customer will use the product, or even if it’s actually the right product for them.
In this article, I present a framework to interpret different types of customer commitments, and early business validation experiments you can run to know if your Minimum Viable Product is actually viable.
In Lean Startup, Eric Ries defines a commitment as an exchange of value between the product team and its customer. Obtaining commitment early and enough is an ideal way of de-risking your product, as an incremental way to validate that a customer is willing to take a chance on you.
There is an inherent risk in any commercial relationship, and it is rarely distributed equally along the spectrum of supply and demand. Convincing customers to make commitments to your product early is one of the most effective ways to validate early on that you are building towards a profitable business.
For example, if a customer funds your startup before it has built a solution, the risk is maximal for the customer. Conversely, if you deliver a functioning MVP before making any money, the risk is maximal for your product team. This is another way of saying that the longer you wait for an exchange of value to happen, the higher your risk is as a product team.
I illustrate this phenomenon in the graph below:
As presented above, the lowest form of commitment for a product team is to research a particular problem. To find the right business, you should be running as many quality experiments as possible with your limited runaway. Each experiment should be as cheap as possible. The highest form of commitment is to build a big piece of software with the technical, legal, and commercial infrastructures to support it.
On the customer side, the lowest form of commitment is to accept discussing with the product team about their problems and context. One of the highest possible types of commitment is to purchase the MVP.
Let’s explore the types of commitment you can ask your customer depending on the maturity of your MVP.
Just having an MVP or working prototype does not mean you have a viable business or product on your hands. For example, if your MVP is already in the market, and the customer is only committing to accepting communications from you (research, notifications, email, etc.), that doesn’t mean they are 100% likely to become users. The same applies if you do research without communicating with your users. On the other hand, if you engage users with your prototype before its release, or even pre-sell a solution before it is built, you are significantly reducing your own risk.
In the chart below, a possible set of commitment levels is overlaid on top of the Viability Risk Map, and I’ll walk you through how to assess viability no matter what stage you’re in.
Your business is at this stage when you have a lot of assumptions about your market, product, and users — but you don’t have a solution (yet). It’s helpful to validate those assumptions with users before developing a proof of concept.
These are customers you’ve talked to for design research, and who seem to experience the problem you’re trying to solve. At this point they are still a question mark, and you do not know for sure if they will be early adopters. Once you’ve isolated these prospects, you should quickly prototype a smoke screen of your solution (through a design sprint, for example), and secure a real commitment. You have already asked for their time in the previous interview, so their commitment could be to build the solution jointly with you, or to fund your idea. Customers who decide not to engage further at this point, should be contacted again once the prototype is delivered. For a variety of reasons, it might be too early for them.
A great example of engagement during the research phase is to ask your customer to share some proprietary data with you. If the interest is real, it provides you with data to test whether you can deliver a solution for them beyond a demo. You are effectively forming a loose partnership with your customer in the pursuit of solving their problem.
The risks for the customer here are competitive and legal (you can suggest signing an NDA if it makes sense). For the product team, there is a danger of over-committing before knowing if the solution is feasible with real-world data and constraints.
The most certain signal of viability that you can get at at the research stage, is a pre-sale of the solution before it even exists. In this case, the customer provides funds in advance of the delivery. Their risk is maximal, as they do not have proof that you will be able to deliver. This makes it a hard commitment to get early on.
You can also co-deliver the solution with the customer to share the risk more equally as part of a consulting engagement where either party can disengage easily.
The risks for the product team are over-committing to one customer on time, or with desired customization. That could become a distraction, and if you end up not being able to deliver, you can also damage your reputation.
You now have a functioning prototype that can fulfill some of the promises of your upcoming MVP. Hopefully you already have a paying or engaged customer who can try this in the real world, and provide useful feedback. This stage is fertile ground for making data-driven business decisions.
What follows are a few of the typical scenarios at this stage.
You have validated both the problem and the usefulness of your solution at the design level with these users, but something went wrong that stalled further commitments. For example:
If the majority of the assumed early adopters give you such feedback at this point, it’s a signal that your viability risk is growing. The underlying reasons should be understood at this stage before committing to further development. Are these users the right kind of early adopters? Is the problem as painful and valuable to solve as we imagined? Have we built enough credibility with other users? It might be a sign that you need to pivot your MVP back to the research phase.
These users are happy to evaluate your prototype by testing it in the real world. They might not yet be a paid customers, but they care enough to test an incomplete product that might only solve part of the target problem. This is a healthy signal that your product will be adopted, but you should still have doubt that the value proposition is strong enough to warrant a higher exchange of value. In order to validate that you users are in this section, make sure to set usage thresholds prior to releasing the prototype. If your alpha/beta testers are aligned to the expected usage based on the frequency of the problem, and other factors…Congratulations! You are solving a problem!
The value of the partial MVP is already high enough to these users that they are ready to invest in your solution. At this point, building the rest of the MVP and its surrounding business infrastructure (payment, support, legal, etc.) should become a priority as your viability is very likely.
One of the most famous ways to generate revenue at this stage is Kickstarter, but while revenue here demonstrates the value of the product and acquires users, it also comes with risks to finances and reputation if you miscalculate costs and carries a burden of early customer support.
You now have an MVP in the market. It’s time to take an objective look at your viability.
“Let’s be friends.”
These users are still happy to talk with you but will neither engage nor buy your product. They have reasons to believe that the product is not right for them. The same recommendation for the “Blocked” stage applies here, but it is more urgent because you have a working product out there that requires time and resources.
This scenario on the map is usually a sign that you lack market validation for target customers. The adoption of your MVP is not sufficient enough proof that this is a safe bet. According to Geoffrey Moore in Crossing the Chasm, these customers might be better addressed, after you’ve crossed the chasm to early and late majorities that can identify you as the market leader.
These users are enjoying your complete MVP, but are not ready to pay for it. You observe this because they do not pursue it beyond the free trial to upgrade to the paid version. Understanding how your product mix is satisfying their needs is critical at this point.
On the other hand, if you already have plenty of paid customers, or are profitable, adding a free service might be used as a growth engine. It might be a great tool to help friend-zone prospects to revenue over time.
If your users oscillate between the Free and the Friend-Zone scenarios, you’re in trouble, as you might be a “nice-to-have” product. This is the most dangerous situation, because you might be deluding yourself into thinking sales will come over time, with little evidence to support that.
At this point, your users are both enjoying your product’s benefits, and happy to pay for it. Depending on your business model, you might be generating revenue differently. Make sure you have enough of them to reach viability.
If you arrived to that section through a series of early partnerships and sales, the transition to some form of long-term revenue (such as subscriptions), should be smoother. You now have to focus on execution and retention to make sure to corner your early adopter market as soon as possible to prepare yourself to cross the chasm.
In the end, it will be much easier to convert users who you already have a commercial relationship or who have engaged with you for a long time. Your product team needs to learn as quickly as possible if there is a commercial potential in your offering. By getting early commitments, you can model your business strategy with minimal waste, pivot bi-directionally, generate revenues, beat the competition, and give people a product that enriches their experience.
This article originally appeared on Built to Adapt.
Category: Productivity
Tags: How to
