Framing (Setting the Boundaries)
Narrow a fuzzy request down to the specific problem worth solving before you design any solution.
- Difficulty
- Moderate
- Time to result
- ~days to results
- Steps
- 3
- Confidence
- 90%
Before shaping a solution, you must reduce a vague request ('build a calendar') to the actual, narrow problem a specific customer keeps hitting ('I need to see empty spaces I could book into'). Framing is where product strategy meets execution — it is the demand-side question of where people are really struggling, and skipping it makes shaping an ever-expanding, never-ending exercise.
Origin
Called 'setting the boundaries' in Ryan Singer's Shape Up book and 'framing' in his later Shaping in Real Life course. Singer explicitly links the upstream demand-clarity work to Bob Moesta's Jobs to Be Done and 'Demand-Side Sales 101.'
Core principles
- 01A fuzzy problem produces a fuzzy, ever-expanding shaping session
- 02Don't take the request at face value — negotiate down to what it really is and where the value is
- 03The narrowed problem is the required input to a shaping session
- 04This is the PM's highest-leverage work: understanding the business, customer, and which slice of the problem is valuable
How to run it
- 1
Trace the request to its source
Identify where the ask came from — a sales lead, a CEO shower-thought, a research finding — and treat it as raw, unnegotiated demand rather than a spec.
Watch out If you accept 'calendar' or 'dashboard' at face value without negotiating what it means, you get an ever-expanding blob no one can conclude.
- 2
Negotiate the problem down to a specific struggle
Reduce the broad label to the concrete moment a specific, repeat-requesting customer is stuck. 'Calendar' becomes 'in the existing agenda view I can only see what's already scheduled, not the free spaces where I could book something.'
Pro tip Reach for Jobs to Be Done / demand-side thinking here — where is the itch people are trying to scratch?
- 3
State the frame so shaping has a target
Write the narrowed problem plainly (e.g. 'this is about empty spaces') so the shaping session has a clear boundary to design against.
Pro tip A good frame is one sentence about the problem, not a solution — it tells you what value you're chasing, not what to build.
Watch out Handing an un-narrowed problem into shaping guarantees the session sprawls and concludes nothing.
In the wild
Customers kept requesting a calendar. Instead of building Google Calendar, the team framed the real problem: users could only see already-scheduled items in the agenda view and had no way to see the free gaps where they could book something.
→ The narrowed frame ('this is about empty spaces') made it possible to shape a concrete, buildable solution instead of an unbounded calendar product.
Common mistakes
Taking the request at face value
PMs often accept 'build X' without negotiating what X really is or where its value lies, so the downstream shaping and building inherit the fuzziness and drag.
Confusing a framed problem with a solution
Framing defines the problem and boundary only. Jumping straight to solution detail (figma, PRDs) before the problem is narrowed produces beautiful artifacts that miss the actual value.
Is it for you?
Best for
PMs who want to move upstream — spending their time on business context and problem clarity rather than babysitting the build.
Not ideal for
Trivial, self-evident work where the problem is already crisp and there is nothing to narrow.
From the transcript
“in shaping in real life we call this Framing”
“we narrowed it down to we understand that for our specific customers who are requesting this again and again it's more about I need to…”
“if the problem is just calendar you know then the shaping is going to be this ever expanding never ending thing”
From the episode
A better way to plan, build, and ship products
Ryan Singer (creator of “Shape Up,” early employee at 37sign