Running a Shape Up Betting Table Session
This skill teaches you how to facilitate the betting table meeting where senior stakeholders review shaped pitches, weigh strategic fit and risk, and commit specific teams to specific projects for the upcoming cycle.
Gather 2-4 senior stakeholders who have pre-read the shaped pitches. Walk through each pitch, discuss appetite and risk, then make a binary bet or pass decision for each one. The session should take 1-2 hours and produce a committed list of projects for the next cycle, with each bet matched to a dedicated team. No backlogs survive the table. Every pitch is evaluated fresh.
Outcome: You produce a firm, committed cycle plan where every approved pitch is matched to a dedicated team, every rejected pitch is cleanly discarded (not deferred to a backlog), and every participant leaves with absolute clarity on what the next cycle contains and why.
Prerequisites
- Understanding of the Shape Up cycle structure (shaping, betting, building, cool-down)
- At least 2-3 shaped pitches ready for review (see shaping-product-pitches)
- Familiarity with the concept of appetites and fixed time, variable scope
- Knowledge of available teams and their capacity for the upcoming cycle
Overview
The betting table is the decision point in Shape Up where shaped pitches either get funded with a team and a time box or get dropped entirely. It is not a prioritization meeting, a backlog grooming session, or a roadmap review. It is a deliberate, high-stakes commitment ceremony. The small group of senior stakeholders (typically 2-4 people with the authority to allocate teams) reviews each shaped pitch, debates its strategic value and risk profile, and makes a binary decision: bet or pass. There is no "maybe later" pile. This is what separates the betting table from traditional sprint planning or quarterly OKR reviews. Projects that don't get bet are not queued. They return to the pool of potential ideas, and if they still matter next cycle, someone will shape them again, often better the second time.
The concrete artifact produced by a betting table session is a cycle plan: a short list (typically 1-3 projects, sometimes more for smaller bets) with each project explicitly assigned to a named team. The cycle plan also specifies the appetite for each project, which is the maximum time the team will spend before the work must ship or get cut. This artifact becomes the single source of truth for the entire organization during the upcoming build cycle. There are no surprise additions mid-cycle. There are no scope negotiations after the table closes. The cycle plan is a commitment, and the betting table is where that commitment gets made.
Running this session well requires a specific facilitation skill set. You need to keep the conversation strategic, not tactical. You need to prevent the group from redesigning pitches on the fly. You need to ensure that every pitch gets a fair hearing without letting any single pitch consume the entire session. And you need to close with firm decisions, not tentative consensus. The betting table is where organizational discipline meets product intuition, and the facilitator's job is to hold the space for both.
How It Works
The betting table works because it compresses a diffuse, ongoing prioritization problem into a single, time-boxed decision event. Most organizations struggle with prioritization because it happens continuously and informally. Features get added to backlogs. Stakeholders lobby for pet projects in hallway conversations. Priority shifts week to week based on whoever spoke loudest in the last meeting. The betting table eliminates this by creating a clear boundary: decisions happen here, at this moment, with these people, using these inputs. Everything outside this boundary is noise.
The mechanism relies on three structural constraints working together. First, the inputs are pre-shaped. Pitches arrive at the table already defined at the right level of abstraction, with a clear problem statement, a proposed solution direction, identified rabbit holes, and an explicit appetite. This means the table does not waste time defining what a project would look like. That work was done during the shaping phase. The table's job is purely evaluative: given this shaped pitch, is it worth betting a team on for this cycle?
Second, the decision is binary and irreversible for the cycle. You bet or you pass. There is no "start it and see how it goes." There is no splitting a pitch across two half-staffed teams. A bet means a full team, fully committed, for the full appetite window. A pass means the pitch disappears. It does not go into a backlog. This constraint forces honest evaluation. When you cannot hedge, you evaluate more carefully.
Third, the decision-makers have skin in the game. The people at the betting table are the same people accountable for the outcomes. They are not advisory. They are not delegates. They are the CEO, CTO, VP of Product, or whoever holds genuine authority to allocate teams. This keeps the conversation grounded in real constraints (available teams, strategic priorities, business context) rather than abstract value scoring. The betting table is a leadership ritual, not a committee process.
The mental model to internalize is that the betting table is a portfolio allocation decision, not a feature selection exercise. You are allocating your scarcest resource (dedicated team time for a full cycle) across competing investment opportunities (shaped pitches). Each bet carries risk: the project might not ship, the problem might be less important than it seemed, the solution might not land with customers. The table's job is to place bets that maximize expected value given current information, knowing that some bets will not pay off. This framing prevents two common failure modes: analysis paralysis (trying to guarantee outcomes before committing) and consensus-seeking (trying to make everyone happy instead of making tough tradeoffs).
Step-by-Step
Step 1: Set the Cycle Context Before Anything Else
Before reviewing any individual pitch, open the session by establishing the constraints and strategic context for this specific cycle. State how many teams are available, what the appetite window is (typically six weeks), and any overriding strategic priorities or constraints. For example: "We have three teams available. One is finishing cool-down from a large project and may need lighter work.
" Also note any carry-over commitments, like a project that was explicitly given a second cycle during the last betting table. This context-setting should take 5-10 minutes and ensures every subsequent pitch discussion happens against the same backdrop. Without it, each stakeholder will evaluate pitches against their own private mental model of what matters, leading to circular debates.
Tip: Write the constraints on a shared screen or whiteboard where everyone can see them throughout the session. When debates stall, point back to the constraints. They resolve most disagreements faster than discussion.
Step 2: Distribute Shaped Pitches 24-48 Hours Before the Session
Send every shaped pitch to every betting table participant at least one full business day before the session. Each pitch should include the problem statement, the proposed solution (with breadboards or fat-marker sketches), identified rabbit holes and no-go areas, and the requested appetite. Make it explicit that participants are expected to arrive having read every pitch. The pre-read is non-negotiable.
If someone shows up without reading, they should listen but not drive decisions, because uninformed opinions waste the table's time and lead to surface-level objections that the pitch document already addresses. Include a brief cover note that lists all pitches with one-sentence summaries and the total number of team-slots available, so participants can begin forming their mental portfolio before arriving.
Tip: If you have more than 5-6 pitches, flag the 2-3 that the shaping team considers strongest. This is not to bias the decision but to help participants allocate their pre-read attention. People will skim if everything looks equal.
Step 3: Present Each Pitch with a Strict Time Box
Walk through each pitch one at a time. The pitch author or a designated presenter gives a 5-minute summary: the problem, the shaped solution, the appetite, and the key risks. Then open 10-15 minutes for questions and discussion. The facilitator's job during discussion is to keep the conversation at the strategic level.
" are productive. " are out of bounds, because they are redesigning the pitch at the table, which undermines the entire shaping process. If a pitch needs significant redesign, the correct outcome is to pass on it and send it back for reshaping.
Tip: Use a visible timer. When discussion runs long on one pitch, it almost always means the pitch is not shaped well enough. Note the concern, table it, and move on. You can revisit after all pitches have been heard.
Step 4: Surface Risks and Rabbit Holes Explicitly
" This is where the CTO or technical leader earns their seat at the table. They should flag integration risks, infrastructure dependencies, or known complexity traps. The goal is not to solve these problems at the table but to assess whether they are manageable within the appetite or whether they make the bet too risky. A pitch with one significant rabbit hole might still be worth betting on if the team can timebox the exploration.
A pitch with three unresolved unknowns is probably not shaped well enough. Document the key risks identified for each pitch, because the team that picks up the project will need them.
Tip: Ask the most skeptical person at the table to speak first on risks. If the CTO thinks something is straightforward, ask the designer. If the designer is confident, ask about data or compliance. Optimism bias is the biggest risk at a betting table.
Step 5: Make the Bet or Pass Decision for Each Pitch
After all pitches have been presented and discussed, return to each one for a final decision. The decision is binary: bet (commit a team and the stated appetite) or pass (the pitch leaves the table entirely). There is no "maybe" category, no parking lot, no backlog. For each bet, specify which team will take it.
" The decision-maker with the most authority should make the final call when the table cannot reach natural agreement, but in practice most betting tables reach consensus quickly because the pre-read and discussion have already surfaced the key considerations. If you find yourself with more good pitches than available teams, resist the urge to squeeze in an extra project. Overcommitting is the most common betting table failure mode.
Tip: If a pitch is a pass, say so clearly and move on. Do not spend 15 minutes softening the rejection. The pitch author is usually not at the table, and even if they are, a clean pass with a clear reason is more respectful than a vague deferral.
Step 6: Match Bets to Specific Teams
Once the bets are placed, assign each project to a specific team. This is not arbitrary. ). Each team should receive exactly one bet, or occasionally one large bet and one small bet if the appetites allow it.
Never split a team across two full-appetite projects. The team assignment is part of the commitment, and changing it mid-cycle undermines the entire model. Write the team assignments down as part of the cycle plan.
Tip: If possible, let teams have some input on which bet they take. A team that is excited about a problem will outperform a team that was assigned one. But do not let this devolve into a negotiation. The table decides, and team preference is one input among several.
Step 7: Document and Communicate the Cycle Plan
Immediately after the session, write up the cycle plan and distribute it to the entire product and engineering organization. The cycle plan should list each bet with its pitch summary, appetite, assigned team, and key risks identified at the table. It should also list the pitches that were passed on, with brief rationale. This transparency serves two purposes: it gives building teams everything they need to start their cycle, and it shows the rest of the organization that decisions were made deliberately with clear reasoning.
The cycle plan should be a short document, not a slide deck. One page per bet is more than enough. Post it where everyone can find it. This document is the contract for the cycle.
Tip: Include the pitches that were passed on in the communication. This prevents people from lobbying to sneak rejected work into the cycle and demonstrates that the betting table takes all proposals seriously even when it says no.
Step 8: Close the Table and Protect the Cycle
Once the cycle plan is communicated, the betting table is closed. No new work enters the cycle. No bets are changed. No scope is added to existing bets.
If an emergency arises (a critical production issue, a major customer escalation), the standard response is to handle it during the cool-down period or, in truly exceptional cases, to cancel a bet entirely and reallocate the team. The facilitator's job extends beyond the session itself: they are the guardian of the cycle boundary. " This discipline is what makes the entire Shape Up framework function. Without it, the betting table becomes a suggestion box.
Tip: Establish a clear escalation path for genuine emergencies before the cycle starts. If someone has to make a judgment call about pulling a team off a bet, decide in advance who has that authority. It should be the same person who ran the betting table.
Examples
Example: Early-Stage SaaS with Two Engineering Teams
A 15-person B2B SaaS startup has two engineering teams of three (one designer, one frontend dev, one backend dev each). The company is pre-Series A with 50 paying customers. Three pitches have been shaped for a six-week cycle: a new onboarding flow redesign (six-week appetite), an API rate-limiting feature requested by three enterprise prospects (two-week appetite), and a dashboard analytics overhaul (six-week appetite). The CEO, CTO, and Head of Product sit at the betting table.
The session opens with context: two teams available, Q2 goal is reducing churn and improving activation. The CEO notes that three enterprise prospects have specifically mentioned the API rate-limiting feature in sales calls. The group reviews the onboarding flow pitch first. The CTO confirms low technical risk, and the pitch aligns directly with the activation goal.
Bet: Team A takes onboarding. The API rate-limiting pitch gets discussed next. It is only a two-week appetite, which means Team B would have four weeks unallocated. The CTO suggests pairing it with the remaining cool-down work from last cycle plus some technical debt.
Bet: Team B takes rate-limiting for two weeks, then shifts to a pre-shaped small bet on improving the data export feature (also two-week appetite) that was prepared as a backup pitch. The dashboard analytics pitch is a pass. The Head of Product notes it is important but less urgent than activation, and without a dedicated team available, betting on it would require splitting Team A. The cycle plan is documented in 30 minutes: Team A on onboarding (six weeks), Team B on rate-limiting then data export (two plus two weeks, with two weeks of cool-down buffer).
The dashboard pitch is not added to any backlog. The Head of Product decides to reshape it with sharper scope for the next cycle.
Example: Growth-Stage Product Team with Five Squads
A 200-person company with five product squads (each with a PM, designer, and 2-3 engineers) runs betting tables every six weeks. Seven pitches have been shaped. The VP of Product, CTO, and CEO sit at the table. One squad is finishing a multi-cycle project that was explicitly given a second six-week window at the last betting table. Four squads are available for new bets.
Pre-read was sent three days before the session. The VP of Product flagged the top three pitches based on strategic alignment with annual goals. The session opens with the constraint: four teams available, annual priority is expanding into the mid-market segment. The seven pitches are reviewed in order of strategic alignment.
Pitch 1 (mid-market permissions model, six-week appetite) is bet immediately. Team 2 gets it based on their experience with the auth system. Pitch 2 (improved reporting for mid-market, six-week appetite) is bet and assigned to Team 3. Pitch 3 (self-serve billing changes, three-week appetite) is bet as a small bet for Team 4 alongside a two-week infrastructure pitch.
The remaining three pitches are evaluated: one is passed because the technical risk is too high (CTO flags an unresolved dependency on a third-party migration), one is passed because it targets the enterprise segment which is not the current priority, and one is passed because it is a "nice to have" that does not move any key metric. Team 5 (the carry-over team) continues its multi-cycle project. The session takes 90 minutes. The cycle plan is emailed company-wide before end of day with all five team assignments and the three passes with reasons.
Example: Agency Running Shape Up for Client Projects
A digital product agency with 20 people uses Shape Up internally. They have three delivery teams. The betting table happens every six weeks and includes the two co-founders and the Head of Delivery. The pitches mix client projects (revenue-generating) and internal tool improvements. Five pitches are on the table: two client projects, one internal tool rebuild, one marketing website redesign, and one experimental AI feature.
The session starts with financials: two client projects represent $180K in committed revenue. The internal tool rebuild would save an estimated 5 hours per week across all teams. The marketing redesign supports a new positioning launched last month. The AI feature is speculative but could differentiate the agency in pitches.
The co-founders immediately bet both client projects (non-negotiable revenue commitments). Team 1 takes the larger client project, Team 2 takes the smaller one. The real debate is about Team 3. The Head of Delivery advocates for the internal tool, citing team frustration and cumulative time savings of 250+ hours annually.
Co-founder A pushes for the marketing site, arguing it supports the repositioning effort. Co-founder B is interested in the AI experiment. After 20 minutes of discussion, they bet on the internal tool rebuild. The reasoning: team retention is at risk due to tooling frustration, and the time savings compound every cycle.
The marketing site is passed with a note that it should be reshaped as a smaller bet (two-week appetite targeting only the homepage and services page instead of a full redesign). The AI experiment is passed because nobody could articulate a clear problem statement, which means it was not actually shaped. The session finishes in 75 minutes.
Example: Remote-First Team Running an Asynchronous Pre-Round
A fully remote company across four time zones has three product teams. Running a synchronous betting table is difficult because no single time slot works well for the CEO (San Francisco), CTO (Berlin), and VP of Product (Singapore). They have adapted the betting table format to include an asynchronous pre-round followed by a shorter synchronous session.
Three days before the live session, the VP of Product posts four shaped pitches in a shared document with a structured comment template: Strategic Fit (1-5), Risk Assessment (1-5), Questions, and Initial Recommendation (bet/pass/need discussion). Each stakeholder completes their assessment independently within 48 hours. " The fourth pitch is split: the CTO rates it high-risk due to a database migration, while the CEO and VP of Product both rate it as a strong strategic fit. The synchronous session is scheduled for 45 minutes at the least-bad overlapping time.
The two unanimous bets are confirmed in the first 5 minutes and assigned to teams. The unanimous pass is acknowledged. The remaining 35 minutes focus entirely on the contested pitch. The CTO walks through the specific migration risk, and the group decides the pitch needs reshaping to isolate the migration into a separate, smaller project.
The pitch is passed. The session produces a cycle plan with two bets and one team on cool-down plus small maintenance work. Total synchronous meeting time: 40 minutes instead of the typical 90-120 minutes, because the async pre-round eliminated discussion on three of four pitches.
Best Practices
Keep the table small: 2-4 people maximum. Every additional participant slows decision-making exponentially. The right attendees are people who have the authority to allocate teams and the context to evaluate strategic fit. If someone needs to be "in the loop" but does not hold allocation authority, share the cycle plan with them afterward.
Larger groups drift toward consensus-seeking and away from decisive commitment.
Enforce the pre-read ruthlessly. If participants have not read the pitches, the session degrades into a pitch presentation meeting where decisions get made based on the presenter's charisma rather than the substance of the shaped work. Send pitches 24-48 hours before the session, confirm receipt, and open the session by asking if anyone has questions about the pitches they read, not by re-summarizing them.
Never redesign a pitch at the betting table. " the pitch is either not shaped well enough or the table is overstepping its role. The correct response is to pass on the pitch and send it back for reshaping. The betting table evaluates shaped work.
It does not produce it. Blurring this boundary wastes everyone's time and produces half-baked commitments.
Leave at least one team unallocated if possible. This creates slack in the system for cool-down work, bug fixes, small improvements, and emergencies. If you fill every team slot with a full-appetite bet, you have zero capacity to handle surprises, and surprises always happen. A team on cool-down between bets is not wasted capacity.
They are doing essential maintenance work that keeps the product healthy.
Time-box the entire session to 2 hours maximum. If you cannot make decisions in 2 hours, you either have too many pitches (pre-filter before the session), too many people (reduce the table), or pitches that are not shaped well enough (send them back). Sessions that drag past 2 hours produce worse decisions because fatigue sets in and participants start agreeing just to end the meeting.
Track batting average over time. After each cycle, note which bets shipped successfully within appetite and which did not. Over 4-6 cycles, you will see patterns: certain types of pitches consistently underperform, certain risk factors predict blowups, certain team compositions work better for certain project shapes. This data makes future betting tables smarter.
Without it, you are placing bets with no feedback loop.
Separate the betting table from status updates and retrospectives. The betting table has one purpose: deciding what to build next cycle. If you mix in updates on the current cycle, retrospective discussions, or strategic planning, the session loses focus and runs long. Hold those conversations separately. The betting table should feel crisp and decisive, not sprawling and exhausting.
Common Mistakes
Treating the betting table as a backlog grooming session and deferring rejected pitches to a "future" list.
Correction
This is the most common mistake and the one that most fundamentally undermines Shape Up. When you keep a backlog, rejected pitches accumulate. Stakeholders start lobbying for their deferred items. The betting table becomes a negotiation over queue position rather than a fresh evaluation of current opportunities.
The fix is simple and uncomfortable: pitches that do not get bet are discarded completely. If a problem is genuinely important, it will resurface naturally. Someone will reshape it, often with better information, and bring it back to a future table. Problems that do not resurface were not as important as they seemed.
Inviting too many people to the betting table, turning it into a committee review.
Correction
Large groups cannot make decisive allocation decisions. What happens is predictable: each person advocates for the pitch closest to their function, nobody wants to be the person who kills a colleague's pitch, and the session ends with vague consensus to "try to do all of them." This overcommits teams and dilutes focus. Keep the table to 2-4 people who have genuine authority to allocate teams. You can detect this mistake when betting table sessions regularly run over 2 hours or when decisions feel tentative and require follow-up confirmation from someone who was not in the room.
Betting on pitches that are not fully shaped, assuming the team will figure out the details.
Correction
Unfinished pitches at the betting table lead to one of two bad outcomes: the team spends weeks of their cycle doing shaping work that should have been done before the table, or the team builds something that does not solve the right problem because the problem was never clearly defined. " questions at the table. If the table is asking how, the pitch is not shaped. Pass on it and send it back.
A well-shaped pitch answers how at the appropriate level of abstraction, leaving room for the building team to make implementation decisions without requiring them to make strategic ones.
Splitting teams across multiple bets to "get more done" in a single cycle.
Correction
This violates the fundamental Shape Up principle that a bet gets a dedicated team for the full appetite. When you split a team, each project gets half the attention and takes twice as long, which means neither project ships within the appetite. The math does not work because of context-switching overhead, coordination costs, and the loss of flow state. If you have more good pitches than teams, make a harder choice at the table.
Bet on fewer things and commit fully. You will ship more total value over several cycles than you would by splitting attention every cycle.
Allowing scope to creep into bets after the table closes, treating the cycle plan as a starting point rather than a commitment.
Correction
Post-table scope additions are a symptom of insufficient trust in the process. " The facilitator must protect the cycle boundary aggressively. " If you allow exceptions, you teach the organization that the betting table is advisory, not authoritative, and participation and preparation quality will decline. Track how often mid-cycle additions happen.
If it is frequent, the root cause is usually insufficient shaping, because important aspects were missed before the table.
Spending the entire session on the first one or two pitches and rushing through the rest.
Correction
This happens when the facilitator does not enforce time boxes. The first pitch gets a thorough, thoughtful discussion. The second pitch gets a good review. By the fourth pitch, people are fatigued and just want to finish.
The later pitches get worse evaluations, which means your cycle plan is partially well-considered and partially rubber-stamped. Set a hard 15-20 minute maximum per pitch (5 minutes presentation, 10-15 minutes discussion). If a pitch needs more time, it probably needs more shaping. Note the unresolved questions and move on.
You can revisit after all pitches have been heard, which often resolves debates because later pitches provide comparative context.
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.
Shaping Product Pitches
How to define problems, set appetites, and craft shaped pitches with fat-marker sketches and breadboarding before committing engineering resources.
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.
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 many shaped pitches should we bring to a shape up betting table session?
5 to 2 times the number of available team slots. If you have three teams, bring 5-6 pitches. Fewer than that and you lack real choice, which means the table is rubber-stamping rather than evaluating. More than 8-10 pitches overwhelms the session and leads to superficial evaluation of later items. If you consistently have far more pitches than slots, it means your shaping process is not filtering enough, and you should add a pre-screening step before pitches reach the table.
What happens if a bet fails and the team does not ship within the appetite?
The default outcome is that the work stops. The appetite was the maximum investment, and if the team could not ship within it, the project either had unresolved complexity (a shaping problem) or encountered genuinely unexpected obstacles. The project does not automatically get a second cycle. If stakeholders still believe the problem matters, someone brings a reshaped version to the next betting table with lessons from the first attempt incorporated. Occasionally, for large strategic projects, the original betting table can explicitly pre-approve a second cycle, but this should be the exception, not the norm.
Should the people who shaped the pitches attend the betting table?
Generally no, unless they are also senior stakeholders with allocation authority. The shaper's job is done once the pitch is written. If shapers attend, two problems emerge: they become defensive about their pitches, which makes honest evaluation harder, and they get pulled into tactical design discussions at the table, which wastes time. The pitch document should stand on its own. If the table cannot evaluate a pitch without the shaper present to explain it, the pitch is not shaped well enough. One exception: if the shaper is the CTO or VP of Product who would attend anyway, they should present their pitches but explicitly invite pushback.
How do we handle urgent customer requests that come in mid-cycle after the betting table has closed?
The standard answer is: bring it to the next betting table. If the request is truly urgent (a production outage, a security vulnerability, a contract-threatening issue for a top customer), it gets handled during the cool-down capacity or by pulling a team off a bet entirely. The key is that pulling a team off a bet is a big, visible decision made by the same people who sit at the betting table, not a quiet side-channel addition. If "urgent" requests are disrupting cycles frequently, the root cause is usually a lack of trust in the process. Track how many mid-cycle interruptions happen per cycle and review at the retrospective.
Should we use the betting table to decide which bugs to fix or only for new features?
The betting table is for shaped work, and shaped work can absolutely include bug fixes if the bug is significant enough to warrant shaping. A critical performance issue that affects 40% of users deserves a shaped pitch with a clear problem statement, proposed solution approach, and appetite. What does not belong at the betting table is a list of 50 minor bugs. Those are handled during cool-down periods or by on-call rotations. The dividing line is effort and impact: if fixing the bug requires more than a few days of focused work and solves a meaningful user problem, shape it and bring it to the table.
How long should the betting table take for a team that is new to Shape Up?
Expect your first few sessions to take 2-3 hours as participants learn the format and resist old habits (backlog thinking, scope expansion at the table, consensus-seeking). By the third or fourth cycle, sessions typically tighten to 60-90 minutes. If sessions are still running over 2 hours after several cycles, diagnose the bottleneck: too many pitches (pre-filter), too many attendees (reduce the table), insufficiently shaped pitches (improve shaping quality), or a facilitator who is not enforcing time boxes. The session length is a leading indicator of process health.
Can we run a betting table for two-week cycles instead of six-week cycles?
You can, but the economics change significantly. With two-week cycles, you run a betting table every two weeks, which means more process overhead relative to building time. You also limit the size of problems you can tackle, because two weeks is not enough time for most meaningful product work. The [Shape Up](/methods/shape-up) framework recommends six-week cycles specifically because they are long enough to build something substantial but short enough to maintain urgency. If six weeks feels too long, the problem is usually insufficient shaping (teams are uncertain about what to build) rather than the cycle length itself. Try a few six-week cycles with well-shaped pitches before concluding you need shorter ones.