The ABCs of Evaluating Customer Feature Requests
Working in church management software over the last few years, customers would reach out with requests for new features or improvements. These requests can be incredibly valuable. They identify real-world needs, real frustrations, and real opportunities. But they can also pile up quickly, making it challenging to determine what should be prioritized.
To bring clarity and consistency to the decision-making process, I like to evaluate and document each request using the ABC method: Alternatives, Benefits, and Considerations. This structure helps teams stay grounded, make thoughtful decisions, and keep the product moving in the right direction.
A — Alternatives
When a feature request comes in, a good first question is: Are there alternatives that already solve this problem?
Sometimes the customer simply isn’t aware of existing functionality or a workaround. Other times, the request might fall outside the intended scope of your software entirely. There may already be other tools that the customer could use to solve the problem beautifully.
Even if the alternative isn’t exactly what the customer asked for, the important thing to document is that the problem is solvable without building something new.
It’s also important to remember that the current features were built in a specific way for a reason. What looks like a missing option or oversight to the customer may actually be an intentional design decision made to support simplicity, data integrity, or long-term maintainability. Revisiting the original intent of the feature helps you determine whether the new request aligns or conflicts with the underlying design.
B — Benefits
Next, consider the potential benefits of the request both for the customer who made the request and for the broader customer base.
This part is usually straightforward because customers tend to describe why they want the feature and how it would help them. Their reasoning gives your team insight into whether the request aligns with the product’s mission, improves usability, removes friction, or adds meaningful value. And if the reasons aren’t clear, it’s always worth following up and asking the customer to explain the benefits in more detail.
It’s also helpful to note how many customers have asked for the same thing. Multiple requests for the same feature can be a strong signal that the feature would make a significant impact.
C — Considerations
Finally, take time to explore the practical implications of building the feature.
Some requests would require significant development time, architectural changes, or brand-new components. Others can be built quickly thanks to existing patterns and reusable UI components. Documenting this helps you assess effort versus impact.
Some questions could include:
- What would it look like if we built it today?
- Would this require new database columns or structural changes?
- Can we reuse existing components or patterns?
- Are there technical risks or future maintenance costs?
- Does this fit naturally with the direction of the product?
Sometimes the way forward with a feature becomes more clear after several customers request something similar. The “Considerations” step captures that and helps shape an informed decision.
Why the ABC method Matters
Using the ABC method ensures that each feature request is evaluated thoughtfully, consistently, and fairly. Instead of reacting to whichever customer is loudest or most persuasive, your team can ground decisions in a shared process—one that balances customer needs, product vision, and technical reality.
Most importantly, documenting the ABCs creates a reference for future roadmap planning. It makes feature discussions easier, provides clarity for support teams who respond to customer requests, and keeps the entire organization aligned on why certain requests are prioritized and others are not.