Problem Definition and Framing Questions

Direct answer

A problem is ready to move into prototyping once you have a validated assumption or two (not just an untested belief), at least one prioritized, testable hypothesis about the cause or the opportunity, and rough alignment among the key stakeholders on what success looks like; missing any of these, more discovery is worth the time before design work starts.

Structured elaboration

Validated assumptions: at least the riskiest assumption underlying the effort has been checked against some real evidence, even lightweight evidence (a quick data pull, a handful of interviews), rather than resting entirely on belief. Moving to prototyping on an unvalidated assumption risks building against a premise that turns out to be false.

Prioritized hypotheses: a ranked, not just listed, set of candidate causes or directions, with the top one identified as the leading candidate to prototype against; a flat list with no prioritization signals discovery hasn't actually converged on a direction yet.

Stakeholder alignment: the people who'll evaluate the prototype (engineering, for feasibility; whoever approves the eventual launch) roughly agree on what the problem is and what success would look like, even if they don't yet agree on the solution; misalignment here, discovered only after a prototype exists, is expensive to unwind.

Worked example, login-flow redesign: (1) Validated assumption: session-replay review of 30 failed login attempts confirmed users are abandoning specifically at the password-reset step, not elsewhere in the flow, checked against actual data rather than assumed from a single complaint. (2) Prioritized hypothesis: the leading candidate is that the reset-confirmation email takes over 5 minutes to arrive for a meaningful share of users, checked against email-delivery logs, ranked above a secondary hypothesis (confusing reset-form copy) because the data more strongly supports it. (3) Stakeholder alignment: both the engineering lead (who'll assess email-delivery-speed feasibility), and the product manager, have confirmed "reduce password-reset abandonment" as the target outcome, even though the specific fix isn't decided yet.

Trade-offs and pitfalls

Waiting for full certainty on all three criteria before ever prototyping can itself become a stalling pattern, particularly on a low-stakes, easily-reversible change where a quick prototype would actually resolve remaining uncertainty faster than more upfront discovery; the criteria are meant to catch problems that are clearly underspecified, not to demand perfect confidence before any building starts. The opposite pitfall, moving to prototyping with none of the three in place because of schedule pressure, tends to produce a prototype that tests the wrong thing, wasting the time it was meant to save.

Direct answer

Scope, timeline, and resources trade against each other: holding any two roughly fixed, the third has to flex, and the most common mistake is trying to fix all three at once and quietly letting quality absorb the difference instead. When a deadline and headcount are both fixed, the honest lever left is scope, and naming that explicitly, rather than pretending everything can still be delivered, is what protects both the deadline and the quality of what does ship.

Structured elaboration

The triangle is a forcing function for an explicit trade-off conversation rather than a silent one. If timeline is fixed (a launch date tied to a marketing commitment) and resources are fixed (the team isn't growing before then), scope is the only remaining lever, and narrowing it, cutting the feature list, is preferable to the alternative of keeping the full scope and letting the team either work unsustainable hours or ship at lower quality without saying so. Extending the timeline or adding resources are the other two levers, but each has its own cost: extending timeline delays value delivery and may miss the reason the deadline existed in the first place; adding resources (particularly late) often slows a project down before it speeds it up, since onboarding new people to a half-built effort has real overhead.

Worked example

A team commits to shipping a redesigned onboarding flow before a fixed marketing launch date, with a headcount that isn't changing. Partway through, new requirements emerge that would add two weeks of work. Rather than silently absorbing the extra work into unpaid overtime or shipping it half-tested, the explicit trade-off conversation: "given the launch date and team size are both fixed, here are the two features we'd cut to stay on track, or here's the one-week delay if we keep everything," puts the actual choice in front of the stakeholder who can weigh in on which lever they'd rather pull, rather than the team making that call invisibly.

Trade-offs and pitfalls

Communicating this trade-off requires naming the cut explicitly rather than hedging ("we'll try to fit it all in"), because a hedge just defers the same conversation to a worse moment, closer to the deadline, with less room to adjust. The pitfall on the other side is invoking the triangle reflexively for every scope addition, even small ones that don't actually threaten the deadline, which trains stakeholders to see every request as a negotiation and erodes the trust the framing is meant to build.

Direct answer

Problem statement: "Users abandon the checkout flow at a rate we believe is avoidable, driven by unclear pricing or an overly long form; we want to identify the dominant cause and reduce abandonment within one quarter." Then three research questions, ranked by how much uncertainty each removes, and two experiments that test the two most likely causes cheaply before committing to a redesign.

Structured elaboration

Turning "make checkout less confusing" into something actionable means resisting the urge to start sketching a new flow and instead doing three things in order:

1. State the problem without naming the fix. "Confusing" is a symptom description from whoever gave you the brief, not a diagnosis. The statement should capture the business impact (checkout abandonment, cart-to-purchase drop-off) without assuming the cause is visual clutter, form length, or anything else specific.
2. Rank the highest-uncertainty questions. Three that reduce the most uncertainty for the least effort: (a) where in the funnel do users actually drop, step by step, not just "checkout" as a whole; (b) do session recordings or support tickets show a specific point of friction (an unexpected shipping cost, a validation error, a confusing field); (c) has anything changed recently (a redesign, a new payment provider, a pricing change) that correlates with the drop, which would point to a regression rather than a long-standing usability gap.
3. Design experiments that isolate one variable each. Confirming the top hypothesis before building the full redesign avoids spending a sprint on the wrong fix.

Worked example

If step-by-step funnel data (question 1) shows the drop concentrates at the shipping-cost step, and session recordings (question 2) show users repeatedly navigating back to the cart after seeing that price, the two experiments become: (1) show an estimated shipping cost earlier in the flow, on the cart page, and measure the change in step-to-step conversion at the shipping step specifically; (2) offer a lower-friction guest checkout for users who abandon at account creation, and measure whether abandonment at that specific step drops. Both experiments have one clearly measurable outcome each (conversion rate at a named step) rather than "conversion is better," which would leave you unable to tell which change caused any improvement.

The same three-part output, statement, research questions, experiments, holds regardless of who the ambiguous brief comes from: an engineering-reported inconsistency (three teams shipping visibly different versions of the same navigation component), a chief executive officer (CEO)-level ambiguous goal ("increase monetization from casual users," with no design specifics attached), and a product manager's (PM's) "improve discoverability" ask with no defined success metric all reduce to the identical framing move, only the domain changes.

Trade-offs and pitfalls

The trap in this kind of prompt is treating "less confusing" as license to redesign everything at once: a full redesign conflates multiple hypotheses, so even if overall conversion improves you cannot attribute the gain to any one change, and if it does not improve you have no idea which piece to revert. The second trap is skipping the funnel-breakdown question entirely and going straight to user interviews, which surface real but not necessarily representative friction points; pairing quantitative funnel data with qualitative signal is what keeps the research questions honest about what's actually costing conversion versus what's merely annoying.

Direct answer

Headline states the problem and its business impact in one line; the three bullets cover the current state, the desired state with its timeframe, and the specific decision or resource being asked for. The whole slide should be readable, and the ask actionable, well within the 90 seconds an executive typically gives a single slide.

Structured elaboration

Headline: a single sentence naming the problem and why it matters in business terms, not a vague title. "Checkout abandonment is costing an estimated [$X] per month, concentrated in the shipping-cost reveal step" is a headline an executive can act on; "Checkout Improvements" is not.

Bullet 1, current state: the specific, quantified baseline, in one line, no supporting detail the executive doesn't need at this altitude ("Abandonment at the shipping-cost step is 31%, up from 22% two months ago").

Bullet 2, desired state and timeframe: what success looks like and by when ("Target: reduce to 24% within one quarter, based on early experiment results").

Bullet 3, the ask: the specific decision or resource needed from the executive, stated as an actual ask, not a status update ("Requesting approval for a two-week experiment testing earlier cost disclosure, no additional headcount required"). This is the part most commonly missing from executive slides that read as informative but leave the executive unsure what they're actually meant to do with the information.

Worked example

Headline: "Checkout abandonment at the shipping-cost step is costing an estimated [$X] per month, calculated as affected sessions times the abandonment-rate gap times average order value, and has worsened over the past two months." Bullet 1: "Abandonment at this step rose from 22% to 31% since early [month], concentrated among first-time buyers." Bullet 2: "Target: back to 22% within one quarter, informed by an early low-cost experiment already showing promise." Bullet 3: "Requesting sign-off to scale the experiment to 100% of traffic; no additional budget or headcount required, two-week rollout." An executive reading this in under 90 seconds knows what's wrong, how big it is (with the dollar figure traceable to a stated formula rather than asserted on its own), what "fixed" looks like, and exactly what they're being asked to approve.

Trade-offs and pitfalls

The most common failure is treating the slide as a status update rather than a decision request, ending with a description of the problem and the current investigation rather than a specific ask, which leaves the executive informed but with nothing concrete to do, and often means a second meeting is needed just to get to the actual decision. The opposite failure is overloading the slide with investigative detail (methodology, alternative hypotheses considered and ruled out) that belongs in a supporting document, not the headline slide; if an executive wants that detail, they'll ask, and a slide should be built to answer that follow-up rather than to pre-empt it by including everything up front.

Direct answer

Opportunity framing starts from a broad market potential ("there's a large addressable market for X") and works toward defining a specific problem within it; problem framing starts from a specific, confirmed user pain and works toward a solution. Confronted with an ambiguous request, defaulting to opportunity framing when the situation actually calls for problem framing (or the reverse) produces a mismatched discovery process: too broad an investigation for a narrow, urgent pain, or too narrow an investigation for a genuinely open-ended strategic question.

Structured elaboration

Opportunity framing fits situations where the mandate is genuinely open, such as "should we enter the small-business segment," where the discovery work is market sizing, competitive landscape, and identifying which specific problems within that broad space are worth solving first; the output is a prioritized list of candidate problems, not yet a committed direction. Problem framing fits situations where a specific pain is already reported or measured, such as "enterprise customers are churning at a rate above the target," where the discovery work is confirming and diagnosing that specific pain, not searching a broad space for candidates.

The downstream differences: opportunity framing's discovery tends toward broader, more exploratory research (market interviews, competitive analysis, top-down sizing) and its metrics tend toward market-level indicators (addressable market size, win rate against a category of competitors); problem framing's discovery tends toward focused, diagnostic research (funnel analysis on the specific reported pain, targeted interviews with affected users) and its metrics tend toward the specific pain's own indicators (the churn rate, the conversion rate, the metric that was reported as off).

Worked example

Given "we should look into offering a mobile app," that's a request phrased as opportunity framing (a broad "should we enter this space" question) and calls for market-level discovery: how many current users have asked for mobile access, what competitors offer and how it performs for them, before any specific problem is even named. Given "our mobile users report the app is too slow to be usable during their commute," that's already a specific problem, and applying opportunity-framing discovery to it, running a broad market study, wastes time the diagnostic work (profiling actual load times on cellular connections) would answer faster.

Trade-offs and pitfalls

The risk of misjudging which framing a request calls for runs in both directions: applying problem framing to a genuinely open-ended opportunity narrows the investigation prematurely around one assumed pain point before the broader space has been explored, while applying opportunity framing to an already-specific, already-measured pain wastes time on market-level research the situation doesn't need. The judgment call is whether a specific, measured pain already exists in the request, or whether the request is genuinely about deciding whether to enter a space at all.