Why it matters
What this principle is for.
Customer Obsession is where the energy comes from. You can invent impressive technology, solve hard problems, and still fail if you are not meeting a real customer need. Competitor-watching is limiting. Learn from competitors. Live for customers.
At every meeting, the customer is the person who is not in the room. Someone has to advocate for them. If you do not, the room will optimize for the people who showed up.
Many jobs never touch the end customer. That does not let you off. Your customer may be another team. You still work backwards from their need, and you still understand how their work reaches the person who pays.
Mature teams get arrogant. They start believing they know better than the people they depend on. The habit that prevents that: in every decision, ask how this affects the customer.
Calibration
Under, just right, over.
Look for a named customer and a real tradeoff. A story that starts with an internal plan and retrofits a customer line is not this principle. Neither is making a process exception for every loud person, or ignoring a complaint because it is only one.
| Situation | Under | Just Right | Over |
|---|---|---|---|
| A customer is blocked this week | Closes the ticket once it is assigned elsewhere. Does not check whether the customer can work again. | Stays with the issue until the customer can continue. Pulls in whoever is needed, gives the customer a clear next step, and keeps the fix small enough that the rest of the week's work still ships. | Camps on the ticket and drops the other customer work already in flight. Those customers wait while one issue gets undivided attention. |
| Picking which bugs to fix | Works the newest or easiest tickets. Breakage that stops customer work sits in the list. | Asks which defects are blocking real jobs this week. Fixes those first, even when they are messy, and leaves cosmetic issues with a short note on why they wait. | Treats every reported nit as urgent. The team spends the week on one-off annoyances while a workflow break stays open. |
| Another team is waiting on you | Leaves the request in the queue. Does not ask what customer work is stuck behind it. | Learns who is blocked and what they need to finish this week. Sends a thinner handoff that unblocks them and parks the extras, so both teams' customer work can move. | Drops their own customer commitments to polish the internal request past what was asked. The asking team gets more than they needed, and external customers wait. |
| In a customer meeting | Walks through internal plans. Leaves without knowing what the customer is trying to get done. | Starts with their current work and what is in the way. Commits only to what the team can do soon, writes it down, and takes the rest back as input rather than a promise. | Says yes to every request to keep the meeting warm. The team spends the following days untangling commitments it cannot staff. |
| A promised date is going to slip | Stays silent. The customer learns about the miss when the work does not arrive. | Calls as soon as the slip is certain. Offers a smaller piece they can use now and a date for the rest that the team can actually hold. | Adds free extras or a tighter new date to soften the news. The second miss costs more trust than the first honest delay would have. |
| One customer asks for a custom change | Parks the request and never checks whether anyone else has the same problem. | Asks how widespread the need is. Builds a shared version if it is common, or declines the one-off and offers a path the product already supports. | Cuts the special case into this week's work. Support now carries an exception, and the next customer expects the same treatment. |
| Reviewing a change before it ships | Marks the ticket done without walking the customer path. Confusing steps go out unnoticed. | Tries the change the way a customer will. Holds the release for a step that would block them, and lets leftover polish wait until after it ships. | Stops the release for rare wording and edge cases. The fix customers are waiting on sits another week. |
| Telling a customer no | Avoids the conversation. The customer keeps planning around something the team will not build. | States the no, the constraint, and what saying yes would cost other customers. Offers the closest supported path and writes it down so the hope does not get revived by accident. | Softens the no until it sounds like a later yes. The customer staffs a plan around a capability that never arrives. |
Examples
What it looks like in the work.
Keep a broken promise in person
A customer was promised a gift by a hard date. The system failed. Someone bought the item locally and put it in the customer's hands. That is not a scalable process. It is a signal: the promise mattered more than the org chart. The next question is what they did so it would not happen again. Heroics without a fix is theater. Heroics that produce a process change are Customer Obsession plus Ownership.
Treat clumsy feedback as an audit
Customers write short, messy, even "simple minded" reviews. Teams that are not obsessed discard them. Teams that are obsessed research each one, because a real person just audited your process for free. The person who can tell you what they changed after a clumsy comment is the one who is actually obsessed.
Say no to a request that would hurt them later
A loud customer wants a shortcut that would help this week and damage the experience for everyone else. The under move is to hide. The over move is to say yes and churn the team. The just-right move is to explain the tradeoff, ship the thing that is best for the collective good, and stay in the conversation. That is how you earn trust with customers without becoming a vending machine.
In the role
Individual and manager.
Individual
You can name who consumes your work and how it shows up in their week. You close the loop when something breaks. You do not wait for an escalation to discover a problem you could have seen in the product.
Manager
You do not let the team hide behind "the business asked for it." You force the doc to name the customer. You kill work that is internally elegant and customer-useless. You teach the team when to say no to one customer so you can say yes to the customer set.
Go deeper
Questions that make the principle concrete.
- Who is your customer, and who is not your customer but should be?
- If your customer is internal, how does their work reach the person who pays?
- When did you last sit with a customer using the product, and what friction did you see?
- Are you implementing the request they asked for, or solving the problem they are actually trying to solve?
- What did you say no to because it would have been a short-term win and a long-term loss for the customer?
- How do customers reach you, and how are you doing against the response time you promised?
- When a problem sits outside your area, what do you do to make sure it stays fixed?
- How will you know the customer had a good week because of your team's work?
- What part of your system causes the most customer pain, and what is the root cause?
- If you cannot hit the date, how do you renegotiate with the customer instead of going silent?
From the blog
Writing that goes deeper.
- Focusing on users is not Customer Obsession
A customer pays you for value. A user is someone you force, addict, or sell.
- Work Backwards From The Customer
Start with the customer outcome, not the technology you already built.
- How To: Write a Working Backwards Doc
The mechanism: write the press release and FAQ before you pick a stack.
Related