Customer Obsession
Leaders start with customer needs and work backwards. Customers are anyone we serve, inside or outside the company. Leaders build relationships that help them understand and anticipate customer pain, then innovate to solve it. They earn and keep customer trust while protecting the long-term health of the business.
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 it is for.
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 sticks a sentence about the customer on the end 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. Bugs that stop customers from getting their work done sit in the backlog. | 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 small complaint as urgent. The team spends the week on one-off annoyances while a bug that blocks customers 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 smaller first version that unblocks them and holds the extras for later, 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 by asking what the customer is working on 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. | Squeezes the special case into this week's work. Support now has to handle 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 over minor wording and rare 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 reason, and what saying yes would cost other customers. Offers the closest supported option and puts the answer in writing, including what would have to change for the team to reconsider. | 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. Hiding is under. Saying yes and yanking the team off its plan is over. Just right is explaining the tradeoff, shipping what is best for all of your customers, and staying in the conversation. That is how you earn trust with customers without saying yes to every request.
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 rest of them.
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 it is for?
- 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?
Further reading
Sources and essays on this principle.
- Focusing on users is not Customer Obsession
The essay argues a customer pays you for value, and a user is someone you force, addict, or sell.
kindel.com
- Work Backwards From The Customer
Start with the customer outcome, not the technology you already built.
kindel.com
- How To: Write a Working Backwards Doc
The mechanism: write the press release and FAQ before you pick a stack.
kindel.com
- Working Backwards, the book by Colin Bryar and Bill Carr
The PR/FAQ chapter. Write the customer experience first, then decide what to build.
macmillan.com
Related
Principles that sit next to this one.
Principles lean on each other, and some pull against each other on purpose (the tension is intentional). Here is how Customer Obsession connects to the rest of the set.
See something wrong or missing? Fix it in Facet.