Good Failures vs Bad Failures in Open Innovation: How to Tell the Difference Before It Costs You

Everyone loves talking about failure these days. "Fail fast," they say. "Embrace failure." It has become the background music of innovation culture, repeated so often it has lost all meaning.

Here is the problem. Most companies that say they embrace failure actually just tolerate waste.

There is a difference. A big one. And if you cannot tell a good failure from a bad one, you are not running an innovation programme. You are running a bonfire for budgets.

What Makes a Failure Good

A good failure is bounded, intentional, and generates usable knowledge. That is it. Three criteria.

Bounded means you set limits upfront. You decided how much time, money, and resource you were willing to spend before you started. You drew a line and said, "We will not go past this."

Intentional means you had a hypothesis. You were not just "exploring the space" or "seeing what happens." You believed something specific, and you designed a test to find out if you were right.

Generates usable knowledge means you learned something you can actually act on. Not a vague sense that "it did not work out." Something concrete. Something that changes what you do next.

Think of it like a clinical trial. Nobody calls a drug trial a waste just because the drug did not work. The trial was designed to produce a clear answer. It did. That answer has value.

Good failures work the same way.

What Makes a Failure Bad

Bad failures are ambiguous, prolonged, and produce no actionable insight. They are the projects that drift for eighteen months, consume resources nobody properly tracked, and end with a shrug.

You know the signs. The objectives were vague from the start. Nobody could quite explain what success looked like. Warning signs appeared at month three, but everyone was too polite or too invested to raise them. And when the project finally wound down, nobody could articulate what was actually learned.

Bad failures are not brave. They are just expensive.

The gap I see constantly is this. Companies set up open innovation programmes, partner with startups or universities, launch pilots, and then have no mechanism to distinguish between the two types of failure. Everything gets filed under "innovation is risky" and life goes on.

Until the budget review, when everything gets filed under "cut."

A Real-Time Evaluation Framework

You do not need to wait until a project ends to figure out which kind of failure you are heading towards. You just need three questions at regular checkpoints.

Can we articulate what we have learned so far? If the team cannot clearly state what they now know that they did not know before, something is wrong. Learning should be accumulating, not just activity.

Are we still testing our original hypothesis, or have we drifted? Drift is natural. Unacknowledged drift is dangerous. If the project has quietly become about something different from what was originally proposed, you need to decide consciously whether the new direction is worth pursuing.

Would we start this project today, knowing what we know now? This is the hardest question and the most important one. It forces you to separate sunk costs from future value. If the honest answer is no, you have your answer.

Ask these three questions at every checkpoint. You will catch bad failures before they metastasise.

Three Things You Can Do This Week

Build kill criteria into every project from day one. Before a project kicks off, write down the specific conditions under which you would shut it down. Not "if it is not going well." Specific, measurable conditions. Revenue target not hit by date X. Technical feasibility not proven within Y sprints. Partner not delivering Z milestone. Write them down. Agree on them. Refer back to them.

Schedule structured reflection points at the midpoint, not just the end. Post-mortems are fine, but they come too late to save anything. A midpoint review, structured around those three questions above, gives you the chance to course-correct or kill with dignity. It also normalises honest conversation about progress while there is still time to act.

Create a failure log. Every unsuccessful project gets a short entry capturing what was tested, what was learned, and what should change as a result. This turns individual project failures into organisational knowledge. Without it, you will repeat the same mistakes with different partners and wonder why nothing improves.

The Point

Failure is not a badge of honour. It is a tool. And like any tool, it is only useful when you use it properly.

Stop celebrating failure generically. Start distinguishing between the kind that builds knowledge and the kind that just burns through goodwill and budget.

"Fail with purpose, or don't bother failing at all."