B2B Product Discovery: 3 Ways to Avoid the Game of Telephone

B2B product discovery can sometimes be like the game of telephone. Ever play that as a kid? For those who haven’t, here’s how it works:

• Players sit next to each other in a line - shoulder to shoulder, facing the same direction.
• One person from either end of the line comes up with a funny, difficult and/or long sentence. 
• He/she whispers that sentence into the ear of the person next to them. There is no repeating the sentence; it’s said only once to each player.
• The second person does their best to remember the sentence, then whispers it into the ear of the next person in the line.
• This continues all the way to the last person, who then says out loud the sentence they heard. 
• The first person who came up with the sentence says the original, and everyone usually laughs because what the last person heard is so far from how it started.

Here’s a great example of how this might play out during B2B product discovery at a software company :

Source: Marketoonist

In this post, we’ll look at how this game of telephone often unfolds at companies, why it's risky, and how to avoid it. This is especially important if you’re looking to establish a B2B product discovery process or build on your team’s existing practices.

How This Game of Telephone Increases B2B Product Development Risk

Before we look at the risks this game of telephone can create, let’s first look at how this pattern emerges as an organization matures.

Early on, the founders are all talking to customers, users and prospects. They wear so many hats: selling the product, onboarding new customers and supporting users once the product is live. They’re probably in the same room, or talk to each other so often that it’s easy for them to share what they’re hearing with each other.

As the product matures and the organization grows, it’s common to create more specialized roles and teams, like sales, marketing, customer success, product, design and engineering. This is when the game of telephone typically starts. Why? The relationship with customers, users and prospects becomes more sacred and therefore protected. The desire to not “overwhelm” external stakeholders with too many company employees leads to this flawed pipeline of information into the company. 

For example, perhaps only one sales person is on a call with a prospect. She hears a feature request and lobs it over to the product manager to ask if it’s feasible and if so, when it can be delivered (yes, sales-led development). That poor PM (it’s been me before!) wants to support the company’s revenue growth goals, so he calls a meeting with design and engineering and shares whatever context the sales person provided. So the trio brainstorms solutions, estimates effort and considers the roadmap implications. Inevitably, someone comes up with an alternative to the requested feature, and everyone agrees it would be better for the users and faster to deliver. But in order to know if it’s OK with the prospect, the PM has to propose it to the sales person, who would of course want to run it by the prospect. By then, it’s been a week or two, and the sales person doesn’t want to delay the deal by starting the product discussion all over again. So everyone agrees to just build what was requested, because the game of “reverse telephone” will take too long.

There are several aspects of this game of telephone that increase the product development risk of building the wrong thing:

• Lossy. As the original message passes from person to person, it changes, meaning key information is lost. This increases the chances that the customer, user or prospect’s original desires are buried as the message morphs.
• One way. Usually the information is only flowing from the customer, user or prospect to the product development team. This means there’s no way to have a real-time conversation about what outcome they’re trying to achieve or discuss all the options for how the product can best help them.
• Biased. In the real game of telephone, the original sentence comes arbitrarily from the first person’s head. In the B2B version, it’s likely that the person who interfaced with the customer isn’t an expert on probing beyond an initial product request to uncover the real desired outcome.
• Slow. The real game of telephone is fast (seconds), but inside of a company, information may move slower, especially if a you're trying to schedule a meeting to discuss the request. By the time the information reaches the product development team, it may be outdated or irrelevant.
• Unique. Every time you play, the original sentence changes, even if the same person starts the game. You can’t assume the customer, user or prospect will say the exact same thing if you ask them to clarify. This can lead to more confusion about what they really want or need.

3 Ways to Avoid the Game of Telephone in B2B Product Discovery

So how do we avoid this? As the graphic above depicts, ideally the company acknowledges that every team interfaces with customers, users and prospects in different ways. And that’s a good thing! Rather than funnel all interactions through a few people or teams, the company instead aims to make it easy for teams internally to share the learnings from those interactions with each other.  Here are 3 things you can do to move towards this ideal state and avoid the damaging ripple effects to the business from this dreaded game of telephone:

1. Increase Touchpoints
Rather than shielding the customer, user or prospect from the company’s employees, build repeatable feedback loops like sales call listening, customer success shadowing, and user research interviews throughout the product development lifecycle to increase qualitative feedback opportunities. At each touchpoint, invite more people to listen in, such as  product managers, designers and engineers. Including more people creates a real-time conversation that’s richer and more efficient than lengthy back-and-forth communications. The more time employees spend listening firsthand to customers, users and prospects, the more likely it is they’ll develop a true understanding and empathy for their external stakeholder and identify patterns.

2. Document Insights
As the team learns from customers, users and prospects, ask them to write down anything that was surprising, interesting or new to them ("insights"). This can be done in a shared Google Doc or Sheet, a customer / user insights Slack channel, an internal blog with tags for searching, or a product like Bloomfire (one of my clients uses this product and it’s really easy to find the historic user research decks by keyword). When sharing an insight, audio or video recordings of conversations can be extremely powerful, as the audience can literally hear the voice of the customer. Of course, this could get unwieldy, so a user researcher or product manager should review and organize the insights so they’re easily digestible. Having all these insights in one place has several benefits:

• You can reference them in future product development artifacts like product briefs or roadmaps.
• You can share them with people who weren’t able to hear them firsthand, making it more efficient to get the insights.
• You can use them to help team members to learn about customers, users and prospects. For example, imagine pointing a new hire to the insights library during onboarding.

3. Discuss Insights Internally
Once the insights are documented, now you need to make it easy for employees to regularly discuss new insights and whether to act on them. Examples of how to do this include a monthly lunch and learn series, a weekly go-to-market sync between sales, marketing and product, or dedicated time during each All Hands to explain what the team is learning.  The product manager should clarify if and how she will respond to each one (ex update a persona artifact, do more discovery, put something on the product roadmap, etc). It’s completely fine if the decision is to ignore the insight (or not act on it immediately) as long as there's a clear rationale.

Work with B2B Product Development Coaches and Advisors

Hopefully this post explains the dangers of this game of telephone, and how to avoid it to build a deeper understanding of your product’s customers, users and prospects across the company.  Ideally, this qualitative feedback loop is paired with a strong quantitative feedback loop (ex monitoring prospect or customer behavior inside the product) to create a holistic understanding of who you’re serving.

If you’d like to talk about how to establish or improve your B2B product discovery process, please request a call. We’re always glad to hear how specific teams are operating and share our thoughts on how to tailor the concepts mentioned here to your company's environment.