Most products fail because the founder skipped one step: checking if anyone actually cares.
Not "would you use this?" caring. Real caring - where someone gives you their time, reputation, or money before you have written a line of code.
I have spent 15+ years helping founders go from idea to launch at Wednesday Solutions. The ones who succeed are not smarter or better funded. They just validate harder and earlier. The ones who skip validation end up six months and $100K deep into something nobody needs.
We have seen this pattern play out across 20+ client engagements rated 4.8/5.0 on Clutch. The founders who win are not the ones with the best ideas. They are the ones who pressure-test their ideas before they build. Here is the exact process.
Step 1: Stop Asking People If They Like Your Idea
This is the number one mistake. You describe your product to someone, they say "oh yeah that is cool, I would totally use that," and you walk away feeling validated.
You are not validated. You just got a compliment. Compliments are worthless.
Here is what to do instead, from a framework called The Mom Test by Rob Fitzpatrick:
Ask about their life, not your idea.
Good questions:
"Tell me about the last time you dealt with [problem]..."
"What is the hardest part about [problem area]?"
"How are you solving this today?"
"What have you tried that did not work?"
"How much are you currently spending on this?"
Bad questions (never ask these):
"Do you think this is a good idea?"
"Would you use a product that does X?"
"How much would you pay for this?"
"What features would you want?"
The difference: good questions uncover facts about past behavior. Bad questions invite speculation and politeness. Your mom will tell you your idea is great. Your customers will too, if you let them. The Mom Test is about not letting them.
When Jackson Reed was building Vita Sync Health, an AI-driven behavioral health companion, the real insights did not come from people saying "great idea." They came from understanding how users, clinicians, and investors actually experienced behavioral health tools - what frustrated them, what they wished existed, where current solutions fell short. That discovery process shaped everything we built together during Sprint Zero. The result: retention improved from 42% to 76% in three months, and the product secured partnerships with three major mental health provider networks.
Step 2: Track Commitments, Not Compliments
After every conversation, ask yourself: did this person commit something real?
There are four types of commitment signals, and they exist on a ladder:
Time - they agree to a longer meeting, an office visit, or to review your documents. This is the lowest rung, but it is still real. Someone giving you 30 more minutes of their day is saying "this matters enough to invest my attention."
Reputation - they introduce you to their boss, a colleague, or publicly endorse what you are doing. This is bigger. They are putting their name next to yours.
Financial - a letter of intent, a pre-order, a deposit. Anything involving their wallet. This is the gold standard of validation.
Effort - they agree to run a pilot, provide their data, or change their workflow to test your thing. This is often more valuable than money because it means they are willing to disrupt how they work.
If you are getting lots of "this is great!" but zero commitments, you do not have validation. You have encouragement. Those are very different things.
Nick Meyer and Nate Hoskin at Sage Content AI had real commitment signals before we ever started building. They had a waitlist of 100 financial advisors who wanted their video content creation tool. That was not polite interest - those were people who had raised their hand and said "I need this." We built the backend, connected their AI agents, and set up the user management system. They collected over $50,000 in their first week, launching only to that waitlist. That is what real demand looks like.
Step 3: Score the Opportunity
Not every problem is worth solving. You need a simple way to prioritize.
For each customer need you have uncovered, rate two things on a 1-10 scale:
Importance: How much does this matter to them?
Current Satisfaction: How well do existing solutions handle it?
The sweet spot: high importance plus low satisfaction.
That gap is your opportunity. If importance is low, nobody cares enough to switch. If satisfaction is already high, you are fighting an uphill battle against something that works fine.
Map out 5-10 needs this way and the picture gets clear fast. You stop chasing every feature idea that sounds interesting and start focusing on the needs where you can make the biggest difference.
This is the framework from Dan Olsen's The Lean Product Playbook, and it is one of the first things we run in our Sprint Zero process at Wednesday Solutions. Before we write any code, we map the landscape of user needs so we know exactly where to aim.
Step 4: Understand the Job, Not the Feature Request
People do not want a drill. They want a hole. But actually, they want to hang a family photo so their house feels like home.
Every product gets "hired" for three types of jobs. This is the Jobs-To-Be-Done framework:
Functional - the practical task. "I need to match with the right vendor for my medical device project."
Emotional - how they want to feel. "I want to feel confident that I am not wasting months on the wrong partner."
Social - how they want to be perceived. "I want my board to see me as someone who runs a tight R&D process."
If you only solve the functional job, you build something adequate. When you nail all three, you build something people love and talk about.
Spencer Jones at XO Medtech understood this. His platform, MedtechVendors.com, was not just a vendor directory (functional). It was about giving founders and engineers confidence in their R&D process (emotional) and making them look organized to stakeholders (social). We roadmapped the entire development plan, built the MVP, then built a sellable V1 - adapting as Spencer learned from real customers. As he told Clutch: "They really cared and felt like an extension of our team. The quality of the work was top notch."
Step 5: Decide Before You Build
Before writing any code, you need a clear answer to four questions. These come from Marty Cagan's Inspired and they are the simplest risk framework that exists:
Will people want this? (Value risk) - Have at least 5 conversations with real commitment signals. Not "I would use that" but "here is my email, call me when it is ready" or "I will introduce you to my boss."
Can people figure it out? (Usability risk) - Can you explain the core flow in under 60 seconds? Can someone who has never seen your product get to the valuable part without help? If you need to be on a Zoom call to walk every user through it, you have a usability problem.
Can you build it? (Feasibility risk) - Do you have the skills, time, and tech to deliver? This is where a lot of vibe-coded MVPs hit a wall. The prototype works, but can it scale? Can it handle real data? Can it integrate with what users actually need?
Should you build it? (Viability risk) - Does the business model work? Any legal, compliance, or ethical issues? For Vita Sync Health, HIPAA compliance was a viability risk we had to address head-on during Sprint Zero.
If any of these is a clear "no," stop. If any is "I do not know," test that specific risk before investing further. The cheapest time to kill a bad idea is before you have spent six months building it.
Step 6: Build the Thinnest Possible Version
Once you have validated demand, build the absolute minimum needed to walk a user through the entire journey end-to-end. Not a feature. A journey.
This concept comes from User Story Mapping by Jeff Patton. He calls it a "walking skeleton" - the thinnest possible slice that covers the whole experience from start to finish.
Ask three questions:
What is the minimum to walk through the entire experience? Not the minimum feature. The minimum journey. A user should be able to start at the beginning and reach the valuable part, even if everything in between is held together with duct tape.
What can come later? Be ruthless here. Every feature you add to v1 is a feature that slows down your learning. The goal is not to impress users. It is to learn whether you are right.
What must be real vs. what can be faked to learn? Maybe your AI recommendations can be manually curated for the first 10 users. Maybe your matching algorithm can be you personally making the matches. The point is learning, not automation.
Anuj Kejriwal at Spotwriters took this approach. He needed to get his writing community platform to market fast so he could start testing with real users. We built the walking skeleton - a copyrighting user journey and marketplace for transactions - and got to the MVP in just four months. As Anuj described it: "The most impressive thing about Wednesday was their ability to grasp exactly what we need, and the developers' ability to give us suggestions on how to make our product better. Even before going to market, we had already made many changes to make the product better."
That last part matters. The suggestions did not come from a feature wishlist. They came from the team understanding the problem deeply enough to say "this would serve your users better." That is what happens when you validate before you build.
Step 7: Measure What Matters From Day One
Most founders launch and then stare at download numbers or signup counts. Those are vanity metrics. They tell you how many people were curious. They do not tell you if your product is working.
Set up what Eric Ries calls innovation accounting in The Lean Startup. Before you launch, define three things:
Baseline metrics - where are you starting? What is the current state of activation, engagement, and retention?
Success criteria - what specific numbers would prove you are learning and making progress? Not "lots of users" but "40% of signups complete the core action within 24 hours."
Pivot triggers - what results would make you change course? Define this before you have the data, when you can still be honest with yourself.
We experienced this firsthand with Off Grid, our open-source on-device AI app. We launched three weeks ago and hit 5,500+ users with zero ad spend. But the number that actually mattered was not downloads. It was that Google organic search became our number one traffic referrer. People were not stumbling on us through social posts. They were actively searching for what we built. That is a demand signal you cannot fake.
Our Reddit posts hit 10K+ impressions with hundreds of comments. Our GitHub repo crossed 900+ stars. Play Store growth spiked +446% week over week. Each of these told us something specific about whether the product was resonating and with whom. The download number alone would have told us almost nothing.
The Shortcut That Actually Works
This process is straightforward but it is not easy. It requires discipline to talk to customers before building. It requires honesty when the data says your idea needs to change. And it requires experience to know which signals matter and which are noise.
This is exactly what we do at Wednesday Solutions through our Sprint Zero process. We take founders from idea through validation to a shipped product - with a team that has done this across dozens of products over 15+ years. We do not just build what you ask for. We help you figure out what is actually worth building, then build it fast through our Vibe Sprints model where you pay for shipped outcomes, not hours.
Eliott Bond, founder of BetU, described this: "As a first-time founder without a technical background, I received unparalleled support. They guided me through all technical needs every step of the way." We acted as his de facto CTO while he focused on the business. The app launched successfully, hit user growth milestones ahead of schedule, and Eliott has since referred other clients to us.
Sachin Gaikwad, founder of Buildd, a banking-as-a-service platform, put it this way: "Their understanding of architecture is very high. I have worked with Google teams and Motorola teams, and Wednesday Solutions is at their level. Their approach to software development is among the best in the industry."
TL;DR
Talk to potential users about their problems, not your idea. Track commitments - time, reputation, money, effort - not compliments. Score needs by importance and satisfaction to find real gaps. Understand the functional, emotional, and social jobs your product is being hired for. Assess all four risks - value, usability, feasibility, viability - before building. Build the thinnest version that tests your riskiest assumption. Measure the signals that actually matter, not vanity metrics.
The founders who do this waste fewer months, burn less money, and build products people actually want.
We help founders validate and launch products at Wednesday Solutions. If you are sitting on an idea, a vibe-coded prototype, or an MVP that is not getting traction - that is our sweet spot. Check out what other founders say about working with us on Clutch.
Top comments (1)
Great breakdown, this is such an important reminder for founders. Too many people fall in love with the idea and skip the hard work of actually talking to users and validating the problem.