I’ve seen this happen more times than I can count someone comes up with a brilliant idea, gathers a team, writes a few PRDs, jumps into design, and before you know it, developers are coding away.

Fast-forward a few weeks… and the product launches to the sound of crickets.

No traction.
No active users.
No revenue.

Just pain, regret, and “But I thought users would love this!”

I’ve been there too. Early in my product journey as a developer-turned-PM, I built things because they felt cool. They looked exciting on paper. They made sense to me. But the market didn’t care. And that reality taught me one thing:

Products don’t succeed because they are well-built. They succeed because they are well-validated.

This deep dive is my attempt to simplify idea validation not the textbook version, but how I’ve learned (sometimes painfully) to validate ideas in the real world.

Why Idea Validation Matters More Than the Idea Itself

In my early journey as a product manager, one of the things I loved (and still do) to do a lot is assumptions and ideas validation, the process of talking to users about an idea, getting real feedbacks and interviewing potential users.

In product management, the hardest truth is this:

You are not your user.

And if you’re building only from your own assumptions, you’re already in trouble.

Validation saves time, reduces cost, and gives clarity. But more importantly, it does one powerful thing:

It shifts your mindset from “building features” to “solving problems.”

And when you start thinking in terms of problems, not solutions, everything changes.

Step 1: Start With a Problem, Not an Idea

Ideas are cheap.
Problems are expensive.

A useful question I like asking myself is:

“Is this a real problem or an imagined one?”

When we were building at Mealfed, one of the first things we validated was whether underserved communities truly struggled with reliable and affordable food delivery.
Not just in big cities but in places most delivery apps don’t reach.

We spoke to users.
We walked in the markets.
We observed how they ordered meals.
We studied their frustrations.

Before writing a single line of code, we documented real, painful, recurring problems.

That’s the foundation of good product work.

Step 2: Validate the Demand, Do People Actually Want This?

A problem is only meaningful if people are willing to solve it.

Here are the simplest signals of demand (in plain English):

• People are already hacking together a solution.
• They complain loudly and frequently about the issue.
• They are actively searching for alternatives.
• They are willing to try anything that makes their lives easier.

You’d be surprised how many products fail because they solve a problem people don’t care enough about.

If users wouldn’t switch from WhatsApp, Excel, pen-and-paper, or the status quo…
The product is dead before arrival.

Step 3: Validate Feasibility: Can You Actually Build This?

This is the step people skip the most.

At one of my previous roles, we designed a savings product, beautiful screens, clean flow, solid logic. Only to find out weeks later that the entire experience depended on a third-party API with limitations that broke our original plan.
We had to redesign everything.

Lesson?
Validate feasibility early.

Ask:

• Do we have the technical resources?
• Do we have the data?
• Are there dependencies or constraints?
• Can we test something quickly without building the whole thing?

PMs who understand feasibility save their teams from months of chaos.

---

Step 4: Validate the Solution: Before Writing Any Code

Validation is NOT a big launch.
Validation is a series of small experiments.

Here are simple, practical ways to test your solution early:

✔ Landing Page Test

Promise the value. Measure sign-ups or interest.

✔ Figma Prototype Test

Let users click through. Watch where they get confused.

✔ Concierge MVP

Manually deliver the service behind the scenes before building automation.

✔ Social Media Demand Test

Put the idea on X/LinkedIn; watch reactions and feedback.

✔ Problem Interviews

Ask users what they’re currently doing to solve their pain.

Each one gives real data.
Real reactions.
Real learning.
Before real expenses.

Step 5: Validate the Business — Will It Make Money?

This is very important.

A feature that doesn’t support the business model is a distraction.

Ask yourself:

If this succeeds, how will it sustain itself?

Revenue doesn’t always need to come immediately, but a path must exist.

Some products grow through margins.
Some through subscriptions.
Some through volume.
Some through ads.
Some through partnerships.

What matters is clarity.

At Mealfed, for example, we validated early that delivery pricing, speed, and recurring purchases were the key levers for revenue. That insight shaped our product priorities from day one.

Step 6: Validate the Market Timing

A great idea at the wrong time is still the wrong idea.

Market validation means checking:

• Economic realities
• Technology adoption
• Regulatory environment
• User behavior maturity
• Competitive landscape

Before you build, ask:
Is now the right time?

A Simple Framework to Remember (My Personal Version

I call it the 6P Validation Framework:

1. Problem: Is the pain real?
2. People: Who exactly feels it?
3. Potential: Is demand strong?
4. Practicality: Can we build it?
5. Prototype: Does the solution make sense?
6. Profitability: Does the business work?

If an idea passes all six…
Build.
If not…
Refine or discard.

Final Thoughts: Products Win When Assumptions Lose

The best PMs aren’t the ones with the smartest ideas.
They’re the ones who validate relentlessly.

Validation is humility.
Validation is discipline.
Validation is respect for the user.

If you want to build a product users actually want, don’t start with code.
Don’t start with features.
Start with learning.

Because the strongest products aren’t built in sprints
they’re built from understanding.