Drawing the Perimeter
The PM's job is to add constraints, not solutions — draw the box, then let engineers and designers fill it.
- Difficulty
- Moderate
- Time to result
- ~weeks to results
- Steps
- 5
- Confidence
- 92%
Kevin Yien defines the PM's core contribution as drawing the perimeter of the problem space: adding as many constraints as reasonable so engineers and designers can push against the bounds and fill the box creatively. Fewer open decisions means more team velocity — the best decision is no decision. But the perimeter is not a licence to stay high-altitude: the PM must also stay obsessed with the final deliverable, because the murky overlaps between roles are where good products get made.
Origin
Developed by Kevin Yien while writing PRDs at Square for the restaurant point-of-sale product line, on a team of three engineers and three designers that had designs but no shared definition of the problem space.
Core principles
- 01Constraints are a gift to makers: they enable creative solutions rather than restricting them.
- 02The best decision is no decision — every constraint you add removes a decision the team would otherwise carry.
- 03Clean swim lanes between PM, engineering, and design feel tidy but produce mediocre products; you need murky overlaps.
- 04Even if engineers build better and designers design better than you, you must bring a strong opinion and do the legwork to earn their trust.
- 05Owning the perimeter does not exempt you from the final pixel — value reaching the customer is your outcome.
How to run it
- 1
Constrain the customer segment
Name exactly who you are serving and, by implication, who you are not. A sit-down restaurant with a 200-item wine list and a taco truck produce entirely different solution spaces; leaving both on the table makes good design nearly impossible.
Pro tip Push on the segment until someone objects — the objection is where the real ambiguity was hiding.
- 2
Constrain the job to be done
State the specific thing the user is trying to accomplish, and how many different pathways to it you are willing to entertain.
- 3
Constrain availability and surface
Decide up front which surfaces are in scope — desktop web, mobile web, native mobile — rather than leaving the team to guess or build for all of them.
- 4
Constrain the tradeoffs you'll be known for
Declare what the product must be known for when it ships, and what you will trade away to get it. 'Speed matters more than consistency of data' is a huge, freeing constraint for an engineer.
Pro tip Technical tradeoffs stated as constraints unlock engineering creativity — an engineer who hears 'no real-time consistency required' can build things you never would have specced.
Watch out If you can't apply many constraints yet, keep pushing on different axes until the scope feels good to the team.
- 5
Then stay obsessed with the deliverable
Do not stop at defining requirements. Stay inside the details of the final experience until value is actually reaching the customer.
Pro tip Audit your calendar periodically — a spring cleaning of everything you do, scored by how much it actually gets value to a customer.
Watch out As companies scale it becomes natural to drift into internally-focused work; keep a hypersensitive antenna for it.
In the wild
Square's restaurant point of sale had to serve both bartenders punching in orders blindfolded from muscle memory and first-time workers who had never touched a POS. Yien and a designer spent an entire week tuning how many milliseconds it took to pop into a menu group, bringing in real servers and bartenders to play with iPad prototypes and watching for the flinch or hesitation when the animation felt too slow.
→ The interaction made a material difference to restaurant adoption. Yien pushed the launch date out three times, holding that the ship-quality bar mattered more than an artificial external GA date.
Instead of specifying a solution, the PM declares a tradeoff: this product will be known for speed, and speed is more important than real-time consistency of data.
→ Engineers hearing that they don't need real-time consistency gain an enormous solution space and can hit the speed goal with approaches the PM would never have specified.
Common mistakes
Drawing clean swim lanes
Declaring 'you do X, I do Y, don't tread on my area' feels professional but produces mediocre work. The overlaps between PM, design, and engineering are where quality actually comes from.
Treating requirements as the finish line
'I define the requirements, designer and engineer figure it out' abdicates the outcome. The PM is on the hook for whether value reaches the customer, animation milliseconds included.
Confusing busyness with impact
PMs enjoy feeling in demand across processes and stakeholders. Much of that is internally-focused work that never gets value to a customer, and it crowds out the details that do.
Is it for you?
Best for
PMs on cross-functional teams with strong engineers and designers who are getting vague, unbounded briefs and low-quality output as a result.
Not ideal for
Teams where the builders are also the customers (Stripe, Figma, Twilio style) and can set their own constraints without a PM intermediary.
From the transcript
“PM should be doing everything in their power to draw the perimeter of the space of the problem space and it's within that enge design…”
“just constraints at the end of the day you should be adding as many constraints as reasonable in order to let engineers and designers come…”
“it is tempting when we think about engineering product and design to draw these really clear swim lanes and say you do X I do…”
From the episode
Unorthodox PM wisdom: Automating user insights, unselling job candidates, logging every decision, more
Kevin Yien (Stripe, Square, Mutiny)