Create shaped project pitches that give teams "the whole idea" - de-risked, bounded, and ready to build. Use when you need to shape a project, create a pitch for the betting table, write a shaped proposal, create breadboards or fat marker sketches, or prepare work for a team. Requires a framed problem as input (use problem-framing skill first if needed).
Create shaped pitches that fix time (appetite) and adjust scope to fit, rather than estimating how long a fixed scope will take.
Wrong question: "How long will this take?" Right question: "How much time do we want to spend on this?"
Appetite is typically 2 or 6 weeks - long enough to build something meaningful, short enough to see the end from the beginning.
| Role | Responsibility | |------|----------------| | PM | Owns the framed problem, negotiates scope | | Designer | Creates breadboards showing flow and logic | | Senior Engineer | Validates feasibility ("is there electricity in the wall?") |
The engineer is NOT there to code. They're there to identify if the proposed UI implies backend work that doesn't exist or would exceed the appetite.
Show flow and logic WITHOUT visual design. A breadboard contains:
[Appointments Screen]
|
├── [2-month dot grid] → shows availability at a glance
| └── tap day → [Day Detail]
|
└── [Agenda list] → scrollable list of booked slots
└── tap slot → [Appointment Detail]
Rough UI sketches drawn as if using a fat marker - impossible to add detail. Shows:
NOT wireframes. NOT Figma files. The lack of fidelity is intentional.
High-level view of components:
Components:
- 2-month dot grid view (client-side render)
- Sliding agenda view (lazy-load past 7 days)
- Creation button (triggers existing booking flow)
Data:
- Reads from existing appointments API
- No new endpoints needed
Dependencies:
- Existing booking service (confirmed available)
# [Project Name]
## Problem
[Paste the Framed Problem Statement from problem-framing]
## Appetite
[2 weeks / 6 weeks] - [Brief justification for why this budget]
## Solution
[2-3 paragraphs describing the approach at high level]
## Breadboards
[Include breadboard diagrams showing flow]
## Fat Marker Sketches
[Include rough sketches if helpful]
## Rabbit Holes
[List technical risks identified and how they're addressed]
| Rabbit Hole | Risk | Mitigation |
|-------------|------|------------|
| [Risk 1] | [What could blow up] | [How we've de-risked it] |
## No-Gos
[What's explicitly OUT of scope - prevents scope creep]
## Nice-to-Haves
[Things that could be cut if time runs short - the "dials" the team can turn]
Give the team "the whole idea," NOT a backlog of tickets.
The team is responsible for:
If the project isn't finished at the end of the appetite:
Before pitching:
For detailed failure modes and how to avoid them, see references/anti-patterns.md.
For breadboard and pitch examples, see references/pitch-examples.md.
Category:business