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.
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 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.
- 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.
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.
| 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? |
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.
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 — ch. 3: stakeholders, business goals, and architecture drivers.
- 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.