Problem Definition and Framing Questions

Direct answer

Changing a team's solution-first habit takes both a structural change (a lightweight artifact that makes framing visible and hard to skip) and a behavioral one (modeling and reinforcing the practice in the moments it matters most, like kickoff meetings), and either alone tends to fail: process without buy-in gets worked around, and buy-in without a structural forcing function fades under deadline pressure.

Structured elaboration

Tactical, structural change: introduce a lightweight "problem brief" that must be filled in and shared before any effort gets scheduled, with a small number of required fields (the problem, the evidence, who's affected) rather than a heavyweight document nobody will complete. Make it a genuine gate, work doesn't get calendared without it, not just a suggested best practice, because a non-enforced template gets skipped first under any deadline pressure.

Behavioral, meeting-level change: in kickoff meetings, ask "what problem does this solve, and how do we know" as the very first question, every time, consistently, until it becomes the team's own reflex rather than something only a lead asks. Use specific, non-judgmental scripts when a solution-first idea arrives ("that's a real idea, what's the underlying problem it addresses, so we can compare it against other ways of solving that same problem"), which redirects toward framing without dismissing the person's contribution.

Measuring adoption: track the share of new efforts that have a completed problem brief before work is scheduled (a simple, binary, easy-to-track process metric), and separately, spot-check a sample of briefs quarterly for actual quality, meaning whether the evidence field cites real data rather than being filled in as a formality after the fact, since a team can technically comply with a process metric while defeating its purpose.

Worked example

Three months after introducing the brief-before-scheduling gate and the kickoff-question habit, if 90% of new efforts have a completed brief (up from an informal baseline of roughly 20% before the change) but a quarterly spot-check finds a third of those briefs were filled in retroactively, after the work was already underway, that's a signal the structural gate succeeded at enforcement but the behavioral shift toward framing-first thinking hasn't fully taken, and it points at reinforcing the kickoff-meeting habit more directly rather than declaring the initiative complete based on the process metric alone.

Two complementary tactics belong alongside the template-and-meeting-structure approach above: a three-step coaching plan for individual contributors (a concrete exercise, a feedback ritual, and a tracked metric, repeated over three months) that builds the habit person by person, and a process for converting an existing backlog of solution-phrased requests into validated problem statements retroactively, with stakeholder workflows and guardrails so the backlog doesn't refill with the same pattern.

Trade-offs and pitfalls

A rigid, heavyweight brief requirement risks becoming exactly the kind of process theater it's meant to prevent, filled in after the fact to satisfy a gate rather than genuinely shaping the work; keeping the brief lightweight and the gate meaningfully enforced (not scheduling work without it, rather than just requesting it) is what keeps it from becoming theater. The behavioral change is the harder, slower half of this and is easy to under-invest in relative to the structural change, since a template is a one-time build while a habit shift requires sustained, repeated reinforcement over months.

Direct answer

A high-quality problem statement names the specific target user, states the current measured condition, states the desired condition, gives a timeframe, and specifies the metric that will confirm the gap is closed. Leaving any one of these out is what turns "we should fix onboarding" into an unactionable slogan instead of a scoped, testable problem.

Structured elaboration

Walking through why each part earns its place:

• Target user: without a named segment, "users are dropping off" could mean everyone or one small cohort, and those two situations call for completely different investigations.
• Current vs desired state: this is the gap the rest of the process exists to close. Stated as two numbers (or two qualitative states with a clear boundary between them), it gives the team a shared definition of "done" before anyone proposes how to get there.
• Timeframe: both the window the current state was observed over, and the window given to close the gap. A statement with no fix-by date competes poorly for prioritization against work that has one.
• Metric: precise enough that two people computing it independently land on the same number. A metric like "engagement" without a computation rule invites disagreement later about whether the fix worked.

A statement that includes all four but is still too broad ("increase engagement, ever, by some amount") fails a different test: it can't be disproven, so nobody can ever say with confidence that it's been solved.

Worked example

For the scenario given: "Among users who received the design update, monthly active users (MAU, the count of distinct users active at least once in a 30-day window) dropped 12% in the 30 days after the update shipped. We want MAU for this cohort back to its pre-update baseline within 6 weeks, measured as the 30-day rolling MAU count for users on the updated design." That single sentence is specific enough that a different analyst, handed only the sentence, could pull the same number from the event logs.

The same components apply to a one-paragraph ML problem statement written for a product requirements document (PRD): target user, current versus desired state, and constraints carry over unchanged, with one addition, an ML problem statement should also name the evaluation metric and baseline the model will be judged against, since "success" for a model is otherwise undefined.

Trade-offs and pitfalls

The most common failure mode is a statement that smuggles in a cause or a solution ("MAU dropped because the new layout hides the main action, so we should revert it"), which shuts down investigation before it starts by presenting an unverified theory as settled fact. The second is treating this as a one-time exercise: the components matter because they are testable, not because they're a checklist to fill in once and never revisit if new evidence emerges during discovery.

Direct answer

Ordered by risk reduction per unit of effort: (1) whatever data you already have access to, since it costs nothing new to check; (2) the single most consequential unknown, the one that would most change your recommendation if it came back differently; (3) whether anyone else has already solved or investigated something similar; (4) a quick, low-cost check on your leading hypothesis; (5) a broader validation pass only if the first four still leave real uncertainty.

Structured elaboration

1. Existing data first: before requesting anything new, check what's already available, dashboards, logs, past analyses, since this is the cheapest possible information and often resolves more uncertainty than expected before you've spent any new effort.

2. The single most consequential unknown: identify which specific unknown, if resolved, would most change your recommendation; investigating a fact that wouldn't actually change your decision either way is low-value regardless of how easy it is to check, so this step comes before anything else that isn't free.

3. Prior work: check whether the organization has already investigated something adjacent, an old analysis, a past experiment, a team that hit a similar question; this can save the entire remaining investigation if a close-enough answer already exists somewhere.

4. A quick check on the leading hypothesis: once you have a working theory from steps 1 to 3, a cheap, fast test (not a full experiment) that would meaningfully update your confidence, before committing more time.

5. Broader validation, only if still needed: a fuller investigation, additional data collection, a proper experiment, reserved for genuine remaining uncertainty after the first four steps, rather than the default starting point.

The ordering logic is strictly about return on a scarce resource, time: each step is ordered from lowest-cost, highest-value first, so that if you run out of time at any point, you've captured the highest-value information available at that cost level rather than partway through a more expensive step that hadn't yet paid off.

Worked example

Given limited time to recommend whether a reported "users can't find the export button" complaint is worth fixing: step 1, existing analytics already show the export feature's click rate over the past month, no new pull required; step 2, the most consequential unknown is whether this is a genuinely common complaint or one vocal user, so that's the priority to resolve, not (for instance) exactly how many pixels the button should move; step 3, a quick search finds a similar complaint was investigated eight months ago and traced to a specific onboarding cohort, which narrows where to look now; step 4, a fast query segmenting current click rate by that same cohort; step 5, a broader usability study only if the segmented data still leaves the picture unclear.

Trade-offs and pitfalls

This ordering assumes you can correctly judge, at step 2, which unknown is genuinely the most consequential; misjudging that (chasing an easy-to-check but low-impact question first) undermines the whole point of the ordering, so it's worth deliberately pausing on step 2 rather than rushing past it to the checks that feel more concrete. The other pitfall is skipping step 3 (checking for prior work) because searching for it feels like it takes effort, when it's often the fastest way to shortcut the rest of the list entirely.

Direct answer

For a designer, problem definition and framing means establishing, before any screens get sketched, exactly who is affected, what is currently happening, what "better" would look like, and how you'll know when you've gotten there. The goal is to make the team's shared understanding of the problem explicit and checkable, rather than letting each person carry a different unstated assumption into the design review.

Structured elaboration

The discipline produces a small set of concrete artifacts, not just a mental model: a written problem statement (who, current state, desired state, timeframe, metric), a short list of prioritized hypotheses about what's driving the gap, the success metrics that will confirm a fix worked, and acceptance criteria, meaning the specific pass or fail checks a proposed change must clear before it ships. These are lightweight, often a paragraph and a bulleted list, but writing them down (rather than keeping them as shared assumptions) is what lets a team catch disagreement before it costs a sprint of design work.

Postponing solutions until after this framing matters because the first plausible-looking fix is rarely the best one, and it is much cheaper to be wrong about a sentence on a page than about a shipped redesign. A designer who frames first is also better positioned to push back when a stakeholder arrives with a solution already attached ("just add a carousel"): the framing step gives you the vocabulary to ask what problem that carousel is meant to solve, rather than either building it uncritically or rejecting it without a reason the stakeholder will accept.

Worked example

A well-formed problem statement in this discipline: "New users who complete account setup in under 2 minutes retain at 3x the rate of users who take longer than 5 minutes; setup currently takes a median of 6 minutes. We want median setup time under 3 minutes within one quarter, measured as time from account-creation-start to setup-complete event." This names the user, the current and desired states, a timeframe, and a metric, without saying anything yet about what the setup flow should look like.

A concrete instance of this same discipline: "Checkout abandons at 38%, well above the 22% baseline for comparable flows; the evidence is a session-replay review, the impact is estimated by multiplying the affected monthly session volume by the abandonment-rate gap and the average order value (a concrete formula, not a bare figure), and the constraint is a two-sprint budget" names the situation, evidence, impact, and constraints in one breath, the same components this broader framing discipline exists to produce.

Trade-offs and pitfalls

The risk of over-investing in this step is real: an experienced designer can spend so long framing that discovery itself becomes the bottleneck, especially on a low-stakes change where a quick prototype would answer the question faster than more analysis. The right calibration is proportional to reversibility and cost: frame carefully before a redesign that will take a quarter to build and is hard to undo; frame lightly, in a sentence, before a change you could ship and revert in a day.

Direct answer

For the low-adoption collaboration feature, a consumer framing would investigate at the level of individual user behavior (did users discover the feature, did the value register immediately, did it fit an existing habit), while a business-to-business (B2B) enterprise framing would investigate at the level of the account and its decision-makers (does an admin need to enable it, does it require a workflow change across a team, is the champion who'd advocate for it even aware it exists). The same low-adoption number can have entirely different causes and different fixes depending on which context the product actually is.

Structured elaboration

Discovery: consumer discovery leans on individual behavioral data and lightweight, high-volume research (in-app surveys, usage funnels for the individual user); B2B enterprise discovery leans on account-level data and fewer, deeper conversations (a handful of account interviews with actual decision-makers and end users, since the population of relevant people per account is small and their input carries more weight).

Metrics: consumer metrics tend to be individual-level and high-frequency (percent of active users who tried the feature, session-level engagement); B2B metrics tend to be account-level and often require aggregation (percent of accounts with at least one active user of the feature, since a single power user within an account adopting it doesn't mean the account or its buyer perceives value).

Stakeholders: consumer discovery mostly involves the end user directly; B2B discovery has to account for a more layered stakeholder set: the end user who'd actually use the feature, the admin who might need to enable or configure it, and the economic buyer who cares about the feature only insofar as it affects renewal or expansion.

Sales motion: for a B2B product, low adoption of a feature can be a sales and customer-success problem as much as a product one, meaning the feature may exist and work but the account team never told the customer it was available, which is a different fix (enablement, communication) than a product fix.

Timelines: consumer product changes and their adoption effects are usually visible within days to weeks; B2B enterprise adoption often moves on a much slower cycle tied to admin rollout decisions and internal change-management within the customer's own organization, so declaring a B2B feature "failed" after two weeks of low adoption may simply be too early to tell.

Worked example

Given questions for each context: consumer, "did users who saw the feature's entry point actually click it, and if so, did they complete the first use, or drop off partway through" (an individual funnel question); B2B, "for accounts where at least one user tried the feature, did the account's admin ever enable it for the full team, or is it opt-in per user and simply undiscovered by most" (an account-level rollout question). Answering the B2B version might reveal the feature works fine once discovered, but most accounts' admins never turned it on, pointing at an activation and communication fix rather than a product-usability one.

Trade-offs and pitfalls

Applying consumer-style, individual-level discovery to a B2B problem risks missing the account-level and admin-driven causes entirely, chasing individual usability issues when the real blocker is that most accounts never had the feature enabled at all. The opposite mistake, applying B2B's slower, account-level patience to a consumer product, risks under-reacting to a genuinely fast-moving usability problem that consumer users would abandon within days, not months.