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

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.

Direct answer

Before committing to a custom build, separate the client's stated request from the underlying problem it's meant to solve, and check whether a narrower, more general solution already on the roadmap (or a small configuration change) would satisfy the actual need. If it does, build the general version; if the need genuinely requires something no other customer would use, weigh the maintenance and fragmentation cost explicitly against the deal's value before deciding to build, generalize, or decline.

Structured elaboration

Evaluate the true underlying problem: ask the client (or their account team) what specific outcome the requested feature is meant to produce, not just what the feature is. A request for "a custom export format" might really be about integrating with one specific downstream tool the client uses, which could potentially be solved by a more general, already-planned integration rather than a one-off export format built just for them.

Test whether a narrower solution works: check the request against the existing roadmap and against other customers' requests; if two or three other accounts have asked for something adjacent, that's a signal the need generalizes and a broader feature is justified, not a one-off; if it's genuinely unique to this one account, that's a different signal.

Decision criteria: (1) does this underlying need show up in other customers' requests, even if not phrased identically, meaning it's a generalizable need rather than one account's idiosyncrasy; (2) what's the ongoing maintenance cost of a custom integration versus a general feature, since custom code paths tend to accumulate cost over years, not just at build time; (3) how does the deal's value compare to the maintenance cost, estimated honestly rather than optimistically; (4) does declining put the deal, and the relationship, at genuine risk, or is there room to offer an alternative the client would accept.

Mitigation options if the answer isn't a clean build-or-decline: a time-boxed custom solution with an explicit sunset date, revisited once usage data shows whether other customers adopt something similar; or a configuration-level solution within the existing general feature, rather than genuinely custom code, which avoids the long-term fragmentation cost even if it takes slightly longer to build initially.

Worked example

If the account team's conversation reveals the client's real need is "get transaction data into their existing accounting software automatically" rather than literally "a custom export format," and two other accounts have separately asked about accounting-software integration in the past two quarters, that's strong evidence the underlying need generalizes; the recommendation becomes building a general integration (serving three accounts' real need) rather than the client's originally-requested custom export (serving only one).

Trade-offs and pitfalls

Generalizing a request into a broader feature takes longer to build than the narrow custom version, which risks missing the specific client's deadline even though it produces a better long-term outcome; when the deal timeline is tight, an explicit trade-off conversation (short-term custom bridge, longer-term general replacement) may be needed rather than a clean either-or choice. The opposite pitfall is defaulting to "always generalize" as a reflexive policy, which can mean under-serving a genuinely large, strategically important deal whose specific need really doesn't generalize and is worth the maintenance cost on its own merits.

Direct answer

Budget, timeline, technical dependencies, legal or privacy requirements, and data quality or accessibility are the five categories worth checking on nearly every problem; each one, left unstated, tends to surface late and expensively rather than early and cheaply.

Structured elaboration

Budget: a fixed engineering or research budget changes the ambition level of the acceptable solution; a problem framed without it invites a proposal that's infeasible before anyone realizes it.

Timeline: whether there's a hard external deadline (a contractual commitment, a regulatory date) versus a soft internal target changes how much discovery is worth doing before committing to a direction.

Technical dependencies: constraints like "can't change the backend data model" or "must work within the existing authentication system" bound the solution space before design work starts; discovering them mid-build is expensive.

Legal or privacy: requirements like data-residency rules or consent requirements can eliminate entire categories of otherwise-reasonable solutions, and they're the category most likely to be assumed away by a team without direct legal expertise.

Data quality or accessibility: whether the data needed to measure success or diagnose the problem actually exists, and at what quality, determines whether an experiment-based approach is even possible, or whether you're starting from a smaller, more manual signal.

Worked example

Framing a project to "reduce fraud losses on the platform": surfacing budget (a fixed quarter of engineering capacity) changes the solution from a from-scratch machine-learning model to an incremental rules-based improvement to the existing system; surfacing legal (regulatory reporting requirements for declined transactions in certain jurisdictions) means any new decisioning logic needs an audit trail, which is easy to omit from a design that didn't ask this question up front; surfacing data quality (the labels for "confirmed fraud" are only reliable going back 6 months due to a past data-pipeline change) bounds how much historical data a model-based approach could actually train on, changing the realistic scope of what's achievable in the given timeline.

Two design-audience versions of this same checklist ask for an identical answer with different framing language ("what constraints should you record when framing a UX problem" and "list common constraints surfaced during problem framing for UI work"), confirming the checklist itself, not its phrasing, is the tested content.

Trade-offs and pitfalls

Surfacing every constraint category on every problem, exhaustively, before any work starts adds real overhead, and for a small, well-understood problem it's disproportionate; the categories are a checklist to consult, not a mandatory five-section document for every request. The bigger risk is the opposite: skipping legal or data-quality checks specifically, because they require pulling in someone outside the immediate team, is the most common way a project discovers a blocking constraint late, after design or even engineering work has started.

Direct answer

Rather than building the dashboard as specified, lead with a short discovery conversation aimed at one question: what decision are you trying to make, and how would you make it differently depending on what the data shows? A request "for visibility" almost always has a real decision hiding behind it, and surfacing that decision usually reveals a narrower, faster deliverable than a full dashboard.

Structured elaboration

The questions to ask, in order: (1) "What decision would you make differently if you had this data, versus if you didn't?" This is the single most important question, because if there's no clear answer, the request may genuinely be for situational awareness rather than a decision, which changes what "done" looks like. (2) "How often would you check this, and what would trigger you to act on what you see?" This distinguishes a need for a live dashboard from a need for a periodic report or even a one-time analysis. (3) "What's the smallest version of this that would already tell you something useful?" This surfaces whether a full dashboard is actually needed or whether a single number, refreshed weekly, would answer the underlying question.

If the VP's (vice president's) answers reveal a genuine, recurring decision (say, "I need to know weekly whether to reallocate budget between two initiatives based on their relative performance"), the request reframes into a much narrower, well-scoped deliverable, two specific metrics compared side by side, rather than an open-ended dashboard. If the answers reveal no specific decision, the honest reframe is proposing a lighter-weight alternative, such as a monthly summary email, and explaining why: building a full interactive dashboard for situational awareness alone is a larger and more expensive commitment (both to build and to maintain) than the underlying need justifies.

Worked example

Discovery timeline: a 30-minute conversation using the three questions above, followed by a one-page problem statement circulated back to the VP for confirmation before any build work starts ("I understand the need is: decide weekly whether to reallocate budget between initiative A and B, based on their relative cost-per-acquisition; is that right?"), rather than starting a multi-week dashboard build on the original vague request.

The identical three-step move, surface the actual intent, propose evidence to test the assumption, offer a non-dismissive path forward, applies just as well to a peer stakeholder as to a VP: when a stakeholder insists "users want a carousel on the homepage because competitors use it," the same sequence surfaces what problem the carousel is meant to solve, proposes a cheap way to test whether that problem is real, and avoids either building the carousel uncritically or dismissing the idea outright.

Trade-offs and pitfalls

Pushing back on a VP-level request "for visibility" carries real political risk if handled poorly: framing it as "I don't think you need this" reads as dismissive, while framing it as "help me understand the decision this supports, so I build the right thing the first time" reads as diligence. The pitfall to avoid is building the originally-requested dashboard anyway to avoid the conversation; that path optimizes for avoiding short-term friction at the cost of shipping something that may not get used, which is a worse outcome for both the requester and the team that built it.