Problem Definition and Framing Questions
Turning an ambiguous prompt into a well-scoped, clearly-stated problem before proposing solutions. Covers structured decomposition, clarifying assumptions, identifying the real user and job-to-be-done, and framing the problem to fit the constraints. Assesses disciplined problem-first thinking under ambiguity.
Design a lightweight governance model to keep problem definition and scoping consistent across multiple product teams and avoid scope creep and premature solutioning. Define the roles, such as an owner and a reviewer, the decision gates, the required artifacts at each gate (a brief, hypotheses, metrics), and how you would measure adherence to the process.
Sample Answer
Direct answer
A lightweight governance model needs three things: clear roles (who owns problem definition for a given effort, and who reviews it), a small number of decision gates tied to when work actually gets committed (not extra process layered on top of existing ones), and a short set of required artifacts at each gate, kept minimal enough that teams don't route around them.
Structured elaboration
Roles: an owner, typically the lead on the effort, accountable for the problem definition being complete before proceeding; a reviewer, someone outside the immediate team (a peer lead, a cross-functional partner) who checks the definition for the gaps a close-in owner might miss, particularly an unstated assumption or a missing constraint. The reviewer role is deliberately lightweight, a 15-minute check, not a full second discovery pass, since a heavyweight review process is exactly the kind of thing multiple teams will start skipping under deadline pressure.
Decision gates: two, tied to existing checkpoints rather than new ones: at the point work gets added to a team's committed roadmap (requiring a completed problem brief and reviewer sign-off), and at the point a solution direction is chosen (requiring the hypotheses and success criteria fields to be filled in, confirming the direction ties back to a specific, testable claim rather than being picked on instinct).
Required artifacts at each gate: at the roadmap-commitment gate, the problem brief (evidence, affected users, impact estimate); at the solution-direction gate, the hypotheses and success criteria that justify the chosen direction. Kept to these two, rather than a longer list, because each additional required artifact is another point where a team under pressure is tempted to shortcut the process.
Measuring adherence: track the share of roadmap-committed efforts with a reviewer-approved brief before commitment (the leading indicator), and separately, sample a subset each quarter for whether the review caught anything substantive (a gap, an unstated assumption) versus rubber-stamping everything that comes through, which distinguishes a genuinely functioning review from a check-the-box formality.
Worked example
If the quarterly sample shows the reviewer step caught a real, substantive gap (a team's brief didn't account for a legal constraint the reviewer, from a different part of the org, happened to know about) in 1 of 8 sampled cases, that's evidence the review step is doing real work, not just adding a signature requirement; if it catches nothing across a full quarter of sampling, that's a signal the review has become a formality and needs either a different reviewer assignment or a more specific review checklist.
Trade-offs and pitfalls
Cross-team governance risks becoming exactly the bureaucracy it's meant to prevent if the gates multiply over time, a common failure mode where each new incident prompts "let's add a check for that" until the process is heavier than the problem it solves; resisting that drift, and periodically removing checks that aren't catching anything, is as important as adding the checks in the first place. The other pitfall is a reviewer role that's purely advisory with no actual teeth at the gate, in which case teams under deadline pressure will proceed regardless of the reviewer's input, and the governance model exists on paper without actually shaping behavior.
A team keeps jumping to solutions before doing any research. Describe both behavioral and tactical approaches you would use to change this pattern. Include meeting structures, artifacts such as a 'problem brief' template, scripts or questions to use in discussions, and how you would measure adoption of the new practice.
Sample Answer
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.
You need a fast decision rubric for triaging ambiguous incoming product requests across teams. Propose a five-criteria rubric, with a short description of each criterion, that a mixed group of engineers, product managers, and stakeholders could use to make consistent, quick decisions. Explain why each criterion belongs and how you would weight them.
Sample Answer
Direct answer
Five criteria: business impact if unaddressed, urgency (real deadline versus perceived), how many users or accounts are affected, whether the request is reversible if wrong, and whether the underlying problem is even confirmed with evidence yet. Weighted together, these separate requests that genuinely need fast-tracking from ones that feel urgent but aren't.
Structured elaboration
Business impact if unaddressed: what happens if this request sits for two weeks versus two months; a request whose cost grows the longer it's unaddressed (an active revenue leak) ranks differently than one whose cost is flat over time (a nice-to-have improvement).
Urgency, real versus perceived: does this have an actual external deadline (a contractual date, a regulatory requirement) or is the urgency coming from whoever's asking feeling strongly about it; the two are easy to conflate and only one of them should move a request up the queue on its own.
Scope of who's affected: one account, a segment, or the whole user base; broader impact generally, though not always, deserves faster attention than a narrow one, all else equal.
Reversibility: a request that's cheap to try and easy to undo if wrong can be fast-tracked with less certainty required up front; a request that's expensive or hard to reverse needs more confirmation before jumping the queue, regardless of how urgent it feels.
Confirmed versus assumed: has the underlying problem actually been checked against data, or is this still at the "someone reported it" stage; an unconfirmed request shouldn't skip the line ahead of confirmed ones just because it arrived more recently or more loudly.
Weighting: business impact and confirmed-versus-assumed carry the most weight, since they answer "is this real and how much does it matter," while urgency and reversibility function more as tie-breakers between requests that score similarly on the first two.
Worked example
Two requests arrive the same week: one from a single enterprise account demanding a specific integration "by Friday" (high perceived urgency, but affects one account, reversibility is low since building it commits ongoing maintenance, and the underlying need hasn't been confirmed against other accounts' needs); another flagging that a payment-confirmation email hasn't been sending for three days, discovered through a support-ticket spike (high business impact, growing the longer it sits, affects all users hitting that flow, and it's confirmed with data). Applying the rubric ranks the payment-email issue above the single-account integration request, even though the account's request arrived with more explicit urgency language attached to it.
Trade-offs and pitfalls
A five-criteria rubric applied mechanically, without judgment, can produce a technically-correct ranking that still feels wrong to the people involved, particularly when a request from a loud or senior stakeholder scores lower than the rubric would suggest they expect; the rubric is a decision aid that should be explained transparently when a ranking surprises someone, not a black box used to avoid a difficult conversation. The other pitfall is treating the weighting as fixed forever; a rubric calibrated for a stable-state product may need re-weighting during a genuinely different period, such as right after a major incident, when confirmed impact should temporarily dominate even more heavily than usual.
Design a reusable 'problem brief' template that a team must complete before any engineering effort begins. The template should include: evidence, affected users, an impact estimate, hypotheses, proposed experiments, success criteria, an owner, a timeline, and risks. Provide a filled example for the problem: slow report generation for large datasets.
Sample Answer
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.
That is every published Problem Definition and Framing question for Cloud Architect so far. Browse the other topics in this category, or practice this one interactively.