Pivot or persevere: how to make the decision in corporate innovation

Most corporate innovation projects that should be killed are not killed. The experiments show weak results. The team misses their fail criteria twice. The evidence is clear. And the project lives on for another nine months.

I see this pattern regularly. A VP pitched the idea to the board, so stopping feels like a political loss. A team of four works on it full-time, so stopping means reassigning people. The company already spent €300.000 or more, so stopping feels like admitting waste. And nobody agreed, upfront, on when to stop.

The pivot or persevere decision is where most corporate innovation processes break down. Not because teams lack the data. Because they lack the structure to act on it.

Why startup advice does not work here

Eric Ries popularized the pivot-or-persevere concept in The Lean Startup. His framework works well for startup founders: one person (or a small founding team) looks at the evidence and makes a call. The stakes are personal, the authority is clear, and the sunk costs are relatively low.

Corporate innovation operates under entirely different forces.

Sunk cost escalation. When a company has spent €500.000 on a project, the psychological pressure to continue is enormous. “We have already invested so much” becomes the dominant argument, even when the evidence says stop. In startups, the founder’s own money runs out and that forces the decision. In corporations, next quarter’s budget is always available if someone makes a strong enough case.

Political sponsorship. Every corporate innovation project has a sponsor. That sponsor’s reputation is tied to the project. Killing the project means the sponsor “failed.” In organizations where failure is punished (and most say they celebrate failure but actually do not), sponsors will fight to keep projects alive regardless of evidence.

Team dependency. In a startup, the founder pivots and the same three people work on the new direction. In a corporation, the team members on a killed project need new assignments. Sometimes their roles were created specifically for this project. The human cost of killing a project is real, and it makes the decision harder than any framework acknowledges.

Consensus culture. Startups decide fast because one person has authority. Corporations require alignment across functions. By the time a pivot decision reaches the right meeting with the right people, months have passed and more money has been spent.

I see this pattern in at least half the companies I work with. The problem is not that people ignore the evidence. It is that the decision-making structure was never designed for evidence-based innovation in the first place. If you want to understand why organizations struggle with these decisions at a deeper level, the innovation readiness assessment helps identify whether the culture and governance are actually set up for it.

Four options, not two

The Lean Startup gives you two options: pivot or persevere. In practice, corporate innovation teams have four.

Option 1: persevere

Keep going with the same hypothesis, the same customer segment, and the same business model. Run the next experiment in the sequence.

When to choose this: Your experiments are producing positive evidence. Customers confirm the problem. They show willingness to pay. The business model math works. Your fail criteria have been met or exceeded.

The corporate trap: Teams persevere by default when no decision process exists. “Nothing has gone wrong, so we continue” is not persevering. It is drifting. True perseverance is an active choice backed by evidence, not the absence of a kill decision.

Option 2: pivot

Change one or more elements of your business model hypothesis while keeping what you have learned. A pivot is not starting over. It is changing direction based on evidence.

Common pivot types in corporate innovation:

When to choose this: The customer problem is real (you have evidence for that), but your current approach to solving it is not working. The experiments fail on solution fit, not on problem fit. You have learned something specific that points in a new direction.

The corporate trap: Calling a restart a “pivot” to avoid killing the project. If the customer segment changes, the value proposition changes, and the revenue model changes, that is not a pivot. That is a new idea wearing the old project’s name. I have seen teams do this specifically to avoid the political cost of a kill decision.

Option 3: kill

Stop the project. Reallocate the team and budget to other opportunities.

When to choose this: The underlying problem is not painful enough for customers to act. The market size cannot support a viable business model regardless of configuration. Multiple experiments have failed on problem fit, not just solution fit. Or the competitive window has closed.

The corporate trap: Almost nobody wants to recommend killing a project. The team does not want to lose their roles. The sponsor does not want to lose face. Finance does not want to write off the investment. So the project continues as a “low-priority initiative” that consumes just enough resources to stay alive and too few to actually succeed. This is pilot purgatory, and it is more expensive than a clean kill.

Option 4: scale

Move from exploration to execution. The evidence is strong enough to justify full investment: dedicated team, production infrastructure, go-to-market. This is where the idea transitions from the explore side to the exploit side of your organization.

When to choose this: You have validated problem-solution fit and business model viability through multiple experiments. Customers are not just interested but are paying (or have committed to paying). The unit economics work. The business model has been tested, not just designed.

The corporate trap: Scaling too early based on enthusiasm rather than evidence. One successful pilot does not mean the business model works at scale. I have seen companies invest millions in production infrastructure for ideas that had exactly one paying customer. Make sure the evidence supports scaling, not just the excitement.

Build the decision into the process from day one

The pivot-or-persevere decision should not be a crisis. It should be a scheduled event.

Here is the process I use with teams, and it starts before any experiment runs.

Step 1: define decision criteria before the first experiment

When you design your first experiment, also design the decision meeting. Define what evidence would lead to each of the four outcomes.

Write it down in a format like this:

These criteria will be different for every project. The point is not the specific numbers. The point is that you agree on them before you have data that could bias the conversation. This follows the same logic as setting fail criteria for individual experiments, but applied at the project level.

Step 2: schedule the decision meeting in advance

Put the meeting on the calendar before the experiment starts. Not “when results are in” but a specific date, four to eight weeks out.

Why a fixed date? Because without one, the team keeps collecting data until the results look good enough to continue. I have seen teams run five rounds of experiments over eight months because nobody scheduled the moment to actually decide.

The meeting should include the project team, the project sponsor, and someone from the innovation portfolio governance who is not emotionally invested in this specific project. That third party matters more than most organizations realize.

Step 3: separate evidence presentation from decision making

This is where most corporate processes fail. The team that ran the experiments presents the results AND recommends the next step AND the same group makes the decision. That is like asking a defendant to also be the judge.

Split it:

1. The team presents evidence. What did they test? What were the pre-agreed criteria? What were the results? Fact-based, no interpretation yet.
2. Discussion. What does the evidence mean? Are there alternative explanations? What did the team learn that is not captured in the numbers?
3. The decision maker decides. Based on the pre-agreed criteria and the evidence presented. Not based on how much has been spent. Not based on who sponsored the project. Based on the evidence against the criteria.

In organizations where this feels too formal, I simplify it to one rule: the person who decides whether to continue must not be the person whose reputation depends on continuation.

Step 4: document the decision and the reasoning

Whatever the decision, write down why. “We are pivoting from customer segment X to customer segment Y because experiments showed strong problem validation but zero willingness to pay at the price point our business model requires.”

This does three things. It creates accountability. It builds organizational learning (the next team does not repeat the same experiments). And it protects the team. When a project gets killed based on evidence, the documentation shows that the team did rigorous work. That is a different story from “the project failed.”

How to present a kill recommendation to leadership

This is the conversation everyone dreads. Here is how to have it.

Frame it as learning, not failure. “We tested five hypotheses over twelve weeks and learned that the market for X is smaller than we projected” is different from “the project failed.” The first is professional. The second triggers defensive reactions.

Lead with the pre-agreed criteria. “Before we started, we agreed that if fewer than three hypotheses validated, we would kill the project. Two validated. Here is the evidence for each.” When leaders agreed to the criteria upfront, they cannot easily argue against their own framework.

Show what the investment bought. Every killed project produces knowledge. Customer insights that apply to other projects. Market data that informs strategy. Business model patterns that the organization can reference. Present these explicitly. A €300.000 investment that produces validated customer insights and market data is not wasted if the learning gets captured and applied.

Recommend what to do with the resources. Do not just say “kill it.” Say “kill it and reallocate the team to project Y, which has stronger evidence and needs additional capacity.” A kill recommendation paired with a better alternative is much easier to accept than a kill recommendation that leaves people without a plan.

Accept that some kills will be political. In one company, I watched a well-evidenced kill recommendation get overruled because the CEO had personally promised the customer segment. That happens. Your job is to make the evidence-based case clearly. You cannot control whether the organization acts on it. But you can build a track record of rigorous thinking that makes your recommendations harder to ignore over time.

Companies that handle the pivot-or-persevere decision well tend to score higher on innovation readiness overall. The ability to kill projects based on evidence is one of the clearest indicators of innovation maturity.

For a deeper look at governance structures that support these decisions, see innovation portfolio governance.

Common mistakes in the pivot-or-persevere decision

After 100+ sessions with innovation teams, I see the same errors repeat.

Treating every decision as binary. Teams think it is “continue or stop.” They forget about pivoting. Or they pivot when they should kill. Having all four options on the table prevents forced choices between two extremes.

No pre-agreed criteria. This is the single most common mistake. Without criteria defined before experiments run, every decision becomes a debate about interpretation. And in corporate debates, the person with the most organizational power wins, not the person with the best evidence. See how to test business assumptions for building hypothesis-driven experiments that produce clear evidence.

Confusing activity with progress. “We ran eight experiments” sounds impressive. But if seven of them tested the same hypothesis with minor variations, the team was not learning. They were looking for confirmation. A real pivot decision framework tests different hypotheses, not the same hypothesis in different wrapping.

Letting sunk costs drive the decision. The €500.000 already spent is gone regardless of what you decide next. The only question is: does the evidence justify spending the next €100.000? Sunk cost arguments sound rational (“we have invested too much to stop”) but they are the opposite of rational. They are emotional attachment disguised as financial logic.

Skipping the kill option entirely. Some organizations do not have “kill” in their vocabulary. Projects get “paused” or “deprioritized” or “moved to the backlog.” These are all ways of avoiding the decision. A paused project still consumes mindshare, still shows up in portfolio reviews, and still prevents the team from fully committing to something new. Kill means kill. For more on how this affects portfolio health, see innovation portfolio mistakes.

Understanding innovation accounting helps teams measure real progress instead of activity.

For corporate-specific approaches to building testing into the organization, see testing business ideas in corporate innovation.

When projects do get killed, having a clear process prevents killing innovation projects from becoming a political event.