Every brief has two versions. The first is what the PM writes. The second is what forms in your head after you've read it twice, slept on it, and opened a blank Figma frame.
The gap between those two versions is where most of the interesting design work happens — and where most of the friction does too.
The first version
The first version contains what's visible: the user story, the acceptance criteria, the deadline, the business context (if you're lucky). It answers: what needs to be built and by when.
Most designers I know start in Figma within an hour of reading this. I used to too.
The second version
The second version takes longer. It's the one you arrive at when you stop reading the brief and start questioning it. It's when you ask:
- Is this the right problem to solve, or is it a symptom of something upstream?
- What would need to be true for this solution to actually work in the hands of a real user?
- Is there a version of this that's simpler and more honest than what was asked for?
This isn't about being difficult. It's about doing the job properly. PMs are operating at the level of business requirements and sprint capacity. Designers are meant to operate at the level of human experience and product coherence. The brief is written from one perspective; the second version is written from another.
When to surface it, and how
The second version needs to be surfaced before you go too deep — not after you've built the thing. The worst outcome is presenting a fully designed solution to what turned out to be the wrong problem.
I try to do this in a short sync, not over Figma comments. My format is usually:
- "Here's what I understood from the brief."
- "Here's a question it raised for me."
- "Here's the direction I'm leaning and why."
That's it. No grand alternative proposal. Just a signal that I've thought past the first read, with enough specificity to invite a useful response.
Sometimes the PM says "yes, that's worth exploring." Sometimes they say "no, that constraint is real and here's why." Both answers are useful. Not asking is the worst outcome.
When to let it go
Not every second version deserves a conversation. If the delta between version one and version two is small — a UI detail, a flow sequence, a presentation choice — just decide and move. Reserve the conversation for cases where the underlying approach feels fundamentally misaligned.
There's also a timing factor. Early in a project, the second version is worth fighting for. Two days before handoff, it's a distraction. Know when the window is open.
What this builds over time
Working this way consistently builds something valuable with the PM: credibility. They start to see you as someone who engages with the problem, not just the spec. That changes the quality of briefs you receive — they start writing them knowing you'll push back thoughtfully, which means they front-load more of the thinking.
The best PM-designer partnerships I've seen aren't ones where the designer executes cleanly. They're ones where both people feel genuinely responsible for the outcome.
Credits & further reading
- Upstream — Dan Heath (Crown, 2020). The book that best captures the instinct behind "the second version" — moving from fixing symptoms to addressing the conditions that create them. The question "is this the right problem, or a symptom of something upstream?" comes directly from this way of thinking.
- Lean UX — Jeff Gothelf & Josh Seiden. Their concept of collaborative discovery — designers, PMs, and engineers aligning on the problem before moving to solutions — is the formal version of what this note describes. Especially useful for the "text before flow before wireframes" discipline.
- Shape Up — Ryan Singer (Basecamp, free online). Basecamp's internal product methodology. Their concept of "shaping" — defining the rough solution at the right level of abstraction before it goes to a team — is a useful reference for thinking about what a good brief looks like and how to push it toward one.