There is a common organisational design in product companies that treats product, sales, and marketing as sequential functions. Product builds the thing. Marketing explains the thing. Sales sells the thing. Information flows from product outward, and the feedback comes back through formal processes: quarterly business reviews, win/loss analysis, feature request logs. This design feels clean. It is also, in my experience, one of the most reliable ways to build a product that is slightly wrong in ways that are very hard to diagnose.
What Happens When Product Is Not in the Room
When a sales conversation happens without a product person present, several things are guaranteed to be lost. The customer's exact language for the problem they are trying to solve. The moment they hesitate when a feature is described. The comparison to a competitor that reveals what they actually value. The objection that was overcome and the reasoning that overcame it. These are some of the most valuable inputs available to a product team, and they evaporate the moment the call ends.
The summary that makes it back to the product team is a processed version of these signals. It has been filtered through the sales person's mental model of what is relevant. It has been simplified to fit into a CRM field or a feature request ticket. The nuance — which is where the real product insight lives — is gone.
"The customer's exact language for their problem is one of the most valuable inputs available to a product team. It rarely survives the journey from sales call to product backlog."
What Product Learns from Being Present
I have made it a practice throughout my career to be present in sales and partnership conversations whenever possible — not as the sales person, but as a technical product voice. The difference in what I learn is not marginal. It is categorical.
In a sales call, you hear the problem in the customer's own words, before it has been translated into product terminology. You see which parts of the product demo generate genuine interest and which parts produce polite nodding. You hear the question that the sales deck does not answer. You identify the assumption in your product narrative that customers do not share.
In a partnership conversation, you understand what the partner actually needs — not what they say they need in a requirements document, but what they are trying to achieve and what they are worried about. You can assess technical feasibility in real time rather than going back and forth through intermediaries. You can make commitments that are grounded in what is actually possible.
The Product Person's Role in These Conversations
Being present in sales and marketing conversations does not mean taking them over. The product manager's role in a sales call is to listen, to ask clarifying questions about the problem rather than the solution, and to provide technical clarity when the sales person reaches the edge of their knowledge. It is not to present, to negotiate, or to make commitments that the business has not already made.
In marketing strategy conversations, the product person's role is to ensure that the product story is accurate and to flag when the marketing narrative is drifting from the product reality. Marketing teams are good at finding the most compelling story. Product teams need to be in the room to ensure that the compelling story is also a true one.
The Information Flow Problem
Beyond what individual product managers learn from being present, there is a systemic information flow problem that the organisational separation of product, sales, and marketing creates. When these functions operate sequentially and separately, they develop different mental models of the product, the customer, and the market. Product thinks in terms of features and architecture. Sales thinks in terms of objections and use cases. Marketing thinks in terms of messages and segments. None of these mental models is complete, and they drift further apart over time.
The product manager who is regularly present in sales and marketing conversations becomes a translation layer. They understand how the product is actually being sold, which means they understand what assumptions sales is making about the product's capabilities. They understand how the product is being positioned, which means they can flag when the positioning is making promises the product cannot keep.
The Feedback That Only Comes from Being Present
Some of the most important product feedback I have ever received came from moments in sales conversations that would never have made it into a feature request. A customer mentioning, almost as an aside, that they are using a workaround for something our product should do natively. A sales person smoothly changing the subject when a question touches on a gap they know exists. A partner asking about a capability we did not have, and the way they reacted when we said we would build it — the pause that tells you they have heard that before and do not believe it.
These signals require presence. They cannot be captured in a summary. They are the raw material of product insight, and they are only available to the person in the room.
Building the Habit Organisationally
The way to institutionalise this is not to require product managers to attend every sales call — that is neither practical nor the right use of their time. It is to establish a regular cadence of joint sessions: product joining sales calls for specific customer segments or at specific points in the sales cycle; product participating in quarterly marketing strategy reviews; a formal mechanism for sales and customer success to escalate conversations that have product implications.
The goal is not to blur the boundaries between functions. It is to ensure that the people making product decisions have the richest possible picture of how those decisions play out in the market. That picture is not available from a desk. It requires being in the room.
I advise founders and product teams on strategy, delivery, and building financial products that work. If this resonated, let's talk.
Get in touch