Validating Ideas Before Development: Avoiding Expensive Mistakes

Some context: (You can skip this piece :))

I come from outsourcing, where projects run on fixed budgets. And, of course, to win the project, you slash your margins to the bone—leaving zero time (and money) for experimenting. Once the contract is signed, it’s straight into development, no real validation of ideas.

Now, if you ask a business analyst or a product manager in an outsourcing firm whether they validate ideas, they’ll likely say, “Yes, the client reviews the specs.” But let’s be honest—that’s not validation. That’s just checking whether the requirements are correctly written, not whether the product will actually succeed in the market.

And here’s the kicker: some clients walk into outsourcing agencies thinking the agency is responsible for their product’s market success. But outsourcing companies are development companies, not discovery companies. They build what they’re asked to build, not what the market necessarily wants. (Not to blame them—it’s just not their job.)

Anyway, this article isn’t about clients misunderstanding outsourcing. It’s about validating ideas before you start building. So, let’s get into it.

Validation & experimenting also costs money

When I moved to product management—working with an amazing team—I ran straight into a very trivial but critical problem:
How do we validate ideas before development? I had read all the books (see the list at the end), but in my head, I was still stuck on one big question: “How do I test ideas without spending money?”

For some reason, I had this naive belief that idea validation should cost zero dollars. Spoiler: it doesn’t. That said, testing ideas is significantly cheaper than building an entire product only to realize nobody wants it. And validation isn’t just one step—it’s a continuous process that evolves through different stages:

• Problem validation – Is this an actual problem that people care about?
• Solution validation – Does this solution solve the problem in a way users want?
• User experience validation – Is it easy and intuitive to use?
• Pricing & business model validation – Will people pay for it, and can it be a sustainable business?
• Anything validation

Each stage takes time and money—just not nearly as much as full-scale development.

The Classic Validation Framework

Desirability – Do People Even Want This?

Before worrying about whether you can build something, ask yourself if anyone wants it in the first place.

What Worked for Me: Customer Interviews

Customer interviews have been one of the best tools I’ve used. They have a few big advantages:
✅ They help shape the right user persona and align everyone on who the real customer is.
✅ Once you have a clear user portrait, finding more people like them is super easy—just tap into LinkedIn or social networks.
✅ In B2B (which I usually work with), it’s just about reaching out to companies and seeing who’s open for an interview.

What Didn’t Work for Me: Mass Surveys

Some people swear by mass surveys, but I’m not a big fan. Even with AI (yes, even ChatGPT 😆), writing survey questions that give useful insights is tricky.

• Even when questions are well-formulated, the answers are ambiguous and open to interpretation.
• You don’t get context, which makes it easy to misinterpret data.

Fake Door Tests – Great, but Costs Some Money

Fake door tests—where you set up a landing page for a product that doesn’t exist yet—are nice, but they require marketing money to drive traffic to your page

• Cheapest way? Email outreach.
• More expensive? SEO, ads, or influencer partnerships.

Competitive Research – A Complement, Not a Standalone Method

I see competitive research as a supporting tool, not the main one.

• It’s useful, but not enough on its own.
• You also have to be open-minded—people may already be paying to solve the problem, but not through software.
• This is why I always go back to customer interviews to understand how people pay for solutions today and how much they’re willing to spend.

Feasibility – Can We Build This?

Forget feasibility as just “technical constraints.” For me, the best ways to test feasibility are:

1. Discovery Sprints

A discovery sprint is a time-boxed effort to focus the whole team on solution finding. What works best for me:
✅ Set a clear timeframe. Otherwise, discovery can drag on forever.
✅ Involve engineers early. Tech feasibility is best understood when engineers are in the room.
✅ Have a goal. The goal could be to find the best approach, validate assumptions, or even create a prototype.

2. Proof of Concepts (PoCs) – The Backbone of Feasibility Testing

I love PoCs because they give practical validation.

• A PoC is not an extended MVP—it’s just a small-scale practical experiment to see if something works.
• I sometimes call them “practical research” because, honestly, you never know until you try.

Viability – Will This Make Money?

This is, hands down, the hardest thing to test.

Pre-Orders – A Double-Edged Sword

Pre-orders and deposits are one way to test viability, but there’s always a catch.

• If I get a lot of pre-orders, I start wondering…
  • Am I charging too little?
  • Is demand real, or did I price it so low that people just clicked without thinking?

Pricing Experiments – Tricky but Necessary

I like experimenting with pricing, but too complex pricing structures kill sales.

• If pricing is complicated, you’ll need to create calculators, help materials, and onboarding guides.
• At this point, you’re not just testing anymore—you’re already building.

The Ultimate Question That Keeps You Awake at Night

👉 If people aren’t paying, is it because the product sucks? Or am I just using the wrong pricing strategy?
This question will haunt you. If anyone has the magic formula for solving it, I’m listening. 😆

Final Thoughts: Validate Before You Burn Money

Skipping validation isn’t just risky—it’s expensive. And this is where discovery pays off: you stop spending money before you even start development. It’s the cheapest way to find out if an idea is worth pursuing—or if it’s better left on the “cool, but not viable” pile. And no, validation isn’t free—but it’s a fraction of what you’d spend on full development. If you’re serious about building something people will love and pay for, put in the work upfront. Your future self (and your budget) will thank you. BUT YOU STILL SPEND MONEY, it just saves you from spending a lot of money.

But even with validation, there’s no guarantee of success. Plenty of people had the ride-sharing idea before Uber, yet Uber was the one that made it work. Why? Because validation isn’t just a one-time event—it’s a continuous process.

Once discovery is done, don’t stop—switch into continuous discovery. The market shifts, user behavior evolves, and not every feature or solution you come up with will land well. The goal is to keep iterating, keep cutting off what doesn’t work, and keep doubling down on what does.

The real winners aren’t the ones who validated once. They’re the ones who never stop validating. 🚀

👉 Next Steps: Want to dive deeper? Check out these books:

• The Lean Startup – Eric Ries
• The Mom Test – Rob Fitzpatrick
• Running Lean – Ash Maurya
• Testing Business Ideas – David J. Bland