In the last two posts of my 0->1 series, I established the foundation that you need before defining an MVP.
In You Don’t Have a Product Strategy — You Have a Guess, I named the core problem: many early products move forward without a clear, defensible thesis. Confidence substitutes for strategy, and momentum hardens before the real decisions are made.
Then, in Customer Conversations Are Not Validation, I went one level deeper, showing why casual feedback alone isn’t enough to pressure-test a thesis. Understanding your audience, the problem you’re solving, and what actually differentiates you requires more than a handful of encouraging conversations. It requires signal that can survive scrutiny.
If you’ve been following along, you should now be sitting with a strong, defensible product thesis — grounded in real user pain and intentional differentiation.
That’s where this article begins. Because even with a solid thesis, there’s a question most teams still avoid:
Does this make sense as a business — at all?
The gap founders feel — but can’t quite articulate
With a clear product thesis in place, most founders aren’t confused about the product anymore.
The confusion shows up somewhere else — and it usually sounds like this:
“I built something users loved, but it doesn’t make sense as a business.”
“We need advice. We’re still figuring out the business model.”
“We’re building a SaaS, but pricing is unclear.”
The product thesis has been validated as desirable, but not as viable.
Nothing is obviously broken (yet).
But nothing has resolved into a business you’d confidently keep funding.
This is the moment where teams start scrambling:
Now that we’ve got an audience, how do we actually make money?
How Deferred Economics Turn into Structural Risk
Most founders don’t reject unit economics. They defer them.
The implicit belief is familiar:
“Achieve scale first. Make money later”
But it’s not the 2010s anymore. Constraints matter.
How expensive it is to reach a customer.
How much it costs to serve them.
How sensitive they are to price.
These constraints do (and should) shape scope, architecture, burn, and runway from the very beginning.
When these decisions stay unmade, development efforts drift away from a tight MVP. Teams build under assumptions that may not hold:
- acquisition will be cheap
- scale will arrive quickly
- customers will tolerate the price required to make the business work
By the time those assumptions are tested, momentum has already hardened around them.
“Scale first, make money later” can be a strategy —
but only if “make money later” is already directionally plausible.
Why early traction doesn’t answer the question you think it does
Early traction answers one question well: does anyone care?
It answers a different one very poorly: does this work economically?
At this stage, users often aren’t paying real prices, acquisition isn’t happening through constrained, repeatable channels, and the hard edge cases haven’t surfaced yet
As a result:
- Engagement looks clean.
- Interest feels strong.
- Retention appears encouraging.
But your product hasn’t been truly pressure tested yet. At this point, progress is still cheap. And cheap progress is deceptive.
I’ve seen teams mistake this phase for momentum, only to discover later that the business only worked under conditions that were never going to last.
The math you don’t need to perfect — but can’t avoid
To be clear: no one expects you to be profitable at launch.
But you do need to know whether the economics are even directionally plausible.
Before investing further, you should be able to reason — at a high level — about three things:
- What customers are realistically willing to pay, and how sensitive that price is
- What it will roughly cost to reach them, given the channels available to you
- What it will cost to serve them, once usage is real and sustained
Put those together, and one question matters more than any formula or benchmark:
Does this plausibly net out positive — or are we implicitly betting on future fixes?
If the answer depends on everything improving later — cheaper acquisition, higher prices, lower costs — then your MVP is built on stacked, unvalidated assumptions.
You don’t need optimism here. You need honesty.
Where this gets expensive to get wrong
This is usually where things stop being theoretical. When you start building systems that the financials can’t support, you’re accumulating decision debt.
Unwinding it later costs months of runway, morale, and credibility.
Sometimes funding.
I’ve lived this outcome.
Investors don’t always wait for the math to improve.
They don’t always fund the next iteration.
Sometimes they simply decide the risk profile no longer makes sense — and pull the plug.
When that happens, it doesn’t matter how elegant the product is or how thoughtful the roadmap was. The decision was already made months earlier, when the economics were deferred instead of confronted.
What comes next
In the next article, we’ll push this logic further by naming what most teams avoid altogether: defining failure.
Because if you can’t clearly articulate what would make this not worth continuing, you don’t have the guardrails in place that you need to stay focused and execute sharply.
If this piece fueled your unease instead of resolving it, that’s intentional.
This is the moment smart teams take a beat, to make sure the direction they’re accelerating in is one they can afford to be wrong about.
This post is part of a longer series on early-stage product bets — how teams decide what to build, what to stop, and when confidence quietly turns into risk.
If this surfaced questions about whether your product thesis actually closes as a business, that’s not something most teams should answer in isolation. This is the kind of inflection point I work with founders on — before momentum hardens around the wrong assumptions.
You can subscribe below to follow the rest of the series.