Lenny's PodcastRyan Singer: Why appetite beats estimates in Shape Up's plan
Through six-week appetites and shaping sessions with engineers in the room; Shape Up teams stop shredding scope into tickets nobody understands.
CHAPTERS
- 0:00 – 4:48
Renovation analogy + the Shape Up premise: start only when you can “see the end”
Ryan opens with a vivid home-renovation analogy: beautiful plans are useless if you haven’t checked what’s behind the walls. That sets up the core Shape Up idea—don’t start work until the team can confidently visualize what “done” looks like, and use a fixed time appetite to shape scope to fit.
- •Shaping is about surfacing hidden complexity before committing
- •Rejects “big concept → estimate” in favor of “fixed time appetite → shape scope”
- •Requires a shared artifact engineers/design/product all understand
- •Goal: clarity that allows a project to finish within a committed timebox
- 4:48 – 10:07
Why Shape Up resonated: teams want alternatives to Scrum/SAFe and safer ways to ship
Lenny frames the episode as a deep dive into an increasingly popular alternative to Agile/Scrum. Ryan notes adoption has been mostly word-of-mouth because leaders are reluctant to publicly admit shipping struggles—yet many organizations feel stuck and are searching for a different operating model.
- •Growing interest since the 2019 book release
- •Shipping struggles are common but rarely discussed openly
- •Shape Up appears as a rare, coherent alternative to Scrum/Kanban/Waterfall
- •Episode goal: give practical guidance to try Shape Up
- 10:07 – 16:28
Ryan’s early Basecamp years: constraints (10 hours/week) and urgency shaped the method
Ryan recounts building Basecamp in the earliest days with intense pressure to make progress and finish meaningful slices. Limited engineering availability (DHH at ~10 hours/week) and founder urgency pushed the team toward clarity, tight collaboration, and minimizing wasteful rework.
- •Early team worked like a startup: fast feedback, high urgency, low tolerance for drift
- •Engineering time scarcity forced better decision-making up front
- •Avoiding waste (build the wrong thing, throw it away, restart) became a priority
- •The roots of “shaping” came from short, intense collaborative sessions
- 16:28 – 19:03
From organic startup flow to formal Shape Up: the first time a project ‘dragged’
As the company grew slowly, the original way of working spread naturally—until a project didn’t converge and nobody could see the end. That moment triggered the need to systematize what made projects succeed, so new hires could reproduce the same shipping reliability.
- •Slow hiring delayed process needs, but didn’t eliminate them
- •A problematic project revealed “we can’t see the end” as a critical failure mode
- •The need: make successful behaviors repeatable across more people
- •Ryan took responsibility for formalizing the framework that became Shape Up
- 19:03 – 27:18
The three pillars of Shape Up: appetite, shaping, and empowered building
Ryan outlines Shape Up’s core structure: set an appetite (time budget), shape a concrete solution that fits, then hand a coherent project to a team to execute with autonomy. The build phase avoids shredding work into ticket soup up front and instead lets builders create tasks with full context.
- •Appetite: decide the maximum time you’re willing to spend before starting
- •Shaping: collaboratively design a solution that fits the appetite
- •Build: hand off a whole idea, not 100 pre-written tickets
- •Outcome: more ownership, less ritual overhead, fewer mid-build clarifications
- 27:18 – 29:32
Six weeks is a ceiling, not a rule: when shorter timeboxes make sense
Lenny probes the six-week cadence; Ryan clarifies it’s an upper limit that forces hard tradeoffs and makes uncertainty manageable. Teams can use shorter appetites (e.g., two weeks) when the work is naturally smaller, but larger value-adding features often need longer than sprint-sized bites to feel “done.”
- •Six weeks as a maximum improves predictability and shaping quality
- •Shorter appetites work for growth/rapid experiments (avoid bundling)
- •Avoids endless “one more sprint” cycles for substantial features
- •Key is choosing a timebox that allows a meaningful, shippable outcome
- 29:32 – 38:56
What happens when projects miss the appetite: circuit breaker vs. ‘back to shaping’
They explore the tricky reality of overruns: simply cutting scope at the end can destroy value and morale, while canceling outright (the “circuit breaker”) is hard for most organizations. A pragmatic middle path is to stop building, return to shaping, and re-clarify what was misunderstood before reinvesting.
- •End-of-timebox cuts can ship something meaningless and demoralizing
- •True circuit breaker (cancel) is effective but hard to stomach culturally
- •Better fallback: remove from build mode and bring it back to shaping mode
- •Focus on diagnosing fuzziness/unknowns rather than blindly extending time
- 38:56 – 46:36
What ‘shaping output’ really is (and isn’t): not PRDs, not polished Figma, but a buildable concept
Ryan contrasts common failure modes—PRDs and high-fidelity designs created without engineering—against what shaping should produce. The right output is a clear diagram/plan with fewer than ~10 moving pieces, aligned across product/design/engineering, that makes builders say: “I know what to go build.”
- •PRDs and polished UI often fail on first contact with engineering reality
- •Shaping output must expose underlying logic/flows, not just surfaces
- •Rule of thumb: describe the solution in <10 moving pieces
- •Example: calendar becomes a specific “two-month dot grid + agenda view” solution
- 46:36 – 53:54
Balancing detail and flexibility: most teams fail with too little detail, not too much
Lenny raises the fear that detail becomes micromanagement; Ryan counters that the dominant failure in real-life adoptions is insufficient specificity. Detail is a dial: increase it to support junior teams or reduce it with trusted senior talent, and involve key engineers in shaping when they need a say in fundamental decisions.
- •Common adoption failure: under-shaped projects that leave builders guessing
- •Detail level should match team maturity and trust
- •If someone needs influence over approach, bring them into shaping
- •Goal: maximum clarity + room for implementation creativity
- 53:54 – 1:04:13
How shaping sessions actually run: fast iteration, breaking ideas, and surfacing ‘time bombs’ early
Ryan describes shaping as rapid, collaborative problem-solving—trying ideas, attempting to break them, and comparing radically different approaches. Sessions are often ~3 hours; teams may run multiple sessions with breaks/spikes in between, but speed depends on having all necessary knowledge (especially senior engineering) in the room.
- •Start from a narrowed problem + appetite, then prototype approaches together
- •Deliberately “break” ideas to reveal edge cases and hidden complexity
- •Typical pattern: 1–3 focused sessions with occasional spikes/breaks
- •Engineering presence prevents late-stage surprises and rework
- 1:04:13 – 1:13:40
Kickoff without the ‘paper shredder’: builder-owned tasks and the 9-box planning exercise
They compare Scrum sprint planning (often ticket-driven by non-builders) with Shape Up kickoff, where a shaped project is handed to builders who create their own task breakdown. Ryan suggests a simple kickoff tool—translate the work into 9 (or fewer) major chunks to keep the whole project cognitively graspable.
- •Key Scrum gap: tickets often written by people who don’t fully understand the work
- •Shape Up kickoff: hand off a coherent shaped concept, then builders make tasks
- •9-box exercise: force a high-level implementation map without ticket overload
- •Cognitive load rationale: keep scope understandable as a whole
- 1:13:40 – 1:28:32
When to try Shape Up (and why ‘feature factory’ is often the wrong diagnosis)
Ryan advises adopting Shape Up when the pain is real: projects drag, teams can’t see the end, and artifacts (PRDs/Figma) don’t produce shared clarity. He challenges the “feature factory” trope—many teams aren’t efficiently cranking out features; they’re stuck and can’t ship predictably.
- •Best trigger: recurring inability to finish and escalating uncertainty during builds
- •Upstream symptom: fuzzy projects (“calendar”, “dashboard”) that never get negotiated down
- •Midstream symptom: endless questions, backtracking, and surprises during implementation
- •Feature factory critique misses the more common problem: lack of reliable shipping
- 1:28:32 – 1:45:09
Basecamp’s unique context + the PM role in Shape Up: move upstream, link strategy to framing
Ryan explains why Basecamp/37signals assumptions don’t generalize (designers who code, founder proximity, fewer competing demands on engineering). In successful Shape Up teams, PMs spend less time shepherding the build and more time upstream—framing problems, negotiating boundaries, and connecting demand-side strategy (e.g., Jobs-to-be-Done) to shaped work.
- •Basecamp advantages: designer-coders, minimal org distance, fewer competing internal stakeholders
- •Real-world adoption requires closing gaps (especially product–engineering collaboration)
- •PM role shifts upstream from project-chasing to problem framing and tradeoff negotiation
- •Strategy link: demand-side clarity (JTBD) feeds framing, Shape Up operationalizes delivery
