How I Evaluate a New Feature Idea in 5 Questions

If you’ve ever been in a meeting where someone says, “What if we just add this?” you know how dangerous feature ideas can be.

They usually sound smart. They often come from good intentions. And they regularly end up on roadmaps without anyone stopping to ask the hard questions.

This is the simple framework I use to slow things down before a feature becomes “work.”

Question 1. What problem is this really solving?

Not the polished pitch. Not the slide headline. The real problem.

If I can’t explain the user pain without using buzzwords, that’s a red flag. Most bad features start with fuzzy problems like “users want more flexibility” and end with something no one actually uses.

I’m looking for a problem that shows up often and is annoying enough that users would miss the solution if it disappeared.

Question 2. Who is this actually for?

Every feature is for someone, even if we pretend it’s for everyone.

I ask:

• Which user segment would be disappointed if this didn’t exist?

• Are we solving for our core users or a loud edge case?

• Who won’t even notice?

If we can’t answer this, the feature usually grows in too many directions at once.

Question 3. How would we know we got this right?

This is where a lot of ideas quietly fall apart.

I don’t need perfect metrics upfront, but I do need a clear signal. Are we expecting fewer support tickets? Faster task completion? Better retention?

If success looks like “it feels better,” we’re setting ourselves up for endless debates later.

Question 4. What’s the smallest version that’s still useful?

This is the hardest one.

Teams love jumping straight to the fully-loaded version because it feels safer. But most of the time, we’re guessing. I push for the version that proves (or disproves) the core assumption with the least effort.

If users don’t care about the simple version, they won’t care about the complex one either.

Question 5. What are we choosing not to do because of this?

Every roadmap is a list of trade-offs; we just don’t always say them out loud.

So I force the question:

• What gets pushed back?

• What won’t we have time to improve?

• Is this more important than what we already committed to?

If we’re uncomfortable naming the trade-off, that’s usually a sign the decision isn’t clear yet.

My Final Thought

Most teams don’t fail because they lack ideas. They fail because they say yes too quickly.

This framework doesn’t kill good ideas—it protects teams from building things they’ll have to explain (or defend) later.

The next time a feature idea feels exciting and obvious, I’ve found it’s worth slowing down and asking these five questions first.