5 Questions Every PM Should Ask Before Prioritizing

Stop Building Features Based on Who's Loudest

Every PM knows the feeling: a customer escalation comes in, an executive forwards an email, or a sales team promises a feature to close a deal. Suddenly, something that wasn't on your radar becomes "urgent."

This is reactive prioritization. It feels productive because you're responding to real requests. But it leads to roadmaps driven by whoever complained most recently, not what will actually move the business.

Before adding anything to your roadmap, ask these five questions.

Question 1: How Many Times Has This Come Up?

One customer complaint is an anecdote. Ten complaints are a pattern. Fifty complaints are a crisis.

The difference matters enormously for prioritization:

• 1 mention: Interesting, but not actionable yet
• 5-10 mentions: Worth investigating further
• 10+ mentions: Likely a real problem worth solving
• 50+ mentions: This is already hurting your business

The challenge is that most teams don't track this systematically. Feedback lives in different channels, and no one has time to count manually. This is where automated feedback analysis becomes essential—not as a nice-to-have, but as a prerequisite for evidence-based prioritization.

Question 2: Is This One Customer or a Pattern?

Related to frequency, but distinct: Is this request coming from one loud customer or multiple segments?

A single enterprise customer requesting a feature represents:

• Their specific workflow (which may be unique)
• Their industry requirements (which may not apply broadly)
• Their leverage (because they're paying a lot)

Before building for one customer, validate with others:

• Do other customers in this segment have the same need?
• Would solving this attract new customers?
• Is the request about their specific setup or a general gap?

Question 3: Is This a Product Problem or a Process Problem?

Not every customer complaint requires a product solution.

Product problems are things the software can't do:

• "I can't export data in CSV format"
• "The search doesn't find partial matches"
• "There's no way to set permissions by team"

Process problems are things the software can do, but customers don't know how:

• "I can't figure out how to export data" (feature exists, UX issue)
• "I didn't know you could search like that" (documentation/onboarding issue)
• "Nobody told us about team permissions" (training issue)

Building features to solve process problems is expensive and ineffective. Often, better documentation, improved onboarding, or support intervention solves it faster.

Question 4: What's the Revenue Impact?

Prioritization frameworks like RICE (Reach, Impact, Confidence, Effort) require estimating impact. But "impact" is vague. Revenue impact is concrete.

Calculate:

• Expansion potential: Would this feature enable upsells?
• Churn risk: Are customers leaving because this doesn't exist?
• Sales conversion: Are deals dying because of this gap?
• Support cost: How much does the workaround cost in support hours?

Even rough estimates help. "This affects 15% of enterprise deals" is more useful than "customers want this."

Question 5: What Do We Already Know About This?

This is the question most teams skip—and it's often the most valuable.

Your company has probably researched this topic before:

• Previous customer interviews that touched on this area
• Support ticket analysis from past quarters
• Competitor research that covered this functionality
• Sales feedback from lost deals

Starting from zero wastes time and misses context. Before kicking off new research, ask: "What do we already know about this?"

If you can't answer that question quickly, you have a knowledge management problem, not a prioritization problem.

Putting It Together

Before any feature hits your roadmap, create a brief intake that answers:

Question	Answer
Frequency	How many times mentioned?
Pattern	One customer or segment?
Type	Product or process problem?
Revenue	What's the $ impact?
Prior Knowledge	What do we already know?

Features that score high across all five deserve prioritization. Features that score low on multiple questions should be deprioritized—regardless of who's asking for them.

The goal isn't to ignore customer feedback. It's to analyze it systematically so you build what matters, not what's loudest.

---