A PM's Guide to Wireframes

Wireframes aren't just for designers. Great PMs use wireframes to align stakeholders, test assumptions, and decrease eng & design work on bad ideas

I was recently talking to the Head of Product at a late stage startup who said:

We just don't have time for PM’s wireframing anymore. We have design do that, and focus instead on great PRDs.

I couldn’t help but feel: this is a mistake.

So, I had to poll you all to understand how often PMs are wireframing:

Just over 50% of respondents wireframe.

The plurality of PMs do not wireframe for big features.

Let’s start with the supposition that this plurality is right. That is, that PMs should never wireframe.

Now let’s do a thought exercise. If that’s our modus operandi, when might a wireframe from the PM still be useful?

• To build something under great time pressure when the designer is already busy

• To explain a product idea to execs before a designer can get their hands on it

• To translate what a PM is hearing so the team can better understand it

• To step in to explain a feature to a new designer to the team

Now, let’s be honest. How much does this stuff happen? It happens a lot!

In every single product org I’ve led, design resources are strapped. There’s 10 feature ideas product execs and managers want to explore for every 1 a designer can work on.

And that’s why I think the majority may want to reconsider. In my opinion:

• 25-75% of big features is probably the “right answer” for most PMs.

• And that group doing them for 100% of big features group probably is doing something right.

In fact, in my final years a senior IC PM—eg when I started at Epic Games—I always used wireframes in my PRDs.

---

“No Question is a Stupid Question”

What is the difference between a wireframe, a mockup, and a prototype?

Some people also talk about “high fidelity wireframes,” which, as you crank up the fidelity, eventually converge to mockups.

---

Why I Love Wireframes

A great wireframe can:

1. Convey your entire feature idea in a picture

2. Uncover edge user segments you would otherwise discover down the line

3. Act as a great tool to use in customer interviews to de-risk your next feature

All before any expensive engineering time is dedicated to the idea.

There’s a reason the Spotify founding team started with a wireframe before touching any code:

Image: Rasmus Andersson

But the thing is: you all probably already know and agree with that! Most of you don’t wireframe because you believe design should be doing that.

So let’s go further on that.

---

Should PMs Wireframe At All?

It’s a philosophical debate. So let’s ask the three questions:

1. Once you agree on the problem to solve, how many ideas do you need to work through to come up with a good one?

2. What should the aperture of your discussions with executives be?

3. Should PMs be full-stack?

Question 1 - Once you agree on the problem to solve, how many ideas do you need to work through to come up with a good one?

In my experience:

1. A lot.

2. It’s best if they are divergent ideas.

Luckily, that’s the case we’re talking about:

• PMs tend to be better experts of what execs and the business wants

• Designers tend to be better experts of what users want and the design systems of the larger product

The result is that:

• PMs tend to create basic, business-driving wireframes

• Designers tend to create beautiful, user-friendly wireframes

So, having two different people build wireframes increases the total variety of ideas you evaluate.

And: the more divergent ideas, the better. I call it, “The Principle of More Ideas.”

Question 2 - What should the aperture of your discussions with executives be?

Let’s say the CEO aligned with the product team on the problems to solve next quarter a week ago.

Then, they ask:

How are things going?

It doesn’t really play well when, this week, the VP of Product responds:

The designers are just starting their solution explorations, and we’ll hear more at design review in three weeks.

What plays much better is:

Check out this wireframe Michael (a PM) created on our top problem. We shared this with a few customers already and they think we’re onto something.

What do you think?

Designers are ramping up on their deeper explorations next week, so we can share feedback today before design review end of next week.

So what I’m arguing here is: the aperture of your discussions with the CEO should actually shift to early-stage solutions, before you necessarily have time for design to get to it.

For two reasons:

1. It increases your credibility with the CEO.

2. You also utilize the CEO more effectively.

Let’s double-click on that second point.

Usually, CEOs have amongst the best product sense in the company. So, their input focuses the teams in the right direction.

It ends up being a useful exercise that reduces overall failure rate of features:

Question 3 - Should PMs be full-stack?

Designers design. Coders code. PMs… manage the roadmap? How much value is that if most of the roadmap is pre-determined by executives and tech debt?

Many PMs find themselves in a “credibility trap,” where their own designers and engineers question their value-add.

This is where being “full-stack” helps.

What is “full-stack?”

• Need to get solution exploration started ASAP? → PM can step in

• Need to get some QA use cases written? → PM can do that

• Designer out during planning week? → PM can make the relevant wireframes

It’s the mentality of getting your hands dirty, and doing whatever the company needs.

For many Silicon Valley series A-C startups, that’s what the PM role looks like. The real question is: should big companies be pursuing these startup PM tactics?

I say yes. For 4 reasons:

1. Communication: A wireframe often says more than a well-crafted, 3,000 word PRD, because people actually process the whole thing.

2. The $1-$10-$100 rule: This rule states that preventing a defect costs $1, akin to PM wireframing. Correcting a defect, though, costs $10, which is akin to a designer wireframing. Finally, dealing with a failure costs $100, which is akin to an engineer building the thing.

3. Modern PM: PMs no linger sit at the intersection of business, tech, and UX. They have a distinct lean towards UX more than they used to.

4. The future of PM: In the world of GPT-7, designers and engineers will be freer than ever to do PM work. In that world, PMs need to be able roll up their sleeves and lean into UX to make sure the work done is high ROI.

Conclusion on PMs Wireframing

As a product leader, I've grappled with whether PMs should wireframe many times over the years.

On the one hand, there's a valid concern that PMs have to focus on the litany of other things they need to do.

But I end up settling the key philosophical debates that PM is one of the highest leverage PMs can be doing:

1. PM wireframing increases the divergence of solutions explored

2. PM wireframing enables PMs to show executives fast, consistent progress

3. PM wireframing extends the startup PM tactics of being full-stack, adding value everywhere

It's not about PMs stepping on design’s toes, but rather about helping the team overall deliver the highest impact most cheaply.

If you agree with me, let’s get into how to do this well…

---

Today’s Deep Dive

Words: 7,782 | Est. Reading Time: 36 Mins

1. The Basics

   • Wireframing’s history

   • How to build a wireframe

   • Tips & tricks for the top 4 tools

2. Advanced Topics

   • What defines a good vs. a bad wireframe

   • Most common mistakes with wireframes

   • The future of wireframing, design, and AI

3. Your Toolkit

   • Your script for user testing

   • The Product Growth Figma Template

   • 10 example wireframes to get inspired by

---