- AI & Tech
Make the Hard Decision Before the Product Fails
Perish, pivot, or persevere — how to decide on evidence before your runway decides for you
I’ve spent over a decade building systems for startups, and if there’s one pattern I’d tattoo on the wall of every founding team, it’s this: the failure was almost always visible months before anyone admitted it.
You know the script. A product launches, the numbers come in soft, and everyone agrees to “give it another quarter.” Then another. Then there’s a board meeting with a slide full of hopeful arrows. And somewhere around month fifteen of an eighteen-month runway, somebody finally says the quiet part out loud.
By then, the damage is mostly done. The runway is half gone. The best engineers — the ones who could read the writing on the wall — have already found somewhere else to work. Technical debt has piled up because nobody wanted to slow down and fix things during a “push.” Customers who gave the product a chance are quietly telling their networks it didn’t stick. The founders are running on fumes. And the investors have heard “it’s turning around” enough times that they’ve stopped believing it.
Here’s what I actually believe about this: waiting for failure to become undeniable isn’t caution. It’s the most expensive decision a leadership team can make, and most teams make it by accident.
Because the alternative isn’t optimism or pessimism. It’s deciding — in advance — what failure would look like, so you can act while acting still matters.
Ask a better question
The question most teams ask when things feel off is “is this product failing?”
It’s a bad question. It invites debate, vibes, politics, whoever speaks loudest in the room. And it frames failure as something you detect after the fact, like a smoke alarm going off in a house that’s already burnt down.
The much better question is:
“What evidence would tell us this product is heading toward failure?”
Notice what changes. Suddenly you’re not arguing about whether the product feels doomed. You’re naming specific, observable things that would worry you before they happen. That single reframe turns failure from a surprise into a plan.
Define your failure signals before you need them
Before launching anything serious, write down the assumptions you’re betting on, with numbers attached. Something like:
Product: customers activate within 7 days of signing up. Customer: mid-sized businesses have a problem painful enough to pay for this. Commercial: we can acquire a customer for less than $500. Retention: at least 70% of qualified customers are still active after three months. Revenue: $50,000 MRR within 12 months.
None of these are promises. They’re hypotheses. And here’s the part everyone skips: deciding now what happens if they don’t hold.
Because if you don’t decide now, you’ll decide later — when you’re eight months in, tired, defensive, and emotionally invested in being right. Few people make their best decisions in that state. I’ve certainly never seen anyone do it.
Turn every hypothesis into a trigger
If you take one idea from this article, make it this one — it’s the mechanism underneath everything else, so let me spell it out.
For every hypothesis you write down, attach three things:
Signal — the leading indicator that tests it. Activation rate for the product hypothesis, acquisition cost for the commercial one, 90-day retention for the retention one.
Threshold — the number and the date that would count as evidence against you. Not “retention should be decent” but “below 70% after three months.” The date matters as much as the number: a metric that might get there eventually is not the same as a metric that gets there by June.
Pre-agreed move — what you commit to doing if the threshold trips. Investigate. Run an experiment. Change the plan. Stop.
Signal, threshold, move. A hypothesis without a threshold isn’t a hypothesis — it’s a hope with a spreadsheet attached.
A few examples built on the assumptions above:
| Hypothesis | Signal | Threshold | Pre-agreed move |
|---|---|---|---|
| Customers activate within 7 days | Activation rate | Below 40% by week 6 | Investigate onboarding; run experiments before touching strategy |
| We can acquire customers for under $500 | Blended CAC | Above $500 for two consecutive months | Pause paid spend; test channels and positioning |
| 70% of qualified customers stay active at month 3 | Cohort retention | Under 70% for two consecutive cohorts | Open the pivot conversation while runway allows choices |
| $50K MRR within 12 months | MRR growth rate | Off track at month 9 review | Reassess pricing and segment before spending further |
Two rules make this work in practice. First, set the move while you’re still optimistic. The whole point is that you’re choosing with clear eyes now rather than negotiating with yourself later. Second, write the triggers where you’ll actually see them — the metrics dashboard, the quarterly review agenda — not buried in a doc nobody opens. An unread trigger is just a wish.
You’ll notice this pattern repeats through the rest of the article, because it genuinely is the load-bearing piece: the decision matrix below pairs signals into triggers, the runway calendar puts them on a schedule, and the premortem converts imagined failures into new ones.
A decision matrix beats the loudest voice in the room
Strategic decisions shouldn’t come out of whichever meeting had the most confident person in it. I’ve sat in plenty of those meetings. The loudest person is rarely the one who read the data.
So pre-commit to some decision rules. For example:
| Signal | What it means | Decision |
|---|---|---|
| Strong retention + weak acquisition | Product works, distribution doesn’t | Fix sales/marketing |
| Strong acquisition + weak retention | People try it but don’t stay | Fix product |
| Strong usage + weak willingness to pay | Value exists, monetization is weak | Test pricing/business model |
| Weak acquisition + weak retention | Fundamental problem | Reconsider product/customer fit |
| Strong enterprise interest + long sales cycle | Product works, GTM is slow | Evaluate runway and sales model |
| Strong demand + execution problems | Market exists, team struggles | Upgrade leadership/team |
| No meaningful customer pain | Core hypothesis wrong | Pivot or stop |
This table isn’t sacred and yours won’t look exactly like mine. That’s fine. What matters is what it gives you: pre-agreed decision criteria. When the moment comes, the argument is about execution, not about whether the rules exist. That difference has saved plenty of companies.
Don’t let your runway make the decision
Picture a company with eighteen months of cash.
At month 3, traction looks weak. At month 6, it still hasn’t improved. At month 9, leadership decides to “give it another six months” — which sounds patient and reasonable and wise. At month 15, panic sets in.
Now the company has six months to reinvent itself. Hiring takes months. Enterprise sales cycles take longer than that. Even pivoting properly — finding a new customer, rebuilding positioning, shipping the changed product — barely fits. The runway has effectively made the decision, and it made the worst possible one: too little, too late, under maximum stress.
Compare that to a team that plans its decision points up front:
Month 0 — define the hypotheses. Month 3 — review the leading indicators. Month 6 — make the first major strategic decision. Month 9 — if the evidence isn’t there, execute the pivot you already scoped. Month 12 — decide whether the new strategy deserves more capital.
The exact timeline varies by company. The principle doesn’t: never allow your runway to become your decision-making mechanism. If you only act when the bank account forces you to, you’re not doing strategy. You’re negotiating with bankruptcy.
Watch leading indicators, not revenue
Revenue matters, obviously. But revenue is a lagging indicator — it reports on decisions made months ago. By the time revenue visibly collapses, the underlying illness has been spreading for two quarters.
So track the things that lead: activation rate, weekly active users, retention, feature adoption, conversion, sales pipeline, qualified leads, time-to-value, referral rate, expansion behavior. Pick the handful that map to your hypotheses and watch those.
And read them together, because the combination tells you which world you’re in. If revenue is flat but activation, retention, usage and referrals are all climbing, you’re probably early, not failing — that’s a “keep going” signal, not a panic button. But if revenue is growing on the back of aggressive discounts while retention quietly falls apart, your headline number is lying to you. I’ve watched companies celebrate exactly that kind of growth. It ages badly.
This is also the hardest judgment in product management: separating “not working yet” from “never going to work.” The trick is to stop asking whether the numbers look good, and start asking whether the numbers are improving at a rate that gives us confidence.
Look at two companies:
Company A: 10 customers, then 18, then 31, then 47, then 72. Company B: 100 customers, then 98, then 91, then 83, then 71.
In any single screenshot, B looks twice the company A is. But B is dying, and A is compounding. Direction matters more than snapshots. Any investor, board member or founder who reads a metric without reading its slope is decorating, not analyzing.
Perish, pivot, or persevere
Every major product initiative eventually falls into one of three buckets. Decide deliberately which one you’re in, because drifting between them by default is how teams waste years.
Persevere. The evidence supports the strategy. Keep executing and stop generating unnecessary strategic noise. Some of the worst advice founders get is to constantly reconsider everything — momentum deserves respect when the data backs it.
Pivot. The underlying opportunity is real, but one of your assumptions was wrong. So you change the customer segment, the pricing, the distribution channel, the scope, the positioning, the business model — while preserving the assets that still have value. Slack grew out of a failed game studio’s internal chat tool. Instagram began as Burbn, a check-in app so cluttered its own founders barely opened it; they cut everything except the photos. Those pivots worked because someone admitted early enough that the original hypothesis had died, while there were still assets worth carrying out of the wreckage.
Perish. Boardrooms usually reach for a blunter four-letter word, but the substance is the same: there isn’t enough evidence of a viable business, and continuing would destroy more resources than it could reasonably create. Stopping isn’t failure. Sometimes stopping early is the single best capital-allocation decision available to you — a founder who retires a product with twelve months of runway intact still has the ability to try again. A founder who burns to zero has nothing left but the lesson.
If you think letting products perish is rare, look at CB Insights’ March 2026 analysis of 431 venture-backed startups that shut down since 2023. The most-cited cause of death was running out of capital — 70% of them — but CB Insights flags that as the final symptom, not the root. The leading root causes were poor product-market fit at 43%, bad timing at 29%, and unit economics that never worked at 19%. Not technology failing. Market judgment arriving too late, with the cash running out as the coroner’s report.
Company-level decisions, not ego-level ones
Founders get emotionally welded to their products. Of course they do — years of their life, stories told to friends and investors and employees about what this was going to become. I’m not going to pretend that attachment is irrational. It’s human.
But the market does not care about the founder’s emotional investment. A product should survive because customers value it, not because shutting it down would be embarrassing.
There’s a famous version of this question from Intel’s history — and the way it’s usually told is tidier than what actually happened, which is exactly why it’s worth retelling properly.
In the mid-eighties, Andy Grove and Gordon Moore were watching the memory-chip business — the product Intel was known for — get crushed by Japanese competitors. In mid-1985, Grove asked Moore a question that has outlived the crisis: “If we got kicked out and the board brought in a new CEO, what do you think he would do?” Moore’s answer: get us out of memory. Grove’s reply: why shouldn’t you and I walk out the door, come back, and do it ourselves?
That’s the legend. Here’s the part it usually leaves out. By then, Intel’s middle managers had been quietly reallocating fab capacity away from memory and toward microprocessors for a long while — the organization had effectively voted with its capacity before leadership formally agreed. And even after the famous conversation, the actual exit took roughly another year of painful winding down. Grove himself admitted in hindsight that the clean narrative was cleaner than the reality.
Notice what that does to the story. It wasn’t one heroic afternoon where two brilliant men saw the truth; it was evidence accumulating until perspective finally caught up with it. Which is precisely the case for pre-agreed triggers: if the signal had been written down years earlier — “memory share below X, margin below Y” — the decision would likely have arrived a year sooner and cost less anguish.
Still, the heart of the lesson stands. Same people. Same facts. Different question. The most valuable thing Grove did was step outside his own investment: if I weren’t already invested in this company, would I invest in it today? If your honest answer is no, that answer deserves attention, not a follow-up meeting.
Don’t make employees the last line of defense
When leadership delays hard decisions, the team feels it first.
The engineers and support folks and account managers figure out “this isn’t working” months before anyone says it officially. Meanwhile management keeps repeating “we just need another quarter.” Then another. Then another.
What follows is organizational fatigue, and I can describe it precisely because the sequence is remarkably consistent. The best people tend to leave first — they’re usually the ones with the most options elsewhere. The people who stay get less confident. Morale calcifies into quiet cynicism. And eventually leadership points at the departures and treats them as another problem, when the departures were actually a symptom of the original one: decisions that arrived too late.
Honest reporting needs psychological safety — people have to be able to bring bad news early without getting punished for it. If your team learned that flagging a dead product is career-limiting, you didn’t just lose information. You lost your earliest warning system.
Sometimes the problem is the leader, not the strategy
There’s also a point where the issue stops being the plan and starts being the person running it.
You’ve seen the shape of it. Clear strategy, real customer demand, big enough market, adequate capital — and yet engineering repeatedly misses commitments. Requirements are mush. Production incidents climb. Customer complaints go nowhere. And the leader responsible keeps making the same mistakes with total confidence.
In that situation, hiring more engineers usually makes things worse. A leadership bottleneck is rarely fixed by adding people underneath it — more often it just widens the traffic jam. Sometimes the correct, brutal move is changing the person responsible for the system — and the same logic applies to sales, product, marketing and operations, not just engineering.
I wrote recently about how so many corporate failures get blamed on technology when the real culprit is delayed, defensive management. This is the same disease at product scale: the market was never the blocker. The blocker was allowed to stay.
Let the evidence set the pace
Here’s a rule worth stealing:
Weak evidence → investigate. Mixed evidence → experiment. Strong positive evidence → invest. Strong negative evidence → change direction. Repeated negative evidence → stop.
The mistake many companies make is treating every situation as though it requires another meeting. Sometimes the evidence is already overwhelming, and the only thing missing is the nerve to act on it. A leadership team’s job, past a certain point, isn’t to deliberate more. It’s to move.
Run a premortem before you commit
Before sinking serious resources into a product, gather the team and ask:
“Imagine it’s eighteen months from now and this product has failed. What killed it?”
Then write the answers down. This technique — the premortem — comes from psychologist Gary Klein, and the research behind it is solid: studies on prospective hindsight found that people identify reasons for future outcomes far more completely when they’re told to assume the outcome has already happened, rather than guessing whether it might. Something about giving your brain permission to be specific.
The answers tend to sound like this: wrong customer. Sales cycle too long. Customers didn’t retain. Infrastructure costs underestimated. Product too complex. Competitors moved faster. Wrong leadership hired. Ran out of capital. Built features instead of solving the actual problem.
Now — and this is the step that separates theater from risk management — convert each risk into a measurable signal and a trigger. For instance:
Risk: the enterprise sales cycle is too long. Signal: average deal cycle exceeds six months. Trigger: if three consecutive quarters show no improvement, we reconsider enterprise as our primary segment.
That’s it. Risk named, signal measured, trigger agreed. Now nobody has to summon courage in month fourteen — the courage was spent on day one.
Ten questions to answer before you build
The quality of a product decision isn’t determined only by what happens after launch. It starts before engineering writes a line of code. Before committing six months of development, leadership should be able to answer:
- Who is the customer?
- What painful problem are we solving?
- Why will they pay?
- What evidence already exists?
- What is our strongest assumption?
- What could make this fail?
- How much are we willing to spend testing the hypothesis?
- What metrics determine success?
- What metrics trigger a pivot?
- What conditions cause us to stop?
If those questions can’t be answered yet, the company isn’t necessarily ready to build. It might be ready to learn. Those are different budgets, different timelines, different expectations — and confusing one for the other is a classic way to spend a year learning nothing.
Put the decisions on a calendar
One practical habit ties all of this together: formal review points, written down, non-negotiable.
Monthly: operational metrics. Quarterly: product and market assumptions. Every six months: strategy and resource allocation. Before major hiring: capability gap analysis. Before major investment: evidence review. Before extending runway: an honest probability-of-success assessment.
The calendar matters because it removes mood from the loop. Strategy decided in reaction to the latest bad week isn’t strategy — it’s anxiety with a slide deck.
Fail cheaply, not fatally
Let me be clear about what none of this is: none of it is a recipe for eliminating failure. Some products will fail. Some features, some hires, some markets — wrong, wrong, wrong. That’s normal and unavoidable, and any founder who claims otherwise is selling something.
The achievable goal is narrower and much more powerful:
Fail cheaply. Learn quickly. Never let a small failure grow into a company-ending one.
A $20,000 experiment that prevents a $2 million mistake is a success. A three-month failed product test that prevents three years of wasted development is a win, even though it stings. A difficult leadership change made early can save the entire company. And letting a product perish while there’s still runway left might be the best decision a founder ever makes — it’s just a decision nobody applauds at the time.
The final leadership test
Nobody makes the right call every time. Not Grove, not Moore, not you, not me. Leadership isn’t a perfect-prediction contest.
It’s creating an organization where wrong decisions become visible early enough to correct. That takes clear assumptions, measurable outcomes, defined decision points, honest reporting, strong people, the psychological safety to challenge ideas, and the courage to change direction — balanced by the discipline not to change direction without evidence.
The companies that survive aren’t the ones that never make mistakes. They’re the ones that catch their mistakes before the mistakes become existential.
That’s the whole difference between a product experiment and a company-wide gamble. For anyone building with constrained resources, it’s the difference between another five years and another five months.
Your product will tell you the truth eventually. The only question is whether you’ll still have the runway to listen.