Customer Obsession

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 can miss. The gap between what customers say they do and what they actually do is a rich source of product insight. Users bending your product toward an unintended use case may signal latent demand. Treat it as evidence to investigate, not an automatic roadmap decision.

For AI-powered products, gemba observation reveals trust patterns, prompt behaviour, error recovery, and the AI detour problem. Watch when users accept or override suggestions, how their language differs from the system's expectation, and what they do after a failure.

The AI UX design chapter turns those observations into interaction decisions. NPS scores and feature requests rarely show the complete behaviour.

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 can spend less time manually reading and tagging, and more time directing the synthesis. A useful request is specific: "show me complaints from enterprise customers about onboarding in Q4". Judgement still matters when deciding whether a cluster is a root cause, a symptom, or an artefact of the sample.

This is part of the broader product builder skill set. AI can expand the evidence one person can inspect, but a generated summary is not the source. Preserve traceability to customers, quotes, records, and observed behaviour.

The litmus test

Put a customer-obsessed PM in a room with a stakeholder and ask them to explain what they're building. A good PM describes the feature. A customer-obsessed PM describes the customer's problem, with specific quotes, specific data, and a specific explanation of why this problem matters more than alternatives. They can discuss a solution, but they do not use it as a substitute for evidence about the problem.

If your PM can't do that, they're building from a feature request queue, not from genuine understanding.

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. The chapter on discovery, feedback, and backlogs covers the structural practices that keep teams grounded in customer problems rather than feature requests.