Have you heard? My new book Continuous Discovery Habits is now available. Get the product trio's guide to a structured and sustainable approach to continuous discovery. Whenever I introduce the topic of customer interviews (the foundational element of continuous discovery), I get a lot of questions about who counts as a customer.
Everyone thinks their company context is unique—whether they’re B2B or B2B2C or some other combination of letters and numbers.
And while yes, there are countless variations across different teams and companies, there are some guiding principles that can help you figure out who to interview. That’s what we’ll be tackling in this edition of Ask Teresa.
Find all the posts in this series here.
While there are countless variations across different teams and companies, there are some guiding principles that can help you figure out who to interview. – Tweet This
Ask Teresa: Who counts as a customer? Who should my product trio be trying to speak with every week?
Customers can vary depending on your company and product. The term “customers” can include buyers, users, prospects, and internal customers.
Here’s a quick rule of thumb: Your customer is whoever uses your product or service or is making the purchase decision. Your outcome will determine who you’ll want to talk to.
When continuous interviewing: Your customer is whoever uses your product or service or is making the purchase decision. Your outcome will determine who you’ll want to talk to. – Tweet This
Let’s look at a few common scenarios.
If you work on a B2C product, your customers are the people who buy and use your product. For example, if you work on a subscription product (e.g. Apple Fitness+, Netflix, Dropbox) and your team is responsible for retention, you would want to talk with both engaged and unengaged customers—these would be people who are currently subscribed to your service. You might also want to talk with former customers who recently canceled their subscription.
If you work on a B2B product, your product has both customers (the people involved in the purchase decision) and end-users (the people who use the product). If your company is small and your team works on satisfying both customers and users, then you’ll need to interview both. As companies grow, they tend to have teams focus on one vs. the other, in which case, each team would interview their own target customer.
For example, if you work at a startup that sells a digital whiteboard product, you likely have an organizational buyer (maybe someone in finance or an IT manager) and end-users (the people who use the digital whiteboard to do their work). If your company is too small to have dedicated teams for each role, you might focus on buyers one quarter and interview buyers each week, and then focus on end-users the next quarter and interview end-users each week.
If your company doesn’t have dedicated teams for each role, you might focus on buyers one quarter and interview buyers each week, and then focus on end-users the next quarter and interview end-users each week. – Tweet This
If, on the other hand, you work on a mature team collaboration product (e.g. Slack, MS Teams), your product has a buyer (the person who made the purchase decision), at least one administrator (the person who sets up and manages the product), and end-users (the people using the product to collaborate).
Your company probably has teams dedicated to each of these roles and your outcome will dictate who you should talk to. For example, a team focused on driving end-user engagement would interview end-users week over week. Meanwhile a team focused on ease of administration might interview administrators week over week.
One of the biggest mistakes I see teams make in either of these contexts is they pinball back and forth talking to different roles, never developing deep expertise about any of the roles. To avoid this mistake, your outcome should set the scope for your discovery. Make sure it’s an appropriate scope and that it allows you to focus your interview efforts.
If you work on a B2B2C product, then you might have business customers, their business customers, and their end-users. For example, a benefit provider might sell their product to companies who offer the benefit to their employees. As in the previous B2B example, you might need to interview all of these folks in the initial stages of your company’s maturity. But as your company grows, your team will likely focus on just one of these audiences, while other teams focus on the others.
This can get even more complicated. Suppose the benefit provider sells their product to payroll companies who then offer it to employers to be used by their employees. That’s a B2B2B2C product. But no matter how many Bs and Cs we string together, the principle stays the same. We need to determine who is involved in the purchase decision and who uses the product or service. We then can use our outcome to identify which subset of those folks we should talk to week over week.
If you work on a two-sided marketplace, then you might need to talk to buyers and sellers when you are first starting out. But as your company grows, your team will likely focus on one vs. the other. (Noticing a pattern here?)
If you work on software that your internal colleagues use (e.g. call center software used by internal customer representatives or inventory systems used by your colleagues), then your customers are your colleagues who use that software. One common mistake that teams make in this context is they simply ask their colleagues for feature requests. But just like we want to interview external customers to uncover unmet customer needs, pain points, and desires, we want to do the same with internal customers. We don’t want to skip the crucial step of mapping the opportunity space. So I recommend you conduct story-based interviews with these internal colleagues.
Just like we want to interview external customers to uncover unmet customer needs, pain points, and desires, we want to do the same with internal customers. – Tweet This
If you work on a platform team building services for other teams, then your customers are those other teams, and more specifically, are often the developers on those other teams. For API or SDK products, I prefer to mix story-based interviews with pair programming.
For example, if I’m trying to increase the adoption of a new API, I might ask people who request access tokens if they want help using the API and offer a free getting started consultation hour. In these sessions, I would watch (and help as needed) as the person tried to use the API for the first time.
Regardless of your context, the key to remember is you want to talk to the people who are either buying or using your product.
For more on this topic, see:
- Customer Interviews: How to Recruit, What to Ask, and How to Synthesize What You Learn
- Ask Teresa: How Do You Select Customers for Customer Interviews?
- How Continuous Discovery Works (And Doesn’t) in Early-Stage Startups
If you need help finding customers to talk to, check out our course: Customer Recruiting for Continuous Discovery.
