Your PM Doesn't Have a Solution Problem. They Have a Listening Problem.

I watched a PM spend three weeks building a prototype for a "scheduling optimization tool" before talking to a single customer. When we finally did interviews, we found out the problem wasn't scheduling—it was that users had no visibility into who was actually available.

By then, the prototype was already in Slack. By then, the PM had already committed to the architecture in their head.

The Disease Is Speed of Opinion

PMs love to move fast. I get it. But there's a difference between moving fast through execution and moving fast through thinking.

The ones who jump straight to solutions? They're usually not faster. They're just noisier.

I watched another one—good operator, shipped real things—reject three rounds of customer feedback because it contradicted the feature spec she'd already written. Not because the feedback was weak. Because she'd already decided. The listening stopped the moment the wireframe started.

The pattern I see most often: a PM hears a problem once (sometimes secondhand), gets excited, builds something in their head in about four minutes, and then spends the next month trying to convince everyone else that their solution was right all along. It's not strategy. It's ego with a gantt chart.

The Math Is Simple

Here's what actually works:

Customer interview #1: You're mostly listening. You ask dumb questions because you don't have a solution yet. Customer interview #2: You hear something that contradicts what you thought. You sit with that discomfort. Customer interview #3–8: You start to see the pattern. The problem becomes clearer. Your assumptions get tested. Then—and only then—you sketch.

The wireframe is the conclusion, not the starting point. If you're wireframing before you've had real conversations, you're not designing—you're guessing with pixels.

Why This Breaks Organizations

When a PM leads with solutions, everything downstream gets twisted. Engineering wastes sprints building the wrong thing "correctly." Design spends cycles polishing the wrong interface. Support prepares for questions nobody's actually going to ask.

I worked with a team that shipped a whole export workflow because the PM was convinced it was the top ask. When we finally ran analytics, it was used 7 times in three months. Turns out the actual problem was that users needed real-time data, not exports. The PM just hadn't listened long enough to hear that distinction.

The Uncomfortable Truth

Good listening is slow. It's boring. You have to sit in ambiguity. You have to hear "I don't know" and not immediately fill the silence with your own answer.

Most PMs are wired to fill silence. That's a strength in sprint planning. It's a disaster in customer conversations.

The best ones I've worked with? They take notes. They ask "tell me more" about three times per interview. They write down customer quotes, not their own interpretations. They come back from the field with more questions, not with confidence.

The worst ones come back with a slide deck.

What Success Looks Like

If you're a PM reading this: before your next big feature, count your customer interviews. If it's fewer than 10 and you've already picked a direction, you haven't listened yet. You've performed.

If you're managing PMs: watch for the ones who disappear into customer conversations and come back with uncertainty. That's the sign they're actually learning. Reward that. Push back on the ones who return with solutions already decided.

The first wireframe should never appear before the second customer interview. Everything after that should be refinement, not invention.

Most PMs get this backward. And that's why most products solve the wrong problem, just really, really well.