✏️Wireframes for PMs
Low-fidelity sketches that align the team faster than a long PRD ever could.
PMs don't need to be designers, but they do need to communicate visually. A 5-minute Figma wireframe or back-of-napkin sketch aligns the team faster than 500 words of prose. The wireframe also forces the PM to make scope decisions early.
PMs should be able to sketch a rough wireframe to communicate intent — not to dictate design. The wireframe shows information hierarchy, flow, and scope. The designer turns it into a polished design. Treating the wireframe as a finished design is the most common PM-designer friction.
What a PM wireframe should communicate
- What's on the screen (information hierarchy)
- How the user moves through the flow (states + transitions)
- What's in scope (and implicitly what's not)
- The most important constraint (e.g., 'this has to fit in 380px wide')
It should not communicate visual polish, exact spacing, branding, or typography. That's the designer's craft.
Tools
- Pen and paper is fine for solo thinking.
- Excalidraw for shared low-fi.
- Figma for anything you'll iterate on with a designer.
- Whimsical for flows + simple boxes.
- AI tools (v0, Bolt, Lovable, Cursor) for vibe-coded prototypes that go beyond wireframes.
The 'good enough' bar
A PM wireframe is good enough when:
- You and the designer agree on the flow without conversation.
- Engineering can scope from it (rough story-point estimate possible).
- The product trio can decide whether to invest in design polish.
If your wireframe is taking longer than 30 minutes to make, you're over-investing. Hand off to a designer.
The PM-designer dance
The best collaboration: PM sketches the wireframe, then sits with the designer for 30 min to walk through it and the user research. The designer takes it from there, comes back with a polished design, and the PM and designer iterate. The wireframe was scaffolding; the design is the output.
The bad collaboration: PM 'designs' in Figma and hands it off, designer feels marginalized, the output is a pixel-pushed version of the PM's mediocre design. Avoid this.
Real-world examples
Stripe PMs frequently include hand-drawn sketches in PRDs to communicate intent quickly. The sketches are explicitly not 'designs' — they're scaffolding for the designer to work from. The clarity in PRDs is partly a consequence of this practice.
Go deeper — recommended reading
Interview questions (1)
Q1Should a PM be able to design? How do you collaborate with designers without stepping on their craft?executionmid▼
A PM should be able to sketch — communicate flow and information hierarchy quickly. A PM should NOT pretend to design — push pixels, choose typefaces, set up component libraries. Those are different skills.
How I collaborate: I bring the problem definition, user research, and a rough wireframe to the designer. We sit for 30 min and walk through it. The designer takes it from there and brings back a polished design. We iterate on the design together, but I defer to the designer on craft.
The signs of bad collaboration: the PM 'finishes' the design in Figma and hands it off (marginalizes the designer), or the designer goes dark for two weeks and comes back with something that misses the user research (often because the brief was incomplete). The fix on both sides is more conversation, earlier.