Customer and User Obsession Questions

Direct answer

I tell it in STAR order (Situation and Task, then Action, then Result, the standard structure for behavioral interview stories), covering the original scope, the cut, the customer test and the outcome, and I make clear that the cut was driven by a customer job (the task the customer is trying to get done), not by what was easiest to build. Sample story below; the shape is what matters.

Situation and original scope (Situation, Task)

Our customers needed to see how their team was performing. The first plan was a reporting module with five parts: a drag-and-drop dashboard builder, twelve chart types, scheduled email delivery (reports emailed automatically on a timetable), CSV and PDF export, and role-based sharing (an admin chooses who in the company can see which report). Estimated work was several months, and we had no real evidence that customers needed all five.

What I cut and why (Action)

• Cut: the dashboard builder, ten of the twelve chart types, scheduled email delivery, PDF export and role-based sharing.
• Kept: two fixed charts answering the question customers raised most often ("is my team getting faster or slower?") plus CSV export.
• Rule used: keep what a customer cannot complete the job without, and cut what only makes the job nicer.
• Applying the rule: the job was "tell whether my team is speeding up or slowing down." Two fixed charts plus CSV export complete it, and the CSV covers anyone who wants a custom view in a spreadsheet. The builder, extra chart types, scheduled email, PDF and sharing make the job nicer, but customers could already finish it without them.

How I validated the minimal version

I showed a clickable mock (a prototype of screens that respond to clicks but has no real working code behind it) to a handful of customers, asked each to do the job with their own numbers, and watched where they hesitated. Then we shipped to a small group and checked whether they came back the next week and exported data, rather than asking whether they liked it. The honest limit: a handful of interviews shows what confuses people, not how many want it.

What happened (Result)

It shipped in about six weeks against an original estimate of about five months (illustrative figures; use your real ones). Customers used the two charts and the export; some asked for scheduled email (the one cut item that proved wanted), so that went next, while nobody asked for the builder and we never built it. What I would do differently: I would have asked the first customers about scheduling before the mock, because two of them raised it unprompted.

Pitfalls

Do not tell a story where cutting was only about speed. Show the customer evidence for what stayed and what went, and name something you got wrong.

Direct answer

Yes. I pick a story where I moved from caring about the elegance of the solution to caring about what the person using it was trying to do, and I show three concrete changes: what I built, what I prioritized, and what I traded away. I tell it in STAR order (Situation and Task, Action, Result), the standard structure for behavioral interview stories.

Situation and Task

I was the engineer on an ordering app used by small cafe owners at the counter during rush hour. I took pride in a clever offline sync design (the app keeps taking orders without internet and merges them with the server when the connection returns). Then I spent a shift watching an owner use the app and saw that what she dreaded was a lost order when the connection dropped, not anything about how sync worked.

Action

• Engineering decisions: I replaced my clever conflict-resolution design (the rules for what happens when two edits to the same order collide) with a simpler one that always kept both versions of an order and flagged the clash in plain words for a human to resolve in seconds. Example: the counter phone edits an order to 2 lattes while offline, a helper's tablet edits the same order to 3 lattes while offline. The clever design silently kept one and lost the other. The simple one shows "Order 41: 2 lattes or 3 lattes? Tap the right one." It was less elegant and much easier to trust.
• Prioritization: I moved a planned refactor (restructuring code without changing what it does) behind a fix that made a half-saved order visible on screen, because that failure cost the owner money in real time.
• Trade-offs: I accepted slightly clunkier code and a delayed internal cleanup to protect the owner's rush hour, and I said so openly to the team.

Result

Support complaints about lost orders dropped from about a dozen a month to two or three (illustrative; use your own measured figures), and the owners I had watched started using offline mode with confidence. I also began asking "who is on the other end of this change?" in design reviews.

Pitfall

Avoid vague "I love our users" language. The proof is a decision you made differently, and a cost you knowingly paid.

Direct answer

A stakeholder is anyone with a say in or stake in the work, here the person pushing for the dense layout. I would neither refuse nor build it blindly. I would treat "a dense dashboard" as a solution the customer proposed and find the need behind it: which users, doing which decisions, how often. Then I would bring the stakeholder evidence rather than opinion, and propose a design that serves both the experts who want density and the novices who might drown, validated with a quick test before we commit.

Step by step

1. Clarify who asked and why. Which customers made the request, and are they the same people as the novice users I am worried about? Power users who live in the tool all day want density. New users want a clear first answer.
2. Find the decisions behind the density. Ask "what do you decide with this screen on a Monday morning?" If three questions drive most of the value, those need prominence; the other numbers can sit one click away.
3. State my concern as a testable claim. "I expect first-time users to fail at finding X on the dense layout." That is something a test can show wrong, which keeps the conversation from becoming opinion against opinion.
4. Prototype both and test with real tasks. Give representative novice users and experienced users the same two or three tasks on each version and watch where they stall. Agree in advance what would count as a pass (for example, most participants can find the key figure unaided).
5. Offer alternatives that meet the request.
   • A summary view by default with drill-down for detail (progressive disclosure: show the essentials first and reveal more on demand).
   • A density toggle or saved "expert view" for power users.
   • Role-based defaults, so each user lands on the metrics they own.
6. Decide and record. Ship what the evidence supports, and write down what you would revisit.

Worked example

An operations dashboard has 24 tiles. Asking the requesters what they check first reveals that they open it to answer three questions: is anything late, is anything failing, what changed since yesterday. I would put those three at the top, keep the other 21 tiles in an expandable detail view, and test both layouts with a few new and a few experienced users. If experienced users complete tasks equally well on both and novices only succeed on the layered one, the layered version is the clear call.

What would change my mind

If testing shows the actual users are specialists who value seeing everything at once, I would ship the dense version, possibly with better grouping and labels. The aim is the customer's outcome, not winning the argument.

Pitfalls

Arguing from taste ("clutter is bad"), testing with colleagues instead of real users, and presenting the stakeholder's request as wrong rather than as a solution worth testing.

Direct answer

Pick an improvement where you can draw a line from your technical change to something a customer felt: faster pages, fewer failed payments, fewer crashes. Show the before-and-after measurement from the customer's side, not just internal numbers like CPU usage, and be honest about other factors.

Structure

1. Problem as customers experienced it. A complaint, a ticket tag or an abandonment point.
2. Change. One or two sentences, in plain terms.
3. Proof it reached the customer. Use a customer-side measure and a fair comparison:
   • A real-user measurement (timing taken from actual customer sessions, for example a small script that reads the browser's built-in performance timing when the checkout form becomes usable and sends it, with the device type, to analytics) rather than only a test machine.
   • A staged rollout (release to a small share of users first) so the old and new versions can be compared in the same week. The 10% who get the new code are the rollout group; the other 90% keep the old code and act as the control group, the comparison group that lives through the same weeks and events but does not get your change.
   • A customer signal such as tickets, abandonment or retries.
4. Caveats. What else changed in that period.

Worked example (illustrative numbers)

A frontend developer notices checkout feels slow on mid-range phones. They defer loading a large recommendations script until after the payment form appears. Rollout goes to 10% of users first. The metric is the 95th percentile (p95) page-ready time: the time within which 95 out of 100 visits finish, so it shows the slow tail that customers complain about, not the average.

In the 10% phase, p95 page-ready time was 3.9 s for the rollout group against 5.7 s for the control group in the same two weeks (illustrative), which is 1.8 s or about 32% faster. Customer-side signal: support tickets tagged "slow checkout" per 1,000 active users. Suppose that was 18 per 1,000 before and 11 per 1,000 after, comparing four-week windows. That is 7 fewer per 1,000, about a 39% reduction (7 divided by 18). The honest line to add: "a marketing campaign ended in the same window, so I also compared the 10% rollout group against the control group in the same weeks, and the gap held." The control comparison is the p95 gap above: the campaign reached both groups, so it cannot by itself explain a gap between them. This holds only if users were assigned to the rollout group at random (for example by a hash of the user ID), so say that in the story. Even then it supports 'contributed to', not 'proved': the ticket drop (18 to 11 per 1,000) is a before and after comparison that the campaign ending can still distort, so also report tickets per 1,000 for the rollout group against the control group over the same weeks.

Pitfalls

• Internal metric as proof. "Server time dropped" does not show a customer noticed.
• Averages hide the tail. Report the tail or the share of affected customers.
• No comparison group. Before-and-after alone cannot separate your change from the calendar.
• Overclaiming. Say "contributed to" unless you had a clean control.

Direct answer

When you never meet customers, obsession becomes a habit of asking "who is affected, and how will they experience this?" before choosing, and of using the closest available evidence about them: support tickets, error logs, product telemetry (usage data the product records automatically), and the people who do talk to customers. The test is behaviour, not belief. A skeptical colleague should be able to point at specific choices you made differently.

What a skeptical colleague would actually see

• A user-impact line in your design notes and reviews. Who is affected, what do they see when it fails, what do they do next? A real line looks like: "Impact: about 2% of checkouts (card payments over $500) hit this path; the user sees a spinner for 30 seconds, then a generic error, and may retry and be charged twice."
• Error and failure behaviour written for the person hit by it. The message says what happened, whether their data or money is safe, and what to do next.
• Metrics tied to a customer outcome. You alert on "checkouts failing" or "reports arriving late to users", not only on server load.
• Instrumentation chosen to answer customer questions. Instrumentation means the logging and metrics you add to code so you can see what it did. You log enough (with an identifier support can look up) that a ticket can be resolved without asking the customer to reproduce it.
• Regular proxy contact. A proxy is a stand-in source: someone or something that sees customers so you do not have to. You read a sample of recent tickets, sit in on a support or sales call now and then, and ask the people who do speak to customers what surprised them.

Worked example (a backend engineer)

A payment call times out. The default behaviour returns "Error 500". The obsessed version does three things differently:

1. The message tells the user whether they were charged and that retrying is safe or not.
2. The log line carries the order identifier, so support can answer "was I charged?" in one lookup.
3. The alert fires on the failed-checkout rate rather than on CPU, so the team learns about customer pain first.

Nothing here needed a customer conversation. It needed the habit of imagining the person on the other end and checking tickets to confirm.

The same habit in other seats

• Network engineer, during an incident: decide the order of fixes by which customers are cut off (for example the region carrying the most checkouts), and write the status update in terms of what customers cannot do.
• Mobile developer: treat battery drain and crashes as customer-facing features, and check crash rate on older phones, not just your own.
• Machine learning engineer: read a sample of real model outputs and complaints, not only the offline accuracy score.
• Data engineer: choose schemas and keys so support can trace one customer's records, and keep the fields analysts need to answer "who was affected".
• Data analyst: build the dashboard for the business intelligence (BI) reader who will use it, with the customer-outcome metric first and plain labels.

Trade-offs and pitfalls

• Proxies mislead. Tickets over-represent people who bother to write in, and telemetry shows what users did, not why. Arrange some direct exposure even if it is only one call a quarter.
• Do not claim to speak for customers from inside your head; cite the ticket, the log or the person who talked to them.
• If your work never changes because of customer evidence, you are doing the same job as before with a nicer label.