5 exercises on framing context, goals and non-goals, success metrics, and keeping the problem separate from the solution.
Key patterns
Lead with measurable symptoms: "X has risen from A to B over <period>".
Non-Goals declare what is deliberately out of scope — and where it lives instead.
Success metrics are specific, bounded, and time-framed (think SMART).
Describe what is wrong, not how you will fix it; answer "why now".
0 / 5 completed
1 / 5
You are opening the Problem Statement of a design doc. Which version frames the context most clearly and objectively?
A problem statement states the situation with evidence, not emotion.
Option B is concrete: it quantifies the symptom (p95 800ms → 3.2s), ties it to a business metric (abandonment), and names the target. That is the native pattern for framing context.
Lead with measurable symptoms: "X has risen from A to B over ".
Connect to impact: latency → abandonment → revenue.
Useful openers: "This document proposes…", "The current system…", "We are seeing…".
Option A is emotive ("disaster", "hate"). Option C states a preference ("nobody likes maintaining it"), not a problem. Option D is vague filler with no data.
2 / 5
Within the Problem Statement you list Goals and Non-Goals. Which line is correctly placed as a Non-Goal?
Non-Goals declare what you are deliberately not doing, to bound scope and pre-empt reviewer questions.
A good non-goal names an adjacent, plausible-but-excluded effort and ideally links where it lives (PLAT-412).
Common phrasing: "out of scope for this proposal", "will not address", "tracked separately".
Option B does this perfectly. Options A and C are actually Goals (they describe desired outcomes). Option D is a requirement/constraint, not a non-goal — you do want the tests to pass. Mislabelling goals as non-goals confuses reviewers about your intent.
3 / 5
Which sentence states a success metric in the most useful, verifiable way?
A success metric must be measurable, bounded, and time-framed — otherwise you can never tell whether the project succeeded.
Option C names the metric (p95, abandonment), the target (<1s, ≤10%), the window (rolling 7-day), and when to evaluate it.
Watch for weasel words: "fast", "reliable", "happier", "significant" are all unverifiable.
This mirrors SMART criteria (Specific, Measurable, Achievable, Relevant, Time-bound). Options A, B and D are aspirational but cannot be objectively checked, so they are useless as exit criteria for the project.
4 / 5
A reviewer says your Problem Statement "jumps straight to the solution". Which sentence is the offender that you should move out of the Problem Statement?
The Problem Statement describes what is wrong, not how you will fix it. Solutions belong in the Proposed Solution section.
Option B names a specific technology and design (Kafka, exactly-once) — that is a solution, so it leaks scope into the wrong section.
Options A, C and D all describe symptoms and impact (overrun, SLA breach, paging) with no implied implementation.
Keeping problem and solution separate lets reviewers agree the problem is real before debating the approach. A good test: could a sentence survive even if you chose a completely different solution? If not, it is solution detail and belongs elsewhere.
5 / 5
Which opening best captures the "why now" — the urgency or trigger that justifies acting on this problem today?
"Why now" answers the implicit reviewer question: why is this worth doing this quarter rather than later?
Option C ties the work to a hard, dated trigger (SLA from 1 Oct) and quantifies the risk of inaction (breach in six weeks). That creates a defensible priority.
Strong triggers: an upcoming deadline, a compliance date, a measured trend crossing a threshold, a dependency being deprecated.
Option A ("always wanted to") and D ("spare capacity") are weak motivations — reviewers will deprioritise them. Option B is a generic observation with no bearing on your timeline. Framing urgency with a concrete trigger is what gets a design doc approved and staffed.