Going from idea to getting your product launch right can be a complex journey. Complex not because the building is hard, but knowing what to build is key to getting it right.
“Give me six hours to chop down a tree, and I will spend the first four sharpening the axe”, Abraham Lincoln
Here are the 10 steps it takes to go from the napkin idea to actual users!
Idea: Congratulations! You’ve identified a problem and care about it enough to try to solve it. Write down the problem statement, the potential customers who face this, and IYO (in your opinion) the specific issues that your potential customers face.
Detail & Validate: Talk to these potential customers, and find out the real problem they’re facing. This is a crucial step, because sometimes your customers won’t word the problem for you, or will just mention symptoms or specific issues off hand. You’ve got to be perceptive, to figure out the problem. For example, when we were building the telemedicine service, there was no such comparison to give customers. Most consumers hadn’t experienced ‘consulting a doctor through chat/phone, behind a paywall’. So, we couldn’t ask them upfront if they would do such a thing as pay and chat with a doctor. In the first consumer interaction, we tested asking about this, and because they hadn’t experienced it in actuality, their responses were often based on their interpretations of the situation, which was all over the place, and thus unhelpful. Thus, we talked to customers about their clinic experiences, the frictions they faced, and eventually we figured out that patients visit clinics only when the problem becomes a lot more serious, that its worth their time to visit the clinic. In this specific case, we were building a 2-sided platform, so we had to talk to doctors also. Fortunately, doctors (much like B2B customers) are a more captive audience, extremely sharp, and many had tried online consultation before, so our interactions (QnA) were a lot more focused and their responses were very useful. One great practice is to record these conversations (with their acknowledgement). Listen and re-listen to them along with your team, to truly interpret the problems. Another great way to interpret problems is to simply watch the operations/flow of your customers. If its a shop, office or a clinic, spend a few hours just observing their behaviours and their friction points.
Money Problem: Among the various frictions and problems faced by your customer, order them in priority, to pick the ‘money problem’. The money problem is the issue that most of these potential customers are willing to pay money for (and/or adopt a new ‘thing’ for), which means they’re deriving significant value from it. This may not be the most frequent problem, but it’s the one that causes the most pain. Find out what they do to overcome it currently. Allocated most ‘money’ to the problem if its frequent, if they have to spend money on it and you can do it cheaper/better (everyone loves saving money), or if they spend time jumping through hoops for it and you can make it easier (consumers appreciate saving time, and businesses are often willing to pay good money for it).
Market Sizing: Once you’ve got the money problem, please don’t hand it to your engineers to build it! Validate the market size. You’ve found a money problem, but you don’t want it to be a market of 10. I do think, you should launch small, but not for a micro/nano market. If you talked to 10 potential customers for your initial research, check with 3–5x the customer base- their willingness to use and pay. As you grow the number of interactions with potential customers and its a lot easier if you have a mockup (see step 5). If you’re targeting consumers with a mobile app, it’s as simple as going to a shopping mall, and getting their feedback. Or use a surveymonkey, google docs kind of tool, and simple targeted marketing ads. May seem time consuming now, but it’s way more expensive to build in the wrong direction- in terms of time, money and team morale.
Mock It: Okay, I know your engineers are waiting to build this, but one more crucial step before you hand it over to your engineers to build it. First, design the mock solution- that could be on paper, or a visual mock-up app like inVision. And run it by this set of potential customers, to check their willingness to use it and to pay money for it. Those are two separate questions, because if there is a high willingness to use, but not pay money, then you likely will have a user-base and need to figure out other ways to monetize. Or if there is willingness to use and pay money, you’ve likely found not just the ‘money problem’, but also how to make money from it.
Go Alpha: Once you’ve validated the money problem, validated the market size is worth going after, and mocked it up, design the product, build an early beta or an alpha, take it back to your early potential customers. Get them to use it. Don’t worry about monetizing these- ask them to give you feedback, that’s way more valuable. The first litmus test is to get them to use it. Figure out how to get them to use it, ie to fit it into their current routine. It should either replace a current task for them.
Go Beta: Get their feedback, incorporate into your product. Here, ‘relevant feedback’ is key. Relevant basically refers to feedback that’s aligned to your product vision. If you’re selling gym t-shirts, and some user doesn’t like the look when they wear it to a party, you don’t need to solve for that. Solve for the ‘workout wear’ use case. With the relevant feedback, keep making it better, till most of them say, they ‘really like it’, the corollary of which is that if they didn’t have it, then 80% of this customer set would be disappointed. Now, you’re beta is ready.
The Money Question: Ask these customers who love your product, how much is it worth to them? As always, very rarely will your customers tell you the right price. Pricing is about figuring out the trade-off between the benefit your product provides, and the cost. Take the B2B example of a marketing automation product. When a business deploys such a product for their marketing, it reduces their dependency on human resources, so its clear. In the B2C case of food delivery. Both the leading food delivery apps of Zomato and Swiggy charge for delivery, over and above the food. Customers value the convenience of having food delivered fast, and thus are comfortable paying for it. Note: If its a B2B product, its value/pricing maybe easier to determine. Its important to test price points, and see how it affects the demand curve. For certain products/services, where users care about quality (like healthcare), there exists a pricing threshold, below which demand drops. [The topic of ‘Pricing’ is a volume in itself, so I’ll try to address it in another post or 2.]
Grow Beta: Next step is to take it to your next set of beta customers- similar 3–5x as your early set. Ask for referrals if possible. Give your current beta users some referral benefit. It can help you test the referral feature too. Like the classic example of how Paypal gave away $10 to every new user. Once you’ve got these next set of users, focus on getting them to adopt the product, and improving their CSAT (customer satisfaction) & NPS (net promoter) scores.
KYC (Know your customers) better: For this larger set of users, get them to try your product and try to understand - What they love about your product. - Who do they think this product is best suited for- understand what is the profile of the customer who likes you.
Incorporate the learnings/feedback into your product. Unfocused customer feedback can lead you in all kinds of directions, so remember to keep the ‘money problem’ and ‘product vision’ framework in mind as you take feedback. The initial few steps of delving into the market, customer, need, and solution is very important.
Keep repeating, step 9 and 10, till you hit your first level of critical mass. Generally speaking, for B2B product that would be ~100–200 users, for B2C product ~1,000 users.
Of course, the target numbers that can be considered critical mass vary significantly based on the sector, product, consumer, customer, pricing, etc. The framework I’ve used for figuring out the beta customer base is:
80–90% of beta customers doesn’t know you/team personally, i.e. Beyond the family and friends network, thus gives honest feedback.
Small enough for you to know the early power users, and large enough to truly understand the challenges/benefits in your product adoption and acceptance.
In terms of timeline, the minimum cycle I’ve experienced in launching products from idea to a successful beta is 3–4 months. And going up to 9 months- this was when the initial idea was partly validated by the beta consumer base, but we still went ahead and pushed for growth, only to re-do parts of the product
Launching a product right takes effort and time. Getting it right in the early stages is critical. Better to invest the time early on, when you’re lean. Pivoting is time consuming, demoralizing, and expensive.
Post launching your beta product, you need to start focussing on getting the Product Market Fit.
Kommentare