Why People Buy and What it Means for Your Product
Your customers don’t want to buy your product. I mean, sure, they’re willing to hand over the cash (or credit card or bitcoin) to...
Customer validation interviews are an important component of the product development process. Product managers use customer validation interviews to help inform product decisions by validating problems, solutions, and pain points.
However, when we talk about “customer interviews” we’re often putting two distinctively different personas into the same bucket: users and buyers. In many cases, especially in the context of SaaS products, the person actually using your product is not the same as the person buying the product.
We’ve said it before and we’ll say it again, product managers aren’t fundamentally in the business of developing products—they’re in the business of solving customers’ problems. And the products they bring to market are simply tools for solving those problems.
But let’s dig even deeper. Most organizations hire product managers to solve customer problems for one reason: selling those solutions will make the company money.
It might sound obvious, but when you think of it this way—as a product manager, everything you do is ultimately aimed at increasing the bottom line. As such, you can see why there are situations where product feedback from buyers can carry a lot more weight than feedback from end-users.
Of course, you’ll still need to develop your product to meet the specific needs and preferences of your user persona, which means you’ll need to learn what those needs and preferences are—ideally by talking with users.
But, at the end of the day, if you can’t persuade buyers to buy, you have an even bigger problem. That’s why you can’t overlook buyers and their needs when developing your product. These people are the decision-makers who either greenlight use of your product by their organization or not, so knowing and serving their needs is of utmost importance. However, getting to know them can be challenging for a number of reasons.
In more cases than you might realize, it’s the company’s buyer—not the end-user—whose opinion should be your top priority. If I’ve learned anything from launching several products, it’s that interviewing potential customers is the best way to predict whether you’ll eventually achieve product-market fit. By asking the right questions, you can determine if your idea solves a big problem, who your potential buyers are, and ultimately whether or not there’s a market for your product.
The problem is, so few product teams conduct the interviews.
Customer validation doesn’t guarantee success, but it’s the easiest and lowest-cost way to reduce the risk for new products. Here are a few of my tips about how to conduct better customer validation interviews.
It can be as early as when you have your initial idea or when you’ve formulated your initial hypothesis. I recommend that you start with a framework such as the Business Model Canvas to develop your initial hypothesis of the market, the customer persona, the product and solution, and some initial thoughts on pricing and customer acquisition.
Once you have those basics, you have enough to start talking with real prospective customers. Your hypothesis doesn’t need to be right. It just needs to be concrete enough that you know who you might want to speak with and have enough of an idea of the problems they’re facing and an idea of how your product might address them.
Connecting with your user personas will often be much easier than reaching buyers, because you can contact users directly without having to worry about gatekeepers. Also, users are often willing and sometimes even eager to try your product or take your survey and tell you what they think about your idea.
Buyers, who are usually higher up in the organization and more frequently approached because they control budget, are less likely to take your call to chat about your product.
Fortunately, though, buyers leave a lot of clues out there about what they’re focused on, what their priorities are, and what they want and demand from products like yours. So if you’re trying to learn how to shape your product (or just your team’s sales pitch for it) to make it more appealing to a potential buyer, there are a lot of ways of gathering useful intelligence about them. For example:
Publications like CIO Magazine often list the top initiatives of corporate tech and IT executives for the coming year.
If you’re a product manager responsible for technology products, that information can be extremely useful in helping you determine if your product roadmap matches the coming priorities of your target buyers. Study these publications.
Because your target buyers are often higher-ups at your customer companies, they will also in some cases be thought leaders in their industries. They might have their own corporate blogs, speak or sit on panels at industry conferences, and contribute articles to industry publications.
Read what they say they’re working on now, and what they see as the next big threats or opportunities in their industries. There could be valuable insights there about how to present your solution to them—or even whether it’s worth pursuing that solution at all.
If your sales team is already selling an existing product, you’ll find that your sales reps are an invaluable source of knowledge on your buyer personas.
Your reps will know, for example, what questions or concerns buyers raise most often in sales meetings (which will be very different from users’ questions). They’ll know where in their demos buyers most often raise objections—or where they cheer that someone has finally solved a specific problem.
So talk to your sales reps often about their encounters with buyers, and join demo meetings if you know buyers (and not just end users) will be attending.
In my experience, interviews need to be at least 30-45 minutes to get valuable information. You need enough time to establish rapport, ask a few initial questions, and leave enough time for asking the questions that you hadn’t thought about at the beginning. But the amount of time that you spend really will depend on the stage of customer validation that you’re in.
In the beginning, you’re not quite sure who the right people are to be speaking with, nor do you completely understand the core problem that your potential customer is facing. Because of that, there are some times when you know fairly early on that you’ve missed the mark and you’ll need to politely escape from the interview so you don’t waste anyone’s time. I’ve found that the slightly later-stage interviews, where you are proposing a potential product to solve someone’s problem—those interviews tend to take up to an hour or more.
When we were starting ProductPlan, we conducted 30 interviews with product managers before we wrote a single line of code. I’m not saying that’s the perfect number, but it took that many interviews to really understand the problem we were attempting to solve and to ensure we spoke with enough product managers representing different market segments, company sizes, and stages of the product manager career path.
I usually recommend that startups begin by interviewing at least 10 prospective customers just to understand the problems that their particular market is facing. In those interviews, you may not even talk about your product. In fact, you probably shouldn’t. You’re not pitching a product at this stage. You’re simply trying to understand a day in the life of your customer, their potential problems, and how they would benefit from solving those problems.
“Startups should begin by interviewing at least 10 prospective customers just to understand the problems that their market is facing. In those interviews, you may not even talk about your product.”
After you’ve conducted a certain number of problem discovery interviews, you can then move on to the product validation interviews. I usually recommend at least 20 of those interviews to really understand the minimum product that you’ll need to build to solve those customer problems.
During development of the product, you will undoubtedly find areas that you’ll need to fine-tune with additional customer interviews. For ProductPlan, this included interviews to define which features we would launch with—our minimum viable product (MVP). This goes beyond what you’ll already be doing for UX and usability and touches more on topics like pricing and your broader go-to-market strategy.
For a business-to-business (B2B) software product, the ideal interview setting is in-person wherever your customer accomplishes his or her job. But that’s not always possible. In that case, a phone interview supplemented with video conferencing and screen-sharing is a good second choice.
But, in my experience, there’s no better way to do customer validation than in person. In this way, you can read your customer’s body language, see their facial expressions, see the stacks of paper on their desk, and ask questions about things that they never would have considered divulging over the phone. In-person interviews are also fantastic for establishing rapport and developing relationships that could eventually turn into your first sales.
But if you’re not able to do it in person, or if you’re developing a consumer-facing product, other interviewing methods might be better, and possibly more cost-effective. I’ve conducted hundreds of interviews using video-conferencing tools. For my interviews, I always prepare a presentation to help guide the conversation. But that presentation changes with nearly every customer interview because I’m constantly updating it and changing it based on every new insight I learn.
In the past, I’ve validated consumer-facing products by stalking potential customers in public locations and offering them a coffee gift card to speak with me. I’ve offered gift cards for telephone conversations as well. However, I don’t usually recommend paying for interviews because I feel that can possibly skew the results. Prospective customers should be motivated enough to speak with you because you’re potentially solving a real problem for them. But it’s always nice to send a thank you note and sometimes even a thank you gift after an interview.
Finally, I generally recommend avoiding email interviews because they take too long. Communicating asynchronously causes unnecessary delay and really limits those impromptu follow-up questions that you didn’t think about until they provided some initial answers. I also don’t recommend using surveys for validation unless you have a very objective set of questions that have discrete answers. Surveys presume that you already know the right questions to ask, and you could be completely missing the mark and getting misleading information based on your preconceived questions.
It’s important to understand who your real customer is. They may not even be an end-user of your product. There might be an economic buyer who will never use your product but is part of the decision-making process, or the person who manages the budget, etc. It’s essential that you speak to these “customers” as well. If you’re only talking to the end-users of the product, but not the person who’s writing the check for it, you may be in for a surprise down the road.
When we validated ProductPlan, we had to ensure that the product team had the budget to buy solutions like ours, especially since many of our customers were using solutions like Excel and PowerPoint, software that had already been widely licensed and implemented throughout their organizations. We did enough research to understand the organizational structure, buying behavior, and budget authority to feel confident about our solution’s potential viability.
When B2B product managers discuss their products with prospective end-users at their target companies, they’re typically interested in answers like these: Would this product improve some aspect of your workflow? Would this product save you time or frustration? Do you find the interface user-friendly enough that you would want to use this product regularly?
If the product meets the user’s own needs or makes some aspect of their job easier or more enjoyable, that user is likely to become the product’s champion.
Product managers must understand how the product fits into a larger picture of competing priorities for the buyer and for the customer’s organization. They need to know, for example, how the buyer would answer questions like these:
In terms of the conversation ratio during a customer validation interview, you need to be doing less than 50% of the talking. On top of that, the majority of your speaking should be you asking questions. If you’re in one of these interviews spending most of your time talking and trying to sell your solution and what you think is right, you’re not setting yourself up to hear things that may take your product in a new and possibly better direction.
I think there are a couple of skills that are valuable for product managers to have during their customer validation interviews. The first is empathy—really trying to understand the things that help make your customer successful in their job is an essential characteristic. Do you know the top priorities for your customer and what they would consider to be a successful year? When I was conducting validation for GoToMeeting, it was questions like these that helped us create and launch a successful online meeting application.
The other technique that is really helpful is simply asking “Why?” This is a great way to get to the true underlying problem that your product needs to solve. Most of your questions should be open-ended to allow your customers an opportunity to speak and explain their thinking.
As product people, it’s so tempting to talk about your future product and the value it provides. But in the beginning, before you thoroughly understand the problem you’re solving, you should be talking very little about your potential product.
After you understand the problem, however, I’ve found that a high-level presentation explaining the value prop of the product, a few key features, and what your product does not do, is often enough to convey the big picture. When we were validating ProductPlan, we had an extremely rough mock-up that we used to visually convey what the product would potentially look like. But it was not high-definition.
Later, after we had validated the features that would be included in the final product, we moved into more detailed prototypes. If we had developed those final prototypes too early in the process, we would have wasted time and money because we were learning so much so quickly and constantly adjusting and refining our hypothesis along the way.
Documenting the interview is important. By your tenth interview, they’ll all start to blend together and you’ll have trouble remembering important details.
“Two or more people should participate in each customer validation interview. Everyone hears the customer’s responses differently.”
I recommend that two or more people participate in each interview. First, this makes the logistics of asking questions and taking notes easier. Secondly, everyone hears the customer’s responses differently. I also suggest that you save five minutes after the interview is over, once you’ve thanked and said goodbye to the customer, to do a quick recap with your fellow interviewers. What did everyone hear? What were the key points? Take notes during these post-interview discussions and include them with the general interview notes.
It’s also helpful to have people on the team with different backgrounds and perspectives listen in on the interviews. Having someone with a sales background, for example, is helpful because they think about the buying process. Someone with an engineering background can help you understand if your solution is technically feasible.
I used to take verbatim notes, but don’t do that anymore. Instead, I use bulleted lists and create an interview outline. I’ll then include a few key quotes from the prospect that emphasize a key learning point—these become valuable later when you’re making the case to perhaps include a certain feature or capability. Quotes are also great because they’re in the voice of the customer and carry a lot of weight. They also help you remember who you’re building a solution for, what problems they’re facing on a daily basis, and more.
Take notes in an online format that’s easy to share (personally, I use Google Docs for this—with a separate document for each customer interview).
It’s important to include basic information about your prospects—such as title, company size (if you’re validating a B2B product), and other demographic information to segment the interviews later. This also helps you identify broader patterns, i.e. noticing that all the prospects from the larger companies you spoke with faced the same problem.
I also record all my interviews. These are useful for going back and listening for key points that I may not have noted in the initial interviews. Audio recordings are also great for getting new team members up to speed on the customer problem we’re solving. Sometimes, I like to share clips of the recordings with the engineering team so they get a flavor of the customer’s challenge. It’s like having a real-life user story on audio. [Note: it’s always important to ask for permission upfront and to emphasize that the recording will only be used internally.]
Questions like these open the door for insightful customer answers. Instead of nodding their head yes or no, prospective customers are given the opportunity to describe friction points in their daily work, identify opportunities for improvements, and ideally, validate your own hypotheses about the problems your product might solve. It’s this process that can help you get to product-market fit faster.
Buyers will have an entirely different set of feedback from the feedback you’re used to receiving from users. But this information is at least as important to the ultimate success of your product—probably more.
This means if you’re trying to validate a new idea for a B2B product—a SaaS application, for example—positive responses from would-be end users are great, but they’re not sufficient evidence for your team to get started on development. In fact, you should not write a single line of code until you’ve talked to a buyer at your target company.
Have experience conducting customer validation interviews? Share your tips in the comments.