How to Write a Scope That Actually Gets You the Right Pod

Two teams can describe the same underlying need — "we need help building our onboarding flow" — and get very different pods, because one of them wrote a scope and the other wrote a wish. This is a practical guide to writing the version that actually works.

Start with the outcome, not the activity

A scope built around activity ("build a dashboard," "improve the API") is under-specified by default — it describes what people will be doing, not what has to be true when they're done. A scope built around outcome specifies the finish line:

• Weak: "Improve our onboarding flow."
• Strong: "A self-serve onboarding flow that gets a new user from signup to first value without a sales call, measured by activation rate."

The strong version does something the weak one can't: it tells us whether the right pod is a Product Pod (if the flow doesn't exist in validated form yet) or an Engineering Pod (if it's already designed and just needs to be built).

Name the constraint honestly

Every scope has a real constraint — time, budget, or scope itself — even if it isn't stated. Naming it changes the pod:

• Time-constrained ("this needs to work before our Series A close date") sizes toward front-loaded capacity, even at higher unit cost, because the cost of missing the date outweighs the cost of a larger pod.
• Budget-constrained ("we have a fixed runway for this") sizes toward a minimal pod with elastic room to grow only when a specific sprint demands it.
• Scope-constrained ("this is genuinely large but not urgent") sizes toward steady-state Cruise Mode capacity, run longer at a smaller footprint.

If you don't name the constraint, we'll ask — but a scope that already states it moves straight to composition instead of spending the call extracting it.

Distinguish "must ship" from "would be nice"

Scopes that don't separate these two produce pods sized for the maximum possible version of the work, which is almost never the right size for what actually needs to happen first. Write two lists:

1. What must be true for this to be a success — the actual bar.
2. What would make it better, but isn't the bar — the backlog for later.

A pod scoped against list 1 alone is almost always smaller, faster to start, and delivers sooner than a pod scoped against an undifferentiated mix of both.

Include what already exists

A scope that omits existing context (a partial codebase, prior design work, an existing team) gets a pod sized as if starting from zero — which is either oversized or misses dependencies that should have shaped composition. Include:

• Links to any existing repo, design files, or specs
• Who else (if anyone) is already working on this, and how the pod should coordinate with them
• Any hard technical constraints — a required stack, a compliance framework, an integration that can't change

A scope brief template

If you want a starting structure, this is the shape that produces the fastest, most accurate pod match:

Outcome: [One or two sentences — what ships, specifically]
Must-ship bar: [The actual definition of done]
Constraint: [Time / budget / scope — name which one is binding]
What exists already: [Codebase, team, design work, links]
Hard requirements: [Stack, compliance, integrations that can't change]

Bring this to a scoping call and the composition conversation — Product Pod, Engineering Pod, QA Pod, Data & AI Pod, or a mix — takes minutes instead of a second call. For the full picture of how composition decisions get made from there, see our delivery pod playbook.