Shaping Product Pitches with a Shape Up Pitch Template
This skill teaches you to define problems, set time appetites, and produce shaped pitch documents complete with fat-marker sketches and breadboarding, so engineering teams receive well-framed work instead of vague feature requests.
Start by identifying a raw problem from customer requests, support data, or strategic goals. Frame the problem in one or two sentences. Set a fixed appetite (typically one, two, or six weeks). Sketch the solution at a high level using fat-marker sketches for visual interfaces or breadboards for workflow logic. Identify rabbit holes and no-gos. Assemble these elements into a written pitch document that a betting table can evaluate without needing a follow-up conversation.
Outcome: You produce a complete, self-contained pitch document that a betting table can accept, reject, or defer without needing a follow-up meeting, giving your team a concrete artifact to evaluate against competing priorities.
Prerequisites
- Basic understanding of the Shape Up framework and its cycle structure
- Familiarity with your product's architecture and customer pain points
- Ability to sketch rough interface ideas (no design skill required, just willingness to draw boxes and arrows)
- Access to customer feedback sources such as support tickets, sales call notes, or usage analytics
Overview
Shaping is the upstream work that happens before any team writes a line of code. In the Shape Up framework, shaping sits between raw ideas and committed build cycles. Its purpose is to reduce risk by doing the hard thinking about a problem and its solution before a team is on the clock. The output is a pitch, a written document that captures the problem, the appetite, the solution sketch, and the known risks. Without shaping, teams either receive vague feature requests that balloon in scope or overly detailed specifications that leave no room for creative problem-solving during the build.
A shape up pitch template is not a PRD, a user story, or a spec. It operates at a specific altitude. Too abstract and the team has no direction. Too concrete and you have removed the team's ability to make tradeoffs during the build. The pitch sits in the middle: concrete enough that the solution is believable and the risks are visible, but abstract enough that the building team can figure out the implementation details. This middle ground is what makes shaping genuinely difficult and genuinely valuable. The person shaping must understand the problem domain, the product's technical landscape, and the customers' actual needs, then synthesize all of that into a document that fits on a few pages.
The artifact you produce is a pitch document with five sections: problem, appetite, solution, rabbit holes, and no-gos. The problem section frames the specific situation you are solving and for whom. The appetite section states how much time the company is willing to spend, which is a strategic decision, not an estimate. The solution section uses fat-marker sketches (rough visual layouts) or breadboards (flow diagrams showing screens, actions, and connections) to describe the approach at the right level of abstraction. The rabbit holes section flags technical or design risks that could derail the build. The no-gos section explicitly states what is out of scope. When all five sections are clear, the betting table can make a confident yes-or-no decision without scheduling a follow-up conversation.
Shaping is typically done by a senior person or small group (one or two people) who combine product thinking with enough technical literacy to know what is feasible. It is not a committee exercise. The shaper works asynchronously, often over several days, iterating on the pitch until it feels right. The goal is not consensus. The goal is clarity.
How It Works
The shape up pitch template works because it forces you to answer four questions that most product processes skip or conflate. First, what is the actual problem? Not the feature request, not the solution someone already imagined, but the underlying situation that makes a customer's life worse. Second, how much is this problem worth solving? The appetite is a business decision about time allocation, not an engineering estimate. By fixing the time upfront, you create a constraint that drives creative scoping during the build. Third, what does a believable solution look like at the right level of abstraction? And fourth, what could go wrong?
The mental model behind shaping is risk reduction through deliberate ambiguity. A pitch must be specific enough that the team knows where to start and can see the finish line, but loose enough that they can make implementation decisions as they discover complexity. Fat-marker sketches accomplish this for visual interfaces: you draw with a thick marker so you literally cannot include fine details like button styles, exact copy, or pixel-level layout. You are drawing regions, relationships, and flows. Breadboards accomplish the same thing for non-visual workflows: you list places (screens or states), affordances (buttons, fields, links), and connection lines between them. Both techniques prevent premature commitment to implementation details while still conveying the shape of the solution.
The appetite deserves special attention because it inverts how most teams think about time. Instead of asking "how long will this take?" and getting an estimate, you ask "how much time is this problem worth?" and get a strategic decision. A two-week appetite means you believe the problem is worth solving but only if you can find a narrow solution. A six-week appetite means the problem is important enough to invest a full cycle. If you cannot shape a solution that fits within the appetite, the pitch is not ready. This constraint is the engine of scope management: it forces the shaper to cut scope during shaping rather than discovering scope problems during the build.
Rabbit holes are the hidden risks that could consume disproportionate time. Identifying them during shaping means the building team does not have to discover them under time pressure. A rabbit hole might be a technical integration with unclear API behavior, a design problem with no obvious interaction pattern, or a data migration that could take one day or three weeks depending on edge cases. For each rabbit hole, the shaper either resolves it (by doing enough research to know the answer), removes it (by cutting that part of the scope), or flags it with a recommended approach so the team is not starting from zero.
No-gos complete the picture by stating what you are explicitly not building. Without no-gos, teams expand scope toward adjacent problems because they seem related and small. Writing "we are not building X" makes the boundary visible and gives the team permission to say no during the build. Together, these five elements (problem, appetite, solution, rabbit holes, no-gos) create a pitch that is genuinely actionable. A well-shaped pitch can go straight to the betting table and, if accepted, straight to a building team without any translation layer in between.
Step-by-Step
Step 1: Identify and Frame the Raw Problem
Start with a raw idea, customer complaint, feature request, or strategic opportunity. Your job is to dig beneath the surface request and find the underlying problem. Read through support tickets, sales call notes, or usage data related to the idea. Write the problem as a specific situation: who is affected, what they are trying to do, and why the current product falls short.
Use real language from customers if possible. The output of this step is a two-to-four sentence problem statement that anyone on the team can read and immediately understand. If your problem statement includes a solution ("we need to add a dashboard"), strip the solution out and restate the actual pain ("users cannot see their monthly performance without exporting data and building a spreadsheet").
Tip: Test your problem statement by reading it to someone unfamiliar with the feature request. If they ask "why does that matter?" your framing is too abstract. If they say "oh just add a button for that," your framing is too solution-oriented. The sweet spot is when they say "yeah, that sounds painful."
Step 2: Set the Appetite
Decide how much time this problem is worth before you design a solution. This is a strategic call, not an estimate. Consider the severity of the problem (how many customers hit it, how often, how painful it is), the strategic value (does solving it open a new market or reduce churn), and the opportunity cost (what else could the team build in that time). Appetites in Shape Up typically come in two sizes: small batch (one to two weeks, usually grouped with other small batches in a cycle) and big batch (a full six-week cycle).
" If you find yourself wanting to say "this needs twelve weeks," that is a signal the problem needs to be decomposed into smaller, independently shippable pitches.
Tip: Appetite is not negotiable downward during the build. If you set a six-week appetite and the team discovers the scope is too large, the team cuts scope to fit the time. They do not ask for more time. This constraint only works if the appetite was set honestly, so do not set a two-week appetite for a problem you know requires six weeks just to pressure the team.
Step 3: Sketch the Solution at the Right Altitude
Now design a solution that fits within the appetite. Use fat-marker sketches for interfaces: draw on paper or a whiteboard with a thick marker so you can only capture major elements like regions of a screen, key data displayed, and primary actions available. For workflows and logic, use breadboards: list the places (screens, dialogs, states), the affordances on each place (buttons, form fields, menu items), and draw connection lines showing how actions lead from one place to another. You are not designing the UI.
You are describing the topology of the solution. The output is a set of two to five sketches or breadboards that, taken together, show the complete shape of what you are proposing. Each sketch should be legible to someone who was not in the room when you drew it, so add brief annotations. If you find yourself drawing detailed wireframes with exact layouts and copy, zoom out.
If you find yourself with only a single box labeled "dashboard," zoom in.
Tip: A useful test: can a competent developer look at your sketches and start identifying the major pieces of work? If yes, you are at the right altitude. If they need to ask "but what happens when the user clicks X," your breadboard is missing a connection. If they say "should the button be blue or green," your sketch is too detailed.
Step 4: Walk Through the Solution from the User's Perspective
Take your sketches and breadboards and narrate the experience from the user's point of view. Start with the trigger: what causes the user to encounter this feature? Then walk through each step they take, screen they see, and decision they make. Write this walkthrough in plain language, referencing your sketches as you go.
This narrative serves two purposes. First, it exposes gaps in your solution. You will discover screens you forgot to draw, edge cases you did not consider, and transitions that do not make sense. Second, it makes the pitch readable by people who were not part of the shaping process.
The walkthrough should be three to six paragraphs that a betting table participant can read in five minutes and understand the complete user experience you are proposing.
Tip: If you find the walkthrough getting complicated with many conditional branches ("if the user is an admin then X, but if they are a member then Y, unless they have permission Z"), that complexity is a signal. Either simplify the solution, split the pitch into multiple pitches, or flag the branching logic as a rabbit hole.
Step 5: Identify Rabbit Holes
Review your solution sketches and walkthrough for areas of hidden complexity. Rabbit holes are the parts of the build that could consume disproportionate time relative to their importance. Common sources include: integrations with external systems where API behavior is unclear, data migrations where edge cases are unknown, performance concerns where the volume of data could make a simple approach unworkable, and design challenges where no standard interaction pattern exists. For each rabbit hole, decide on one of three responses.
Resolve it by doing enough research now to have a clear answer (call the API, run a query, build a spike). Remove it by cutting that part of the scope. Or flag it with a recommended approach so the building team starts with your best thinking rather than from scratch. Write each rabbit hole as a short paragraph: what the risk is, why it could be expensive, and your recommended response.
Tip: Ask yourself: "If I were the developer picking this up on day one, where would I get stuck for more than half a day before making visible progress?" Those sticking points are your rabbit holes. If you cannot identify any rabbit holes, you either have not looked hard enough or the pitch is too abstract to reveal them.
Step 6: Define No-Gos
Write a short list of things that are explicitly out of scope. No-gos are features, behaviors, or integrations that someone might reasonably expect to be included but that you are deliberately excluding to keep the solution within appetite. Each no-go should be one sentence stating what is excluded and, optionally, a brief reason. For example: "We are not building a CSV export for this view.
" No-gos serve as a contract between the shaper and the building team. They prevent scope creep by making the boundaries visible and explicit. Without them, a well-meaning developer might spend two days adding a "small" feature that was never part of the shaped solution. Aim for three to seven no-gos per pitch.
If you have zero, you likely have not thought about adjacent features that could expand the scope.
Tip: No-gos are especially important for pitches that touch existing features. The team will naturally see opportunities to improve or refactor nearby code. A no-go like "We are not refactoring the notification system as part of this work" saves days of scope expansion.
Step 7: Assemble the Pitch Document
Combine all elements into a single written document with five clearly labeled sections: Problem, Appetite, Solution, Rabbit Holes, and No-Gos. The pitch should be readable in 10-15 minutes. Use your problem statement from Step 1, your appetite from Step 2, your sketches and walkthrough from Steps 3-4, your rabbit holes from Step 5, and your no-gos from Step 6. Embed or attach your fat-marker sketches and breadboards directly in the document rather than linking to external files, so the pitch is self-contained.
Write a one-sentence summary at the top that captures the pitch in a single line. Store the pitch in whatever format your team uses for asynchronous review (a Basecamp message, a Notion doc, a Google Doc, a markdown file in a repo). The pitch is now ready for the betting table.
Tip: Read the entire pitch from top to bottom as if you are a betting table participant seeing it for the first time. If you need to open a separate document, ask a clarifying question, or refer to a meeting you attended to understand any part of the pitch, revise until the pitch stands on its own.
Step 8: Pressure-Test Before Submitting
Before bringing the pitch to the betting table, share it with one or two trusted colleagues for a quick review. Ideally, one person has technical context and one has product or customer context. Ask them specific questions: Does the problem statement ring true? Does the solution feel achievable within the appetite?
Do the rabbit holes cover the real risks? Are there obvious no-gos missing? Incorporate feedback that strengthens the pitch. If a reviewer raises a concern that invalidates a core assumption (the API does not work that way, customers do not actually have that problem, the data volume is 100x larger than assumed), pause and investigate before submitting.
A pitch that gets rejected at the betting table because of a preventable oversight wastes everyone's time. This review is not a formal approval process. It is a five-to-fifteen-minute sanity check.
Tip: Choose reviewers who will push back, not agree. The worst thing that can happen to a pitch is that it reaches the betting table with a fatal flaw that a five-minute conversation would have caught.
Examples
Example: SaaS Reporting Feature for a Small Product Team
A B2B project management tool with 2,000 active accounts and a four-person engineering team. The most common support ticket category is "how do I see my team's progress this month." The team works in six-week cycles. One product person acts as the shaper.
The shaper reviewed the last 30 support tickets in the reporting category and identified a pattern: team leads want a weekly summary of completed and in-progress work per project, but currently must click into each project individually and count items. " The shaper set a six-week appetite because the problem affects a large segment of paying customers and touches core data models. For the solution, the shaper drew three fat-marker sketches: a new summary view accessible from the main navigation showing project names with progress bars, a detail panel that expands when clicking a project to show completed and active items for the selected week, and a "share" action that generates a read-only link. The breadboard showed: Summary View (affordances: project list, week selector, share button) with connections to Detail Panel (affordances: item list, status filters) and Share Link (affordances: copy URL, set expiration).
Rabbit holes identified: the current database does not index items by completion date (resolution: the shaper ran a test query and confirmed adding an index would take under an hour), and the "share" feature could expand into a full permissions system (resolution: cut to simple expiring link with no authentication). No-gos included: no PDF export, no custom date ranges beyond weekly, no per-person breakdown. The pitch was three pages plus two sketched photos, and the betting table approved it in their next session.
Example: E-Commerce Checkout Flow Improvement for a Mid-Size Team
An online retailer with 50,000 monthly orders, an eight-person product and engineering team, and a checkout abandonment rate of 68%. Analytics show the address entry step has the highest drop-off. The team uses two-week small batches alongside six-week big batches.
The shaper examined session recordings and found that mobile users were abandoning at the address form because it required 11 fields on a single scrolling page with no autofill support. " The shaper set a two-week small batch appetite. The reasoning: this is a high-impact conversion problem, but the solution should be narrow since the team has a six-week project running in parallel. The solution sketch showed a single fat-marker screen: a simplified address form with an address autocomplete field at the top (using a third-party geocoding API the company already pays for but does not use in checkout), followed by only three editable fields (apartment number, phone, delivery instructions).
The breadboard was simple: Checkout Cart connects to Address Step (affordances: autocomplete input, edit fields, continue button) connects to Payment Step. Rabbit holes: the geocoding API returns addresses in a format that may not match the warehouse system's required format (resolution: the shaper tested 20 sample addresses and confirmed the mapping works for US addresses but not Canadian ones). No-gos: no Canadian address support in this batch, no guest checkout changes, no payment step modifications. The pitch was one and a half pages.
The betting table slotted it into the next cycle as a small batch.
Example: Internal Tool for a Large Organization
A 200-person company where the operations team manually reconciles vendor invoices against purchase orders using spreadsheets. The reconciliation takes one full-time employee three days per week. The product team shapes internal tools alongside customer-facing features.
The shaper spent two hours shadowing the operations team member who does reconciliation. The core problem: invoices arrive as PDFs via email, purchase orders live in the ERP, and the employee manually cross-references invoice line items against PO line items in a spreadsheet, flagging discrepancies for the finance director. " The shaper set a six-week appetite because the ROI (recovering 24 hours per week of skilled labor) justified a full cycle investment. The solution used breadboards rather than fat-marker sketches because the tool is workflow-heavy with minimal visual design: Upload Screen (affordances: drag-and-drop PDF upload, PO number lookup) connects to Match Review (affordances: auto-matched line items listed with confidence scores, unmatched items flagged, approve or reject buttons per line) connects to Discrepancy Report (affordances: list of rejected matches, export to ERP format, email to finance director).
The shaper identified three rabbit holes: PDF parsing accuracy for different vendor invoice formats (resolution: tested three PDF parsing libraries against 15 real invoices and found one that handled 13 of 15 correctly, with the two failures being image-based PDFs that would need manual entry), line item matching logic when descriptions differ between invoice and PO (resolution: flagged as needing fuzzy matching but scoped to a simple keyword overlap score rather than ML-based matching), and ERP integration for pushing approved matches (resolution: removed from scope, replaced with CSV export that the ops team can import manually). No-gos: no automatic approval of matches without human review, no image-based PDF support (manual entry fallback), no direct ERP write-back. The pitch was four pages with two breadboard diagrams and became the top-priority bet for the next cycle.
Example: Mobile App Feature for a B2C Startup
A fitness app startup with 15,000 monthly active users and a three-person team (one designer, two engineers). User interviews revealed that people stop using the app after two weeks because they cannot see their progress over time. The team runs four-week cycles instead of six.
The shaper (who is also the founder) re-read transcripts from eight user interviews. " The appetite was set at four weeks (a full cycle for this team). The solution included three fat-marker sketches: a progress tab in the bottom navigation showing a simple line chart of workout frequency per week, a personal records section listing the user's best performance for each exercise type, and a milestone card that appears after completing 10, 25, 50, and 100 workouts. The sketches were intentionally rough, showing only the data displayed and the navigation path, not colors, typography, or exact layout.
Rabbit holes: calculating personal records requires retroactively processing all historical workout data (resolution: the shaper wrote a quick database query and confirmed the dataset is small enough to compute on the fly for current user volumes, with a note to revisit if users exceed 100,000), and the milestone card could expand into a full gamification system (resolution: scoped to four fixed milestones with no badges, streaks, or social sharing). No-gos: no social comparison features, no streak tracking, no coach commentary on progress, no integration with external fitness devices. The pitch was two pages with three phone-sized sketches photographed from a notebook. The team bet on it for their next cycle and shipped it in three and a half weeks.
Best Practices
Write the problem statement before thinking about solutions. Premature solutioning is the most common failure mode in shaping. When you start with a solution ("we need a dashboard"), you anchor on a specific implementation and stop exploring whether the underlying problem could be solved more simply. Force yourself to articulate the pain without referencing any implementation for at least the first 30 minutes of shaping work.
Shape alone or in a pair, never in a group. Shaping requires holding a complex mental model of the problem, the product, and the constraints simultaneously. Committees dilute this focus and produce compromise solutions that satisfy nobody. One or two people should own the pitch. Others can review it, but shaping by consensus produces mediocre pitches.
Use appetite as a creative constraint, not a deadline. The appetite should inform the solution design. If you have a two-week appetite, design a two-week solution. Do not design a six-week solution and then hope the team can squeeze it into two weeks.
The appetite shapes the solution, which is where the framework gets its name. Ignoring this inversion leads to pitches that are perpetually over-scoped.
Keep sketches intentionally rough. The moment a sketch looks polished, reviewers start debating visual details instead of evaluating the shape of the solution. Use paper and thick markers, not Figma. Photograph your sketches and embed the photos. The roughness is a feature, not a limitation. It signals to the building team that implementation details are theirs to decide.
Resolve at least one rabbit hole before submitting. A pitch with nothing but flagged risks and no resolved risks signals that the shaper did not do enough homework. Resolving even one rabbit hole (running a quick database query, testing an API endpoint, spiking a proof of concept) dramatically increases the betting table's confidence that the pitch is buildable.
Write no-gos in the affirmative style ("We are not building X") rather than implied scope ("X is future work"). The phrase "future work" suggests the team should keep X in mind and design around it, which is a form of hidden scope. "We are not building X" is a clearer boundary that prevents gold-plating.
Time-box your shaping work. A pitch for a six-week appetite should take roughly four to eight hours of total shaping effort spread over a few days. If you have been shaping the same pitch for two weeks, the problem is either too complex for a single pitch (split it), too ambiguous (do more customer research first), or you are going too deep into implementation details (zoom out).
Include at least one concrete customer scenario in the problem section. Abstract problem statements ("users struggle with reporting") are easy to dismiss. A concrete scenario ("A regional manager with 12 locations currently exports CSV files from each location, merges them in Excel, and sends a screenshot to their VP every Monday morning") makes the problem visceral and testable.
Common Mistakes
Writing a specification instead of a pitch
Correction
The most common mistake is going too deep into implementation details: exact field names, pixel-level layouts, API endpoint structures, database schemas. This happens because shapers with technical backgrounds default to the level of detail they are comfortable producing. The signal to watch for is when your pitch exceeds five pages or when you catch yourself making decisions that the building team should make (which JavaScript library to use, how to structure the database query). Zoom out to fat-marker altitude.
Describe what the user sees and does, not how the system implements it.
Skipping the problem statement and jumping straight to the solution
Correction
When the solution feels obvious, shapers skip the problem framing entirely. The pitch opens with "We should build X" without explaining why. This creates two risks: the betting table cannot evaluate whether X is the right solution because they do not understand the problem, and the building team cannot make intelligent scope tradeoffs because they do not know what outcome matters. Watch for pitches where removing the first section would not change a reader's understanding.
If so, the problem framing is decorative, not functional. Rewrite it to stand on its own as a compelling case for action.
Setting appetite as a disguised estimate
Correction
Teams new to Shape Up often treat appetite-setting as estimation by another name. They design a solution, estimate how long it would take, and call that estimate the appetite. This defeats the purpose. Appetite is a business decision made before the solution is designed, and the solution is then shaped to fit within it.
The telltale sign is when every pitch has a six-week appetite regardless of problem severity, or when the appetite mysteriously matches whatever the team estimated. Force yourself to set the appetite before sketching the solution, and treat it as a genuine ceiling, not a target.
Ignoring rabbit holes because the solution feels simple
Correction
Simple-looking solutions often hide the most dangerous rabbit holes because nobody looks for them. A pitch to "add a search bar" sounds simple until the team discovers the database is not indexed for text search, the product has three different data models that need to be searched simultaneously, and users expect fuzzy matching. The fix is to spend at least 20 minutes per pitch specifically hunting for rabbit holes by asking: what third-party dependencies does this touch, what data volume or performance concerns exist, what edge cases in the current system might interact with this change. If you genuinely find zero rabbit holes, include a note explaining why, so the betting table knows you looked.
Shaping as a committee with too many stakeholders
Correction
When three or more people shape together in real-time, the pitch becomes a negotiated compromise. Each person adds their preferred scope, nobody cuts anything, and the solution grows beyond the appetite. The result is a pitch that tries to please everyone and solves nothing cleanly. Shaping should be done by one person or a close pair (usually a product-minded person and a technically-minded person).
Others review the pitch asynchronously. If you notice your shaping sessions regularly involve four or more people debating at a whiteboard, you have a process problem. Let one person own the pitch and bring it to others for critique after the first draft.
Treating no-gos as optional or leaving the section empty
Correction
An empty no-gos section does not mean everything is in scope. It means scope boundaries are invisible, which is worse. " Every pitch should have at least three no-gos. If you struggle to write them, look at the feature area you are touching and list the adjacent features or improvements that a well-intentioned developer might tackle.
Then explicitly exclude them.
Other Skills in This Method
Managing Six-Week Build Cycles
How to structure and execute fixed-time build cycles including setting appetites, forming small teams, and enforcing the circuit breaker when time runs out.
Planning Cool-Down Periods
How to structure the cool-down period between cycles for bug fixes, technical debt, exploration, and preparing the next round of shaped work.
Setting Appetites and Cutting Scope
How to set a time appetite for a project and then deliberately cut scope and identify must-haves versus nice-to-haves to fit within the fixed timebox.
Tracking Progress with Hill Charts
How to use hill charts to visualize whether scopes are in the uphill (figuring it out) or downhill (executing) phase and communicate progress without status meetings.
Running Betting Table Sessions
How to facilitate the betting table meeting where stakeholders review shaped pitches and decide which projects to commit to in the next cycle.
Mapping Scopes Instead of Tasks
How to organize work into meaningful scopes — integrated slices of front-end and back-end work — instead of traditional task lists during the building phase.
Using Breadboards and Fat-Marker Sketches
How to use breadboarding for flow design and fat-marker sketching for visual concepts to define solutions at the right level of abstraction during shaping.
Frequently Asked Questions
How long should a shaped pitch document be?
A typical pitch runs two to five pages including embedded sketches. The five sections (problem, appetite, solution, rabbit holes, no-gos) should each be concise. If your pitch exceeds five pages, you are likely going too deep into implementation details. The test is whether a betting table participant can read and evaluate the pitch in 10-15 minutes. If it takes longer, cut detail from the solution section and move implementation specifics into rabbit holes or remove them entirely.
Should I shape a pitch before or after talking to the betting table?
Shape first, then bring the finished pitch to the betting table. The betting table evaluates completed pitches, it does not co-create them. If you bring a half-formed idea to the betting table, you will get opinions instead of decisions. The only exception is when you need the betting table to confirm appetite before investing shaping time. In that case, a one-paragraph problem statement with a proposed appetite is enough to get a directional "worth shaping" or "not now" signal.
How do I write a shape up pitch template when I lack technical knowledge?
You do not need to be a developer, but you need enough technical literacy to know what is roughly feasible and where complexity hides. If you lack this context, pair with a senior developer during the rabbit hole identification step. Share your sketches and walkthrough and ask: "Where would you get stuck? " The developer should not co-design the solution. They should pressure-test your assumptions about feasibility. If pairing is not possible, err on the side of flagging more rabbit holes and let the building team resolve them.
What if my pitch gets rejected at the betting table?
Rejection is normal and expected. Not every pitch gets bet on, and many pitches are deferred rather than permanently rejected. If deferred, the pitch goes back into the pool and can be re-evaluated in a future cycle. If rejected outright, ask for the specific reason: was the problem not compelling enough, the appetite too large, the solution too risky, or was there a competing priority? Use that feedback to reshape or retire the pitch. Do not take rejection personally. The betting table is choosing between competing investments, and a good pitch at the wrong time is still a good pitch.
Can I shape multiple solutions for the same problem?
Yes, and it is sometimes the right move. If you can see two credible solutions at different appetite levels (a two-week version and a six-week version), present both as separate pitches. This gives the betting table a genuine choice between investment levels. However, do not present three or four options hoping the table will pick one. That shifts the shaping burden to the betting table. Two options with clear tradeoffs is the maximum. Each option must be a complete pitch with its own solution sketches, rabbit holes, and no-gos.
How does shaping differ from writing user stories or a PRD?
User stories describe desired behavior from the user's perspective but do not constrain scope, identify risks, or sketch a solution. A PRD specifies detailed requirements but removes the building team's autonomy to make implementation decisions. A shaped pitch sits between the two: it provides enough direction that the team knows where to start and can see the finish line, but leaves enough open space that the team makes tactical decisions during the build. The appetite replaces the estimate, the sketch replaces the wireframe, and rabbit holes replace the assumption that someone else will handle the hard parts.
Why does my pitch keep growing beyond the appetite during shaping?
This usually means you are solving a problem that is too broad or you are including adjacent improvements that belong in separate pitches. The fix is to narrow the problem statement. Instead of "improve the reporting experience," try "let team leads see a weekly cross-project summary." Each time you add scope to the solution, ask: "Is this required to solve the problem I stated, or is this a separate problem?" If it is separate, move it to a future pitch idea list. If you consistently cannot fit solutions within your appetite, your appetites may be too small for the problems you are tackling, which is a strategic conversation for the betting table.