Introduction
Product development is fundamentally about making choices. With limited resources and time, product teams must constantly decide which features to build, improve, or defer. Yet many product managers rely on intuition or stakeholder pressure rather than structured reasoning when prioritizing features.
Here at Allstar.Software, we excel at breaking down and prioritizing functionality scopes, ensuring the most critical elements consistently receive the highest priority.
This article introduces a powerful framework for feature prioritization based on the philosophical principle of "reductio ad absurdum" (reduction to absurdity). By systematically analyzing what happens when a feature is absent or broken, teams can make more objective decisions about what truly matters to their users and business.
The Reductio ad Absurdum Framework
Rather than asking "How important is this feature?", which often leads to subjective answers, the reductio approach asks: "What would happen if this feature didn't exist or was broken?"
This question produces clearer insights that can be categorized into three levels of impact:
Level 1: Functional Failure - "It won't serve the purpose"
At this level, the absence of the feature makes the product unable to fulfill its core purpose. These are must-have features without which the product essentially doesn't work.
Examples:
- Authentication in a private service (users can't access anything)
- Payment processing in an e-commerce site (no transactions can occur)
- Search functionality in a search engine (the core value proposition disappears)
- Database connection in a CRM (can't access customer data)
These features are non-negotiable and should be prioritized above all others.
Level 2: Functional Friction - "It serves the purpose but less conveniently"
At this level, the core functionality remains intact, but users must employ workarounds or endure inconvenience. The product still works, but the user experience degrades.
Examples:
- Direct image pasting is broken, but users can still upload via a file dialog.
- Autocomplete is missing, but users can still type full entries manually.
- Bulk actions are unavailable, forcing users to perform repetitive individual actions.
- Keyboard shortcuts don't work, requiring more mouse navigation.
These features significantly impact efficiency and satisfaction but don't prevent core usage.
Level 3: Perception Impact - "It serves the purpose without workarounds, but is perceived worse"
At this level, functionality and convenience remain intact, but the user's perception of quality, professionalism, or brand alignment suffers.
Examples:
- Inconsistent styling or outdated design.
- Minor visual glitches that don't affect functionality.
- Lack of animations or transitions between states.
- Non-optimized performance that's noticeable but not disruptive.
These features affect brand perception and may impact long-term user retention and satisfaction.
Contextual Factors: Why One Size Doesn't Fit All
The importance of each level varies dramatically depending on the product context. What constitutes a Level 3 issue for one product might be Level 1 for another. Several factors influence this calibration:
Product Type and Audience
- Internal tools typically have more forgiving users who prioritize functionality over aesthetics.
- Consumer products face users with lower tolerance for friction and higher aesthetic expectations.
- Professional tools may have users who value efficiency over aesthetics but won't tolerate workflow disruptions.
- Luxury or premium products have users with elevated expectations across all dimensions.
Product Lifecycle Stage
- MVP/Early stage: Focus on Level 1 issues and critical Level 2 issues.
- Growth stage: Address remaining Level 2 issues and begin addressing high-impact Level 3 issues.
- Mature stage: Refine all levels, with increasing attention to Level 3 issues.
Competitive Landscape
- Few alternatives: Users may tolerate more issues across all levels.
- Highly competitive: Even Level 3 issues may drive users to alternatives.
- Disruptive entrant: Novel core functionality may temporarily overshadow Level 2 and 3 issues.
Stakeholder Analysis and Prioritization Matrix
To apply this framework effectively, create a stakeholder-feature prioritization matrix. This approach acknowledges that different stakeholders have different perspectives on what constitutes a Level 1, 2, or 3 issue.
Step 1: Identify Key Stakeholders
Common stakeholders include:
- Primary user personas (may have several)
- Secondary user personas
- Business stakeholders (revenue, growth, legal)
- Technical stakeholders (engineering, operations)
Step 2: Create a Prioritization Matrix
Below is an example matrix for a project management tool with four stakeholder groups:
| Feature | Project Managers | Team Members | Executives | Technical Ops |
|---|---|---|---|---|
| Task Assignment | L1 - Critical for workflow management | L1 - Need to know responsibilities | L2 - Important for oversight | L3 - Not directly relevant |
| Gantt Charts | L2 - Helpful for planning | L3 - Occasionally referenced | L1 - Critical for timeline visibility | L3 - Not directly relevant |
| Dark Mode | L3 - Nice to have | L3 - Preference for some | L3 - Rarely noticed | L3 - Not directly relevant |
| File Attachment | L1 - Critical for documentation | L1 - Needed for work artifacts | L3 - Rarely used directly | L2 - Storage implications |
| API Access | L3 - Not directly used | L3 - Not directly used | L2 - Enables integrations | L1 - Critical for system integrations |
| Activity Reports | L2 - Useful for tracking | L3 - Occasionally referenced | L1 - Critical for oversight | L2 - Data generation concerns |
Step 3: Determine Overall Priority
When analyzing the matrix, look for:
- Features that are Level 1 for multiple stakeholders (highest priority).
- Features that are Level 1 for primary users but lower for others (high priority).
- Features that are never above Level 3 for any stakeholder (lowest priority).
| Feature | Project Managers | Team Members | Executives | Technical Ops | Overall Priority |
|---|---|---|---|---|---|
| Task Assignment | L1 - Critical for workflow management | L1 - Need to know responsibilities | L2 - Important for oversight | L3 - Not directly relevant | HIGH |
| Gantt Charts | L2 - Helpful for planning | L3 - Occasionally referenced | L1 - Critical for timeline visibility | L3 - Not directly relevant | MEDIUM |
| Dark Mode | L3 - Nice to have | L3 - Preference for some | L3 - Rarely noticed | L3 - Not directly relevant | LOW |
| File Attachment | L1 - Critical for documentation | L1 - Needed for work artifacts | L3 - Rarely used directly | L2 - Storage implications | HIGH |
| API Access | L3 - Not directly used | L3 - Not directly used | L2 - Enables integrations | L1 - Critical for system integrations | MEDIUM |
| Activity Reports | L2 - Useful for tracking | L3 - Occasionally referenced | L1 - Critical for oversight | L2 - Data generation concerns | MEDIUM-HIGH |
Consider weighting stakeholders differently based on their importance to your product strategy. For example, in a B2B product, the needs of paying clients might be weighted more heavily than end users.
Implementation Strategy
Once you've categorized features using this framework, consider these implementation strategies:
For Level 1 (Functional Failure) Features:
- Include in MVP/initial release.
- Implement comprehensive testing.
- Establish monitoring and alerting.
- Create fallback mechanisms where possible.
For Level 2 (Functional Friction) Features:
- Prioritize based on frequency of use and severity of workaround.
- Implement after core functionality is stable.
- Gather usage metrics to validate importance.
- Consider A/B testing to measure impact.
For Level 3 (Perception Impact) Features:
- Batch similar updates for efficiency.
- Time with regular update cycles.
- Consider market segments where perception is most critical.
- Use as "delighters" when core functionality is solid.
Case Study: E-Commerce Platform
Consider an e-commerce platform evaluating these features:
- Credit Card Processing Analysis: Level 1 for customers and business (no purchases possible without it). Decision: Must include in initial release with highest reliability.
- Saved Payment Methods Analysis: Level 2 for customers (can re-enter card), Level 2 for business (slightly lower conversion). Decision: Important but can follow after initial stable release.
- Product Recommendations Analysis: Level 3 for customers (nice but not essential), Level 2 for business (impacts revenue). Decision: Medium priority, implement after core functions are stable.
- Order History Analysis: Level 2 for customers (important for tracking), Level 2 for service team, Level 3 for business. Decision: Medium-high priority, implement in early post-MVP release.
Conclusion
The reductio ad absurdum approach to feature prioritization shifts the conversation from subjective importance to objective impact analysis. By systematically examining what happens when features are absent, teams can:
- Make more defensible prioritization decisions.
- Align stakeholders around objective criteria.
- Balance user needs with business requirements.
- Allocate limited resources more effectively.
Remember that prioritization is not a one-time exercise but an ongoing process. As your product evolves, user expectations shift, and competitive landscapes change, revisit your feature evaluations regularly using this framework.
By distinguishing between features that cause functional failure, create friction, or merely impact perception, product teams can deliver what matters most while maintaining a sustainable development pace.