Problem Definition and Framing Questions

Direct answer

Treat what stakeholders report as a symptom, and require yourself to trace at least one causal step further before accepting it as the thing to fix. A three-step framework: (1) restate the reported symptom precisely and confirm it with data rather than accepting the description at face value, (2) ask "what would have to be true for this symptom to occur" and list two or three candidate mechanisms, (3) find the cheapest data check or observation that would distinguish between those mechanisms, and run it before proposing a fix.

Structured elaboration

Symptoms are what stakeholders and dashboards report first: a metric moved, a support ticket volume spiked, a click-through rate dropped. Root causes are the mechanism actually producing that symptom, and they are frequently one or two steps removed from what got reported. The discipline is refusing to stop at the first plausible-sounding explanation, because the first explanation is usually the one that requires the least investigation to state, not the one best supported by evidence.

Step 1, confirm the symptom: reported symptoms are sometimes wrong or overstated (a stakeholder says "nobody uses this feature" when usage is actually flat, not zero); confirming with data prevents investigating a problem that doesn't exist as described.

Step 2, generate candidate mechanisms: for a checkout-abandonment symptom, candidates might include an unexpected cost revealed late in the flow, a technical error on a specific browser, or a change in the mix of traffic sources bringing in less-qualified visitors. List more than one candidate deliberately, because settling on the first one you think of is exactly the failure mode this framework exists to prevent.

Step 3, find the cheapest distinguishing check: for the checkout example, segmenting abandonment by browser and by traffic source, and checking whether an error-tracking tool logged anything at the abandonment step, would distinguish between the three candidates in step 2 without requiring a new experiment.

Worked example

Reported symptom: "checkout abandonment is up." Step 1 confirms it with data: abandonment rate rose from 22% to 31% over two weeks. Step 2 lists candidates: a recent shipping-cost change, a bug in a specific browser, or a traffic-source shift. Step 3 finds the segmenting check shows abandonment rose specifically for one browser after a deploy two weeks prior, which points to a technical regression rather than a pricing or traffic issue, an outcome none of the three candidate labels alone would have confirmed without the segmentation.

The same three-step framework applies just as directly to a payment-failure support-ticket spike (the reported symptom) or a rising churn number (a different reported symptom): in both cases, step 1 confirms the number against data, step 2 generates more than one candidate mechanism rather than the first plausible one, and step 3 finds the cheapest check that would distinguish between them.

Trade-offs and pitfalls

The main pitfall is stopping at the first plausible mechanism because it's the one a stakeholder already believes, which produces a fix that treats the wrong cause and leaves the metric unrecovered. The framework also has a cost: three steps of investigation take longer than accepting the reported symptom at face value, so it should be scaled to the stakes; a genuinely urgent, high-cost-of-delay incident may warrant compressing steps 2 and 3 into a fast, parallel check rather than a sequential one.

Direct answer

A reusable problem brief forces the same five questions onto every proposed effort before it gets engineering time: what's the evidence, who's affected, how big is the impact, what do we believe is causing it, and how will we know we've fixed it. Filled in for "slow report generation for large datasets": evidence is a p95 report-generation time of 45 seconds against a 10-second target, affected users are accounts generating reports over 500,000 rows (roughly 8% of active accounts), and so on through the remaining fields.

Structured elaboration

The template's nine fields, and why each one is there: Evidence (the data that proves this is real, not anecdote); affected users (a specific segment, not "everyone"); impact estimate (how big a deal this is, to compete fairly for prioritization against other work); hypotheses (candidate causes, plural, not a single assumed one); proposed experiments (the cheapest way to test the top hypothesis before committing to a fix); success criteria (the metric and target that will confirm it's solved); owner (one accountable person, not a team); timeline (a fix-by date); risks (what could go wrong or what this might break).

Worked example, filled in:

• Evidence: p95 report-generation time is 45 seconds, against a 10-second internal target; this affects the "export large dataset" feature specifically.
• Affected users: accounts generating reports over 500,000 rows, roughly 8% of active accounts but disproportionately represented among the highest-tier customers.
• Impact estimate: three support escalations in the past month cite this directly, and it's a named blocker in two enterprise renewal conversations.
• Hypotheses: (1) the report-generation query itself is unindexed for this data volume, (2) generation is single-threaded and doesn't parallelize across data partitions, (3) the bottleneck is actually in rendering the output file, not the query.
• Proposed experiment: profile a sample of slow report requests to see where time is actually spent, query execution versus rendering, before committing engineering time to either fix.
• Success criteria: p95 report-generation time under 10 seconds for the 500,000+ row segment, measured over a rolling 7-day window post-fix.
• Owner: the data-platform lead for this feature area.
• Timeline: profiling complete in one week, fix scoped and estimated within two weeks of that.
• Risks: a fix to one part of the pipeline could shift the bottleneck elsewhere without profiling first, which is why profiling precedes any commitment to a specific fix.

A second filled instance of the same template, this time for an analytics team: evidence is "ad-hoc metric requests take a median of 4 days to fulfill," the hypotheses include an unindexed query pattern and a lack of self-serve dashboards, and the template's owner, timeline, and success-criteria fields work identically, only the domain (analytics turnaround time rather than report-generation latency) changes.

Trade-offs and pitfalls

A template like this adds friction to starting any effort, which is the point for anything nontrivial, but applying it uniformly to genuinely small, low-risk changes turns a lightweight fix into unnecessary process overhead; the template should scale down (a shorter version, or an explicit skip) for changes below some size or risk threshold, agreed in advance, rather than being enforced rigidly on everything. A second pitfall is filling in the hypotheses field with only one candidate cause, which defeats its purpose: the field exists specifically to force considering more than the first plausible explanation.

Direct answer

Problem discovery is the work of understanding and confirming what's actually wrong and for whom, before anyone commits to how to fix it; solution delivery is building and shipping that fix. Jumping from a reported symptom straight into solution delivery skips the step where you'd have caught that the symptom had a different cause than assumed, and the cost of that mistake is a shipped feature that doesn't move the metric.

Structured elaboration

The two phases answer different questions and use different tools. Discovery asks: is this real, who does it affect, and what's actually causing it, using tools like funnel analysis, session recordings, interviews, and support-ticket review. Delivery asks: given a confirmed cause, what's the best way to address it, using tools like prototyping, engineering estimation, and design iteration. A team that conflates the two ends up debating solution details ("should the button be blue or green") for a problem whose existence hasn't even been confirmed with data.

Worked example

A stakeholder reports "our search feature isn't good enough, we should invest in better relevance ranking." Jumping straight to solution delivery means starting a multi-quarter ranking-model project on the stakeholder's assumption alone. Reframing to discovery first: pull search-abandonment and zero-result-rate data (is search actually underperforming, and by how much, compared to what baseline), segment by query type (is the issue concentrated in a specific category, like long-tail queries, rather than search broadly), and review a sample of failed searches to see whether the pattern is a relevance-ranking issue at all, or something narrower, like a specific product category having thin catalog coverage. If the data shows the "bad search" complaints concentrate on one under-stocked category, the actual fix is a catalog gap, not a ranking-model investment, an outcome the discovery step surfaces and the jump-to-solution path would have missed entirely, at the cost of a much larger, misdirected engineering investment.

Trade-offs and pitfalls

Discovery isn't free: it takes time, and on a genuinely well-understood, previously-validated problem, re-running discovery from scratch every time is wasteful. The judgment call is proportional to how confident you already are that you understand the cause, and how expensive and reversible the proposed solution is: a multi-quarter model investment warrants discovery; a one-day copy change that's trivial to revert may not. The opposite failure, treating every request as needing full discovery regardless of stakes, reads as obstruction rather than rigor and burns trust with stakeholders who have a genuinely well-scoped, low-risk request.

Direct answer

Ship the web version on the six-week timeline as planned, and for mobile, ship the smallest set of changes that avoids leaving the two platforms visibly and confusingly inconsistent, deferring the full redesign to a follow-up phase. The problem statement makes the trade-off explicit rather than silent: "we are prioritizing a complete redesign on web within the six-week window, and a scoped-down update on mobile to avoid inconsistency, with the full mobile redesign following in phase two, because engineering capacity does not support both platforms simultaneously in this window."

Structured elaboration

Scope boundaries: define explicitly what mobile gets in this phase (the same underlying search logic and results ranking as web, but not the new visual layout) and what it doesn't (the redesigned card layout, the new filtering interface), so engineering, design, and stakeholders share the same understanding of what's actually shipping on each platform.

Phased delivery approach: web ships the full redesign on schedule; mobile ships a minimal-viable-change version, updated results data and ranking behind the existing mobile layout, in the same window, with the mobile visual redesign following as an explicitly scheduled phase two rather than an open-ended "later."

Risks: users switching between web and mobile may notice the visual inconsistency during the gap between phases, which is a real but bounded cost, worth naming explicitly rather than discovering through user complaints; and phase two needs a committed timeline and owner, or "we'll get to it" phases have a well-documented tendency to slip indefinitely once the pressure of the original deadline is gone.

Worked example

The problem statement communicated to stakeholders: "Web search results redesign ships on the original six-week date. Mobile ships the same underlying search improvements (data and ranking) within the same window, on the existing visual layout, with the mobile visual redesign following in phase two, targeted for [specific date] and owned by [specific person]. This avoids either delaying the entire launch to accommodate mobile engineering capacity, or shipping a visually inconsistent experience with no plan to resolve it." Naming a phase-two date and owner up front is what prevents "phase two" from becoming a phase that never happens.

The same scope-boundary discipline applies to a "quick" UI update that can't touch the backend data model (a checklist of what must be clarified up front: which fields are display-only versus backend-dependent, what trade-offs a display-only fix accepts) and to a legacy design-system migration spanning 200-plus component variants (a phased migration with a rollback strategy and acceptance criteria defined per phase, not just at the end).

Trade-offs and pitfalls

The main risk in this kind of phased approach is that phase two loses priority once the phase-one pressure is gone and a new deadline arrives for something else; committing to a specific date and owner for phase two at the same time you commit to phase one is what protects against that, though it isn't a guarantee. The other pitfall is defining the phase-one mobile scope too narrowly to be worth shipping at all, in which case the better call might be a short, explicit delay on mobile alone rather than a phase-one release so minimal it doesn't move any of the metrics the redesign was meant to improve.

Direct answer

For the design team: "Search results feel irrelevant to users, and we don't yet know whether the cause is our outdated ranking signals, a design or discoverability issue, or something else; we want to identify the dominant cause and improve perceived relevance within [N] weeks." For executives: "Search relevance issues may be costing us engagement; we're investigating root cause now and will have a scoped fix plan within [N] weeks." Same underlying problem, different altitude and different information each audience actually needs to act on.

Structured elaboration

The design-team version needs enough specificity to guide investigation: it names that the cause is unconfirmed (avoiding the trap of asserting "outdated ranking signals" as settled, since that was engineering's theory, not a validated finding) and gives the team something to test against.

The executive version needs business framing and a commitment, not investigative detail: executives generally don't need to know whether the candidate cause is ranking signals or a discoverability issue, they need to know the business impact is being taken seriously and when they'll get a real answer. Including engineering's specific technical theory in the executive version invites a premature commitment to a fix nobody has confirmed yet, and it gives a busy executive a detail they can't act on.

Worked example

If the original brief's inputs turn out to conflict, customers say results are irrelevant, engineering says ranking is outdated, product wants more engagement, and there's no formal measurement yet, both rewritten versions deliberately do NOT pick a side on which input is correct. Instead they state the shared fact (search relevance is a live concern with unconfirmed cause) and commit to finding out, which is honest given that no measurement exists yet to confirm any of the three inputs' theories.

Trade-offs and pitfalls

The risk in writing two versions of the same statement is that they drift into actually describing two different problems if not written carefully from the same underlying facts; keeping both versions traceable to the same baseline problem (search relevance concerns, cause unconfirmed) is what prevents the executive version from over-promising or the design-team version from under-specifying. The other pitfall is defaulting to the technical version for both audiences, which is a common failure when the person writing the statement is closer to engineering than to executive communication; the tell is a statement executives read but can't act on, because it's full of implementation detail they have no way to evaluate.