The Intelligence Problem Most PMs Don't Solve

I’ve seen this pattern at five different companies now. Smart PMs, experienced teams, solid processes—and they’re still making bad decisions. Not because they’re not capable. Because they’re flying blind.

Here’s what happens: A PM gets tasked with prioritizing the roadmap. They dutifully run customer interviews, collect feedback from support tickets, check the NPS scores. They feel like they’re doing everything right. They present a roadmap backed by “customer insights.” The team builds it. And six months later, customers don’t care.

What went wrong? The PM wasn’t lacking talent or effort. They were lacking intelligence—the kind that actually matters.

Most Feedback Is Noise

The worst thing you can do as a PM is treat all customer feedback equally. But that’s exactly what most teams do. They build systems that collect everything: every support ticket, every feature request, every casual comment in a sales call. Then they wonder why they can’t figure out what to build.

I learned this the hard way at my last company. We had thousands of data points. Spreadsheets full of feedback. Every PM felt like they were “close to the customer.” But when we actually looked at what we were building, it didn’t match what customers actually needed. We were responding to noise, not signal.

The problem wasn’t the volume of feedback. It was that we treated it all the same. A casual comment from a prospect got the same weight as a critical blocker from our biggest customer. A nice-to-have request from someone who’d never buy got logged next to a deal-breaking issue from a paying customer.

Intelligence Is About Context

What changed? We stopped collecting feedback and started building intelligence.

Intelligence isn’t just data. It’s data with context. Who said it matters. Why they said it matters. What they’re actually trying to accomplish matters. The difference between “I wish this was faster” from a power user versus a first-time user is massive—but most feedback systems throw them in the same bucket.

Here’s what real product intelligence looks like:

Customer context. Every piece of feedback should be tagged with who said it, what segment they’re in, how much they pay you, and how they actually use your product. Not because you’re trying to only listen to big customers—but because the same request from different contexts means different things.

Job context. What job is the customer trying to do? Not “they want feature X.” What are they actually trying to accomplish? I’ve seen teams build entire features because “customers asked for it” only to discover customers just wanted to solve a problem the feature didn’t actually address.

Pattern recognition. One person asking for something is a feature request. Twenty people asking for it might be a pattern. Twenty people from your target segment asking for it because it blocks a critical job? That’s intelligence.

Building Systems That Work

Most teams think about this wrong. They think: “We need a better way to organize feedback.” So they buy a tool, create a taxonomy, and feel productive. Six months later, they’re back where they started.

The problem isn’t organization. It’s that you’re still collecting feedback, not building intelligence.

At my current company, we built something different. We don’t have a feedback database. We have an intelligence system. Every input gets processed through filters:

• Who said it? Not just name and company—segment, usage pattern, strategic importance.
• Why do they care? What job are they trying to do? What’s the underlying need?
• How urgent is this? Are they blocked? Working around it? Mildly annoyed?
• What’s the pattern? Is this isolated or recurring? New or long-standing?

This sounds like more work. It is. But here’s what we get: When a PM sits down to prioritize, they’re not looking at a list of feature requests. They’re looking at intelligence about what jobs customers are trying to do, what’s blocking them, and where the leverage points are.

The difference is night and day.

What This Actually Looks Like

Let me give you a real example. We kept hearing requests for “better filtering.” If we’d had a traditional feedback system, we’d see fifteen tickets about filtering and think “okay, we should improve our filters.”

But when we looked at the intelligence—who was asking, why they cared, what they were trying to do—we discovered three completely different jobs:

1. Sales ops people trying to segment lists (blocked daily, critical to their job)
2. Executives wanting to slice data for board presentations (monthly need, nice-to-have)
3. Customer success trying to find at-risk accounts (weekly need, working around with exports)

Same feature request. Completely different problems. Building “better filtering” wouldn’t have actually solved what mattered most. Building role-based views did.

You only see this when you build for intelligence, not feedback.

The Hard Part

The hard part isn’t the system. It’s the discipline.

Every company wants better product decisions. Few are willing to do the work of actually building intelligence. It’s easier to collect feedback, throw it in a spreadsheet, and call it customer-driven development.

What I’ve learned: If your PM team is making decisions based on “what customers are asking for,” you’re already behind. The best product work happens when PMs understand jobs, patterns, and context well enough to see opportunities customers haven’t articulated.

That only comes from building real intelligence systems. Not feedback databases. Intelligence systems.

Most companies won’t do this work. Which is why most products feel like Frankenstein’s monster—a collection of requested features that don’t add up to a coherent whole.

The teams that win? They’re the ones who stop collecting feedback and start building intelligence.