LLenny's Podcast
← All episodes
Ryan Singer (creator of “Shape Up,” early employee at 37sign30 March 2025

A better way to plan, build, and ship products

6Frameworks
14Insights

Frameworks in this episode

Productivity3 steps

Fixed Time, Variable Scope (Appetite-Based Planning)

Set the max time you'll spend first, then design a solution that fits it — instead of estimating a concept.

Read →
Strategy3 steps

Framing (Setting the Boundaries)

Narrow a fuzzy request down to the specific problem worth solving before you design any solution.

Read →
Innovation5 steps

Live Shaping Session

Put product, a senior engineer, and a designer in a room to sketch and break ideas until one is clearly buildable in the appetite.

Read →
Productivity3 steps

The Circuit Breaker (Back to Shaping)

When a project overruns its appetite, don't extend it or gut the agreed value — pull it back into shaping mode.

Read →
Leadership4 steps

The Detail Dial

Calibrate how prescriptive a shaped plan is to the builder's seniority — more detail lifts juniors, less frees seniors.

Read →
Productivity3 steps

The Nine-Scopes Kickoff

At kickoff, have the builders translate the shaped idea into nine-or-fewer implementation chunks to test scope and build clarity.

Read →

Insights & moments

The myth-busts, hot takes, explainers, and tools worth keeping.

Myth Buster· 2

Myth Buster32:00

Why You Can't Just 'Cut Scope' When Time Runs Out

A seductive misreading of Shape Up says: fix the time, and if you run out, just cut scope like Parkinson's Law. Singer says that works for a low-stakes landing page but not for real product work where functionality has to actually exist. If the work wasn't shaped, cutting the agreed-upon value at the deadline kills morale and leaves the team with a debt feeling going into the next cycle. The real answer is doing the shaping work up front.

  • Parkinson's Law logic (cut scope at the deadline) only fits trivial work like a landing page
  • Real product functionality can't simply be trimmed away when time runs out
  • Cutting agreed value at the deadline destroys morale and creates a 'debt feeling'
  • The fix is upfront shaping, not last-minute scope-cutting

“but when it comes to real product work you know where there's some functionality that we have to figure out how to make it exist…”

Ryan Singer · 32:30
#shape-up#scope#parkinsons-law#shaping
Myth Buster47:00

The Real Failure Mode Is Too Little Detail, Not Too Much

PMs fear that a detailed shaped pitch turns engineers into code monkeys. Singer says the dominant real-world failure is the opposite: not enough detail, with engineers running back to product saying 'I'm not getting enough from you.' The amount of detail that helps is a dial you turn based on who's on the team — more guidance makes a junior engineer far more successful (and stops them from hiding that they're lost), while stellar senior talent can be given less.

  • The most common failure is too little detail, not over-specification
  • Engineers frequently complain they aren't getting enough from product
  • Detail is a dial tuned to the seniority of the person building
  • Junior engineers hide when they're lost; more guidance sets them up to succeed and learn

“the dominant failure case that I see in the real world is always again and again not enough detail”

Ryan Singer · 47:30

“the amount of detail that the team is going to feel helps them is a dial that we can turn that depends on who on…”

Ryan Singer · 48:00
#shape-up#shaping#product-management#seniority

Hot Take· 2

Hot Take1:18:30

A Feature Factory Is Actually Healthy — Just Feed It Better Input

Singer reframes the popular 'feature factory' critique. If your org is reliably cranking out features, you're probably quite healthy — you just need to feed a different input (real problem framing and demand) into the front of the factory. The far more widespread and painful struggle he sees isn't over-shipping; it's teams that can't ship predictably at all, where work drags, the end is invisible, and people burn out.

  • A team that reliably ships features is healthy; fix the input, not the output engine
  • The feature-factory critique is really about not negotiating value and outcomes upfront
  • The bigger real-world problem is unpredictable, non-repeatable shipping
  • Dragging work with no visible end is what actually burns teams out

“if you have a feature Factory meaning you're continually cranking out features you're probably quite healthy all you need to do is feed a different…”

Ryan Singer · 1:19:00

“what most teams are struggling with is that they can't they can't they don't have predictable repeatable shipping of things”

Ryan Singer · 1:19:00
#shape-up#feature-factory#shipping#framing
Hot Take1:28:30

Basecamp Was Uniquely Set Up — Don't Blindly Copy It

Singer only realized how unusual Basecamp was after leaving. Every designer there actually coded — running the app locally and rendering views themselves — so the painful wall between design and engineering simply didn't exist. There was also no sales or marketing org creating contention for engineering time; the founders did all of that, and stayed close to problem definition. Copying Basecamp's advice without those conditions is why Shape Up often stumbles elsewhere.

  • Every Basecamp designer coded, not just HTML — they ran the app and rendered their own views
  • The disappointing 'engineer says no to the Figma file' moment didn't exist there
  • No sales or marketing meant no contention for engineering time
  • Founders stayed close to problem definition, keeping constant clarity on what and why

“every designer codes imagine if every designer codes and not and I don't just mean html I mean like running the app locally”

Ryan Singer · 1:29:00

“imagine you have no sales or you have no marketing that all of sale selling and marketing is happening by the Unicorn Founders so it…”

Ryan Singer · 1:30:30
#basecamp#shape-up#team-structure#context

Explainer· 2

Explainer35:30

Shape Up Works at Big Companies — and Not the Whole Company Has To

Singer counters the assumption that Shape Up only fits tiny Basecamp-like teams. He cites a pharmaceutical company with thousands of people where a few teams run it successfully. The unlock is good engineering leadership that untangles dependencies so one system can be worked on independently, plus capacity management to protect a team from being pulled onto other work for a set number of weeks.

  • A thousands-person pharma/clinical-trials company runs Shape Up on a few key teams
  • Dependency hell is not inevitable — good engineering leadership untangles it
  • A senior engineer must make architectural choices and back-stop the team from being pulled away
  • Only part of a large company needs to adopt it, which many find freeing

“so many people are used to it and they think that it's just how it is but it's actually not it is possible for engineering…”

Ryan Singer · 36:30
#shape-up#scaling#engineering-leadership#dependencies
Explainer40:30

The Home Renovation Analogy: Check for Electricity in the Wall

Singer's signature analogy for why beautiful designs mislead. You can have a perfect rendering of a bedroom with wall-mounted lamps, but if you never checked whether there's electricity in that wall, the real cost and time change drastically once you have to rip the walls open. A high-fidelity Figma file hides the same unknowns — the engineering team has to put on x-ray goggles to figure out the logic and flows underneath the UI.

  • A perfect rendering means nothing if you haven't checked what's behind the wall
  • Unseen wiring (or backend logic) drastically changes cost and time
  • So much of a feature's real work is invisible on the surface of the UI
  • Engineers must 'x-ray' a design to understand flows, cases, and behind-the-scenes logic

“you can like have the perfect rendering and the perfect lamp and the perfect color but if you haven't checked if there's electricity in that…”

Ryan Singer · 41:00
#shape-up#shaping#design#analogy

Story· 4

Story11:00

The 10-Hours-a-Week Constraint That Seeded Shape Up

Singer traces Shape Up's origins to the first version of Basecamp, when DHH (David) was only programming about 10 hours a week while building the app. That scarcity of engineering time, combined with Jason Fried's relentless push for visible forward movement, forced the team to be ruthless about not wasting a single build cycle. The pressure to use David's limited time well is what pushed them toward figuring out ideas sharply before committing to build them.

  • David (DHH) was programming only ~10 hours a week on Basecamp V1
  • That constraint created intense pressure to use engineering time efficiently and never build the wrong thing
  • Jason Fried's constant demand for movement added cultural urgency even with no outside pressure
  • Avoiding wasteful build-and-throw-away cycles became the founding motivation

“even when we were building V1 David wasn't actually full-time as the as our only technical person he was programming 10 hours a week so…”

Ryan Singer · 11:00
#shape-up#basecamp#engineering-time#origin-story
Story17:30

The Project That Forced Basecamp to Formalize Shape Up

For roughly the first decade, the natural startup way of working spread organically as Basecamp hired slowly. Then one project broke the pattern: a review session revealed lots of open questions, no quick answers, and the dawning realization that not only would it not ship, they couldn't even see its end. That moment convinced Singer the organic method wouldn't scale forever, and he took on systematizing it into what became Shape Up.

  • For ~10 years the way of working spread organically because founders hired deliberately slowly
  • One project's review session surfaced many open questions and slow answers
  • The team realized it wouldn't ship and they couldn't see the end of it
  • That failure triggered Singer to formalize and systematize the method

“what we're starting to realize is like oh this is not only is this not going to ship but we can't even see the end…”

Ryan Singer · 18:00
#shape-up#basecamp#scaling#origin-story
Story50:30

The Fintech Onboarding Step That Was Secretly Three Steps

A fintech team wanted to remove a high-drop-off onboarding step by piping customer data from partner banks — a clear conversion win, on paper. What they missed: in the code, that single step was actually three different branches depending on which bank the customer was integrated with. Discovering that in week four is a disaster; discovering it in the shaping room, before greenlighting, turns it into a productive tradeoff conversation. Singer frames the shaping engineer as the 'grumpy old plumber' who opens the walls before quoting.

  • A fintech team planned to cut an onboarding step by importing data from partner banks
  • The one step was actually three code branches depending on the customer's bank
  • Finding this in week four (after resourcing) is painful; finding it in shaping is productive
  • The shaping engineer is like a plumber who opens the walls to inspect the pipes before quoting

“the thing that they didn't look at was if you go into the code on that step of the onboarding it's not actually one step…”

Ryan Singer · 51:00

“the grumpy old plumber who's seen everything and he insists on opening up the walls and looking at the pipes before he'll give you a…”

Ryan Singer · 52:30
#shape-up#shaping#risk#fintech
Story1:33:30

Why Shape Up 'Didn't Work' — No Engineer in the Room

After the book, Singer heard from teams whose projects kept running over. When he asked to see their shaping work, they'd show him a PRD or a stack of Figma files — nothing like the book. The pattern: people in existing roles kept producing their usual artifacts, and there was no engineer in the shaping picture. His breakthrough came on a consulting project where they brought the best-suited engineer over into product for the shaping session, and suddenly he was 'in the world' he knew again.

  • Teams reported projects constantly running past the cycle
  • Their 'shaping work' was actually PRDs and Figma files, unlike the book
  • The root cause: no engineer was present in the shaping
  • The fix that unlocked it: bring the right engineer into product for the shaping session

“it wasn't that this doesn't work I was just in a like a foreign country you know it was like um we tried it and…”

Ryan Singer · 1:33:30

“can you show me your shaping work and then they would show me a PRD I'd be like like well that's not that doesn't look…”

Ryan Singer · 1:34:00
#shape-up#shaping#consulting#engineering

Tool· 2

Tool1:06:00

The Nine-Boxes Kickoff Exercise (Rule of 7±2)

For mixed-seniority teams, Singer uses a simple kickoff exercise: take what was shaped and have the builders draw a grid of nine boxes representing the nine major chunks of implementation. It surfaces whether the scope is too big, and creates coaching moments where seniors correct juniors' approaches. If it needs more than ~10 boxes you've fallen into ticket land; nine or fewer maps to the cognitive 'rule of 7±2' — a whole you can hold in your head.

  • At kickoff, builders translate the shaped work into nine major implementation chunks
  • Six weeks / nine boxes is roughly four business days per box
  • More than ~10 boxes means you've dropped into unhelpful ticket land
  • Nine or fewer maps to the 7±2 cognitive limit — a whole you can hold in your head

“give me nine boxes of the nine major chunks that you think have to get implemented from an implementation standpoint”

Ryan Singer · 1:06:30

“if it's more than 10 then you just get into ticket land of here's a million things I have to do”

Ryan Singer · 1:08:00
#shape-up#kickoff#estimation#tools
Tool1:38:30

Book Pick: 'Demand-Side Sales 101' for the Framing Step

Singer connects shaping's upstream 'framing' step to product strategy and jobs-to-be-done. When projects fail because the very input is unclear — you don't know what's important to customers or where the value is — he reaches for Bob Moesta's work. His top recommendation is 'Demand-Side Sales 101' (a tactical jobs-to-be-done book despite its off-putting title), with Clayton Christensen's 'Competing Against Luck' as a good general intro to the spirit of jobs-to-be-done.

  • Many shipping failures trace back to an unclear input at the very start (framing)
  • Framing links Shape Up to product strategy and jobs-to-be-done
  • Top pick: Bob Moesta's 'Demand-Side Sales 101' — tactical despite the sales-y title
  • 'Competing Against Luck' by Clayton Christensen is a good intro to jobs-to-be-done

“the one that I recommend the most is a demand side sales one 101”

Ryan Singer · 1:40:00

“competing against luck is a really good intro that's the one that Clayton Chris uh Klay Christensen wrote”

Ryan Singer · 1:41:00
#jobs-to-be-done#framing#books#product-strategy

Takeaway· 2

Takeaway31:00

The Circuit Breaker: Pull a Stuck Project Back Into Shaping

Basecamp's original rule was a 'circuit breaker' — if a project isn't on track to finish, cancel it and rethink. Singer admits almost no team has the stomach to just kill projects. The more palatable version: don't keep reinvesting in something you don't understand. Take it out of build mode and bring it back into shaping mode, which may mean different people, a different conversation, and different questions to find what's fuzzy.

  • Basecamp's circuit breaker: cancel a not-on-track project and rethink it
  • Almost no team has the stomach to actually cancel
  • Better move: stop reinvesting in what you don't understand
  • Pull the project out of build mode and back into shaping mode with fresh people and questions

“the circuit breaker like if a project is not on track to actually finish after the six weeks we're just going to cancel it and…”

Ryan Singer · 31:00

“let's take this out of build mode and bring this back into shaping mode which might mean different people a different conversation asking different questions”

Ryan Singer · 31:30
#shape-up#circuit-breaker#shaping#project-management
Takeaway1:26:00

In Shape Up, the PM Moves Upstream

Singer argues that PMs today often get stuck babysitting the build phase — closer to project management than product management. In teams that hit their Shape Up stride, the PM moves upstream: away from keeping a project out of a bad state, and toward understanding business context, narrowing the problem, and negotiating with leadership about which slice of a problem is actually worth spending weeks on. Lenny notes AI-assisted building may push the PM role in the same upstream direction.

  • PMs often over-invest in shepherding the build, which is really project management
  • In mature Shape Up teams the PM shifts upstream to problem definition and framing
  • The high-leverage PM work is understanding the business, customer, and which problem slice is valuable
  • AI-assisted building may pull the PM role further upstream toward deciding what to build

“what we see in really In Shape Up teams when they hit their stride is that the PM moves Upstream”

Ryan Singer · 1:26:30

“that really getting deeper understanding of the business and the problem and the customer domain and like what problem is worth solving”

Ryan Singer · 1:27:00
#shape-up#product-management#framing#ai