How I Evaluate Product Ideas Before They Reach the Roadmap

Category: Product Author: Shivam, Founder at Fidusia

---

Introduction

One of the biggest myths in product management is that great products come from great ideas. They don't. They come from great decisions. Every company has hundreds of feature requests.

• Customers ask for them.
• Sales teams request them.
• Founders think of them in the shower.
• Engineers suggest them during retrospectives.

The challenge isn't generating ideas.

The challenge is deciding which ideas deserve to exist.

Over the years, I've realized that whenever I evaluate a product idea, I subconsciously follow the same sequence of questions.

It's not a formal framework.

It's simply how I think.

This article walks through that mental model.

---

Most Teams Start With the Wrong Question

The first question in many roadmap discussions is:

"What should we build next?"

I think that's the wrong place to begin.

Instead, I start with:

"What problem deserves our attention the most?"

Notice the difference.

One starts with a solution.

The other starts with the user.

That single shift changes the quality of every discussion that follows.

---

Step 1 — Is There a Real Problem?

Every feature request sounds reasonable.

Until you ask:

Who is actually experiencing this problem?

Then:

How frequently?

Then:

How painful is it?

If the answers aren't backed by evidence, the discussion ends there.

Evidence might come from:

• Product analytics
• User interviews
• Session recordings
• Customer support tickets
• Sales calls
• Community discussions

Opinions are useful.

Evidence is essential.

---

Step 2 — Is This the Right Problem to Solve?

Not every problem deserves engineering time.

I usually ask:

• Does this affect our core users?
• Does it impact business goals?
• How many people experience it?
• Is the pain recurring or occasional?

Many interesting problems simply aren't important enough.

That's okay.

Roadmaps are built through prioritization—not generosity.

---

Step 3 — What Assumptions Are We Making?

Every feature is built on assumptions.

For example:

Users don't complete onboarding because the process is too long.

Maybe.

Or maybe they don't understand the product's value.

Or perhaps they never intended to use the product in the first place.

Different assumptions lead to completely different solutions.

Before discussing implementation, I try to write down every assumption we're making.

Once assumptions become visible, they can be tested.

---

Step 4 — Can We Learn Before We Build?

One of my favorite product questions is:

What's the smallest experiment we can run?

Examples include:

• Landing pages
• Fake door tests
• Manual workflows
• Concierge onboarding
• Prototype testing
• A/B experiments

Learning early is significantly cheaper than rebuilding later.

---

Step 5 — What Does Success Actually Look Like?

Many teams celebrate launches.

Users celebrate outcomes.

Before approving a feature, I define success.

Examples:

• Increase activation by 15%
• Improve retention by 8%
• Reduce support tickets
• Increase weekly active users
• Improve task completion rate

If success can't be measured, it's difficult to know whether the feature solved anything.

---

Step 6 — What's the Cost of Saying Yes?

Every roadmap item competes with another opportunity.

Building Feature A usually means delaying Feature B.

That's why I rarely evaluate ideas in isolation.

Instead, I ask:

What are we choosing not to build?

Opportunity cost is invisible—but it's always present.

---

My Mental Model

Whenever I evaluate a product idea, my thinking usually follows this sequence:

textProblem
   ↓
Evidence
   ↓
Priority
   ↓
Assumptions
   ↓
Experiment
   ↓
Build
   ↓
Measure
   ↓
Learn

Notice what isn't at the top.

The feature.

The feature only appears after we've earned confidence that it's worth building.

---

Why This Matters

Many organizations accidentally reward shipping.

I believe product teams should reward learning.

Sometimes the biggest win isn't launching a feature.

It's discovering that the feature was never needed.

That's a successful product decision.

---

Questions I Keep Asking

Whenever I review a product idea, these questions stay on my desk:

• What problem are we solving?
• Who experiences it?
• How do we know?
• What's our evidence?
• What's the smallest experiment we can run?
• How will we measure success?
• What are we giving up by building this?

These seven questions eliminate surprising amounts of noise from roadmap discussions.

---

Key Takeaways

• Great products begin with great questions—not great ideas.
• Start with problems instead of solutions.
• Validate assumptions before committing engineering resources.
• Measure outcomes instead of celebrating output.
• Every "yes" on the roadmap is also a "no" to something else.
• Strong product decisions come from evidence, not intuition alone.

---

Final Thoughts

Product management isn't about having the best ideas.

It's about making the best decisions with incomplete information.

Ideas are easy.

Prioritization is difficult.

Execution is expensive.

That's why I've found it more valuable to improve my decision-making process than to chase more ideas.

The better your thinking becomes, the better your roadmap becomes.

Every roadmap is ultimately a reflection of the decisions that shaped it.

Make those decisions intentionally.

---

About the Author

Shivam Giri is the Founder of Fidusia, where he writes about product management, product strategy, UX, growth, and the decision-making behind building products people love.