The Comfortable Approximation
Last week I attended a transport committee meeting for one of our major Northern cities. Around the table: the constituency MP, national infrastructure providers, representatives from transport carriers, fleet/rolling-stock manufacturers, local authority officers, transport planners, access campaigners and passenger advocates.
I have worked in travel for a while now. I have built features, including some global firsts. Reflecting after the meeting, I realise that as a Product Manager, I've never felt as close to the customer as I do now, which gives me pause in that perhaps I wasn't as close as I thought I was in the past.
The claim we make
Product managers routinely describe themselves as the voice of the customer - the function whose job it is to represent user needs in the room where build decisions are made. It is an attribute with real weight.
It is also, in most large organisations, a comfortable approximation of something that requires far more than the structures typically in place to support it.
Being the voice of the customer requires knowing the customer. The synthesis of forty interviews conducted by a research team, then presented in a sixty-minute readout does not provide this. Knowing the actual texture of the problem: the constraints people are operating under; the ecosystem of stakeholders they are embedded in - these are the contextual factors that make a problem real and move a proposed solution from middling to "wow".
The breadth problem
The transport committee meeting was not user research. It was a room containing people who look at problems and consider solutions from a diverse set of entirely different perspectives and an entirely different conceptualisation of what good looks like. I was struck by how together they created a system level view, rather than a "user journey" which as PMs we're more familiar with - drawn as a singular view of "the truth" and pinned to a wall at work.
Understanding the end-user: what they want when they open an app, what makes them book or abandon, misses, dare I say, most of what shapes the experience they will eventually have.
The footpath to the station that makes or breaks the journey for someone with a disability. The carrier staff who choose to delay a service to help a passenger find a misplaced walking cane. The policy maker trying to connect a rural community to economic opportunity, healthcare, and family. These are not peripheral or irrelevant to a Product Manager, or at least they shouldn't be. Incidentally - all real examples from last week.
The complexity compounds wherever a business operator sits between the Product Team and the end user. Moreover, that operator may be a customer in their own right, with constraints of their own - but also often the most available lens into end-user behaviour. Understanding their systems, their incentives, their relationship with their own customers is highly valuable.
Most Product organisations are structurally prevented from accessing this richness. Industry intelligence: what carriers are thinking, what regulators are signalling, where policy is heading, is often siloed at VP and Director level and does not flow to the PMs making day-to-day build decisions. The expectation is that PMs will represent stakeholders whose context they are either excluded from seeing, or whose context has been filtered and distilled several times over such that it bears little utility. This is an organisational failure with a Product cost.
The depth problem
Breadth is one dimension. Depth is the other.
There is a widely held view that Product Management is a portable skill, a strong PM can move between sectors and be effective quickly. This is partly true and often overstated. Process, communication skills do transfer. Judgment and taste require immersion.
Knowing which problems are real versus perceived, which constraints are structural versus addressable, which user behaviour reflects a genuine need versus an adaptation to a broken system - that pattern recognition takes time and genuine proximity to build. It does not come from an induction deck or a market overview. A PM without deep domain knowledge can run a discovery process competently but they cannot reliably distinguish the problems worth solving from those that only appear important because the system is poorly understood.
I'm not building an argument that every PM should spend their time attending committee meetings or commissioning multi-week field studies. PMs are among the busiest people in any organisation.
What I am doing is highlighting a tension between speed, practicalities and quality of understanding. My answer is honesty about where and how knowledge and sense making work, and to invest in the relationships and structures that bridge the gap.
The researcher as partner
Researchers are among the most undervalued professionals in product organisations. They are typically treated as a service function: they receive a brief, go and find things out, and return with a presentation. The PM attends, notes the headlines, and moves on. The relationship is transactional. The research is an input to a decision already half-made.
This is almost the inverse of what makes research valuable.
A researcher embedded in a team, working alongside a PM as a genuine partner rather than a service provider, extends the PM's ability to inhabit the problem space. They bring craft the PM typically does not have: the ability to design a research programme that surfaces what is not being said, to read what a participant is performing versus experiencing, to connect individual signals into a pattern that changes the frame rather than confirming it. That craft is not in the deck. It lives in the process, and in the relationship.
The PM-researcher relationship deserves the same intentionality as the PM-engineering manager relationship: structured, reciprocal, built on mutual respect for what each person brings. Not: researcher delivers to PM. But: researcher and PM jointly own the problem, with the researcher's judgment carrying real weight on the questions of what to build and why.
This points toward distributing research expertise rather than centralising it — I'm sceptical of central units that own "the customer" and report findings upward on a quarterly cadence. Embed researchers in teams. And extend the relationship outward: brand, marketing, public affairs all benefit from and contribute to this kind of proximity. Customer understanding is not a Product-only discipline.
The organisations that close this gap are not necessarily the ones with the biggest research budgets or the most sophisticated discovery processes. They are the ones that have stopped treating customer understanding as a deliverable and started treating it as a discipline - something that is practised continuously, embedded in the team, and held to a higher standard than what a readout deck can provide.