The Anatomy of a Shape Up Pitch

A good pitch lets you make a confident bet. It gives you enough information to decide whether an idea is worth time without boxing in how the team builds it.

A pitch is a document that lets someone decide whether to bet time on an idea. It needs enough detail to understand what you’re building and why, but not so much detail that you’re doing the team’s job for them.

The structure is fixed: Problem, Appetite, Solution, Rabbit Holes, No-Gos. That’s it. Those five sections come from the Shape Up book and they’re not negotiable.

We add a sixth section sometimes, Open Questions, when we need stakeholder decisions before work can start. More on that below.

Here’s what goes in each section and how to know when it’s right.

Problem

This section answers one question: why does the status quo not work?

You need a specific story. Not “users are confused” but “when someone tries to export their data, they click the export button, wait thirty seconds staring at a blank screen, then give up assuming it’s broken.” Observable behavior. Real evidence.

Then you need a hypothesis about why it’s a problem. What’s actually broken? In the export example, it’s lack of feedback during processing. The export works fine, but users don’t know the system is doing anything.

Finally, state what you’re betting you can achieve. Concrete outcomes you’ll use to judge whether this worked. “Reduce support tickets about broken exports. Increase successful export completions by showing progress.”

The problem section is done when someone who wasn’t in the room can understand what’s not working and why it matters.

Length: Two to three short paragraphs maximum. If it’s longer, you’re including backstory that doesn’t support the hypothesis. Cut it.

Appetite

How much time is this idea worth?

Not how long it will take. How much time you’re willing to spend on it before you’d rather do something else.

State it clearly. “10 developer days.” “Six weeks.” “Two weeks.” Real time, not story points or vague timeframes.

Add any calendar context that affects the timeline. “Given the holiday break and Maria’s availability, this translates to roughly three calendar weeks before end of quarter.”

State quality expectations explicitly. Is this proof-of-concept scope where throwaway code is fine? Or production-grade where you need it to scale? Teams need to know what “done” looks like.

The appetite section is done when someone reading it knows exactly how much time they have and what quality level to aim for.

Length: Two to three sentences. Any longer means you’re discussing scope, which belongs in Solution.

Solution

This is where you show what you’ll build.

Visual first, always. Fat marker sketches showing screens, layout, flow. Rough boxes and labels, not pixel-perfect mockups. You want the team to see the structure without being boxed into your exact design choices.

For multi-screen flows, break it down screen by screen. Give each screen a name. Bullet the key elements. Embed the sketch. Move to the next screen.

After you’ve shown the visual flow, add technical architecture. What stack are you using? What are the key technical decisions? What constraints exist that affect how this gets built?

Keep the technical section scannable. Bullets, bold headers, short explanations. Engineers should be able to assess feasibility without wading through paragraphs.

The solution section is done when someone can visualize what you’re building and an engineer can assess whether it’s feasible in the appetite you set.

Length: As long as needed, but if it’s more than two pages, you’re probably over-specifying. The solution should be concrete enough to understand but abstract enough to give the team latitude.

Rabbit Holes

These are technical details that prevent wasted time.

Not obvious things the team would figure out anyway. Specific constraints and decisions that could send them down wrong paths if they don’t know upfront.

Examples that work:

• “PostgreSQL only. MySQL has different transaction handling that breaks our approach. No time to support both.”
• “Read-only API access. We can’t write data back to their system. Export is one-way only.”
• “Browser-side processing only. No server uploads. Files stay local for privacy compliance.”

Three to five bullets maximum. If you have more than five, some of them aren’t really rabbit holes. They’re either obvious or they belong in the solution section.

The rabbit holes section is done when an engineer reading it won’t waste days exploring approaches you’ve already ruled out.

No-Gos

What you’re explicitly not doing.

Things that might seem related but are out of scope. Features someone might assume are included but aren’t. Quality levels you’re not aiming for if relevant.

Examples:

• “Custom export formats (CSV only for v1)”
• “Scheduled exports”
• “Email delivery of exports”
• “Production-grade error handling (basic validation only)”

Three to five bullets maximum. More than that means your scope isn’t clear enough. If you have to list twenty things you’re not doing, you haven’t defined what you are doing tightly enough.

The no-gos section is done when scope creep has nowhere to hide. When someone suggests adding something during the cycle, you can point to this list and say “that’s a no-go.”

Open Questions (Our Extension)

Shape Up doesn’t include this section. The book lists five ingredients and that’s it. We add this sixth section because it’s useful for measuring how shaped an idea is.

Here’s the logic: the number of unresolved questions is a direct measure of shapedness. Start with twenty open questions and you have a raw idea. Get it down to three or four and you’re close. Get it to zero and you’re ready to bet.

During shaping, you’re hammering down open questions. Every question you answer through research, exploration, or decisions makes the idea more shaped. If you’re stuck at fifteen open questions, you’re not done shaping yet. Keep going.

When you’re ready for the betting table, zero open questions is ideal. Three to four maximum if they require stakeholder decisions you can’t make alone. More than that means it’s not shaped enough to bet on.

Only include this section in the pitch if those three to four remain. Each question should have two to three concrete options, not be open-ended. You’re not asking “what should we do?” You’re asking “should we do option A, B, or C?”

Example: “What’s the best way to handle authentication?

• OAuth with existing provider
• Magic link email
• Simple token-based”

The key constraint: if the open questions block a team from starting work, they don’t belong in a pitch. They need to be resolved during shaping. If the open questions are decisions that can be made quickly at the betting table or in the first day of the cycle, they’re acceptable.

Skip this section entirely if you don’t have real decision points. Most pitches don’t need it.

Length: Two to four questions maximum. More than that means the idea isn’t shaped enough yet.

Quality Checks

Before you call a pitch done, verify these things:

Can someone who wasn’t in the room understand the problem? If you need to explain it verbally, the problem section isn’t clear enough.

Is appetite stated as time, not scope? “Build the entire feature” isn’t an appetite. “Six weeks” is an appetite.

Are there visual sketches embedded in the solution? If it’s text-only descriptions of UI, it’s not done. Create the sketches or note placeholders and request them.

Can an engineer assess feasibility? If the technical architecture is too vague or too detailed, adjust it.

Do rabbit holes prevent obvious wrong paths? If they’re generic warnings, they’re not useful.

Do no-gos prevent scope creep? If someone could read this and still misunderstand what’s included, tighten the boundaries.

Can this be read in five minutes? If it takes longer, you’ve included too much detail. Cut anything that doesn’t help someone decide whether to bet on this.

What Happens After

A pitch lets leadership decide whether to bet on the idea. That’s the only job it has.

If they bet yes, a small team gets the pitch and the appetite. They own the project completely. They make implementation decisions. They solve problems. They ship something valuable within the time constraint.

The pitch gives them enough direction to start and enough latitude to do their job well. That balance is what makes a pitch work.

Too vague and the team doesn’t know what to build. Too detailed and you’ve done their job for them. The anatomy exists to hit that balance every time.

Using This Reference

When you’re writing a pitch, work through the sections in order. Problem, then appetite, then solution, then rabbit holes, then no-gos. The sequence matters because each section builds on the previous one.

When you’re reviewing a pitch, run through the quality checks. Missing sections, weak spots, and scope creep all show up quickly when you know what to look for.

The structure works because it forces the questions that matter. What’s broken? How much time is it worth? What does good look like? What could go wrong? What are we not doing?

Answer those questions clearly and you have a bet someone can make. Skip any of them and you have an idea that’s not ready yet.

That’s the anatomy. Everything in its place for a reason.