Should I Say YES to This Feature Request?
As Product Managers, we need to make sure our product is consistently good throughout time, despite all the forces that try to interfere with it. This is our most challenging job.
Feature requests rain down from every source. My-young-self would jump immediately to discussing roadmap prioritization and trade-offs, trying to please everyone. My-slightly-more-experienced-self learned that when we say YES to all requests, we end up building a Swiss knife. It’s not a good knife; it’s not a good anything. But that’s what happens when there are many trade-offs.
- By building every feature competitors have, we might be making what they are already trying to get rid of.
- By building what “every customer is asking for”, we might just be creating what we heard twice during last week. When we listen to it frequently, and recently, we think it’s a must-have. But it probably isn’t.
- By building what our biggest customers want to pay more for, we might ruin it for every other customer.
- By building that “awesome engagement feature” our executives thought of, we might just be moving the user’s attention around instead of increasing it. And is all engagement good?
- By building what the press says we’re going to do next, we might miss out on more significant opportunities.
- By building what the development team wants to build, we might be wasting resources and time on something that does nothing for the company’s business goals.
- By building that “tiny feature” that doesn’t impact the roadmap, we might discover that it’s just the tip of the iceberg. We’ll have to deal with all the technical debt there’s underneath.
Product Management requires a lot of saying NO. But how are we sure it’s a NO? There can be a precious YES in a haystack of thousand NOs. How can we filter all the noise? And how can we prevent the people suggesting features from getting frustrated when their ideas are not being incorporated?
Here’s a short practical guide. Whenever a request comes in, we should ask three questions:
- What problem is this request trying to solve?
- Does solving that need align with our objectives?
- Is it more important than what we have in the roadmap now?
1. What problem is this request trying to solve?
Most often, specific feature requests are one person’s guess about the best solution to an unstated problem. And many problems are just symptoms of deeper issues. We need to drill down to identify the underlying cause.
There’s a simple method to achieve this — it’s so simple that every child from 3 to 6 years old masters it. In adulthood, it takes the name of the 5 Whys technique. This technique is known to work wonders for fail post-mortems, but it can be just as powerful to get to the bottom of feature requests. We start with the request and then take the time to ask “Why?”, not just once but multiple times, to peel back the layers until we discover the root problem.
Let’s look at the classic Ford example:
Request: I need a faster horse.
- Why? “So I can reach my workplace quicker.”
- Why? “So I can come back home sooner.”
- Why? “To spend less time working and more time on my personal projects.”
- Why? “To improve my knowledge and skills.”
- Why? “So I can grow a business out of them.”
Problem: Too much time spent on transportation. It could be used for greater things.
Once the real issue is revealed, then solving it should be the desired outcome.
❌ If we discover that the issue is not relevant enough for it to be solved or that there’s already a good enough workaround for it, then we stop here. It’s not worth moving the request forward.
✔️ If the issue seems relevant enough, then there’ll be multiple possibilities for solving it, not just the output/feature suggested. But first, there are two more questions we should ask:
2. Does solving that need align with our objectives?
Before taking the initiative to solve problems, we need to check if those are our problems to solve. The world is full of things waiting to be improved, but we won’t be able to help any of them if we decide to tackle them all. We need to choose a direction and pick our battles.
In a company, Vision sets the ultimate direction — every decision needs to move the product closer towards making it a reality. But that alone is not enough. We have to find a sustainable way to get there and have tangible goals that represent crucial steps forward. That’s what Business Intents are for.
When we pick the digested desired outcome that you got from question 1, we need to distinguish if it’s simply providing value or if it’s an accomplishment needed to support our company to reach its Vision and Business Intents.
We should ask:
- Does this fit our Vision?
- Is it a forward step along the way?
- Can we grow the business because of it?
- Will it really generate new and relevant engagement?
- Will it increase adoption?
- Will it matter in 5 years?
❌ If the desired outcome doesn’t survive any of these questions, then we stop here.
✔️ But if it proves to be aligned with your objectives, then there’s one more question we should ask:
3. Is it more important than what we have in the roadmap now?
When the request arrived, we already had a set of priorities represented on a roadmap. Is the desired outcome from the request more important than the other outcomes we planned to be working on in the foreseeable future?
❌ If not, then we can probably stop here. It’s too far out in the future to think about it now. When the time comes, the context will have changed so much that it’s not worth saving it — let’s be pragmatic.
✔️ If yes, then we’ll have to find a place for it on the roadmap. We’ll have to re-prioritize items and trade-off.
Adding something to a roadmap always comes at an expense, even though some conveniently think not. Let’s put our project manager hats on. In every project, we control 4 variables: Cost, Time, Quality, Scope. By adding something to a roadmap, we need to flex 1 of these 4.
By adding scope, either we cut scope elsewhere, or delay delivery times, or raise costs by adding more resources, or lower quality. Whatever we choose to sacrifice, it comes with its drawbacks. The right choice will always depend on the context. Nevertheless, lowering quality or adding resources are the options that itch me most.
By following this flow, most requests will be filtered out at the start. We won’t be wasting so much time negotiating the roadmap. We’ll only do it for input that really matters. Given we decide to incorporate an input, we’ll direct our saved energy to ideate and experiment with ways to solve it when the time comes.
As for the people suggesting features, we should include them in this decision process. When we are transparent on our framework, context, limitations, and variables, we’re contributing to alignment and understanding. Hopefully, they’ll also fall in love with the problem, and they won’t feel frustrated if their ideas are not being incorporated or take another shape.
The biggest beneficiary of this is our product and, ultimately, our users. Our product will constantly remain really good.
