Pivot vs Kill: staying longer in the 0-1 mess before you decide.

Why good product leaders resist false clarity and learn faster instead.

• Pivot vs Kill: staying longer in the 0-1 mess before you decide.
• Why “pivot vs kill” is the real 0→1 test
• The mess: why 0→1 decisions are uniquely hard
• A simple Pivot vs Kill lens
• Story 1: When validated need meets technical immaturity
• Story 2 – Killing a validated idea that didn’t fit strategy
• Staying longer in the mess (and not getting stuck there)
• How AI changes the pivot/kill flow
• What good product leaders actually optimise for

It’s not hard to imagine why. Imagine you’ve validated a real need, your deck looks good, even someone’s paying you… and you still suspect this product should die. This is what happens in reality: founders’ emotional sunk cost, teams craving clarity, leadership wanting “traction” while the real work is learning.

Good product leaders don’t optimize for idea survival, but for learning speed and portfolio value, so they often stay in the mess longer, and kill faster. This article is for PMs and product leaders running 0→1 bets who struggle with “how do I know when to pivot vs kill?”

The mess: why 0→1 decisions are uniquely hard

Why are managers reluctant to kill ideas?

• Emotional sunk cost (founders, sponsors, teams).
• Confirmation bias (searching for proof we’re “right”).
• Local success vs global strategy (an idea that “works” but doesn’t fit this company).

Over the last 3.5 years, I've learned to prioritise “time to insight” rather than “number of features shipped” or “NPS after v1.” In this piece, I’ll use two real examples to show how I decide when to pivot vs kill and how to hold the space in the mess without drifting forever.

A simple Pivot vs Kill lens

Here's my mental model, you can use it too.

Ask yourself/your team these questions:

• Q1: Evidence of a real, repeatable problem? Have we seen consistent signals across segments? Are we solving a hair-on-fire (painkiller) problem vs a nice-to-have (vitamin)?
• Q2: Viable path to a defensible solution? Can we build/operate this reliably with our current tech/org maturity? Are constraints (regulation, data, integrations) realistically solvable?
• Q3: Strategic and economic fit? Does this move our P&L, strategic positioning, or flywheel meaningfully? Or is it a distracting “pet success” that won’t ever matter?

“Good product leaders don’t optimize for idea survival, but for learning speed and portfolio value.”

Igor Ponikarchik, Senior Product Manager @ Street Group

Once you have answers,here’s a basic model

• Pivot: Problem signal strong, but solution/segment/model wrong.
• Kill: Either problem isn’t real/large enough or no viable/strategic path for this company to win—even with validation and early revenue.

With that lens, here’s how we handled two very different calls.

Story 1: When validated need meets technical immaturity

One idea went through discovery and even smoke testing via a fake landing page, winning first leads begging to buy a solution to remove huge overhead from their operations by automating field visits. Leads were impressed by how easily they could collect data from the field in seconds instead of paying 3rd parties to send agents—a process taking ages and hundreds of thousands of dollars.

The pain was real, we had leads ready for technical pre-sales calls and even partnership talks.

On the back of that, we delivered a PoC to test tech feasibility , and soon learned the underlying data and infrastructure didn’t provide enough accuracy (we reached only 80%). For our ICP, accuracy was key since it powered decisions risking non-compliance fines. False positives could add more work instead of reducing workload. The solution works for SMEs but the numbers didn’t add up financially. We needed enterprise clients.

It was a great validated problem, but the tech wasn’t mature enough for our SLA and business case. Pivoting would have broken the validation, as the product was very niche, addressing a bulls-eye problem.

Decision: Kill. Strong Problem, weak Solution feasibility, questionable Economic payoff.  We framed it internally as a validated opportunity without enough commercial traction to cover capex and support. But we still used the learnings in another project.

Story 2: Killing a validated idea that didn’t fit strategy

While discovering opportunities for adjacent 2030 revenue goals and exploring AI products, I came across a problem in fleet management where fleet owners used 4-6 different tools that didn’t talk to each other. The idea: an LLM-based chatbot with DB access and integrations to enable fleet managers to chat with their fleet, do root cause analysis, and get performance improvement insights.

Qualitative interviews succeeded, and a quantitative marketing campaign generated excited leads.

After deeper refinement and SLT review, we realised this drifted from our core domain and would require entering a new, oversaturated market with established leaders controlling most shares. Defensibility was low, no barriers for incumbents to copy. Plus, it would send confusing market signals and scare investors.

Decision: Kill. Problem real, Solution validated, but no Strategic/Economic fit.

Validation is necessary but not sufficient. It reminds the team: not every bet goes to the end, learning speed matters more.

Staying longer in the mess (and not getting stuck there)

To protect your and founders’ egos from hurting, and be more productive, you need to hold multiple hypotheses alive. Also, keep the team from emotional attachment: remember that 6–7 out of 10 options will blow up. Keep stakeholders close to the learning, not just the outputs.

I use a stage-gated approach like sprints with clear outputs you need to achieve that should inform your decision making. Track “time to insight” as your primary metric, focusing on shrinking discovery and validation cycles.

How AI changes the pivot/kill flow

Not using AI in your product journey nowadays sets you back, letting competitors test faster.  Don’t use AI to decide if you should kill an idea, or even to synthesize customer interviews, due to potential hallucinated “insights” that reinforce existing bias. You ego will be happy but down the road you will be more painful. Instead, have AI use your learning data to provide an initial assessment and scoring, similar to Claude with access to your design or code repository to write Jira tickets.

What good product leaders actually optimise for

In the AI era, shipping is easy, but shipping differentiating products defines leaders. Add ruthless post-ship learning: does it move the P&L?