Sachin Rekhi

In my previous post I detailed how I typically go about documenting the initial set of product/market fit hypotheses for an early stage startup and each of the key elements that are important to capture as part of it. Once you've done that, then the far more interesting work begins: validating whether there is in fact truth to each of your most uncertain hypotheses and iterating upon them to eventually find product/market fit.

When it comes to customer validation, the most important piece of advice I can give you is exactly what Steve Blank has been prescribing all along: to get out of the building and talk to potential customers and eventually actual customers leveraging your MVP or later product iterations. This advice sounds so simple and so obvious, yet I see way too many product and design teams spending significant iteration time within their four walls holed up in conference rooms debating the merits of various strategies, features, and design decisions with limited direct customer input. Or maybe they did talk to customers, but months ago on the last iteration, and haven't incorporated it into a systematic process for getting regular feedback from customers. Quantity and quality of customer feedback are both important, but if you have to pick one to optimize for, frequency of exposure to actual customer feedback is incredibly important. Jared Spool's research showed a few years ago that increasing exposure hours to customers had the strongest link to building great customer experiences. So heed Steve Blank and Jared Spool's advice and get out of the building and talk to your actual customers early and often.

When doing so, there are a wide variety of research methods that you can leverage to validate each of your hypotheses. Choosing the right research methods depend on what type of hypothesis you're validating and what stage you are in defining your product and solution. Research could be as simple as grabbing coffee with a buddy and asking him some questions about your product idea. It doesn't have to be painful nor does it have to be time consuming.

I've found though that sometimes folks are in fact spending time with their customers listening to their feedback, but not gleaning as actionable customer insights as they could be to help them appropriately validate their hypotheses and efficiently find product/market fit. Given this, I wanted to share a more defined approach that I've leveraged as a customer validation process that maximizes for gleaning true signals and actionable insights at the earliest stages of your product.

Customer Validation Process
I typically try to recruit 20+ potential customers that fit the target audience criteria that has been identified as part of the key hypotheses. I then conduct 1:1 interviews with the customer and the validation team typically for 45-60 minutes. I find it ideal to have a facilitator, a separate note taker, as well as a recording of the session if possible. This ensures the facilitator can keep the conversation going in the right direction while a separate note taker can capture the entire discussion. The recording allows others on the team to later hear directly from the customer as opposed to just getting the summarized conclusions. I've certainly conducted interviews entirely myself as well, so a note taker or recording is not required. I find it best to take copious notes of most of the dialog and summarize the findings later. This is important because patterns will emerge between interviews which will turn into the true summary conclusions which you might not be able to get to if you only jotted down a few high level notes each interview. It's best to conduct these 1:1 as opposed to large group sessions because you want to avoid "group think" which reduces the amount of unique customer signals that you are capturing.

I always prepare an interview guide or presentation that you can run every customer through. It ensures you don't forget to hit on all the key questions you were hoping to cover during the interview and also ensures consistency in the way that you ask questions between the interviews. This is helpful so that you are getting answers that are comparable between interviews which facilitates deriving more cross-customer insights.

What follows are each of the sections I cover as part of the interview guide to ensure I get the right kind of feedback on each of the key product/market fit hypotheses.

Overview
I typically start with a very high-level single sentence description of what your product or service is trying to accomplish. The goal here is not to introduce your product in-depth, but simply to give the customer an idea of what problem space your solution is looking to solve for. This could simply be mentioning an existing category of products they are familiar with or more broadly a workflow or process that they are typically engaging with.

Problem You're Solving
The next goal is to discover the pain points that the customer currently faces today in your problem space. I like to do this both aided and un-aided. So start by asking broadly, "what are the pain points you face today in this problem space?". I then follow up the free-form discussion with a list of potential pain points you've heard from other customers, including of course the problems you're solution is specifically looking to solve, and ask if any of them specifically resonate for them individually.

It's important that they are answering for themselves or their organization. Not "in general" or "other people". A good customer interview can only speak to their own experience and you want to make sure you're capturing that. If you hear them saying something like "I can imagine how others might suffer from that" simply ask them more specifically if it's an issue for them or their organization and stick to those takeaways.

You'll also want to get a sense of severity of the pain points identified. Ask them to stack rank the various pain points that resonated or they self identified so you get a sense of which are most pressing for them to solve. It's also helpful to ask how are they tackling those pain points today. Do they have active projects to attempt to address them? Or actively looking for solutions? Or are they instead not specifically taking any actions to address it? The more proactive they are engaging in finding a solution, the more severe the pain truly is for them.

Overall this will help validate whether the problem you're solving is a real pain for the customer and how high a priority it is for them to solve.

Value Propositions
I then find it helpful to start introducing your solution by stating the value propositions that your solution promises to deliver on. I usually just provide the value propositions with limited context and get the customers immediate reaction to it.

First, this will give you a sense of whether your value propositions are clear enough that the customer can understand them with limited additional context. Second, it will give you a sense of whether the high level solution resonates with the customer.

Oftentimes customer reactions may be vague at this time, which is fine. What you're looking for is just an initial reaction. They may say, "I'm intrigued as theoretically that would solve a lot of our problems, but unclear on whether you can actually deliver on that promise." That's a great positive affirmation at this point on the value proposition, since you haven't yet introduced the details of the solution.

The Solution
Now it's time to walk the customer through your solution and it's differentiation. The fidelity of this really depends on what stage you are in the process of formulating your product. It could be a high level description of how the solution works, the features it provides, and how it's different from alternatives. If you've had a chance to design the key flows, you could instead walk them through mockups of the core experience. If you have a prototype, then you can go ahead and present the prototype to them.

The fidelity of this isn't too important. It's great if you have more detail and crispness around how your solution is going to work, but at the same time it's far better to get customer feedback early and often. So I don't usually encourage people to wait to a certain point to starting to run this process because you'll find the learnings at any stage incredibly helpful.

After you've presented the solution and clarified any questions they had, I like to first get initial un-aided reactions. Just gauging their excitement at this point can even be helpful, so make sure to note down emotional reactions in addition to the specific words that they are saying. Then I ask what scenarios or features were the most compelling and useful for them specifically. It's helpful to get stack ranking out of the key scenarios you support from each customer. I also like to ask what's missing from the solution? What would they add if they could? What issues do they have with the solution?

Competition
It's then helpful to have a discussion around alternatives to your solution. What other tools are they using right now to address this problem? Or are they in the process of considering other such solutions? How do they handle this problem right now without yours or other solutions? If they have experience with other solutions, how do they think this solution compares?

Target Audience
I then like to verify the target audience criteria that we've come up with. I ask them if they would in fact be the end user of this application and if not, who would be? For B2B solutions, I also ask who influences purchases of this kind of solution in the organization and who ultimately is the business decision maker who can pull the trigger on purchasing such a solution? It's important to be precise here and determine exactly the kinds of roles within their organization that will be each of the target end users, influencers, and business decision maker.

Acquisition Strategy
If the customer is in fact in the proper target audience, then you can ask them how they or others in their organization go about finding out about solutions in your problem space. How did they hear about your current solution? How do they go about evaluating such solutions? Who's typically involved? How do they prefer to engage with products like yours? With a sales rep? Or on their own on your website?

Monetization Strategy
You can then probe on willingness to pay and comps. How much are they paying to solve this pain point today? It's important to look at this both from the perspective of alternative solutions they are using to establish comps, but also to look at this from the perspective of how much value this would generate for their organization. It's helpful to have them walk you through how they might even calculate this value since it'll help you ultimately deduce value-based pricing options.

Vitamin or Pain Killer?
The final but arguably most important question is assessing whether the potential customer perceives your solution as a vitamin or a pain killer. Depending on what stage you are at, there are a variety of ways to accurately glean this information.

At the earliest stage, I like to ask, if this solution were available tomorrow, where would it sit in the list of your or your team's priorities to implement and deploy? What you're looking for here is whether this fits in their current or next quarter's top 5 priorities. If they say their team would immediately jump on it, that's a great sign. If they say they like the solution, but just have too many other things going on in their organization for the foreseeable future, then that's a bad sign. While their may be organization-specific reasons for why they can't adopt your solution now, I find that when you are hearing such excuses from several customers, it's an indicator of lack of product/market fit instead of it being circumstantial.

When you are close to releasing an MVP, a better question to ask is whether they are willing to sign up for an early pilot. This is similar to the above question, but it moves it from a theoretical ask (which people often overstate their willingness) to an actual ask. The earliest MVPs I usually do as free products and the ask is a commitment of time on their part to deploy the solution, commit to using it, and providing feedback. In later MVPs I often do a paid pilot with a low/discounted price point. Both of these act as great validation for actual product/market fit. You'll either get them to agree or find similar circumstantial excuses like above, which again point to a lack of product/market fit.

You'll notice these questions are not just there to gauge their interest or excitement or their willingness to meet to discuss again, but far more precisely to assess a pull from the customer in terms of demand for the solution you've proposed. This is incredibly important because it is the only true indicator of closeness to product/market fit compared to general interest and excitement.

Once you've conducted the interview, it's important to summarize each of the key take-aways from each hypothesis validation. You'll want to summarize it in a digestible form that is comparable across interviews since individual interviews are simply anecdotes and it's the summary of all the interviews from which you can start drawing trend-lines and conclusions. You'll likely want to go back through both raw notes and summaries again at the end to see additional trends that you may not have picked up the first time through. It's this synthesis process that's incredibly important not to skimp on in order to maximize learnings and to put you on the best path to finding true product/market fit.

You'll likely find that some of your hypotheses were strongly validated while others were far murkier. That's when the hypothesis iteration can begin on the murky ones. And you can then rinse and repeat either another full validation wave or abbreviated waves if many of your hypotheses were already met. And when you start to get to the point of more than 50% of your potential customers saying they're immediately willing to take action on your solution (ie. it's a pain killer), then you now know that your truth seeking endeavors have been fruitful and product/market fit is now far less elusive :)