BQ-013 · SELF-GUIDED PRACTICE
Tell me about a customer problem that changed your priorities.
Illustrative fictional example · Editorial draft, version 1. Use the structure and reasoning to prepare your own experience. Do not present this sample as your personal history.
Attempt before reading the example
Spend about two minutes explaining your own experience aloud, then use the worksheet. The sample stays closed until you choose to reveal it.
Build your own answer
This worksheet stays in this page’s memory. It is not saved to your account or this device. Copy or download it before leaving or refreshing. Remove confidential details and use only experiences you can defend.
Self-review against observable evidence
This is a coaching checklist, not a company hiring score. Choose one rating per dimension.
Review each dimension to choose one concrete improvement for your next attempt.
Next exercise
Rehearse your own example, then ask a listener to identify clearer completion and retry understanding in the tested billing task and the decision that led to it.
Prepare a follow-up on finishing the planned charts before fixing the download flow. Replace every fictional detail with your own facts and identify one claim that needs more evidence.
What the interviewer may evaluate
These are general coaching criteria; interviewers and roles differ.
- Explain the customer evidence, its effect, and why it justified changing priorities rather than merely adding work.
- Can you explain the evidence behind clearer completion and retry understanding in the tested billing task?
- Can you describe prioritizing the customer task using concrete support evidence without overstating the outcome?
Before you start
- Explain the customer evidence, its effect, and why it justified changing priorities rather than merely adding work.
- Separate personal actions from team outcomes.
Choose an experience that answers the prompt
Suitable examples
- Customer evidence that exposed a different underlying need.
- A priority change with an acknowledged delivery trade-off.
Examples to avoid
- Treating the loudest customer as automatically representative.
- Claiming customer obsession while ignoring the work displaced.
Gather your evidence
- Explain the customer evidence, its effect, and why it justified changing priorities rather than merely adding work.
- Your decision, the alternative of finishing the planned charts before fixing the download flow, and the reason for the choice.
- The observations that support clearer completion and retry understanding in the tested billing task and their limitations.
Build the answer
- Situation and responsibility. Explain the customer evidence, its effect, and why it justified changing priorities rather than merely adding work.
- Actions and reasoning. Explain what you personally changed, who helped, and why you considered finishing the planned charts before fixing the download flow.
- Outcome and evidence. Report clearer completion and retry understanding in the tested billing task. Distinguish observation from an assumption or future goal.
- Reflection and follow-through. Explain prioritizing the customer task using concrete support evidence. Name one limitation or remaining follow-up.
Full sample answer and paragraph explanations
Read aloud to check pacing. Expand the annotations to see why each paragraph matters and which detail belongs in a follow-up.
Reveal the full illustrative answer
Situation and responsibility
I was building a richer billing dashboard when support escalated repeated reports that customers could not tell whether an invoice download had completed. Some clicked several times, received multiple files with similar names, and then asked support which one was current. The planned work emphasized more charts. I owned the dashboard implementation, so I needed to decide whether the reported problem should change the delivery order.
Why this paragraph works
Evidence: Task failure and the original plan.
Why it matters: Shows a genuine prioritization choice.
Prepare for a follow-up: Prepare how reports were selected and anonymized.
Actions and reasoning
I reviewed anonymized support examples and reproduced the flow with a support specialist. We found that the page gave no clear progress state and did not explain which billing period the file represented. I took that evidence to the product owner and proposed delivering a progress state, a stable period label, and a clear failure-and-retry message before the new charts. We discussed the opportunity cost explicitly: the chart work would move later rather than being added to the same deadline.
Why this paragraph works
Evidence: Reproduction, proposed scope, and work displaced.
Why it matters: Turns customer concern into an explicit decision.
Prepare for a follow-up: Explain who approved the change and what happened to the charts.
Outcome and evidence
I implemented the smaller flow with the designer and checked it using a delayed response, a failed download, and an empty billing period. Support then walked through the new behavior without my explanation and could identify the period and next action in each state. We released it before returning to the chart work. That exercise supported a usability improvement in the tested flow; it did not establish a company-wide reduction in billing tickets.
Why this paragraph works
Evidence: Edge-case verification and uncoached task review.
Why it matters: Provides a concrete observation without invented ticket metrics.
Prepare for a follow-up: Describe the support walkthrough and its limitations.
Reflection and follow-through
I followed up with support on whether the next billing cycle exposed unresolved cases. More broadly, I started asking what task a customer was struggling to finish before proposing additional information on the dashboard. The lesson was that a request for more visibility can mean clearer state and next steps, not necessarily more charts. The priority change worked because we connected evidence, scope, and an explicit delivery trade-off.
Why this paragraph works
Evidence: Billing-cycle follow-up and a changed discovery question.
Why it matters: Shows learning about the actual customer need.
Prepare for a follow-up: State what the later follow-up did or did not reveal.
Reveal the concise version — roughly 60–90 seconds
While building billing charts, I reviewed support reports showing that customers could not tell whether an invoice download had completed or which period the file covered. I reproduced the flow with support and found missing progress and failure states. I proposed prioritizing a clearer download flow with a period label before the charts, and made the schedule trade-off explicit with the product owner. I implemented it with design and tested slow, failed, and empty responses. Support could then identify the next action without coaching. That was evidence for the tested task, not a claim that all billing tickets decreased. I followed up after the next billing cycle and changed my discovery questions to focus on the customer’s task rather than adding dashboard content.
Improve a weak answer
Weak excerpt
A customer complained, so I stopped everything and built what they wanted.
Improved excerpt
I reviewed anonymized support examples and reproduced the flow with a support specialist. We found that the page gave no clear progress state and did not explain which billing period the file represented. I took that evidence to the product owner and proposed delivering a progress state, a stable period label, and a clear failure-and-retry message before the new charts. We discussed the opportunity cost explicitly: the chart work would move later rather than being added to the same deadline.
Connects several concrete support examples to an observed task failure and an explicit priority trade-off. The improved excerpt still needs the observed result and its limits to become a complete answer.
Prepare for probing questions
Attempt each response before opening the guidance. Replace fictional details with your own evidence.
How did you know the reports represented a real problem?
I compared several support examples and reproduced the task rather than reacting to a single vague complaint. I would also state who was represented and who was not. Support evidence can reveal a problem without establishing its exact population frequency.
Who decided to reprioritize?
I provided the evidence and proposed a bounded change. The product owner decided the ordering after discussing the impact on chart delivery. Explain your influence without implying you unilaterally controlled the roadmap.
What if the charts were contractually committed?
I would present the customer impact and the cost of each option, including a smaller mitigation or a staged chart release. A contractual constraint matters, but should be discussed openly rather than used to hide a known usability problem.
Did you measure fewer support contacts?
Not in the evidence described here. We verified task understanding with support and planned follow-up after a billing cycle. A real decrease would need comparable periods, a definition of relevant tickets, and awareness of other changes.
Why was this engineering work rather than just design work?
The flow involved request state, failures, retry behavior, and the relationship between a file and its billing period. I worked with design on presentation and owned the implementation and edge-case checks. The outcome depended on both contributions.
Adjust the evidence to your level
Early-career
Use a bounded project, internship, or volunteer example that demonstrates customer judgment. Explain guidance you received rather than claiming senior authority.
Mid-level
Show independent responsibility for a defined outcome, including clearer completion and retry understanding in the tested billing task. Name dependencies and when you sought help.
Senior
Explain trade-offs with affected colleagues, the verification plan, and prioritizing the customer task using concrete support evidence. Broader scope needs evidence rather than a larger job title.
Staff
Show a mechanism that changed decisions or capability across teams, including who adopted it and what remained outside your authority. Do not describe a local change as organization-wide influence.
Common mistakes
- Listing tasks without explaining why you considered finishing the planned charts before fixing the download flow.
- Claiming clearer completion and retry understanding in the tested billing task without describing how you observed it.
- Claiming sole credit for decisions or work owned by collaborators.
- Treating a proposed follow-up as already completed.