Event Recap: What Product Teams Miss When Customer Insight Gets Filtered Through Too Many Layers with Jake McKee

# Product

# Community

# Format: Event Recaps

Jake McKee joined Context First to talk about Conversation Debt, customer conversations, and why product teams need closer contact with the people they’re building for.

June 11, 2026

Joshua Zerkel

Jake McKee

Jake McKee joined Context First to talk about Conversation Debt, customer conversations, and why product teams need closer contact with the people they’re building for.

Most teams I talk to are not short on customer information. They have survey results, support tickets, Gong snippets, customer advisory board notes, community posts, product analytics, win-loss themes, and research readouts. In many companies, there’s actually more customer data moving around than anyone has time to process.

What’s harder to see is how much of that information has already been translated before it reaches the people making product decisions.

A customer says something in a support call. It gets summarized in a ticket. The ticket gets grouped into a theme. The theme gets added to a report. The report gets discussed in a meeting. By the time it reaches the team building the product, the original context may be hard to find.

That was the part of my conversation with Jake McKee that I’ve kept coming back to.

Jake has spent nearly three decades helping organizations build stronger relationships with customers, fans, members, and users. He’s worked with teams at LEGO, Apple, EA Games, Southwest Airlines, Canon, H&R Block, and plenty of others, but what I’ve always appreciated about his work is that it comes from doing the work with real teams, real customers, and real organizational constraints.

He’s spent a lot of time sitting between groups that don’t always speak the same language and helping them understand one another better. Product and customers. Community and company. Creative and engineering. Humans and, increasingly, intelligent systems.

Early in our conversation, Jake said something that named the issue very clearly: “It’s hard to build great products with secondhand insight.”

I don’t think most teams would disagree with that. The problem is that many organizations have created systems where secondhand insight becomes the default. Not because anyone thinks customers should be kept at a distance, but because the safer, faster, cleaner path is often to collect, summarize, and route the information internally.

That may keep the process moving, but it can also make the customer feel more like an input than a person.

Secondhand insight creates distance

I don’t think most organizations set out to distance product teams from customers. Usually, it happens for understandable reasons. The research team is trying to create consistency. Customer success is trying to protect important relationships. Sales doesn’t want a technical person dropped into a customer conversation without preparation. Support is trying to make recurring issues easier to see. Leadership wants a cleaner summary so decisions can move faster.

None of those instincts are wrong on their own. In many cases, they’re necessary.

The trouble starts when all of those reasonable protections create a system where the people building the product are mostly hearing about customers instead of hearing from them. Product teams may be surrounded by customer information, but still separated from the texture of the customer’s actual experience.

That texture matters.

Summaries tend to remove the mess. They clean up the hesitation, the contradiction, the strange phrasing, the frustration, the workaround, and the moment where someone says something that doesn’t fit neatly into the category you expected. In community work, those are often the most useful moments. A person rarely hands you a perfect insight in a perfectly packaged sentence. They tell a story, double back, describe something awkwardly, or explain a workaround that makes perfect sense to them and no sense to your internal model of the product.

If you’re in conversation with them, you can slow down and ask the next question. If you’re reading the summary later, that chance is usually gone.

A report can tell you what was said. A conversation can help you understand what was meant.

Conversation Debt builds gradually

Jake calls this gap Conversation Debt, which I found useful because it makes the problem feel specific enough to work on.

Conversation Debt is what builds up when a team goes too long without direct, meaningful conversations with customers. Like technical debt, it rarely shows up all at once. It accumulates through a series of reasonable tradeoffs that make sense in the moment.

You skip customer conversations because the sprint is full. You rely on the persona deck because it’s already been approved. You ask research for a synthesis because it’s faster than joining the calls yourself. You scan support themes instead of listening to the recording. You assume the community team will surface anything important. You tell yourself there will be more time next quarter.

None of that is irresponsible. It’s how busy teams operate.

The risk is that, over time, the organization starts treating the summary as if it were the customer. The persona becomes the person. The dashboard becomes the lived experience. The internal interpretation becomes the thing everyone reacts to, even when the original customer context has become faint.

That’s where product decisions can start to drift, sometimes without anyone noticing right away.

Feedback and conversation do different jobs

One of the parts of the discussion I appreciated most was Jake’s distinction between collecting customer feedback and having a customer conversation.

A lot of companies use those phrases interchangeably, and I understand why. Both are ways of learning from customers. Both can be useful. Both can help teams make better decisions when they’re used well.

But they don’t do the same job.

Feedback is often easier to collect, sort, quantify, and report. It helps teams see patterns, validate known issues, and understand what’s happening at scale. It’s useful because it gives structure to a large amount of customer input.

Conversation does something different. It helps teams get closer to the why.

A good conversation gives you room to ask follow-up questions. It lets you hear the language customers actually use. It creates space for someone to explain what they were trying to do, where they got stuck, what they expected, and what else was happening around that moment.

Jake shared a story about speaking with a group of market researchers where someone asked how relationship-driven conversations could ensure statistical validity. His response was essentially that they don’t need to do the same job as formal research.

That felt important.

This isn’t an argument against research, surveys, analytics, or quantitative data. Those things matter. In my experience, the best teams use them together. The quantitative work helps you see whether something is widespread. The conversation helps you notice what you didn’t know to look for yet.

When those work together, the organization gets a much more useful picture of what customers are experiencing and what the team may need to do next.

Relationships change the quality of what customers share

There was another thread in the conversation that felt very familiar from a community perspective: people share differently when there’s a relationship.

If a customer feels like they’re being studied, they may answer the question. If they feel like they’re talking to someone who actually wants to understand their experience, they’ll often tell you the story around the answer.

That difference matters because some of the most useful things customers share are not clean feature requests. They’re frustrations, habits, workarounds, small confusions, or moments where the product fits into a broader process the team may not fully understand yet.

Those details often require trust.

Jake talked about vulnerability as a condition for better insight. That may not be the word most business teams reach for first, but I think it’s the right one. Honest customer conversations require enough trust for someone to say what they really think, not just what sounds polite, reasonable, or easy to explain.

This is one of the reasons community can be so valuable when it’s connected properly to product, research, success, and leadership. Community creates more than a place to collect comments. It creates ongoing relationships. It gives teams a way to hear from people over time, across different moments, not only when there’s a research project or escalation.

That ongoing context changes the quality of what the organization can learn.

Better conversations need architecture

One thing I appreciated about Jake’s framework is that it doesn’t stop at “talk to more customers.”

That advice is easy to give and much harder to make real inside a company.

A product leader may want engineers to hear directly from customers. A customer success leader may worry about adding risk to important relationships. A salesperson may not want product people in a live sales conversation without preparation. A researcher may want to make sure customer conversations are handled thoughtfully. A community leader may want customer insight to travel more clearly across the business, but not every conversation can become another Slack summary that disappears by the end of the day.

Those are real constraints, and pretending they don’t exist doesn’t help.

Jake’s point was that teams need conversation architecture.

Conversation architecture is the structure that makes customer conversations easier, safer, and more useful. Depending on the organization, that might include training, expectations, intake processes, conversation guides, internal sharing rituals, customer programs, or clear rules for when and how product teams engage directly with customers.

Without architecture, customer conversation depends too much on individual effort. The teams that happen to care will do it. The people who already have relationships will learn more. The insights that get shared will depend on who has time, who remembers to write something down, and who happens to be in the right meeting.

With architecture, direct customer understanding has a better chance of becoming part of how the team works.

That is usually where the real work begins. Not convincing people that customers matter. Most people already believe that. The harder part is creating a system where direct customer understanding can happen consistently without creating confusion or risk for the teams involved.

Customer insight needs somewhere to go

The last part of the Compass that stayed with me was traction.

Jake named something I’ve seen many times: insight often dies in someone’s notebook.

A product manager has a great customer conversation. A community manager notices a pattern. A support leader hears the same frustration again and again. A researcher finds something that challenges the roadmap. Everyone agrees it’s interesting, maybe even important, and then the system doesn’t quite know what to do with it.

Maybe it gets mentioned in Slack. Maybe it becomes a note in a doc. Maybe it makes it into a meeting, but no decision changes.

That’s where customer conversation can start to feel performative, even when everyone involved has good intentions.

If the insight never changes a decision, priority, tradeoff, roadmap conversation, onboarding flow, or support motion, customers eventually feel that too. They can tell when an organization is collecting their input without building the internal muscle to act on what it’s hearing.

This is where community, product, research, support, customer success, and leadership have a real opportunity to work together. The goal is to build a clearer path from what customers are experiencing to what the organization does next.

That’s the work I’m still thinking about after this conversation.

There’s no magic wand answer. I wish there were. But there is a useful starting point: look honestly at where your team is relying on secondhand insight, where the customer’s actual words are getting lost, and where direct conversation would change the quality of the decision.

For teams building products, communities, or customer programs, that’s a worthwhile audit.

▶️ Watch the full replay from our webinar here.

Key takeaways

Product teams often have more customer information than they can process, but much of it reaches them after the original context has been filtered out.

Conversation Debt builds when teams rely too heavily on secondhand insight and lose regular contact with customers.

Customer feedback and customer conversations are both useful, but they help teams answer different kinds of questions.

Relationships create the trust customers need to share more honest, specific, and useful context.

Conversation architecture helps organizations make direct customer understanding part of the work rather than an occasional activity.

Customer insight needs a path into decisions, priorities, and action, or it risks becoming another artifact.

FAQ

What is Conversation Debt?

Conversation Debt is the gap that builds when teams rely too heavily on secondhand customer information and do not have enough direct, meaningful conversations with customers.

Why isn’t customer feedback enough?

Customer feedback helps teams see patterns and understand what customers are asking for, but direct conversation helps uncover context, motivation, confusion, and the deeper reasons behind what customers say.

What is conversation architecture?

Conversation architecture is the structure that helps teams have better customer conversations consistently. It can include training, processes, conversation guides, internal sharing rituals, and clear ownership.

How can product teams get closer to customers?

Product teams can start by identifying where customer insight is being filtered too heavily, then creating practical ways for builders to hear directly from customers in settings that are thoughtful, prepared, and useful.

Comments (0)

Popular