Ten weeks on the road, interviewing customers, building minimum viable products and running experiments. Ben Hafele remembers a team in China that did almost everything he could have asked for. Its findings changed how the company understood its customer segments and supported a clear product recommendation.
Then came the meeting with the vice president. Leadership had already decided to take a different direction six weeks earlier. The evidence arrived after the decision.
For Hafele, CEO of Lean Startup Co., this is where corporate innovation often breaks down. Teams can learn the methods and do excellent work, yet their findings never shape what the business builds. In this conversation with Dr. Christian Mühlroth, he explains what leaders must put in place for experimentation to matter.
Give core innovation a serious job
Hafele challenges the tendency to reserve innovation teams for disruptive ideas and distant growth opportunities. Promising returns five to seven years away creates a difficult conversation in businesses facing quarterly pressure. Meanwhile, important uncertainty exists inside the core business, where a poor product or customer decision can hurt much sooner.
Looking back at his time at Caterpillar, he wishes someone had encouraged him to become indispensable to the existing businesses. Helping them make better decisions gives innovation work a purpose that remains relevant when leadership changes or budgets tighten.
Strategy also needs to exclude work. At Caterpillar, Hafele's team identified which strategic themes it would support, which it would leave alone and where it would focus on only part of a theme. That gave the team a clear basis for turning requests down.
“This is not waste everybody's time startup. It's lean startup, right?”
Make evidence part of the decision
The familiar build-measure-learn loop is one part of Hafele's framework. Strategy, milestones, teams, governance and culture must work with it. Leaders need to establish who will run experiments, how much time they have and what evidence will count as progress.
He describes another engagement where a team barely experimented despite training and coaching. At the final presentation, its sponsor interrupted the findings and spent 45 minutes explaining his own vision. The team's reluctance suddenly made sense: its members had expected to be told what to build anyway.
Hafele wants someone inside the company to play the investor's role, requiring evidence before an initiative advances. That can be one executive. Teams should be able to recommend continuing, changing direction or stopping, without treating every stopped project as a personal failure.
For R&D leaders, the question is concrete: which forthcoming investment decision will this experiment inform, and who has agreed to use the findings?
Learn in the right order
Hafele describes the practical starting point as learn-build-measure. Identify what you need to learn, build the smallest viable experiment that can help answer it, then assess whether the evidence is sufficient.
Early milestones should establish who the customer is, what problem matters and whether it is important enough to solve. Next comes evidence that the proposed offering addresses that problem. Go-to-market questions and the remaining business-model assumptions follow.
He sees large companies spending too much attention on feasibility and viability before establishing whether customers want the proposed solution. Technical confidence cannot settle that question.
Nor does customer discovery mean asking people to design the product. Hafele asks workshop participants to look around their desks: how many of those things would they have known to request? The work is to understand problems deeply enough to offer a solution customers did not anticipate.
Ask for something more revealing than praise
An experiment needs a prediction made before the results arrive. Hafele breaks its design into an instrument, a channel and a call to action: what will people encounter, how will they encounter it and what do you expect them to do?
Set the response threshold in advance. Otherwise, a team can reinterpret almost any result as encouraging once it has invested effort in the idea.
His more surprising point concerns evidence strength. A sophisticated prototype can still produce weak evidence if the only question at the end is whether someone liked it. Even a Wizard of Oz test, where people simulate the service behind the scenes, can finish with little more than polite approval.
A preorder, pilot application or commitment of time asks more of the customer. One of Hafele's favourite tests is deliberately inconvenient:
“Meet with us at 4:00 on Friday if you want to know about this.”
The example makes his point memorable. The effort someone will make can reveal more about demand than their enthusiasm in a conversation.
Start with one leader willing to learn
Hafele supports using AI to accelerate experiment design, prototypes and analysis. He still wants people to examine the assumptions, add the specifics of their situation and decide what to test. Faster tools leave the harder questions about strategy and governance with leadership.
That does not require persuading every executive before starting. Find a leader willing to give a team time and let the approach prove itself. Useful results can help the next group understand why it is worth adopting.
“The minimum number of leaders is one.”
For the next product initiative, that is a manageable place to begin: a meaningful problem, a team with time to investigate it and a sponsor whose decision can still change.

