Lesson 0039 · Initiative Lead · Module 1

Turn a Product Brief into an Initiative Frame

A brief is an invitation to investigate, not a specification to estimate. Your first leadership move is to turn requested output into a decision-ready frame.

Reading ≈ 9 minPractice ≈ 40 min

Mission tie-in: architecture starts before boxes and arrows. The outcome, constraints, uncertainty, and cost of failure decide which architecture is responsible.

Knowledge: make the problem testable

Imagine product brings this brief: “Build a self-serve returns portal by Q3. It needs automated approvals, carrier labels, and status notifications.” It sounds precise because it names features. It is not. You do not yet know whose problem matters, what improvement counts, which policies must hold, or whether a portal is the cheapest intervention.

A lead does not reject the brief or silently accept it. Product, design, and engineering rewrite it together into six decisions:

Outcome and baseline. Whose behavior changes, from what to what, by when? “Reduce median resolution from 72 hours to under 4 hours for eligible domestic returns by the end of the pilot.”
Guardrails. What must not get worse? Fraud loss, support contacts, accessibility, manual workload, and carrier cost are measures too.
Scope boundary. Name the first users and situation, plus explicit non-goals. International returns and exchanges are out of the pilot.
Constraints. Facts the design cannot negotiate: the existing order system remains authoritative; labels come from a contracted carrier; PII is retained for 30 days.
Assumptions. Beliefs that might be false: customers want self-service; policy rules are codifiable; the carrier can meet the latency target.
Decision and ownership. Who decides scope, experience, architecture, and rollout—and what evidence will reopen each decision?

The principle behind the principle

The leadership force here is preserved freedom to change the solution. A commitment is a constraint on future decisions, so what you commit to determines what evidence is allowed to do to you. Commit to an output — "a portal by Q3" — and you have chosen a solution before you have the evidence that would let you choose one; every later discovery is then a threat to the plan, and a team defends a plan instead of learning. Commit to an outcome — "under four hours for eligible domestic returns" — and the same discovery becomes an input, because the target survives while the solution is free to move.

There is a second mechanism, less often named. An outcome is falsifiable, and a falsifiable statement is the only kind that lets product, design and engineering resolve a disagreement by measurement rather than by seniority. That is what the frame is for: not to inform stakeholders, but to make the team's disagreements decidable.

So the principle has a boundary, and it is sharp. When the output is the obligation — an accessibility regulation with a date, a contractual deliverable, a platform going end-of-life — the deliverable is genuinely the point, and asking "but what outcome does this drive?" spends three weeks proving something everyone already knows. And an outcome nobody can measure is worse than an output, because it cannot be checked at all; when the instrumentation does not exist, the first slice of the initiative is getting the baseline, and the frame should say so out loud.

The distinction that protects the whole initiative is outcome versus output. “Ship a portal” is output. “Resolve eligible returns in four hours” is an outcome. Output can be on time while the customer problem remains untouched. The outcome lets the team change its solution when evidence changes.

Artifact · initiative frame, version 0.1

Problem: Eligible returns wait a median 72 hours for an agent decision; 41% produce a support contact.
Outcome: Under 4 hours median and 25% fewer contacts for the domestic pilot by 30 September.
Guardrails: Fraud loss ≤ current baseline; manual review queue ≤ 50/day; WCAG 2.2 AA critical flows.
First slice: Signed-in domestic customer, unopened item, within 30 days, refund to original payment method.
Non-goals: Exchanges, international shipping, guest checkout, redesigning warehouse intake.
Constraints: Order system owns order truth; carrier contract is fixed; no payment data enters the new module.
Unknowns: Policy exception rate, carrier label latency, customer comprehension, agent override needs.

Worked: the arithmetic that changes the frame

Take the brief as given — portal, automated approvals, carrier labels, notifications — and watch where a lead's attention goes first. Not to the feature list. To the baseline and the population: 72 hours median, 41% of returns producing a support contact, and roughly 3,000 returns a day across the whole book.

Then the question that reshapes the frame: what share of the problem does the proposed output actually touch? The pilot cohort is signed-in domestic customers with unopened items inside 30 days — about 38% of volume, some 1,140 returns a day. Suppose the initiative works perfectly and those 1,140 resolve in four hours. The median across all returns barely moves, because the other 62% still take 72 hours and the median sits among them. An initiative whose stated success metric it cannot move by arithmetic is not an ambitious initiative; it is a mis-specified one, and it will be judged in October by a number that was never in its reach. That is why the outcome in the frame reads "for eligible domestic returns" — the population is not a caveat, it is the difference between a measurable claim and an unwinnable one.

The same arithmetic converts a guardrail into a design driver. The frame caps the manual review queue at 50 cases a day. If automation handles 90% of the cohort — the figure the team believes but has not evidenced — the remaining 10% of 1,140 is 114 cases a day, more than double the cap. So the guardrail silently requires the policy engine to decide at least 95.6% of pilot cases automatically, or requires the cohort to be narrower. Nobody wrote that requirement down; it fell out of two numbers already in the frame. Finding it in week one costs a conversation. Finding it in week nine costs the pilot.

The alternative a lead rejects is the appealing one: widen the pilot to all returns so the headline metric moves. It multiplies the policy surface — international shipping rules, exchanges, guest checkout — while the review-queue guardrail is already stretched, and it converts a testable bet into a programme. The narrower cohort is chosen precisely because being wrong about it is cheap.

What the frame buys is visible on the other side of the pilot. If contact rate falls 25% and that holds across the book, 3,000 × 41% = 1,230 contacts a day become about 307 fewer; at six minutes each that is roughly 31 agent-hours a day, near four full-time roles. Stated as an outcome, that is a result the team can claim, argue about and extend. Stated as "we shipped the portal", it is an activity report, and the first person to ask "did it work?" will have no way to answer.

A useful frame is short enough to argue with. Attach evidence and longer research; do not bury the decision beneath it. Version the frame as facts change. A changed frame is learning, not failure.

Field notes · brief smells and leadership moves

You hear this	What is missing	Ask instead
“We need a dashboard.”	The decision it should improve.	Who will do what differently after seeing it?
“This must scale.”	A load and a response target.	Which peak, which operation, and how fast?
“Launch by Q3.”	The smallest evidence worth launching.	Which cohort proves or disproves the bet?
“Everything is priority one.”	A stated cost of delay.	Which failure hurts the outcome first?

What people get wrong after reading this

"An outcome is a KPI with a target on it.": An outcome names four things: whose behaviour changes, from what baseline, by how much, and by when. Drop the population and you get a number arithmetic will not let you move; drop the baseline and nobody can say afterwards whether it worked.
"Constraints and assumptions are two words for the same list.": A constraint is a fact you design around; an assumption is a belief you test. Mislabelling an assumption as a constraint — "the order system cannot expose that" — is how teams spend a quarter designing around something that was never true, and nobody re-checks it because constraints are not supposed to be questioned.
"The frame is a document for stakeholders.": It is a working instrument for the team. If it is not reread at the weekly review, and if no decision this month cited it, it has become a launch artifact — and the initiative is now steered by whatever the loudest recent message was.
"Framing outcomes means engineering gets no requirements.": The opposite: an outcome plus guardrails plus constraints gives engineers the architecture drivers a feature list never contains. "Under four hours, fraud loss flat, queue under 50 a day" tells you what to design for. "Build a portal" tells you what to type.

When this is the wrong move

Three situations where reframing is the wrong instinct. When a regulator, a contract or an end-of-life date makes a specific deliverable the obligation, the output is the point and the useful leadership work is sequencing and risk, not outcome discovery. When the initiative is a like-for-like migration whose entire success criterion is "nothing changes for users", an outcome statement adds a layer of translation over a goal everyone already shares. And when nothing is instrumented, an outcome is unfalsifiable — the honest frame then commits to producing the baseline first and names the date on which the real target will be set.

There is also a timing failure. Reframing a brief that arrives the same week as a hard deadline can be correct engineering and bad leadership: if the conversation cannot change the decision, run it as a risk conversation instead, and save the framing energy for the initiative that is still shapeable.

In the lab: the companion Phase 4 exercise starts from the flawed returns service you repaired in Phase 3 and asks you to write the frame the code should have been built from — outcome, guardrails, cohort, non-goals — then to name which module in the existing code contradicts each guardrail. For a fully worked version of this artifact, see the capstone's initiative frame.

Skill: separate the bet from the build

Which statement is an outcome?

A fixed carrier contract belongs under:

Why write explicit non-goals?

Practice: rewrite a real brief

Take one initiative in your organization. In one page, write its baseline, target outcome, guardrails, first cohort, non-goals, constraints, top five assumptions, and decision owners. Circle every number without a source and every “must” without an owner. Those circles are your first discovery backlog.

Reveal: the frame quality test

Give the page to someone outside the initiative. They should be able to answer: why now, for whom, what measurable change, what is deliberately excluded, what cannot move, what might be false, and who can decide. If they can only describe the proposed features, the brief has not yet become a frame.

Teach it back

In two sentences, explain to a junior engineer why committing to an outcome gives the team more freedom than committing to a feature.
Take the initiative you are on this week. Find one number in it with no source and one "must" with no owner, and name what each will cost when it turns out to be wrong.
Predict where the initiative lands in a year if it stays framed as output: what will be shipped, what will be claimed, and which question will nobody be able to answer?

Your win

You can convert a feature-shaped request into a measurable initiative frame that gives product freedom to learn and engineering enough context to design responsibly.

Read and watch deeper

Continuous Discovery Habits, Teresa Torres — ch. 3–6: outcomes, opportunity mapping, and turning assumptions into tests.
Inspired, Marty Cagan — product discovery chapters: separating the problem to solve from the feature to ship.
Software Architecture in Practice, Bass, Clements & Kazman — 4th ed., ch. 3 and 19: business goals, stakeholders, and turning them into architecture drivers.
Escaping the Build Trap, Melissa Perri — ch. 1–4: the organisational reasons output commitments survive even when everyone agrees outcomes are better.
Reference: Initiative Playbook · frame template and the trade-off method.

Bring a brief to your agent-teacher and ask it to label every sentence outcome, output, constraint, assumption, guardrail, or unresolved.

Mark lesson complete