How to Validate Ideas When User Feedback Fails

100% honesty here - I thought I'd do a great job at listening to user problems, which would tell me what to build. I analyzed about 5 different sources of information for my next app - all pretty good and data rich, but found nothing that said 'build this'. In the end, I'm going with a partial market signal, and what I think might be helpful to users. Now here's the problem - 'think' and 'might' are disastrous words when you need to produce something that gives genuine returns. So I need a way to tell me what I'm thinking is right or not. Building products doesn't take much time (thanks to vibe coding), but getting to users, building funnels around them, getting SEO traffic - all takes time. So you need some sort of signal beyond your thinking and builder excitement to go all in. And that's the step that makes the whole philosophy of doing small experiments come alive. Validating ideas - because only user listening can't give you the validation you were looking for.

Don't get me wrong - listening to users is never a bad idea. It genuinely works - but much like most good things in life, it won't help you when you desperately need it to help you. User listening is an ongoing process, and you need to act when you get the signal and see a pattern. I did the opposite - I decided my moment of action, and then looked up to see what signals were coming. If you take this approach, you'll always be the last person to know about what's really going on. People are always listening, in the domain, ready to build, so your timing is everything.

But I got the next best thing - a thought and partial signal. So I need to fill the gaps myself.

What does a validated idea look like?

If we want to crack the process of getting to a validated idea, then we need to understand what does a validated idea look like. Let's look at an example:

A monday.com app builder had no audience, no network, no existing customers. What he had was time and a willingness to read. He spent it in monday.com Facebook groups and community forums, not posting, just watching - looking for the complaints that kept coming back. The one that turned into his most successful app wasn't a feature request. It was a workaround. Power users were manually duplicating data across boards to simulate synchronisation that the platform didn't natively support. They weren't asking for a solution. They were just living with the friction. He built the solution anyway, shipped it in two weeks, and let the marketplace do the rest. The community was already there. The pain was already documented. He didn't need an audience because he found one that already existed - and it had already told him exactly what it needed, without being asked.

This is the most clear example of a validated idea - something that is a user reported pain, repeating, and partially solvable by a manual workaround - best if that workaround also incurs cost.

But all of us are not that lucky - I couldn't find such an idea in the moment I was looking. So I need to build a way to say:

1. The idea is a pain to users, enough to make them express it (user reported)

2. The pain is not situation specific - happens to most users (repeated)

3. The pain is strong enough that people try to find ways to solve it by paying for it (like knowing that people are using paid workarounds for it)

The intention-behaviour gap

Cold email marketing promoters are telling me the same thing - ask users, talk to them. And yes, talking to users is a great way to get things moving in business. But when it comes to idea validation, asking users is not enough, because users suffer from the intention-behaviour gap. They usually can't differentiate between what is good to have vs what is essential in the moment of being asked.

The research behind this is a meta-analysis of 422 studies. The finding is uncomfortable: even when someone genuinely intends to do something - not lying, not being polite, actually meaning it - their intention only explains about a quarter of what they end up doing. The gap isn't deception. It's the distance between how people imagine their future behaviour and how they actually behave when the moment arrives, with real friction, real cost, real alternatives competing for attention. For a solo founder asking "would you pay for this?", the problem isn't that people lie. It's that they answer from imagination. And imagination is cheap. The act of paying (or not paying) - is where the real answer lives.

The evolution of behaviour based validation

How users act on an unforced discovery is the key to validation. You can get users to act at different stages of development, and trigger it from multiple places too.

Different stages of dev:

Stage 1: You can trigger action to a landing page with a waitlist - this is a commonly used method if you're thinking of building a complex platform OR something like a community or course.

Earlier, it would usually come in before you started building, since building took time and effort. But in 2026, this has changed - not suddenly but slowly. People started building landing pages with a waitlist, because that was what vibe coding tools produced without errors - they are exceptional at it. So people give prompts, they get a landing page, they reach out through DMs, reddit and community posts, drive traffic to a landing page and that leads to waitlist numbers. Based on the waitlisted people, and traffic to the landing page - you get to know if the idea has legs.

Stage 2: You can trigger action to the stage of MVP, so users can access a free MVP and then see how many retain or return.

As vibe coding tools enhanced, I think the validation process also evolved. Now you build an actual MVP in days - solve the core problem quickly and then drive traffic to a buy button. As the buy button clicks scale, your product scales too. This is more like a grow-as-needed approach. The core idea of an MVP based validation is to find out if the most essential part of the product has a need or not.

Stage 3: A possible next step in behaviour based validation is to build a more core product - something that's more than a simple MVP page. You can spend a day with AI assisted coding and make it more like an actual product. So this is the cheapest version of the product - one that helps you go just above break-even. So now it's more than just creating MVPs, you create something that is close to the final product so they want more - that is the real test in many ways.

I'm building a monday.com app, it's mostly ready. I'm now going to give it a landing page, with option to install. I'm going to try this approach at marketing, so I'll be doing multiple experiments and see what lands - landing page, MVP, core product - all stages. Back it with some marketing on reddit plus the monday community, and YouTube to land people at the landing page, and see if they install. Only if it grows will I invest more time in it. I'll be sure to share the results here.

Follow along as I build and experiment in public - @lifedesignshare on X.