Picture this scenario, which may sound painfully familiar if you’ve ever tried to build a side project or even launch a startup:You have what feels like a brilliant idea for a new B2B SaaS tool. Because you’re a responsible engineer who has read all the startup books, you decide not to just lock yourself in a dark room and code for six months. Instead, you go out and “validate” the idea first.

You grab coffee with ten industry friends and potential users. You explain your architecture, show them a couple of Figma mockups, and ask: “Would you use something like this?”

Nine out of ten people nod enthusiastically: “Oh man, that’s a great idea! Our current workflow is terrible. I would definitely use that—let me know when it’s ready!”

Validated! Energized, you spend the next four months wiring up a database, configuring your CI/CD pipelines, polishing the UI, and deploying to production. You send out the launch email to those exact same nine people.

And then… nothing.

One person replies two weeks later saying they’re “swamped right now, maybe next quarter.” The other eight don’t even click the sign-up link.

Welcome to the first post of The Unbiased Founder, an 8-part series on early-stage customer validation!

With AI coding assistants and cloud primitives making it faster than ever to ship software, our biggest bottleneck as builders is no longer how fast we can write code—it’s making sure we aren’t building something nobody actually wants to buy. Over the next eight articles, we are going to treat customer discovery the way we treat software: stripping away the non-essential, debugging our assumptions, and building a repeatable framework to extract the hard truth from our market.

In this first article, we’ll dive right into the foundation of the entire series: why customers lie to you, why bad validation is worse than no validation at all, and a simple 3-rule framework for unbiased questioning.

The Validation Trap: Why “False Positives” Kill Startups

We all know we ought to talk to customers. Yet many founders talk to customers every single week and still end up building products nobody buys.

Why? Because talking to customers is hard, and doing it wrong is actually worse than doing nothing at all.

As usual, let’s start with an engineering analogy. If you’ve been following my blog, you know I love them as a way to better frame a concept.

Think of customer conversations like your automated test suite in CI/CD:

• No customer conversations (No tests): You know you are flying blind. You deploy cautiously, keep your scope tiny, and expect things to break because you know you have zero test coverage.
• Biased customer conversations (A broken test suite returning False Positives): Imagine writing a test suite where assert True == True is hardcoded at the end of every test. Every pull request turns bright green! Because the dashboard is green, you gain massive, undeserved confidence. You refactor critical billing logic, merge 10,000 lines of code, and scale up your infrastructure. Usually right before production catches fire :).

Bad customer conversations generate False Positives. They convince you that you are on the right path, causing you to over-invest your cash, your nights and weekends, and your team’s sanity into a mirage.

Why Do Customers Lie to Us?

Here is rule zero of customer discovery: You shouldn’t ask anyone if your business is a good idea.

The truth is, people will naturally lie to you to protect your feelings, just like your mom or a close family member would (which is why Rob Fitzpatrick famously coined this The Mom Test).

When we sit across from someone and ask, “Do you think this is a good idea?”, we aren’t asking an objective data question. We are exposing our ego. We are implicitly asking: “Please validate my intelligence, my passion, and the thing I’ve been obsessing over for the last three weeks.”

Most human beings are fundamentally nice. Telling an excited founder to their face, “Honestly, your idea sounds awful and it has a few fundamental issues” feels cruel and confrontational. Saying, “Oh, that sounds really cool!” is free, pleasant, and ends the awkwardness immediately.

Key Takeaway: It is not the customer’s responsibility to give you the hard truth; it is your responsibility to extract it. If you give them an easy way to protect your feelings with a polite lie, they will take it 100% of the time.

The Unbiased Questioning Framework: 3 Core Rules

If we can’t ask people whether they like our idea, how do we figure out if our business is viable?

We change the protocol. Instead of pitching an idea and asking for an opinion, we run a structured diagnostic on their current reality using three simple rules:

1. Talk about their life and problems instead of your idea.
2. Ask about specifics in the past rather than generics or opinions about the future.
3. Talk less and listen more.

Let’s break down the mechanics of each rule:

Rule	The Biased Trap (Bad Data)	The Unbiased Protocol (Clean Data)	Why It Works Mechanically
1. Talk about their life, not your idea	“We’re building an AI tool that automates cloud cost audits. Would you use it?”	“How do you currently track and audit your AWS spend each month?”	If you don’t mention your idea, they literally cannot lie to you to protect your ego.
2. Specifics in the past, not generics in the future	“Would you pay 99€/month for a tool that fixes slow SQL queries?”	“Tell me about the last time a slow SQL query caused an incident. What did you do?”	Humans are wildly optimistic about what they “will” do in the future,(I’m still “going to” fix all those broken gadgets in my broken gadget drawer!, eventually…). Past behavior is an immutable fact.
3. Talk less, listen more	Spending 20 minutes explaining your roadmap and 5 minutes taking questions.	Asking open-ended questions about their workflow and staying quiet while they vent.	Every minute you spend talking is a minute you are biasing the witness and learning zero new information.

Hands-On: Refactoring a Customer Conversation

Let’s look at how this plays out in a concrete scenario. Suppose you want to build a tool that helps engineering managers automate compliance documentation (SOC2 / ISO27001).

❌ Conversation A: The Ego-Driven Pitch (Full of False Positives)

Founder: "Hey Sarah! I'm building an automated compliance assistant that 
         hooks into GitHub and generates SOC2 evidence automatically. 
         Do you think engineering managers would use this?"

Sarah:   "Oh, definitely! Compliance is always a huge pain for everybody. 
         Automating that sounds super useful."

Founder: "Awesome! And if it saved you 5 hours a week, would you pay 
         around 200€ a month for it?"

Sarah:   "Yeah, 200€ a month is nothing for B2B software. Keep me posted 
         when you launch!"

Diagnostic: You walked away feeling like a million bucks, and you learned zero facts. You don’t know if Sarah even deals with SOC2, when she last did an audit, what tools she currently pays for, or if she has budget authority.

✅ Conversation B: The Unbiased Diagnostic (Clean Behavioral Data)

Founder: "Hey Sarah, I'm trying to understand how engineering teams of 
         your size handle security audits. When was the last time your 
         team went through a compliance review like SOC2 or ISO?"

Sarah:   "Actually, we just wrapped up our SOC2 Type II audit three weeks ago."

Founder: "Oh wow, fresh wounds! Walk me through how you collected the 
         engineering evidence for that. What was the worst part?"

Sarah:   "Honestly, the GitHub pull request checks were automated already 
         because we pay 8k €/year for Vanta. The real nightmare was chasing 
         down 15 external sub-processor vendor questionnaires over email. 
         My lead SRE spent three full days doing just that in a spreadsheet."

Founder: "Three full days?! Did you look for any tools to automate the 
         vendor questionnaire part, or just brute-force it?"

Sarah:   "We looked at two enterprise tools, but they wanted 25k € a year, 
         so we just suffered through the spreadsheet."

Diagnostic: Look at the signal clarity in Conversation B!

1. You never mentioned your idea, so Sarah never had to be polite.
2. By asking about three weeks ago (past specifics), you discovered that your original idea (GitHub PR evidence) is already solved for her by an incumbent tool!
3. Even better, she handed you a real, painful, unsolved bottleneck (vendor questionnaires) and told you the exact price anchor (8k vs. 25k €) without you ever pitching a single slide.

The Elephant in the Room: “Wait… Don’t I Eventually Have to Pitch?”

One of the things that may be bothering you at this point is: “But Carlos, if I never mention my idea or product, how do I ever validate my actual solution or close a sale?!” This bothered me when I first learned this approach!

Here is the distinction: Problem Discovery and Solution Validation / Selling are two different phases of your state machine.

In the early days, when you are still figuring out what to build and whether the problem even matters, pitching your solution contaminates the “crime scene”. Once you say, “I’m building an X to solve Y,” the customer’s brain locks onto your framing. They stop telling you what they actually care about and start politely critiquing your hypothetical solution.

Once you have proven through unbiased past-behavior facts that:

1. The problem is real and painful,
2. They are actively spending time or money trying to solve it today, and
3. Current workarounds are failing them,

then (and only then) do you earn the right to put a solution on the table and ask for a concrete commitment (which we will cover in depth in Post #6!).

Production Realities: How to Audit Your Own Questions

When you’re in the middle of a live conversation, it is shockingly easy to slip back into bad habits. We are engineers and builders; we love talking about the cool thing we’re building!

Before your next customer chat, run your question list through this quick 3-Point Linter:

1. The “Would You Ever…” Regex Check: If a question starts with “Would you…”, “Could you see yourself…”, or “Do you think you might…”, delete it immediately. Refactor it into: “When was the last time you…” or “How do you currently…”
2. The Workaround Check: Always ask how they solve the problem today. If a problem is truly painful, customers will already have an ugly workaround (a messy Python script, an intern copying data into Excel, a 40-step Notion checklist). If they haven’t even bothered to hack together a workaround, the problem isn’t painful enough for them to buy your software.
3. The Talk-Time Ratio: If you spoke for more than 20% of the conversation, treat the call as a failed test run.

Wrap-Up & What’s Next

Early-stage customer validation isn’t about convincing people that your idea is smart; it’s about uncovering the cold, hard truth of how your market behaves before you write a single line of production code:

• People will lie to protect your feelings if you expose your ego.
• Talk about their life, not your idea.
• Anchor on specific past behaviors and existing workarounds, never future promises.

However, even when you try your absolute best to ask unbiased questions, conversations in the wild are messy. Sometimes you’ll slip up and mention your idea, or a prospect will figure out what you’re working on and start showering you with praise: “Honestly, you’re onto something huge here! Put me on the waitlist!”

How do you handle compliments when they happen, and why is praise the most dangerous data point a founder can collect?

In the next article, Deflecting the Fool’s Gold of Compliments – The Unbiased Founder #2, we’ll explore the Pathos Problem and learn how to deflect fluff and steer conversations back to solid ground.

Hope you find this useful as I did and are able to apply some of it. Cheers! 🙂