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:
Here’s a great example of how this might play out during B2B product discovery at a software company :
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.
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:
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:
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.
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.