Frame the problem before you propose a solution

The four-section one-pager a reviewer can reject in five minutes — before anyone spends a week building the wrong thing.

You already know how to break a feature down and ship it. The gap between that and senior-level planning usually isn’t skill — it’s sequence. Engineers who haven’t done this at scale tend to jump straight from “here’s the ask” to “here’s my design.” Senior engineers insert a step in between: they write down the problem, tight enough that a reviewer could reject the framing before anyone wastes a week on the wrong solution.

That’s the whole lesson. One document, one habit, one rule: no solutioning until the problem is written down and someone else has read it.

Why framing comes first

Two ideas worth knowing the origin of, because they’ve shaped how most serious engineering orgs plan:

Amazon’s PR/FAQ process requires teams to write the future press release and FAQ for a product before writing any code — forcing them to state customer value in plain language and surface disagreements while they’re still cheap to resolve (Working Backwards, “PR/FAQ Instructions & Template”). Most companies don’t write full six-page PR/FAQs for ordinary projects — but the underlying discipline, state the problem and the win before the solution, scales down cleanly to a one-pager.

The RFC/design-doc culture used at companies like Uber, Stripe, and Asana runs on the same logic in reverse: proposals get circulated for review specifically so that decision quality improves before commitment, not after (Gergely Orosz, “Engineering Planning with RFCs, Design Documents and ADRs”). A framing document is the artifact that makes that review possible — reviewers can push back on a problem statement in five minutes; pushing back on a half-built design costs everyone an hour and feels personal.

The anatomy of a one-pager

Four sections, in this order, each one sentence to one short paragraph. If any section balloons past that, it’s a sign the problem isn’t actually understood yet.

1. Problem

What’s broken or missing, for whom, stated without reference to a solution. Not “we need SSO” (that’s already a solution) — “enterprise buyers require identity-provider login and won’t sign contracts without it.”

2. Why now

What makes this worth doing this quarter instead of some other quarter. Usually a number: revenue at risk, deals blocked, incidents caused. If you can’t fill this in, that’s real signal — surface it rather than inventing urgency.

3. Success criteria

Specific, observable outcomes — not tasks. “Enterprise customers can provision and deprovision users via their identity provider with zero manual account creation by our team” is a success criterion. “Build SSO” is not.

4. Non-goals

What this project explicitly will not do. This is the section junior framing docs skip, and it’s the one senior reviewers check first — it’s where scope creep gets stopped before it starts.

Retrieval check

Without scrolling up: which of the four sections is most often missing from a first-draft one-pager, and why does its absence cause the most damage later?

Check your answer

Non-goals. Without it, every stakeholder silently assumes their pet feature is included, and you discover the disagreement mid-build instead of during review — the most expensive possible moment to find it.

Now apply it: draft the SSO one-pager

Using only the raw Slack message above (resist the urge to invent extra context you don’t have yet), draft the four sections for the SSO project. Keep each section to 1–3 sentences — the constraint is the point.

Hands on

Draft the four sections

Done when: You have a one-pager short enough to read aloud, and a reviewer has pushed back on it.

Write Problem without naming a solution. If the word “SSO” appears, you have written a solution.
Write Why now. You have exactly one number available to you — use it, and note what else you would want to know.
Write Success criteria as things someone could observe being true, not work someone could do.
Write Non-goals. Aim for three. This is the section you will be tempted to skip.
Paste the draft into the chat. Your teaching agent will review it the way a senior peer would in an actual RFC comment thread — pushing on vague success criteria, missing non-goals, and unstated assumptions.

Frame the problem before you propose a solution

The four-section one-pager a reviewer can reject in five minutes — before anyone spends a week building the wrong thing.

That’s the whole lesson. One document, one habit, one rule: no solutioning until the problem is written down and someone else has read it.

Why framing comes first

Two ideas worth knowing the origin of, because they’ve shaped how most serious engineering orgs plan:

The anatomy of a one-pager

Four sections, in this order, each one sentence to one short paragraph. If any section balloons past that, it’s a sign the problem isn’t actually understood yet.

1. Problem

2. Why now

3. Success criteria

4. Non-goals

What this project explicitly will not do. This is the section junior framing docs skip, and it’s the one senior reviewers check first — it’s where scope creep gets stopped before it starts.

Retrieval check

Without scrolling up: which of the four sections is most often missing from a first-draft one-pager, and why does its absence cause the most damage later?

Check your answer

Now apply it: draft the SSO one-pager

Hands on

Draft the four sections

Done when: You have a one-pager short enough to read aloud, and a reviewer has pushed back on it.

Write Problem without naming a solution. If the word “SSO” appears, you have written a solution.
Write Why now. You have exactly one number available to you — use it, and note what else you would want to know.
Write Success criteria as things someone could observe being true, not work someone could do.
Write Non-goals. Aim for three. This is the section you will be tempted to skip.
Paste the draft into the chat. Your teaching agent will review it the way a senior peer would in an actual RFC comment thread — pushing on vague success criteria, missing non-goals, and unstated assumptions.