Customer Obsession
How to stay relentlessly focused on solving your customers' hardest problems, not building feature lists.
TL;DR
- Your long-term value is tied to the significance of the problems you solve, not the features you build.
- Easy problems yield incremental results. Hard problems create new markets and sustainable value.
- AI can now scale customer understanding, but the PM's job is directing that synthesis and applying judgement to the output.
Customer-centric is table stakes. Customer-obsessed is the bar. The difference: customer-centric organisations listen to what customers ask for. Customer-obsessed organisations pursue the deepest, most urgent pain points, even when customers can't articulate them.
This matters because the significance of the problem determines the ceiling of the solution. Solve a trivial problem and you get a trivial product. Solve the hardest problem in a customer's workflow and you become indispensable.
Five practices for customer obsession
1. Start with the press release
The press release is the first artefact you create for any strategic initiative, not the last. It forces you to articulate the customer's problem and the solution's impact from the start. If you can't write a compelling one, the problem isn't worth solving.
A strong press release answers four questions:
- Who is the customer?
- What is their pain?
- What is the value of solving it?
- What is the core message?
This is an adaptation of the Working Backwards methodology. Write the press release before any code exists. It exposes weak thinking faster than any sprint planning session.
For AI products, this technique matters even more. Customers often cannot articulate what they want from AI because they don't know what's possible. The press release forces you to describe the outcome in concrete terms ("Analysts complete portfolio reviews in 20 minutes instead of 4 hours") rather than hiding behind vague capability claims ("AI-powered analytics").
2. Talk to a customer every week
Data provides the "what." Direct customer insight provides the "why." Every product manager and designer should speak to a customer weekly. Not a sales demo. Not a feature walkthrough. A genuine conversation about their workflows, challenges, and goals.
This builds empathy, validates assumptions, and surfaces needs that quantitative data alone would miss.
3. Go to the gemba
"Gemba" is the real place where work happens. Spend time in your customers' environments: their office, their factory floor, their digital workspace. Observe how they interact with your product within their ecosystem.
This reveals pain points and opportunities that surveys or calls would never uncover. The gap between what customers say they do and what they actually do is where the best product insights live.
For AI-powered products, gemba observation reveals a distinct set of behaviours. Watch for trust patterns (when do users accept AI suggestions vs. override them?), prompt behaviour (how do they phrase requests, and how does that differ from what the system expects?), error recovery (what happens when the AI gets it wrong?), and the AI detour problem (users spending more time wrestling with an AI feature than doing the task manually). These observations don't surface in NPS scores or feature requests.
4. Treat the problem statement as a hypothesis
Your problem statement is a living document, not a one-time declaration. Constantly test and refine your understanding of the customer's needs throughout the product lifecycle.
Use the "Five Whys" technique to push past surface symptoms and reach root causes. The first answer is almost never the real problem.
5. Use AI to scale customer understanding
A single PM can now process signal at a scale that previously required a research team. AI can synthesise thousands of support tickets into thematic clusters, analyse call transcripts for recurring pain points, process NPS verbatims to surface sentiment shifts, and identify patterns across behavioural data that no human would spot manually.
The PM's job shifts. Less time manually reading and tagging. More time directing the synthesis ("show me complaints from enterprise customers about onboarding in Q4") and applying judgement to the output ("this cluster looks like a symptom, not a root cause"). The risk is trusting the AI's summary without interrogating it. The opportunity is that a PM with good questions and AI tools can maintain genuine customer understanding across a much larger surface area than was previously possible.
Hallmarks of a customer-obsessed PM
| Behaviour | In practice |
|---|---|
| Obsessed | Can clearly and concisely articulate the customer's problem without mentioning a solution. |
| Grounded | Points to specific customer quotes, survey data, and behavioural evidence that validates the problem. |
| Focused | Can explain why this is the hardest, most important problem to solve right now, over any other. |
| Proactive | Is continuously engaging in discovery activities with customers and stakeholders. |
The anti-pattern: feature request driven development
The opposite of customer obsession is treating your backlog as a feature request queue. Customers ask for solutions, not problems. If a customer says "I need a CSV export button," the customer-obsessed PM asks why. The answer might reveal a reporting workflow problem that a better dashboard would solve entirely, no CSV needed.
Taking feature requests at face value produces an incrementally better product. Obsessing over the underlying problem produces a transformatively better one.