"Validating" Was the Wrong Word for What I'd Been Doing on My SaaS

I want to share something I noticed about my own vocabulary last week.

For several months, I've been working on my next SaaS product — IVP, Idea Validation Pot. A small tool that helps founders pressure-test product ideas before they commit to building. During those months, I did real product work: I wrote multiple versions of the spec, drew the architecture, evaluated tech stacks, built a competitor matrix, and watched the market.

Whenever someone asked what I was working on, I'd say: "I'm validating IVP."

Last week, in one focused scoping session, I realised I'd been using the wrong word.

I had been doing real work. I had not been validating. Those are two different things, and I'd been quietly conflating them — which is, ironically, the exact failure mode IVP is built to solve. The tool was working on me before I'd written a line of its code.

I'll explain what I mean by that, because the gap between "doing product work" and "validating a product" is where I think many founders quietly burn months without noticing.

Let me list, plainly, what I did whenever I sat down to "work on IVP":

Every one of those activities is legitimate product work. Spec writing matters. Architecture matters. Stack evaluation matters. Competitor research matters. None of it was wasted — when I finally sat down to scope Phase 1, all of that prior thinking made the session faster and sharper.

But here's what I want to name precisely: none of that work was validation. Not one item on that list put IVP in front of someone who could say "no, I wouldn't pay for that." Not one item exposed the idea to a real-world test. Every item on the list was me, at my desk, working through the product with myself.

That's the distinction I'd been blurring. Product work happens at your desk, in documents, where you can refine and reconsider. Validation work happens out in the world, with other people, where you can be told the idea is wrong. They are both real work. They are not the same work.

For months, I'd been doing the first one and calling it the second one. Not because I was avoiding validation, but because the vocabulary was loose, and I never stopped to check.

Last week, I sat down for a different kind of work session. I called it a "scoping session" — meaning I was going to make actual yes/no decisions about Phase 1 of IVP, on paper, in one sitting. No exits, no tab-switching, no "let me research this and come back."

Roughly four hours in, the difference between the two kinds of work became obvious. Making forced yes/no decisions about what IVP would and wouldn't do felt structurally different from anything I'd done in the prior months of spec writing and architecture work. The prior work kept options open. This session was closing them.

Months of product work had killed zero options. Every idea, every workflow, every feature was still alive in a doc somewhere.

One scoping session killed five.

That's what made the gap visible. Validation isn't a softer version of product work — it's a different mode of work, with a different output. Product work produces options. Validation produces commitments and rejections. I'd been producing options and calling them validation.

Let me show you exactly what got killed and why. These are the five decisions one session forced.

1️⃣ Killed: the imaginary "future user." Kept: me, this week.

Every time I tried to write the spec for "a generic founder," it fell apart. The features got vague. The flows got bloated. So I tried something different — I wrote the spec for exactly one user: me, scoping IVP, this week.

The spec instantly got sharper. I knew what I needed because I was the person who needed it. Decision: the first version of IVP gets built for one named user with a real problem. If it can't pass that test, it can't pass a stranger's either.

This is the opposite of what most product books say. They tell you to define your "ideal customer profile" first. But when you're early, and the product is still in scope, that's another way of writing a doc instead of building. The fastest path to a usable product is to be your own first user, then expand outward from a real user you actually understand.

2️⃣ Killed: four out of five planned workflows.

The original spec had IVP doing five things — five workflows the user could run. Stress-test an idea. Compare two ideas. Score an idea against your strengths. Track ideas over time. Generate a pre-mortem.

Each one looked easy in isolation. Together, they were a six-month build at minimum.

So I forced myself to pick one. If I could only ship one workflow, which one?

Stress-testing. The one that pressure-tests an idea against named failure modes. Everything else is Phase 2 or never.

Four workflows died in that decision. None of them died in several months of prior spec work.

3️⃣ Killed: the rest of my product roadmap, until IVP earns it.

This was the hard one. I have four other SaaS ideas mentally pre-committed — a LinkedIn marketing tool, a multi-channel social tool, an email tool, a workflow automation tool. All "next."

Scoping IVP forced me to write down, in plain English, a rule I'd been avoiding: IVP itself is the gate the other ideas have to pass. Meaning — if IVP can't validate them as worth building, I'm not allowed to build them.

That cuts my own roadmap by 75%. Three out of four products go on hold until the one I'm building proves it can pick winners.

Should have made me anxious. Made me lighter.

4️⃣ Killed: comparing IVP to competitors on features.

For weeks, I'd been building that competitor matrix. Feature by feature. IVP has this, they have that, here's where IVP wins.

The scoping session made me notice: I was playing the wrong game.

Other validation tools score ideas based on what you tell them about the idea. IVP scores your next idea based on evidence from what you're currently doing — your actual decisions, your past attempts, your real constraints. That's a different category, not a better feature.

The architecture didn't change. The way I described the product changed entirely. Feature comparison is a frame that kills indie SaaS — there's always a competitor with more features. Category framing is the way out.

5️⃣ Killed: the urge to put up a waitlist tomorrow.

Most founder advice on the internet says the same thing: put up a waitlist page immediately, drive traffic to it, and validate demand.

I almost did. The scoping caught it.

Here's the problem with a waitlist when you have nothing real to show: people who sign up are signing up for an idea. An idea has a 100% conversion rate to "sounds interesting." A demo has maybe a 5% conversion rate to "I'd pay for this." The first number lies. The second one is the truth.

A waitlist before a product is real is just another form of building without validating. It feels productive. It doesn't tell you whether you have a product.

Decision: no waitlist until there's a demo or a date. That's a month or two of holding my nerve while every guide on the internet tells me I'm doing it wrong.

If you're reading this and thinking "okay, but what was actually different about the scoping session?" — here's the honest answer.

The scoping session forced me to say "no" to things.

Every one of the five decisions above is a "no." No to imaginary users. No to four workflows. No to three side products. No to feature comparison. No to early waitlists.

Months of spec writing and architecture work had produced zero "no"s. That's not a criticism of that work — it's a description of what spec writing and architecture work are for. They produce options. They keep things open. That's their job.

Scoping, on the other hand, makes you close things. Which means scoping is closer in nature to validation than spec writing is. And that's the part I want to land precisely: closing options is what validation actually produces.

When someone tells you "no, I wouldn't pay for that" — that's validation. When you find out a competitor already does it and does it well — that's validation. When you realise the workflow you were planning to build is a many-month project, and you don't have many months — that's validation.

Validation isn't a process that says "yes, this is great, keep building." Validation is a process that says, "This won't work, drop it." If your validation process never closes options, it isn't validation. It's option generation, dressed up.

Here's the pattern as I see it now, plainly:

Founders say they need to validate before building. They then do legitimate product work — spec, architecture, research, planning — and use the word "validating" to describe all of it. The product work matters. It just isn't validation. And until you name the gap, you can't close it.

The vocabulary is the slippery part. "Working on it" covers both kinds of work. "Validating" gets used loosely. The two activities sit on the same calendar, often in the same week, and most founders never stop to ask which one a given task actually is.

The result: months can pass where you've genuinely built up the product in your head — sharp spec, clean architecture, sensible stack — but you've never put the idea in front of someone who could reject it. The product is more developed. The idea is no more validated than it was on day one.

A coach who's worked with 50+ founders wrote about this earlier this year. She described one founder who spent €80,000 and 18 months building a platform that ended up with zero customers. After two weeks of actual validation work — talking to potential users, repositioning the offer — that same founder had three paying customers.

That's a more extreme version of the same gap. The founder wasn't lazy; he built a real platform. He just spent 18 months in product work and called it validation. Two weeks of actual validation — exposing the idea to real users — produced more signal than the prior 18 months had.

The gap I noticed in my own work is a smaller-scale version of the same shape. Product work was real. Validation was missing. The fix wasn't to stop the product work — it was to name it correctly and add the validation work alongside it.

I'm not going to pretend one scoping session fixes everything. It didn't fix everything for me — it just made the picture honest and gave me a way to separate the two kinds of work going forward.

But here's the move that made the gap visible, and might do the same for you if you're somewhere in the "I'm validating my SaaS" phase right now:

Sit down for one focused session this week. No tabs, no research, no "let me come back to this." Just decisions. Force yourself to say "no" to five things.

Five workflows you've been planning — pick one, drop four. Five tech stack options — pick one, drop four. Five potential first users — pick one, drop four. Doesn't matter which five. The act of closing five options in one session will tell you whether your current product work has been generating options or closing them.

One last thing. A line I read recently that I keep coming back to: "We build a beautiful, intricate key before finding the lock."

The product work I'd been doing was building the key — and it was good work. The scoping session was the first time I described the lock. Both are needed. They are different jobs.

If you've been refining the key, this is the nudge to also start describing the lock.

I want to hear from anyone reading this who's shipped (or is currently shipping) a SaaS as a solo or two-person founder.

Has a focused decision session ever changed your view of your product more than weeks of building it up in your head did?

Reply to this email or hit me on LinkedIn — the answers from last week's threads have already started shifting how I'm thinking about Phase 1.

And if you're earlier than that — still in spec-and-architecture mode, with no validation steps booked — the only honest suggestion I can offer is: book yourself a scoping session this week. See if you can close five options in one sitting.

That's what made the difference for me.

If this landed, the easiest thing you can do is subscribe. No funnel, no sales sequence. I write one of these a week. Each one is a journal entry from inside an actual build — what I'm scoping, what I'm deciding, what I'm learning as I go. Subscribe here.

Sources
1. The 7-Day Validation Sprint — how2transform.substack.com
2. What founders fail at most — Avni Patel Thompson
3. Why Indie Founders Fail — Indie Hackers, Feb 2026
4. Solo founder rate growth — Indie Hackers, Apr 2026
5. Most SaaS products fail for the same boring reason — Indie Hackers, Mar 2026