Prioritizing Product Features Under Perceived Urgency

When all features feel urgent, prioritize by objectively quantifying impact against core product goals. De-emphasize subjective urgency. Focus on data-backed decisions. This ensures resources target highest-value outcomes, not loudest requests.

Why This Happens

Perceived urgency for all features stems from several factors. Stakeholders often lack a shared product vision metric. Each individual evaluates features based on their specific priorities. Customer feedback without segmentation or clear business context creates a deluge of equally-weighted requests. An absence of objective scoring mechanisms forces subjective comparisons. Finally, a reactive development culture without strong product management encourages this.

How to Approach It

1. Define Primary Product Goal: Establish one clear, measurable North Star Metric. This metric represents the core business value delivered. All feature prioritization must align directly with this goal.
2. Establish Secondary Metrics: Identify 2-3 supporting metrics. These might include activation rates, retention, or conversion. Ensure these also map to the primary goal.
3. Quantify Feature Impact: For each proposed feature, estimate its direct, measurable impact on the primary and secondary metrics. Use historical data or A/B test results if available. If no data exists, assign a quantitative proxy score. Avoid qualitative assessments.
4. Assess Implementation Cost: Estimate engineering effort. Include design, development, testing, and deployment. Use t-shirt sizes or relative point estimates.
5. Calculate Impact-to-Cost Ratio (ICR): Divide the quantified impact by the estimated cost. Features with higher ICRs yield more value per unit of effort. This provides an objective ranking.
6. Identify Strategic Dependencies: Determine if a feature unlocks future high-ICR work. Factor this strategic value into the overall prioritization. Do not overweigh this.
7. Set a Scope Box: Define a fixed time or resource allocation for the next development cycle. Only select features that fit within this box, ordered by ICR. Adhere strictly to the box.
8. Communicate Decisions: Clearly articulate the prioritization framework. Explain why certain features were selected and others deferred. Refer to the North Star Metric.

Practical Example

A B2B SaaS startup builds a project management tool. Their North Star Metric is “Weekly Active Project Collaborations (WAPC).” Each user collaborating on a project counts towards WAPC. Their secondary metric is “New Account Activation Rate.”

The team faces requests for:

• Feature A: Native integration with a popular CRM. (Requested by sales)
• Feature B: Custom analytics dashboards. (Requested by a large anchor customer)
• Feature C: Improved mobile notifications for task assignments. (Identified by product after user interviews)
• Feature D: Export project data to CSV. (Common support request)

They apply the approach:

1. Primary Goal: Increase WAPC.
2. Secondary Metrics: New Account Activation Rate, Daily Active Users (DAU).
3. Quantify Impact:
   • Feature A (CRM Integration): Estimated +5% New Account Activation Rate, indirectly +2% WAPC (new users from CRM).
   • Feature B (Custom Dashboards): Estimated 0% New Account Activation, potentially +1% DAU (for specific users), no direct WAPC impact.
   • Feature C (Mobile Notifications): Estimated +3% DAU, +4% WAPC (better collaboration due to timely alerts).
   • Feature D (CSV Export): Estimated reduction in support tickets, no direct WAPC or activation impact.
4. Assess Cost:
   • Feature A: High (Complex API integration, security, data mapping).
   • Feature B: Medium (Requires new UI components, backend aggregation).
   • Feature C: Low (Utilizes existing notification service, minor UI adjustments).
   • Feature D: Very Low (Existing data, simple export script).
5. Calculate ICR:
   • Feature A: (Impact: Moderate, Cost: High) -> Low ICR.
   • Feature B: (Impact: Low, Cost: Medium) -> Very Low ICR.
   • Feature C: (Impact: High, Cost: Low) -> Very High ICR.
   • Feature D: (Impact: Nil on WAPC, Cost: Very Low) -> Cannot calculate WAPC ICR, but high on non-core value (support overhead). This falls under /blog/measuring-engineering-time-lost-to-investigations.
6. Strategic Dependencies: None identified as critical for immediate future work.
7. Scope Box: One 2-week sprint for a small team.
8. Decision: Feature C is prioritized. It has the highest ICR directly impacting WAPC. Feature D is considered for a future maintenance sprint due to its low cost and support benefit, but not WAPC impact. Features A and B are deferred. The team can develop minimum viable solutions rather than full features.

Common Mistakes

• Prioritizing by Loudest Voice: Giving undue weight to a single influential stakeholder or customer. This leads to features that benefit few users, not the overall product.
• Ignoring Implementation Cost: Focusing solely on perceived value without accounting for engineering effort. A high-value feature with extreme cost often has a lower actual return than a medium-value, low-cost feature.
• Constantly Shifting Priorities: Reacting to every new request or problem without a stable framework. This creates context switching overhead and fragmented development. It often leads to unrealistic engineering timelines.
• Lack of a North Star Metric: Without a clear, quantifiable primary goal, all features appear equally important. This makes objective decision-making impossible.
• Over-optimizing for Maintenance/Bug Fixes: While critical, maintenance features that do not directly improve core product metrics or reduce significant engineering time lost to investigations should be balanced against growth features.

Key Takeaways

• Define a single, measurable product North Star Metric.
• Quantify feature impact objectively against this metric.
• Estimate implementation costs accurately for all features.
• Use an Impact-to-Cost Ratio for objective ranking.
• Strictly adhere to a fixed development scope.

Related: how we help founders build products