Customer and User Obsession Questions

Direct answer

Choose a moment when you had already committed (designed it, built toward it, or announced it) and something you watched users do contradicted the plan. Say what you saw, show that you checked it was not a one-off, change course openly, and prove the change helped. The strongest stories name the sunk cost (work already spent) and still pivot, because the evidence was specific and repeated.

Story shape (Situation, Task, Action, Result)

• Situation: the direction, why it was reasonable, and your personal stake in it.
• Task: the learning moment. Name the source: a usability session (watching someone try the product while they think aloud), support tickets, or usage data.
• Action: three beats. (1) Describe behaviour you observed, not opinions. (2) Look for a second source before acting. (3) Tell the team what is being cut, what is reused, and why.
• Result: one measurable outcome plus what you would do differently.

Worked example (illustrative skeleton; substitute your own real story)

A product designer and an engineer are three weeks into a step-by-step setup wizard for a reporting tool, assuming new customers are lost and need hand-holding. In moderated sessions (a researcher or colleague is present, giving tasks and asking questions live) with six new customers, every one pauses at step one and asks whether they can just bring their existing spreadsheet. Two give up. Six sessions cannot show how common this is, so the next step is to look at support tickets tagged "setup" (same request repeated) and the sign-up funnel (the steps from starting sign-up to first success, showing where people drop off), where roughly half of sign-ups stop at step one (illustrative).

With three sources agreeing, the designer writes a one-page note: the original assumption, what was observed, work already spent, and a replacement (spreadsheet import with a preview, no wizard). An excerpt:

Assumption: new customers need a guided setup wizard.
Observed:   6 of 6 asked at step one to import their spreadsheet; 2 of 6 gave up.
            9 of the last 40 setup tickets ask the same thing (illustrative).
Spent:      3 weeks. The progress component is reusable.
Proposal:   replace the wizard with spreadsheet import plus preview; cut its five
            remaining steps.
Check:      re-test with the same 6 people in 2 days, then track first report
            within 24 hours.

The wizard's progress component is reused for the import steps, so part of the sunk work survives. A clickable prototype (linked mock screens people can tap through, with no working product behind them) goes to the same participants within two days.

Result to report: the share of new accounts that reach their first report within 24 hours, compared across two equal-length windows before and after. A result might sound like this (illustrative): "In the four weeks before, 31% of new accounts got a first report within 24 hours (62 of 200). In the four weeks after, 48% (96 of 200). A marketing push ran in week three, so I also checked sign-ups from the same channel, and the rise held." In your own story, state your real two numbers and the caveat that other changes shipped in the same period.

Trade-offs and pitfalls

• One loud user is not evidence. Cross-check with a second and third source.
• Sunk cost: say the cost out loud ("we had spent three weeks") so the pivot reads as a decision, not an accident.
• Do not make the story about being right. Credit the users and the colleagues who adapted.
• Say what you would do differently: test a rough prototype in week one, before building.
• Engineering variant: a machine learning engineer who tuned a model for accuracy, then learned users cared about response time and explainability, tells the same story with the metric changed.

Direct answer

Being customer-obsessed means starting every decision from the customer's underlying problem and letting that change what you do, including when it costs you something. Being responsive means reacting quickly to what customers say. Responsiveness waits for the customer to speak; obsession goes looking for the problem behind the words, and for the customers who never speak at all.

How the ideas differ

• Customer focus is caring about customers in general. It is an attitude and does not have to change any decision.
• Customer obsession is customer focus that shows up as a changed choice: a scope cut, a delayed date, a "no" to a loud request.
• Voice of the customer (VoC) is the collected record of what customers say they want and struggle with (tickets, interviews, survey comments). It is evidence, not a decision.
• Customer advocacy is using that evidence to argue for the customer in internal decisions when a deadline or a revenue target pushes the other way. VoC informs you; advocacy is what you do with it.

Two decisions I would make differently

1. Ask what the request is for before building it. A customer asks for a CSV export of a report. A responsive team ships the export this sprint. An obsessed one asks "what do you do with the file?", learns the customer pastes it into a spreadsheet to compute one weekly figure, and builds that figure into the product. The customer gets a better outcome and nobody maintains a one-off export.
2. Protect a rough spot users hit, even at the cost of a date. Suppose first-run setup is confusing: in observed sessions people stall at the same step and support tickets mention it. A responsive team waits for enough complaints to reach a threshold. An obsessed one moves the date by a few days, fixes that step, and says openly what the delay buys. I would accept a small, stated schedule cost to avoid a large, silent cost to every new user.

Same idea, different seats

A customer success manager (CSM) asks why an account's usage is falling before the renewal call, not after. A sales engineer (SE) or solutions architect (SA) recommends the smaller design that fits the customer's need over the bigger one that is easier to sell. A user-interface (UI) designer tests the layout with the people who will use it, not only the person who bought it.

Trade-offs and pitfalls

• Obsession is not "the customer is always right". Customers describe solutions; your job is to understand the problem and weigh it against other customers and the business.
• Be honest about limits: one customer's problem is a hypothesis until you see it elsewhere.
• The tell that you are only being responsive is that your backlog is a list of requests with the customer's wording still attached.

Direct answer

I weigh the security benefit against the friction a customer will actually feel, using numbers where I can. Then I look for the lowest-friction way to get most of the protection, and I roll it out in stages with measurements and an exit. Security wins when the risk is serious and not otherwise reducible, but how it ships is a customer-experience decision.

How I weigh it

1. Risk removed. What attack or loss does the change prevent, how likely, and for whom? Ask security for a specific scenario, not "best practice."
2. Friction added. Which customers feel it, how often, at what moment (signing in daily versus a rare admin action), and what do they do when annoyed (abandon, call support, work around it)?
3. Cheaper routes to the same protection. Apply the strict control only where risk is high (risk-based or step-up checks: ask for an extra proof only when something looks unusual or the action is sensitive), remember trusted devices, or give a smoother factor.
4. Who carries the cost. Friction on a signup flow costs conversion; friction in an enterprise admin flow costs support calls.

Three related cases

Worked example (illustrative): rolling out MFA to 100,000 accounts

• Stage 1: 5% of accounts (5,000), chosen to include small and large customers. Track setup completion, lockout-related support contacts, and sign-in success.
• Gate: advance only if the thresholds agreed beforehand with security and support are met. Illustrative thresholds: at least 80% of prompted accounts finish setup (4,000 of the 5,000), no more than 10 lockout-related support contacts a week (2 per 1,000 accounts), and sign-in success falls by no more than 1 percentage point. Miss any one and I pause, fix the cause, and rerun the stage.
• Stage 2 and 3: widen, with in-app explanation of why, then move from encouraged to required on a published date. Keep a rollback and an exception path for customers with real blockers.

Pitfalls

Do not frame it as security versus customers. Do not roll out to everyone at once. Do not set a "will not hurt conversion" bar with no measurement behind it.

Direct answer

A strong answer owns the miss without excuses, shows what I did fast to limit harm (tell the customer early, give an interim fix, coordinate engineering with one owner), what I changed so it would not recur, and how the relationship ended up. The example below is an illustrative skeleton; use your own facts.

Situation

I had told a customer an integration would be ready by their launch date. Two weeks before, it became clear the date was not safe, because engineering found an unexpected limit in a third-party service.

Recovery

1. Tell them early, directly. I called the customer's lead as soon as I knew, rather than waiting for the date to pass. I said what I had promised, what had changed, and that the fault was in how I committed.
2. Offer an interim path. A manual workaround covered their launch while the integration was finished.
3. Coordinate engineering. I became the single point of contact (one person the customer can always reach): one shared channel, a named engineering owner, and a status update to the customer every few days even when nothing had changed.
4. Give a new date with an honest range. I committed only after engineering confirmed it, stating a range and what could move it.

The same story from a reliability seat

If your seat is site reliability engineering, the promise is usually a service level agreement (SLA, the uptime or recovery commitment written into the contract) rather than a launch date, but the recovery has the same shape. Say the service fell below the promised uptime. You post a status update as soon as you know, not after the customer notices. You put in a mitigation (a temporary fix such as failing over to a standby system) while the real fix is built, and you run one incident owner so the customer talks to one person. You then give an honest estimate of the fix, and afterwards run a blameless post-incident review (a written account of what happened and why, aimed at fixing the process, not blaming a person) with named action items such as better alerting or a capacity limit check.

Turning the customer around

The customer was frustrated at first, but the early warning, the workaround and the regular updates gave them what they needed to plan. They later agreed to act as a reference (a customer who vouches for you to prospective customers) for the integration, which is the outcome I aim for: a detractor (an unhappy customer; in the Net Promoter Score survey, someone answering 6 or lower on the 0 to 10 "would you recommend us" question) becoming an advocate because of how a problem was handled.

What I changed afterwards

• I stopped promising dates before engineering confirmed an estimate, and began giving ranges.
• I added a checkpoint at the midpoint of any customer commitment to check confidence.
• I wrote a short review of what went wrong and shared it with the team.

Pitfalls

Blaming engineering or the customer, minimising the miss, claiming a recovery you cannot show, or describing only the apology. The strongest answers show the specific process change. A strong story also shows the specific process change, since an apology alone does not stop a repeat.

Direct answer

I would not agree yet. A rising Net Promoter Score (NPS) tells me that more survey respondents said they would recommend us. Before I treat that as "customers are happier" I want to know who answered, whether the rise is bigger than noise, and whether behaviour (retention, usage, support contact) moved the same way.

What NPS is

Customers answer one question, "How likely are you to recommend us to a friend or colleague?", on a 0 to 10 scale. Scores of 9 to 10 are promoters, 7 to 8 are passives, 0 to 6 are detractors.

NPS = % promoters - % detractors

The result runs from -100 to +100. Passives do not count in the formula.

What I would ask before agreeing

1. How many responded, out of how many invited, and did the response rate (answers divided by invitations) change? A different mix of respondents can move the score on its own.
2. Did the customer mix change (more enterprise, fewer trial users), or the survey wording, timing or channel?
3. How big is the rise relative to the survey's noise? See the example below.
4. What do the open-text "why" answers say? Did detractors shrink, or did promoters grow?
5. Did retention, renewals, usage depth and time to first value (how long new customers take to get their first real outcome) move in the same direction?

Worked example (illustrative responses, reproducible)

The code below measures noise, meaning the random wobble you get because a different set of customers answering would give a slightly different score even if nobody's feelings changed. To measure it, give every answer a value: +1 for a promoter, -1 for a detractor, 0 for a passive. NPS is 100 times the average of those values, which is exactly the share of promoters minus the share of detractors. The spread of the individual values is p + d - (p - d)^2, where p is the promoter share and d the detractor share. Dividing by the number of answers n and taking the square root gives the standard error: the typical amount the score would move if you re-surveyed a different random group of the same size.

standard error = 100 * sqrt( (p + d - (p - d)^2) / n )

Small surveys wobble more, because n sits under the square root. Two independent surveys combine their wobble as sqrt(se1^2 + se2^2), which is why a comparison between two quarters is noisier than either score alone.

Last quarter: 80 promoters, 70 passives, 50 detractors (200 answers), NPS +15. This quarter: 54, 36, 30 (120 answers), NPS +20. The VP sees +5.

from math import sqrt

def nps(promoters, passives, detractors):
    n = promoters + passives + detractors
    p, d = promoters / n, detractors / n
    score = 100 * (p - d)
    se = 100 * sqrt((p + d - (p - d) ** 2) / n)  # standard error of the score
    return score, se

q1, se1 = nps(80, 70, 50)
q2, se2 = nps(54, 36, 30)
diff = q2 - q1
se_diff = sqrt(se1 ** 2 + se2 ** 2)
print(round(q1), round(se1, 1))
print(round(q2), round(se2, 1))
print(round(diff), round(se_diff, 1), round(diff / se_diff, 2))

It prints 15 5.6, then 20 7.4, then 5 9.3 0.54. The standard error of the difference is about 9 points, so a 5-point rise is about half a standard error (5 / 9.3 = 0.54). A common rule of thumb is that a gap needs to be roughly two standard errors (here about 19 points, since 2 x 9.3 = 18.6) before you treat it as more than chance. With these samples a rise of 5 points cannot be told apart from chance, and the response count fell from 200 to 120, which itself needs explaining.

When another measure tells you more

Timing matters: CSAT and CES measure a moment, NPS measures a feeling about the relationship, so asking NPS right after a good support reply inflates it.

Limits of survey scores alone

Only responders are heard, scores can be gamed (asking only happy customers), and a number gives no reason. Pair every score with open-text answers and with behaviour. If NPS rises while renewals and usage are flat, believe the behaviour.

What I would tell the VP

"The rise is encouraging but not yet proof. Let me show you the segment split, the response counts and the retention trend next to it."