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.
- Difficulty
- Advanced
- Time to result
- ~weeks to results
- Steps
- 5
- Confidence
- 95%
Shaping is an intense, live, collaborative session — not a solo document — where product, design, and a hands-on senior engineer wrestle a narrowed problem into a concrete solution. You rapidly try ideas and actively try to break them from technical, UX, and value angles, using low-fidelity breadboards and fat-marker sketches. It's done when a technical person can look at the result and say 'I know what to build.'
Origin
Ryan Singer's formalization of the fast, whiteboard sessions he ran for years with Jason Fried at 37signals, where a few Sharpie strokes would crystallize the idea before handing it to DHH to build. Published in 'Shape Up' (2019) and expanded in the 'Shaping in Real Life' course.
Core principles
- 01The right people must be in the same room: product (the why), a designer, and the senior engineer who 'knows where the bodies are buried'
- 02Try ideas and actively try to break them — technical infeasibility, or failing the customer scenario
- 03Don't get stuck circling one idea for hours; step back and sketch a deliberately different approach
- 04Use fat-marker sketches and breadboards, not figma — but they must actually communicate the idea, not be a 'blurry figma'
- 05De-risk rabbit holes and time bombs before greenlighting, not in week four
- 06Done = a technical person says 'yeah, I know what to go build now'
How to run it
- 1
Assemble the three perspectives
Bring the product person who knows the backstory, a designer, and the senior engineer who genuinely knows what's hard and easy in your infrastructure. Their combined, real-time knowledge is what makes the session fast.
Pro tip If someone on the build team insists on shaping the fundamental approach, bring them into the shaping room rather than letting them resent a handed-down spec.
Watch out Shaping with only product and designer — 'we'll show the engineer later' — is the dominant way sessions blow up when they hit engineering reality.
- 2
Try ideas fast and try to break them
Sketch an approach, then attack it: the engineer looks for what won't work technically, the product person plays the customer scenario to see if it actually delivers value. Rotate through genuinely different approaches, not variations of one.
Pro tip When stuck circling one idea, force the question 'what's a very different way of doing this?' and sketch that instead.
- 3
Open the walls before you quote
Like a plumber who opens the wall to check the pipes before quoting, have the engineer open the actual code for any risky step and confirm what's really there. This surfaces hidden branches and complexity while you can still trade off, not after resourcing.
Pro tip Finding a hidden rabbit hole in the shaping room turns a disaster into a productive tradeoff conversation ('do all three branches, or just the biggest one?').
Watch out Discovering the same complexity in week four of a resourced project, after beautiful mockups, is 'a bad place to be.'
- 4
Express it in breadboards / fat-marker sketches
Capture the solution at low fidelity — buttons, flows, states, what connects to what — clearly enough that a builder understands intent, but loose enough to collaborate on live. Avoid high-fidelity figma at this stage.
Pro tip Keep it under ~10 moving pieces; if you can describe the whole thing in fewer than 10 parts, it's shaped well.
Watch out A vague wireframe ('dashboard goes here, four reports') is a blurry figma — it still doesn't tell anyone what to build.
- 5
Run 2–3 sessions and test the output
For work buildable with your existing tech stack, expect to reach a conclusion in about three ~3-hour sessions across a couple of days, with quick spikes in between. The exit test: hand it to a technical person and see if they say 'I know what to go build.'
Watch out Just getting product and engineering into the same room to shape at all means you're already far along — most of the difficulty is organizational, not the sketching.
In the wild
From the framed problem ('empty spaces'), the team shaped a concrete solution: a two-month dot grid (dots mark days with events), a tap that slides an agenda view underneath, month navigation, and a create button. Described in under ten moving pieces, it was no longer 'a calendar' but 'a two-month dot grid with a scrolling agenda view and a new-event button.'
→ Engineering could have a realistic conversation about whether it fit six weeks — instead of x-raying mockups to guess the intent.
A team wanted to remove an onboarding step by piping user data from partner banks. It looked like one step, but the code revealed three different branches depending on which bank the customer was integrated with. Caught in the shaping room rather than mid-build, it became a tradeoff conversation about which bank branches were worth doing.
→ The team could negotiate scope (do the biggest branch, or all three for more time) before committing engineering time, instead of discovering it in week four.
Common mistakes
Shaping without an engineer in the room
When only product and design solution all the way down, the plan collapses on first contact with engineering ('we can't do that, it doesn't work like that') and goes back to the drawing board. Singer names this the number-one real-world failure mode.
Producing a 'blurry figma' instead of a communicative sketch
Deciding figma is too detailed and then drawing vague low-fidelity wireframes that still don't say what to build. A fat-marker sketch is only valuable if it makes a builder say 'now I get it.'
Is it for you?
Best for
Mixed product/design/eng teams that keep overrunning because plans are defined by PRDs or figma files and blow up when they reach engineering.
Not ideal for
Teams inventing genuinely new technology (new algorithm, database, or AI model) where feasibility can't be established in a few sessions.
From the transcript
“so now what we need to do is try out different ideas and and this is the real thing we have to try to break…”
“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…”
“breadboarding and fat marker sketching these are tools to help us express an idea very very clearly in detail”
“it's shaped if we can give this to technical person and they say yeah I know what to go build now”
“here's a good rule of thumb if it's shaped well you can usually describe it in less than 10 moving pieces”
From the episode
A better way to plan, build, and ship products
Ryan Singer (creator of “Shape Up,” early employee at 37sign