I've shipped three products I was genuinely proud of with clean architecture and features people actually asked for. All three are gone.
For a long time I filed them under bad luck. However it’s more honest to say that at no point could I trace the strategy back to the evidence it was supposedly built on. We had plans and decks and roadmaps. What we didn't have was a line you could follow from “here's what we saw in the market” to “so here's what we decided to do about it.” When those two things drift apart, engineering quality doesn't save you. It just makes the failure more expensive.
I'm an engineer by training, and in engineering you can't ship a number that came from nowhere. Someone will ask where it came from, and “it felt right” isn't an answer. It took three failures to make me hold strategy to the same standard I'd always held code to.
I was a founder for these, but none of the failures are founder problems. They're the three questions a product manager answers every quarter — in the roadmap you defend, the features you prioritise, the bets you write into an OKR: is this worth building, what are we betting on, and will anyone pay? I got all three wrong with well-built products in hand. And if you shape product direction at all — PM, product owner, UX lead, or a transformation lead dragged into roadmap fights — the same trap is set for you. Here's what each taught me, and the discipline I use now so the “why” never goes missing again.
1. We proved we could build it. We never proved anyone needed it.
The first was a social-impact venture I co-founded: a mobile app for anonymous, campus-led reviews of how UK universities lived up to their equity, diversity, and inclusion promises — crowd-sourced accountability to expose the gap between policy and lived experience, aimed at students and staff across 50-plus UK universities. With a co-founder and an outsourced team I managed, I owned the architecture and backend and took it from concept to launch on the App Store and Google Play. It was a serious effort — we earned SEIS/EIS advance assurance and ran it as a live consultancy brief with a London university's students. We got the engineering right: the scale, the integrations, the reliability. The one thing we never validated was demand. We'd talked to people who said it sounded interesting, and we treated "interesting" as a signal to build. It wasn't. It was politeness.
Looking back, there was no evidence line running into the decision to build. If you'd asked me “which specific, observed market signal does this trace back to?” I'd have gestured at a vibe. Building something the market doesn't actually want — poor product-market fit — is the most common root cause in startup post-mortems, and it almost never feels like that from the inside; from the inside it feels like momentum. This is the discovery failure in its purest form: we skipped the part of the job that exists precisely to stop us. The lesson was that a decision to build should carry a pointer back to the evidence that justifies it, and if you can't name the pointer, you don't have a reason — you have a hope.
CB Insights’ own reading: running out of cash is where the story ends; poor fit, bad timing, and broken economics are why — almost exactly my three failures.
2. The model rested on one assumption about the world. We never named it, so we never protected it.
The second was a staff-augmentation business I co-founded — at its peak, twelve of our engineers were embedded in four clients' product teams. It worked, until COVID hit. To survive, clients cut their easiest-to-cancel costs first: they paused projects or brought engineering in-house, and dropped outside vendors like us. Three of our four clients were gone in two months, the fourth in the third. A young firm with a handful of clients has no cushion for that. The ground moved, and only the incumbents were left standing. It's tempting to call that bad luck as nobody forecast a pandemic, and for years that's how I explained it.
I don't anymore. We failed because the whole model depended on one assumption about how the world worked, and we never wrote that assumption down as a bet. Because we never named it, we never asked the two questions that follow: what's our mitigation if this breaks, and what's the early signal that tells us it's breaking? We'd built no such signal — so by the time the falling revenue confirmed it, the clients were already gone. The incumbents had reserves and many clients to absorb the hit; we had neither, and one core assumption we'd never named.
Every roadmap is a stack of these bets however most of them unspoken. That's the risk-mitigation failure: a traceable strategy names its load-bearing assumptions out loud and puts a trip-wire on each — so when one breaks, you find out in weeks and know exactly which decisions are standing on nothing.
3. Everyone loved it. Nobody would pay.
The third was an AI platform I engineered solo, with a co-founder on the business side: one photo of a shop's shelf became online listings and a storefront for an independent retailer. It hurt most, because by every signal we'd taught ourselves to trust, it was working. People used and praised it. The demos landed. What we had was overwhelming evidence of enthusiasm and zero evidence of willingness to pay — and I'd let myself treat the first as a proxy for the second.
The pricing was freemium: a free tier to prove the value, then paid subscription tiers. That sounds reasonable until you're in it, freemium-first burns real capital and asks users to trust a promise. Nobody trusts words; they trust their own experience of having paid and not regretted it, which is exactly the evidence you don't have when you need the investment decision. The free tier filled up but the paid tiers stayed empty.
We'd proven the product was lovable but never that it was buyable. It's the business-value case every PM is eventually asked to defend: "they love it" and "they'll pay for it" are two separate decisions, and enthusiasm is not a receipt.
One chain, three snap points — each product broke at a different link, but every break is the same defect: a decision that had drifted from its evidence.
The discipline: make every decision traceable
Three different failure modes — a discovery failure, a risk failure, a pricing failure — but one root cause. In every case, a decision had drifted from the evidence meant to justify it, and nobody saw the drift because nobody had drawn the line in the first place.
I'm not the first to argue for evidence over instinct — Itamar Gilad's confidence work and the honest post-mortems this community keeps publishing make that case well. What I'd add is smaller and more mechanical. I now treat a strategy the way I'd treat a codebase: everything traces back to something. Every conclusion carries an ID that points to the inputs that produced it. An opportunity isn't “we should expand into X” — it's O1 = P3 + S1: opportunity 1 exists because of a specific market signal I logged (P3) meeting a specific internal strength I can name (S1). Kill P3 or S1, and O1 is supposed to die with it. On a roadmap, it reads the same: this item ships because this user signal meets this objective — pull either thread, and it comes off the board. The IDs aren't bureaucracy; they're the audit trail. Six months on, when a stakeholder or an exec asks “why are we doing this?”, the answer isn't a memory of a meeting — it's a chain you can walk backwards to the evidence. And when a piece of evidence turns out to be wrong, you can see instantly every decision that was resting on it.
In the AI era, anyone can generate a strategy in seconds. The rare and defensible skill is a strategy you can stand behind, where every recommendation traces to something real. AI can draft the trail however answering for it is still on you.
Five questions to pressure-test any strategy
Before you commit to a plan, ask:
- For each major decision, can you name the specific evidence it rests on — or is the honest answer “we all agreed”?
- What's the one assumption that, if it's false, sinks this — and is anyone actually watching it?
- Have you separated “people like it” from “people will pay for it,” and do you have evidence of the second, not just the first?
- If someone joined tomorrow, could they trace your decisions back to their evidence without you in the room?
- Which of your decisions would survive being asked “why?” five times before you hit “because it felt right”?
I lost three good products learning that the deck was never the strategy. Build yours before you build the product.
If you want to go deeper, you're in good company. Teresa Torres's Opportunity Solution Tree keeps every solution traceable to an outcome and its evidence; Marty Cagan's four big risks push you to test what could sink an idea before you build it; Bland and Osterwalder's Testing Business Ideas turns assumptions into experiments, riskiest first.
