Why most PMs build the wrong thing (and how to stop)

The opinion-driven roadmap

Here's how most roadmaps get built: the CEO has an idea from a board meeting. A sales rep forwards a feature request from a big prospect. Someone on the team saw a competitor launch something new. The PM collects all these inputs, picks the loudest ones, writes a PRD, and ships it off to engineering.

Nobody talks to users. Or if they do, it's a handful of conversations that confirm what they already believe.

This isn't a planning process. It's a guessing game with a Notion template.

Why this keeps happening

It's not because PMs are bad at their jobs. It's because real product discovery is hard and slow. The ideal workflow looks something like this:

1. Talk to 20–30 customers
2. Read through hundreds of support tickets
3. Analyze usage data for drop-off patterns
4. Cluster all of this into themes
5. Prioritize themes by impact and frequency
6. Write specs for the top priorities

That's weeks of work. Most teams don't have weeks. They have a sprint planning meeting on Monday and need to know what to build by Friday. So they skip steps 1 through 5 and jump straight to 6.

The result? Features that feel right in a meeting but fall flat with users.

What great teams do differently

The best product teams I've worked with (and studied) do three things that most teams skip:

1. They treat discovery as a continuous process, not a quarterly event

Discovery isn't a two-week sprint you do before quarterly planning. It's something that happens every week, in the background. Great teams are constantly feeding new data into their understanding: new interviews, recent support tickets, fresh usage numbers. Their picture of "what matters" is always up to date.

2. They let the data argue, not the people

In most teams, roadmap discussions are political. The loudest voice wins. In great teams, every roadmap item links back to specific user evidence: interviews, tickets, data points. When someone asks "why are we building this?", the answer isn't "because I think so." It's "because 47 users told us so, and here are their words."

3. They close the gap between "decide" and "ship"

Even when a team does great discovery, there's often a weeks-long gap between deciding what to build and actually shipping it. The PM writes a PRD. Engineering translates it into tickets. Context gets lost along the way.

Great teams minimize this gap. The output of their discovery process is something engineering can start building from immediately, not a 15-page document that needs another round of interpretation.

The real bottleneck isn't code

With AI coding tools like Cursor, Claude Code, and Copilot, the time from "spec" to "shipped feature" has collapsed. A good spec can become working code in hours.

But that only makes the discovery problem worse. If you can build faster, you need to be more sure you're building the right thing. Speed without direction is just wasted energy.

The teams that win in 2026 won't be the ones with the best engineers. They'll be the ones who always know what to build next, because they have a system for listening to their users at scale.

How to start fixing this today

You don't need to overhaul your entire process. Start with one habit:

Before your next sprint planning, gather all the customer data you have: interviews, support tickets, NPS responses, usage drops. Spend two hours finding the patterns. Not what you think users want. What they're actually telling you.

If two hours feels like a lot, it's because you're doing it manually. That's exactly the problem tools like BuildFR are designed to solve: reading all your customer data, finding the patterns, and surfacing what matters most. But even without a tool, the habit of looking at real data before deciding what to build will put you ahead of 90% of product teams.

Stop guessing. Start listening.