In January 2026, a founder called a development agency after spending $94,000 on an MVP that nobody used. The idea wasn't the problem. The product worked. Positioning failures like this are exactly what the Series A Decision Library is designed to prevent. But he'd built seven features to test one core hypothesis, chosen a tech stack his agency recommended but couldn't maintain cheaply, and had no plan for getting users after launch. A simpler version at 60% scope would have cost $35,000 and shipped three months earlier, with real user data instead of a polished product gathering dust.
When you hear that story, the instinct is to call it a product mistake. Too many features. Wrong technical choices. Poor launch planning. All of that is true.
But there's a prior question nobody asked him: Who, specifically, is this for?
Not "SMBs in the logistics space." Not "ops teams at Series B companies." The kind of specific that lets you say: these ten companies, these buyers, this workflow, this exact frustration they have right now with whatever they're doing instead.
Nobody asked because nobody in the room was responsible for asking. That's the actual problem.
The stat everyone cites, and what it actually means
CB Insights updated its startup failure analysis in 2024, reviewing 431 failed VC-backed companies. The headline barely changed from their 2014 study: 43% failed due to poor product-market fit. Running out of capital affected 70% of failures, but CB Insights now explicitly frames that as the final symptom, not the root cause.
Here is what that number actually means. Founders built something and then discovered not enough people cared to pay for it. The market was too small. The problem wasn't painful enough. Or the solution didn't match what buyers actually wanted.
In other words: they skipped the positioning.
They assumed demand existed because the problem seemed obvious to them. They built the product first and then handed it to marketing to figure out the story. By then, the scope was locked, the budget was spent, and the messaging was a wrapper applied over a product that was never built around a specific buyer's specific pain.
No market need is not a discovery you make after launch. It's information available before you write a single line of code.
The inversion founders make
April Dunford has spent 25 years positioning B2B tech products and has worked hands-on with more than 200 companies, including Google, IBM, and Postman. When she talks about what founders get wrong, the answer is consistent: they start with the product.
Founders understand their product deeply. They know every feature, every architectural decision, every tradeoff. So they lead with capabilities. Then they ask marketing to translate those capabilities into a message.
Dunford's framework runs in the opposite direction. You start with value: what does this product actually do for someone? From there you identify the customer who experiences that value most acutely. Then you name the competitive alternative those buyers are living with right now. Only after that do you ask what you do better. Finally, you ask what frame makes that advantage obvious to the specific buyer you identified.
The product is the last thing you reason about. Not the first.
When you run the sequence correctly, the MVP scope defines itself. Every feature either helps your specific buyer switch from their current alternative, or it doesn't ship. Done becomes a clear answer, not a moving target.
What Loom learned the hard way
Loom's founders didn't start with an async video tool. They started with Opentest, a user-testing platform. It failed to gain traction. By 2016, the team was two weeks from running out of money with credit cards maxed and no clear path forward.
What saved them wasn't a new feature. It was a positioning decision.
They noticed users were engaging with a screen-recording component they'd built as a side function. That one capability solved a specific, painful problem for a specific group of people: remote and distributed teams who were drowning in meetings and long emails to explain things that took three minutes to show on screen. The founders stopped trying to be a testing platform for everyone and repositioned as an async video tool for async-first teams.
They launched on Product Hunt. Three thousand new users in 24 hours, more than their total user base from the previous six months. The product hadn't fundamentally changed. The positioning had.
Atlassian acquired Loom in 2023 for $975 million.
The lesson for an early-stage founder isn't "pivot until something works." It's that the Loom team found their answer by asking a positioning question first: who actually has this problem badly enough to change their behavior? That question was available to them before they built Opentest. They just weren't asking it yet.
The three questions that scope your MVP
If your founding team can't answer these three questions with specifics before the first sprint, you are setting scope on assumptions.
Product asks whether you can build it. Engineering asks how. Marketing, if it exists at all at this stage, asks how to announce it. Nobody asks whether you should build all of this, given who you are actually selling to.
That question is a marketing strategy question. And when no one in the room is responsible for it, the MVP becomes a product shaped by what the founders find interesting to build. That is how a $94,000 product ends up gathering dust with a solid core idea inside it.
The choice in front of you
I've watched founding teams spend six months building the wrong scope because nobody asked the positioning questions before the sprint began. The work wasn't wasted exactly, but most of what got built didn't survive contact with real buyers. They then spent the next three months rebuilding on a foundation they could have had from the start.
The MVP is not the test. The positioning is the test. The MVP is what you build once you have the answer.
Get the positioning wrong, and you spend months building for a buyer you can't quite describe, solving a problem you can't quite name, better than an alternative you've never clearly identified. Then you launch. Then you look for signal in feedback from users who aren't your ICP, iterate toward features they requested, and wonder why traction keeps feeling just out of reach.
Get it right first, and the scope becomes obvious. The launch is a confirmation, not a discovery.
You have two options before the next sprint starts. Run those three questions yourself, with the same rigor you'd apply to any technical decision. Or bring someone in whose job it is to ask them. Either way, the questions don't go away. The only variable is how much you spend finding out you needed them.