Innovation portfolios are often described as collections of bets.

The metaphor has value. It reminds executives that no amount of analysis can guarantee a successful outcome. Markets move, competitors respond, technologies change, and customers behave differently from what a business case predicted.

But the metaphor can also distort the work of innovation management.

A bet sounds like a decision made once. The organization chooses an opportunity, places capital behind it, and later discovers whether it won or lost. Governance then becomes a search for better bets: better ideas, better forecasts, better selection criteria, or leaders with better instincts.

Innovation does not unfold that way. An initiative is a sequence of decisions made as new information becomes available. The first commitment should create the conditions for a better second decision. The second should improve the third. Capital should increase only as the organization earns a stronger basis for committing it.

The central question is therefore not whether management picked a future winner at the beginning.

It is whether each investment made the next decision better than the previous one.

Outcomes are unreliable teachers

When an innovation succeeds, the original decision is usually remembered as insightful. When it fails, the decision is recast as misguided. Annie Duke calls this tendency to judge a decision by its outcome “resulting.” Outcomes reflect both decision quality and luck, so a good process can produce a bad result while a weak process occasionally succeeds.[1]

Formal decision analysis makes the same distinction. Decision quality depends on how well the problem was framed, which alternatives were considered, what information was available, how uncertainty was assessed, and whether the choice was consistent with the decision-maker’s objectives at the time.[2] None of this guarantees the desired result.

Innovation adds a deeper difficulty. Frank Knight distinguished measurable risk from uncertainty, where probabilities cannot be estimated reliably because the relevant knowledge does not yet exist.[3] Early innovation decisions often concern exactly these unknowns: whether the problem matters enough, whether behavior will change, who controls the purchase, whether the technology can perform in context, and whether the economics can work.

Detailed forecasts do not convert these uncertainties into facts. They often make untested assumptions look precise.

Once the outcome is known, hindsight makes the path appear more predictable than it was.[4] Outcome bias then leads people to evaluate otherwise identical decisions differently depending on whether they produced favorable or unfavorable results.[5] The successful initiative acquires an origin story of foresight. The unsuccessful one fills with warning signs that supposedly should have been obvious.

An organization that learns only from winners and losers therefore learns too late—and may learn the wrong lesson.

Project progress can hide decision stagnation

Because outcomes take sometime months or years to appear, organizations look for earlier signals of progress. They review whether the team completed interviews, produced a prototype, launched a pilot, met its milestones, or stayed within budget.

These are legitimate project-management questions. They are poor substitutes for innovation governance.

A prototype can be completed without testing the assumption most likely to destroy the opportunity. Fifty interviews can produce little more than favorable comments if the sample, questions, and interpretation protect the original idea. A pilot can demonstrate technical feasibility while revealing nothing about adoption, willingness to pay, or the operating model required to scale.

Activity has increased. The organization’s ability to decide may not have changed.

This confusion is reinforced by the different economics of exploration and exploitation. James March described exploitation as the refinement of what is already known and exploration as the search for new possibilities.[6] Established operations can be evaluated through delivery, efficiency, revenue, and variance from plan. Early innovation cannot, because the assumptions that would make those measures meaningful are still being investigated.

When both are governed through project progress, exploration begins to imitate execution. Teams produce plans and artifacts that make the initiative look increasingly real. Momentum grows faster than evidence, and stopping becomes harder precisely when the organization should still be preserving flexibility.

Stage gates should govern commitments, not presentations

Stage-Gate was not originally designed as a bureaucratic checklist. Cooper’s model divided new-product work into stages that generate information and gates that decide whether further resources should be committed.[7] Later versions emphasized adaptability, different pathways, spiral development, and “gates with teeth,” while warning against rigid and over-bureaucratic implementation.[8]

The problem is not necessarily Stage-Gate theory. It is what many gates reward in practice.

Teams arrive with polished slides, prototypes, roadmaps, financial projections, and evidence summaries. Gatekeepers assess whether required deliverables exist and whether the presentation supports continuation. The initiative receives another tranche because it appears to have progressed.

Yet the governance question is not whether the team has been busy or persuasive. It is whether the evidence generated since the previous gate justifies exposing more capital, credibility, and organizational energy.

Discovery-Driven Planning made assumptions explicit and treated plans as hypotheses rather than facts.[9] Real-options reasoning showed why small, staged commitments can preserve the right—but not the obligation—to invest more after uncertainty has been reduced.[10]

Both point toward the same principle:

Knowledge should increase before commitment increases.

That principle needs an operational condition at the gate. I call it Decision Readiness.

Decision Readiness is the degree to which decision-relevant uncertainties have been made explicit and investigated with signals sufficient to justify a specified next commitment.

It does not mean that uncertainty has disappeared. Nor does it promise a successful outcome. It asks whether the organization has reduced the avoidable ignorance relevant to the decision before it increases its exposure.

What Decision Readiness requires

An initiative is ready for its next decision when governance can see six things clearly:

1. The decision: What commitment is being requested now—not the eventual ambition, but the next release of money, people, access, or reputation.

2. The theory of value: Why this initiative is expected to create value, for whom, and through which change in behavior or economics.

3. The critical assumptions: What must be true for that theory and the next commitment to remain defensible.

4. The evidence change: What the organization knows now that it did not know at the previous gate, including contradictory observations.

5. The decision thresholds: Which findings support scaling, pivoting, stopping, or deferring.

6. The proportional commitment: Why the size and reversibility of the next tranche are appropriate to the evidence available.

If these conditions are absent, another deliverable will not repair the decision. The project may be ready for its next activity without being ready for its next investment.

This also changes how stopping should be interpreted. If a €40,000 discovery stage produces credible evidence that a planned €3 million program should not proceed, nothing has launched and no revenue has been created. Yet the stage may have generated substantial governance value by preventing a much larger, weakly supported commitment.

The return is not failure avoided with certainty; that claim would be impossible to prove. The return is a materially better capital decision made while the downside was still contained.

The question every gate should ask

The most revealing gate question is not:

Did the team deliver what it promised?

It is:

Knowing what we know today, would we make the same next commitment again?

If the answer is yes, governance should be able to show which evidence supports the commitment and why the next tranche is proportionate.

If the answer is no, the organization should not conceal that learning behind project momentum. It should pivot, stop, or redefine the commitment.

If the evidence is insufficient, it should defer the decision through a bounded investigation with a date, cost ceiling, and explicit learning objective—not extend the initiative by default.

Innovation governance cannot remove luck. It can reduce how much capital is exposed to assumptions that could have been investigated earlier.

That is why innovation management is not primarily about making better bets. It is about earning better decisions before each larger commitment is made.

If this diagnosis is useful, the paid section provides the application: a Decision Readiness Gate you can use on one live initiative within the next seven days.

Share

The Decision Readiness Gate

Use this gate before approving a new tranche for an initiative whose commercial outcome remains uncertain. It is not a project scorecard. Its purpose is to expose whether the proposed commitment is supported by decision-relevant evidence.

Start with one real decision. Do not apply it to the portfolio in general.

Read more

A salesperson reports that customers have stopped responding to the company’s value proposition. A support representative notices clients constructing the same workaround, again and again. An account manager sees purchasing authority shift to a stakeholder the product was not designed for. An operations employee watches a process become more expensive while delivering less.

They raise it.

Their managers listen. Nobody is punished. The employees are thanked for their candor. The meeting may even be remembered as evidence of a healthy culture.

Then it ends.

The targets do not move. The roadmap continues. The budget stays where it was. The next executive presentation describes the market using the same assumptions as before.

The information was accepted socially and rejected operationally.

This organization may be safe enough for people to speak. It is not yet capable of learning from what they say.

Psychological safety makes learning possible. It does not complete it.

Amy Edmondson defined team psychological safety as a shared belief that a team is safe for interpersonal risk-taking. Her research connected it to learning behaviors such as discussing errors, seeking feedback, asking for help, and experimenting.[1] Later reviews have reinforced its importance for voice, teamwork, and organizational learning.[2]

That contribution is difficult to overstate. In many organizations, admitting uncertainty or challenging authority can still carry reputational and career risk. If people expect embarrassment, punishment, or exclusion, important information will remain private.

Yet psychological safety solves a specific problem: whether a person can take an interpersonal risk. It does not, by itself, determine what the organization does with the information that emerges.

This distinction matters because voice and learning are not synonyms.

Voice is an act: someone communicates an idea, concern, observation, or challenge.

Learning is an update: the organization changes what it believes or what it does because new evidence has altered its understanding.

The first can happen without the second. A leadership team can encourage disagreement, run candid retrospectives, and score well on a safety survey while leaving every consequential commitment untouched. The conversation changes. The decision system does not.

Psychological safety is therefore an input to learning, not proof that learning occurred.

The hidden failure is safe futility

Research on employee voice and silence shows that people consider more than the danger of speaking. They also consider whether speaking is likely to make a difference.[3] The practical questions are simple:

Is it safe to raise this?

Will anything happen if I do?

Organizations have become more attentive to the first question. They train managers to listen without defensiveness. They create surveys, retrospectives, town halls, ethics channels, and escalation paths. These mechanisms can be valuable.

But the second question is easier to neglect.

An organization can reduce fear while preserving futility. Employees are invited to report what they see, but no process connects their observations to the assumptions behind a strategy, the evidence required to revise it, or the authority to change the allocation of resources.

The feedback mechanism then becomes a container. It absorbs disagreement without allowing disagreement to touch commitment.

The employee is heard. The assumption is not examined.

The concern is logged. The project remains protected.

The risk appears on a slide. The funding continues automatically.

The organization has built a pressure-release valve, not a learning system.

Morrison and Milliken described organizational silence as a collective pattern in which employees withhold information about potential problems, limiting an organization’s capacity for change and development.[4] Safe futility is a less visible route to the same destination. People may speak at first, but they learn from repeated inaction that the expected value of doing so is close to zero.

Eventually, candor becomes ceremonial. Employees continue attending the meetings while becoming more selective about what they genuinely challenge.

Silence returns, not because speaking is forbidden, but because experience has taught people that speaking is inconsequential.

A safe meeting can sit inside a defensive organization

Most leaders support employee voice in principle. The harder test comes when the message threatens a commitment they helped create.

Research shows that perceived managerial openness is strongly related to whether employees speak up.[5] It also shows that employees carry implicit rules about when voice is risky or inappropriate: do not bypass the boss, do not challenge authority in public, do not raise a problem without already having the solution, and do not speak outside your formal area of responsibility.[6]

The content of the message matters as well. Managers tend to respond more favorably to voice that supports the current direction than to voice that challenges it.[7]

“We should improve the sales script” asks for better execution.

“Customers no longer value the problem we built the product to solve” challenges the strategy.

“We need more training” protects the operating model.

“The operating model makes the behavior we want economically irrational” challenges it.

The first type of voice is easier to welcome because it leaves the governing assumptions intact. The second creates a threat: if the observation is correct, targets may need to change, forecasts may need to be revised, investment may need to move, and leaders may need to explain why the previous view no longer holds.

That is where an apparently open organization can become defensive.

Defensiveness rarely announces itself as a refusal to learn. It arrives as a plausible explanation. The signal is too early. The sample is too small. Customers do not know what they want. Sales is positioning the offer incorrectly. The market needs more education. The team needs another quarter.

Any of these explanations may be right. The warning sign is not their existence, but their asymmetric use. Evidence that supports the plan is treated as confirmation. Evidence that threatens it is treated as an exception requiring a much higher standard of proof.

Chris Argyris distinguished between single-loop learning, which corrects execution while preserving governing assumptions, and double-loop learning, which examines whether those assumptions, goals, or policies remain valid.[8] Defensive governance has a reliable way to avoid the second loop: it translates strategic contradictions into execution problems.

Declining demand becomes a sales-discipline problem. Repeated customer workarounds become a training problem. Weak adoption becomes a communication problem. Deteriorating unit economics become a scale problem.

The explanation keeps changing so the decision does not have to.

Information can disappear at five different handoffs

The path from speaking up to learning is not one event. It is a chain:

Voice → attention → interpretation → test → decision → allocation

Psychological safety mainly strengthens the first link. The remaining links are governed by attention, incentives, authority, process, and resource allocation.

1. Voice without attention

A concern is raised but never enters a forum with the authority to act on it. It stays inside a team retrospective, employee survey, customer-success report, or risk log.

The organization can honestly say the issue was surfaced while the relevant decision-makers never have to confront it.

2. Attention without interpretation

Leaders hear the signal but do not connect it to a specific belief. The discussion remains at the level of impressions: sales is concerned, support is frustrated, customers seem hesitant.

Without identifying the assumption under pressure, the conversation becomes a contest between opinions.

3. Interpretation without a test

The team agrees that an assumption may be wrong but does not design a way to distinguish among competing explanations.

The issue becomes an open question that can remain open indefinitely.

4. A test without a decision threshold

The organization gathers more data but has not agreed what different results would mean. When the evidence arrives, it is interpreted after the fact.

Every outcome can then be made compatible with continuing the current plan.

5. A decision without allocation

Leaders announce that they have learned, but the roadmap, staffing, targets, and capital remain unchanged.

The language updates while the commitment does not.

This last handoff is decisive. An organization’s real beliefs are visible less in what leaders say than in what they continue to fund.

The edge often sees change before the center can measure it

People close to customers, suppliers, operations, and service failures frequently encounter change before it becomes legible in an executive dashboard.

Salespeople hear new objections. Support teams see recurring workarounds. Field staff observe how a product is actually used. Procurement sees supplier behavior shift. Operations notices where formal processes are quietly bypassed.

Research on frontline sensing argues that these observations can provide early information for strategic decisions because frontline employees participate in the daily transactions through which changing conditions first become visible.[9]

This does not mean the edge is automatically right. Frontline employees have partial views, local incentives, and their own interpretive biases. Executives do too; their information is simply more aggregated, delayed, and filtered.

The governance advantage comes from treating frontline observations neither as truth nor as anecdote, but as signals that can be converted into questions:

• What exactly was observed?

• Which current assumption would be weakened if the observation were representative?

• What rival explanations could also produce it?

• What is the cheapest credible test that would separate those explanations?

• Which pending decision depends on the answer?

This shifts the conversation away from whether the employee can prove the entire strategic case. A person should not need a fully developed solution before the organization becomes willing to investigate a contradiction.

Requiring that level of proof gives the existing plan an unfair advantage: the plan receives resources, analysts, and executive sponsorship, while the challenge must arrive complete.

A weak signal is not a verdict. It is a reason to investigate.

Endorsement is not implementation

Managers can sincerely agree with employee input and still be unable to act. Research distinguishes between endorsing voice and implementing it; implementation depends partly on motivation, felt obligation, perceived control, and the surrounding network of relationships.[10]

That gap is easy to recognize in practice.

A line manager listens but cannot alter the product roadmap. A product leader accepts the evidence but remains locked into annual targets. An executive sees that the forecast rests on a weakening assumption but fears the consequences of revising guidance. A board asks for candor while rewarding predictability and treating deviation from plan as failure.

At that point, the problem cannot be solved by asking the direct manager to listen more skillfully. The information has reached the boundary of that person’s authority.

Voice becomes strategically useful only when it is attached to a decision system with four properties:

• A named decision that the signal could affect

• An owner with authority to investigate and act

• A date by which the evidence will be reviewed

• An explicit rule for what happens under different results

Without these, leaders can endorse the message while the organization rejects its implications.

The test of learning is observable change

Not every concern should change the strategy. Psychological safety does not mean that every challenge is correct, that all evidence is equally strong, or that leaders must follow every suggestion.

It does mean that material challenges deserve a fair route to resolution.

The strongest evidence of a learning organization is not the number of ideas submitted, the volume of discussion, or the score on a speaking-up survey. It is whether new information can produce an observable update.

That update should appear in at least one of four places:

1. Assumption: What the organization believes about customers, value, behavior, capabilities, economics, or the environment.

2. Test: What the organization will do next to reduce a consequential uncertainty.

3. Decision: Whether to scale, pivot, stop, or defer a commitment.

4. Allocation: Where time, attention, people, and capital go as a result.

If none of these changes, the organization may have communicated. It has not demonstrated learning.

The board-level question is not whether people feel heard

Feeling heard matters because it affects whether people will contribute again. But a board cannot infer adaptability from that feeling alone.

The sharper question is whether uncomfortable information can change what the organization is committed to.

A board or executive team should be able to answer:

• What new evidence has challenged a material assumption since the last review?

• Which signals from customers, sales, support, operations, or partners were investigated?

• What alternative explanations were tested?

• Which assumption, test, decision, or allocation changed?

• What evidence would cause us to scale, pivot, stop, or defer the initiatives currently under review?

• What happened to the last three material concerns raised inside the organization?

These questions expose the difference between a culture that permits voice and a governance system that converts voice into adaptation.

The diagnosis is complete: psychological safety makes uncomfortable information more available. Learning requires governance to make that information consequential.

Share

The Signal-to-Decision Protocol

The purpose of this protocol is not to reward every person who raises a concern by accepting their interpretation. It is to prevent a consequential signal from disappearing before the organization has learned what it means.

Use it when someone surfaces information that could change a material commitment: a product investment, market entry, transformation program, acquisition thesis, operating-model change, or strategic partnership.

The protocol begins with a real decision, not a general discussion.

Read more

Every struggling innovation project eventually becomes good at explaining why it should continue.

A missed milestone becomes a temporary resource issue. Weak customer interest becomes a positioning problem. Low willingness to pay becomes a pricing issue. A disappointing pilot is declared unrepresentative, while a new competitor is treated as proof that the opportunity must be real.

None of these explanations is necessarily false. Each may be reasonable on its own. The problem is their direction. They all lead to the same conclusion: give the project more time, more money or another chance.

I think of this as the press secretary in our heads—and, eventually, in our organizations. Its job is not to determine what caused the result. Its job is to produce an account that sounds coherent, defensible and compatible with what we already want to do.

The spokesperson is not the decision-maker

The metaphor comes from Robert Kurzban’s work on the modular mind. In Why Everyone (Else) Is a Hypocrite, Kurzban argues that the mind is not a single, unified decision-maker with complete access to its own motives. It contains specialized systems whose interests and conclusions do not always align. The conscious explanation can therefore resemble a press secretary: it presents a coherent public account without necessarily having access to the processes that produced the behavior.[1]

This is best treated as a useful model rather than a precise neurological description. Its value lies in the distinction between producing a decision and explaining one. The explanation may feel like an investigation even when it is closer to representation.

Ziva Kunda’s research on motivated reasoning supports the distinction from another direction. People seeking a preferred conclusion do not usually abandon reason. They access, construct and evaluate beliefs in ways that make the preferred conclusion easier to reach, while remaining constrained by the need to produce a justification that appears reasonable.[2]

Kevin Simler and Robin Hanson extend the argument to hidden motives. The reasons people publicly give for their behavior may coexist with less visible motives concerning status, signaling or self-presentation. We can sincerely believe the public account because introspection does not automatically reveal everything that shaped the decision.[3]

The press secretary therefore does not need to lie. It only needs enough ambiguity to select one plausible explanation from several.

Projects develop press secretaries too

Innovation projects reproduce the same pattern collectively.

Nobody appoints the spokesperson. It emerges through steering-committee decks, status reports, dashboards and the repeated need to explain why the expected results have not appeared. A weak signal enters the organization as evidence and leaves as a story about why the project remains promising.

This does not require manipulation. Product leaders, sponsors, finance teams and executives can all interpret the same evidence sincerely while protecting different interests. The sponsor protects the original decision. The team protects its work and identity. The executive protects a strategic narrative already communicated upward. Finance protects the credibility of earlier allocations.

The resulting story belongs to no single person, yet it has a consistent policy: continue.

This is why asking whether an explanation is true is often insufficient. Several explanations may be compatible with the available evidence. The more important question is whether the organization is testing among competing explanations or selecting the one that preserves the existing commitment.

Continuation protects more than the project

Recommending that a project stop creates an asymmetric personal risk.

If the project would later have succeeded, the person who argued against it may be remembered as the one who nearly killed the opportunity. Recommending another quarter is safer. It preserves relationships, avoids challenging the original sponsor and postpones the point at which someone must admit that the initial decision may have been wrong.

The dynamic becomes stronger when the people reviewing the project are the same people who authorized it. Barry Staw’s classic experiment on escalation of commitment found that decision-makers who felt personally responsible for an earlier choice allocated more resources to it after receiving negative feedback.[4] Continuing did not merely protect the project. It protected the meaning of the original decision.

Prospect Theory provides a complementary mechanism. Kahneman and Tversky showed that people evaluate choices relative to a reference point and may become more willing to accept risk when facing losses.[5] Applied cautiously to innovation investment, stopping can feel like realizing a loss, while continuing preserves a possibility—however uncertain—of recovering it.

The financial case for the project may be weakening at the same time as the psychological case for one more investment becomes stronger.

Organizations often call this commitment. Sometimes it is. Sometimes it is self-justification with a budget line, and the two are difficult to distinguish from inside the room.

Private doubt becomes public confidence

The press secretary does not only protect individual judgment. It also solves a coordination problem.

Several people may privately doubt the project while each assumes that everyone else still supports it. Speaking first carries personal risk. Silence is safer, particularly when the sponsor has more status or the group has already communicated confidence publicly.

Morrison and Milliken describe organizational silence as a collective phenomenon in which employees withhold information about potential problems because speaking appears risky or futile.[6] Irving Janis’s work on groupthink describes a related failure: groups committed to cohesion and consensus can suppress dissent and discount contradictory evidence.[7]

The result is an organization that appears more confident than its members actually are. People update their private beliefs while the public narrative remains unchanged.

What looks like alignment may therefore be a measurement error. The meeting records the story people are willing to defend, not necessarily the judgment they privately hold.

Evidence does not speak—and it does not decide

This is why calling an organization evidence-driven tells us very little.

Evidence does not interpret itself. A lower conversion rate may indicate a weak value proposition, the wrong segment, poor execution, a flawed channel, insufficient time or a measurement problem. The data alone cannot decide among these explanations.

The important capability is not collecting evidence but allowing it to change a decision. Many organizations reward visible confidence, commitment and delivery more reliably than they reward someone for disproving an expensive assumption early.

Eric Ries built the Lean Startup around experiments that reduce uncertainty before more resources are committed, with evidence informing whether to persevere or pivot.[8] The organizational press secretary reverses that logic. Evidence stops testing the project and starts supplying material for why it should continue.

A dashboard full of green metrics may mean that the underlying assumptions are holding. It may also mean that the team has become skilled at selecting metrics that remain green.

Psychological safety helps, but it does not solve this problem alone. Amy Edmondson’s research shows that psychological safety is associated with learning behavior because people can discuss errors, ask for help and take interpersonal risks.[9] That makes difficult evidence speakable. It does not automatically make the evidence consequential.

I have sat in rooms where doubts were expressed clearly and without punishment, yet the project continued because the meeting had no mechanism for translating a concern into a capital decision. Psychological safety had done its job. Governance had not.

The governance failure happens before the pilot

The press secretary gains influence when nobody defines in advance what the evidence must change.

Ask a steering committee which result would make it stop a project and the answer often becomes vague: the numbers will be reviewed next quarter, the market needs more time or the team will know when it sees the signal.

Without a pre-committed threshold, every result remains negotiable. Continuing is the default. Stopping requires an active decision that can be challenged, delayed and reframed.

The team does not need to distort the evidence. It only needs the decision rules to remain soft enough that almost any outcome can be interpreted as encouragement.

Organizations would not accept a capital-expenditure threshold invented after the money had been spent. Yet innovation projects routinely define their stop conditions after a pilot has disappointed. At that point, the threshold is no longer an independent decision rule. It is part of the negotiation over whether the existing commitment should be protected.

The fix is not more analysis. It is better sequencing.

A threshold agreed before the pilot is different from the same threshold proposed after the result, even when the number is identical. The first was set before people knew which conclusion it would support. The second is proposed by people who already know what it will do to their project.

The board-level question

For executives and boards, the practical question is not whether the story supporting a project sounds plausible. Most continuation stories do.

Ask instead who defined the conditions under which the project would scale, pivot, stop or defer—and when those conditions were set relative to the capital already committed.

Then ask the harder counterfactual: If this initiative did not already exist, would we fund its next tranche today, knowing what we now know?

The question is not a complete decision rule. Stopping may carry costs, and an existing project may contain option value that a new proposal would not. But the counterfactual exposes how much of the current case depends on future value and how much depends on defending the past.

Evidence is not decision-grade because it is quantitative, recent or displayed on a dashboard. It becomes decision-grade when it is tied to a prior assumption, compared with an explicit threshold and allowed to change the allocation of capital.

Without that structure, the project is not being governed by evidence. The evidence is being recruited by the press secretary.

Leave a comment

The Press Secretary Protocol

Read more

The exercise is commonly associated with Tom Wujec because his 2010 TED talk made it widely known. Its origin predates that talk, and Peter Skillman is generally credited with originating it. Skillman says he began running what he called the Design Challenge with IDEO clients, later used it in university lectures and helped introduce it into corporate Design Thinking training through the IDEO University curriculum. He also notes that the exercise evolved with IDEO colleagues Dennis Boyle and Christine Kurjan and that he no longer remembers exactly how its first version arose. He presented it at TED in 2006. What is clear from his account is its original purpose: it was a tool for teaching the value of iteration and revealing how status, ego, vulnerability and interaction affect team performance.[1]

Wujec popularized the exercise and extended its meaning. His materials describe it as a way to help teams build rapid prototype solutions and learn about collaboration, creativity and innovation. They even invite organizations to use it to consider what would dramatically increase innovation and describe the early testing of hidden project assumptions as the mechanism that produces effective innovation.[2]

This evolution is understandable. The exercise demonstrates several behaviors that innovation needs: teams experiment, expose a hidden assumption, learn through interaction and adapt before time runs out. In that sense, it is partly an exercise in innovative thinking.

The problem begins when it is treated as a model of innovation as a whole. It demonstrates how to explore solutions after the challenge has been framed. It does not demonstrate how to discover whether the brief, customer, outcome, metric or decision to build should exist in the first place.

Give a team twenty sticks of spaghetti, one meter of tape, one meter of string and one marshmallow. Ask them to build the tallest freestanding structure in eighteen minutes, with the marshmallow on top.[1]

The Marshmallow Challenge produces a reliable contrast. Many adult teams spend most of their time discussing the ideal structure, allocate tasks and begin building once they believe they have a plan. They test the marshmallow only near the end, when its weight reveals that their imagined structure and the physical one are not the same.

Children and architects tend to do better. They put the marshmallow on early, build small structures, watch them fail and adapt while they still have time. They do not eliminate uncertainty through discussion. They interact with it.

This is why I continue to use the exercise. It makes the difference between planning and learning physically visible. Explore before you commit is a better response to solution uncertainty than plan first and execute later.

But innovation does not start when a team begins building a solution. It starts earlier, when the team investigates whose situation should improve, which outcome matters, what may cause that outcome and whether a solution should be built at all. The Marshmallow Challenge starts after those decisions have already been made.

Before anyone touches the spaghetti, the problem has been defined, the desired output has been specified, the resources have been allocated and the success metric has been fixed. The facilitator has decided that height matters, that every team must work with its own materials and that the teams are competitors. Participants may question how to build the tower. They are not allowed to question the frame around it.

That makes the Marshmallow Challenge an excellent exercise in iterative execution. It does not make it a complete innovation exercise.

The tower is an output, not an outcome

The winning structure must be tall and remain standing long enough to be measured. Nobody has to use it. Nobody needs to make progress because it exists. There is no customer who values height more than stability, portability, surface area or cost. Height matters because the facilitator can measure it with a tape, not because anyone has shown that it is valuable.

That distinction is easy to miss because the activity looks like innovation. Teams build, experiment, collaborate and work under uncertainty. Yet the uncertainty is contained inside a task whose purpose and boundaries are treated as facts.

Several questions remain outside the room:

• Who is this structure for?

• What are they trying to achieve?

• Is height the outcome that matters, or merely the easiest output to measure?

• What would make them adopt, use or pay for the result?

• Which other actors must participate for the outcome to occur?

• Would combining resources with another team create more value than competing with it?

These are not secondary questions to ask after the tower stands. They determine whether the tower is worth building at all.

Innovation contains three different uncertainties

Organizations often speak about uncertainty as though it were one problem. It is more useful to separate at least three kinds.

Discovery uncertainty concerns the opportunity. Who experiences the problem, in which context, how important is it, what progress are they seeking and which assumptions support our belief that an opportunity exists?

Solution uncertainty concerns the response. If the opportunity is real, which intervention could create the required outcome, what will people adopt and how must it fit into their existing behavior and system?

Execution uncertainty concerns delivery. Once the problem and solution are sufficiently understood, can the organization build, operate and scale the solution at the required quality, speed and cost within a business model that creates enough value for all the involved parties?

Each uncertainty requires a different capability. Discovery needs observation, problem framing and evidence about what matters. Solution development needs design, comparison and behavioral tests. Execution needs engineering, coordination and reliable delivery.

The Marshmallow Challenge operates mostly in the last two categories. The opportunity, user, metric and rules are fixed. What remains uncertain is which structure will work and whether the team can build it in time.

Children and architects do not win because they have discovered a better customer or a more important outcome. They win because they explore possible solutions within the given frame and expose structural failure earlier than teams that rely on planning.

That is a valuable capability. It is simply not the whole innovation job.

Most innovation projects are set up the same way

The limitation matters because many corporate innovation programs and startups reproduce the same structure without noticing it.

A team receives a budget, a deadline and a mandate to build an app, introduce an AI assistant, create a platform or enter a market. The mandate already contains assumptions about the customer, the problem and the appropriate response. A roadmap then converts those assumptions into milestones, and progress is measured through delivery: prototypes completed, features released, users acquired or pilots launched.

The team may work in sprints and test early versions. It may be highly agile inside the assignment. But agility does not make the original frame true.

Perhaps the selected users do not experience the problem strongly enough to change their behavior. Perhaps the metric being optimized is easy to count but weakly related to customer value. Perhaps the apparent customer cannot decide alone because procurement, operations, regulators or channel partners can prevent adoption. Perhaps an adjacent team, supplier or external partner has capabilities that make a joint model more credible than an internal build.

If these possibilities were excluded before the project began, the team is not discovering an opportunity. It is improving its execution of an inherited belief.

The organization then judges the team on how well it builds a tower whose purpose, user and rules it was never allowed to question.

Agile cannot rescue the wrong frame

Steve Blank distinguished a startup searching for a repeatable business model from an established organization executing one it already understands.[3] Eric Ries translated this search logic into Build-Measure-Learn.[4] Both challenged the assumption that detailed planning can remove uncertainty before contact with reality.

The Marshmallow Challenge demonstrates this argument well. Early prototypes reveal something that analysis alone cannot: the marshmallow changes the structure.

But faster iteration is only useful when the experiment addresses the uncertainty that matters. A team can build, measure and learn repeatedly while leaving the customer, outcome and business-model assumptions untouched. It becomes faster at learning inside the wrong frame.

Research on scientific decision-making by entrepreneurs shows why the framing step matters. In a large-scale replication and extension, entrepreneurs trained to articulate theories, make assumptions explicit and design tests around them were more likely to terminate weak projects earlier, make more focused pivots and perform better.[5] The improvement did not come from generating more ideas or running more activity. It came from connecting experiments to explicit beliefs and decisions.

Related work on theory-driven strategic decisions makes a similar distinction. Under uncertainty, the first task is not to select a plan of action but to develop a theory of value: an explicit explanation of why a particular action should produce a valuable outcome. That theory can then be challenged with evidence.[6]

The Marshmallow Challenge begins with the theory already embedded in its rules: tall towers are valuable, isolated teams are the unit of action and the winner is whoever produces the highest output in the given time. Participants test structures, not that theory.

Commitment changes how evidence is treated

This omission becomes expensive once a project gathers momentum.

Budgets, teams, roadmaps, executive sponsors and public promises do more than support delivery. They create attachment to the original decision. As commitment grows, evidence is no longer interpreted neutrally. A negative signal threatens previous investments, internal credibility and sometimes professional identity.

Research on escalation of commitment has documented this pattern across organizational decisions.[7] When a project becomes difficult to abandon, teams often respond to disappointing evidence by defending, reinterpreting or extending the commitment rather than revisiting its underlying assumptions.

The longer a team has been building its tower, the harder it becomes to ask whether height was ever the point.

This is why discovery must precede large commitments. Its purpose is not to prove that an idea will succeed. It is to expose the assumptions that could make the commitment irrational while changing direction is still relatively cheap.

Keep the exercise, but change the conclusion

I will continue to use the Marshmallow Challenge. It remains one of the clearest ways to show why teams should test the load-bearing assumption early, why a prototype can reveal more than a planning discussion and why iteration beats a single late attempt.

I will no longer present it as a model of innovation as a whole.

It teaches teams to explore before committing to a solution, but only after someone else has committed them to a customer, an outcome, a metric, a resource boundary and a competitive structure. Those upstream decisions often determine the fate of an innovation before execution quality becomes decisive.

Real innovation begins one step earlier. Before asking how to build the tower, a team must make the frame around it visible and testable: who is it for, what outcome matters, which evidence would justify building and whether the organization should build alone.

The tower was never the hardest part, understanding why you should build beforehand is.

Leave a comment

The Upstream Decision Test

Read more

That interpretation begins too late.

Adobe did not replace one business model once. It repeatedly changed whichever element was limiting its ability to create, deliver or capture more value.

PostScript established an OEM-licensed printing standard. PDF extended Adobe into universal document exchange. Creative Suite integrated previously separate tools. Omniture added analytics and marketing. Creative Cloud created a recurring relationship. Behance added a creator community. Document Cloud expanded PDF into workflows. Magento connected content with commerce. Express opened creation to non-professionals. Firefly and GenStudio are now moving Adobe towards AI-enabled enterprise content production.

Each adaptation strengthened Adobe’s position in the customer workflow. Each also increased the customer’s dependence on Adobe.

The familiar story begins too late

The familiar Adobe story starts with Creative Cloud. In 2012, the company began moving customers from perpetual licenses and periodic upgrades towards recurring subscriptions and continuous software delivery.

It was a consequential and controversial decision. But it was already Adobe’s sixth major business-model adaptation in this chronology.

Adobe’s original commercial model was built around licensing PostScript to printer manufacturers. Acrobat and PDF then expanded the value proposition from reliable printed output to exchanging digital documents across different systems. The free Reader reduced adoption friction and helped PDF become more valuable to those paying to create and manage documents.

Creative Suite integrated specialist applications into a broader workflow. Macromedia expanded that workflow into web and interactive creation. Omniture moved Adobe beyond producing content and towards measuring and optimising what that content achieved.

Creative Cloud did not begin Adobe’s transformation. It changed the constraint again.

Periodic product releases and upgrade decisions were replaced by continuous delivery and recurring access. Revenue became more predictable, but Adobe also became responsible for maintaining an ongoing service and continually demonstrating value.

The move changed far more than the price.

Four phases of adaptation

1. Establish standards and reduce adoption friction

PostScript created value by connecting computers, software, fonts and printers. Adobe did not need to manufacture the entire system. It occupied an important position between its components and captured value through OEM licensing and royalties.

PDF expanded that position. Instead of focusing only on producing printed output, Adobe enabled documents to retain their appearance across systems.

The free Reader was central to the model. It reduced the friction of receiving and viewing a PDF, making the format more useful to those paying for document creation and professional capabilities.

Free access on one side supported paid value on the other.

2. Integrate and broaden the creative workflow

Creative Suite combined specialist applications into a broader offering. This increased the amount of the creative workflow Adobe could support and the value it could capture from each customer.

The Macromedia acquisition added Flash, Dreamweaver and other interactive-media capabilities. Adobe was no longer concentrated primarily on print, imaging and documents. It expanded with the changing forms of digital content.

Integration improved the customer workflow because tools could be used together. It also increased switching costs because the customer relationship no longer depended on one replaceable application.

Adobe was becoming more valuable partly because more of the customer’s work happened inside its ecosystem.

3. Turn products into recurring relationships and workflows

Omniture moved Adobe into analytics, marketing and hosted services. This introduced new buyers, including marketing departments and large enterprises, and required capabilities in data, cloud operations and enterprise sales.

Creative Cloud then changed payment, delivery and the customer relationship. Instead of selling a major release and later convincing customers to upgrade, Adobe could deliver improvements continuously and maintain a direct recurring relationship.

Behance extended that relationship beyond the use of software by adding portfolios, professional discovery and community. Document Cloud expanded PDF from a file format and desktop product into mobile access, storage, collaboration and electronic-signature workflows.

Adobe Spark, later relaunched as Adobe Express, created a freemium entry point for first-time creators, communicators, students and small businesses. Magento extended Adobe’s enterprise portfolio into commerce and transaction workflows.

These were different moves, but they followed the same direction: Adobe kept expanding from the individual tool into the surrounding work.

4. Move from proprietary tools towards governed AI workflows

Firefly embedded generative AI inside the applications Adobe customers were already using. Generative credits also introduced metered usage within subscription plans.

This was a business-model response as much as a product response. Generative AI creates variable computing costs that a conventional software subscription does not automatically accommodate. Credits allowed Adobe to connect usage with commercial limits without abandoning the subscription relationship.

GenStudio extended the proposition further into the enterprise content supply chain: planning, creation, brand governance, activation and measurement.

Adobe then began adding partner models from companies including OpenAI and Google to Firefly. This changed the platform logic again. Adobe no longer had to depend entirely on its proprietary models being superior for every task. It could compete as the trusted workflow and governance layer through which customers access different AI capabilities.

The individual model may become interchangeable. The surrounding workflow is harder to replace.

Three lessons from the case

1. Business-model innovation can be cumulative

Not every Adobe adaptation replaced the previous model. Many changed only one or two elements while preserving capabilities, customer relationships, standards or assets created earlier.

PostScript established Adobe inside the publishing ecosystem. PDF expanded the job. Creative Suite increased the share of the workflow. Creative Cloud changed delivery and revenue capture. Later moves added community, analytics, commerce, collaboration and AI.

Continuous business-model innovation is therefore not necessarily a sequence of dramatic pivots. It can be the repeated reconfiguration of selected elements before the existing configuration becomes a constraint.

2. A new revenue model requires a different operating model

Creative Cloud is often reduced to subscription pricing. But recurring billing alone would not have created recurring value.

The change also required continuous product delivery, cloud infrastructure, account management, direct customer relationships and a different development rhythm. Omniture, Document Cloud, Magento, Firefly and GenStudio required additional capabilities in analytics, enterprise sales, commerce, AI computing, governance and workflow orchestration.

Changing how a company captures value without changing how it creates and delivers that value produces a commercial mechanism, not a coherent business model.

3. Customer value and customer dependence can grow together

Adobe’s integrations can make work easier. Files move between applications, teams share assets, organisations manage permissions, and enterprises connect creation with approval, activation and measurement.

The same integrations make Adobe more difficult to leave.

Files, skills, subscriptions, workflows, shared assets, communities, governance rules and enterprise systems accumulate around the ecosystem. Exiting may require more than replacing a product. It may require changing how work is organised.

This creates the strategic tension at the centre of the case:

Each move expanded customer value and revenue predictability, but also increased customer dependence on Adobe. The model became stronger partly by making exit, substitution and ownership less simple.

The relevant distinction is not simply between integration and lock-in. It is between retention created by value customers repeatedly choose and retention created by the cost of leaving.

Both may produce similar commercial results. They indicate different qualities of business-model strength.

Future cases will examine other organizations that changed their business models as technologies, customer behavior and old assumptions became constraints. Subscribe for source-backed cases, strategic interpretation and practical decision tools.

2 Adobe Continuous Business Model Innovation Final

54.4KB ∙ PDF file

Download

A two-page, source-backed chronology of fourteen business-model adaptations, including a Business Model Canvas View, Core Pattern and Strategic Tension.

Download

What would you challenge?

Which Adobe adaptation most fundamentally changed the company’s business model?

I am particularly interested in interpretations that challenge the chronology, the business-model elements I assigned or the tension between increasing customer value and increasing customer dependence.

Use this case with your team

I am developing Continuous Business Model Innovation as a format for executive briefings, strategy off-sites, workshops, bootcamps and teaching.

The purpose is not to copy Adobe or introduce a subscription because it worked for someone else. It is to help a team determine which part of its own business model has become a constraint, which assumptions require evidence and what should be tested before committing further resources.

If your organization is facing such a decision, send me the concrete situation you are working through.

This analysis reflects my personal interpretation of Adobe’s business-model adaptations based on available public data and public sources. Adobe and related marks are trademarks of Adobe Inc. This independent analysis is not affiliated with or endorsed by Adobe.

Subscribe to INNOVATION&

Evidence-based analysis, practical tools and innovation strategy consulting for leaders deciding what to test, fund, pivot, stop or scale.

Subscribe now

A venture can have a team, a budget, a roadmap, a name, a pitch deck, and even a recognizable culture before it has a business.

That is not necessarily a problem. Ventures need enough structure to begin operating, and founders need enough confidence to act before the outcome is known. Without that confidence, nobody takes the first risk, makes the first call, interviews the first potential customer, builds the first prototype, or asks another person to join something that may never work.

Confidence is necessary because every venture begins before certainty exists.

Overconfidence starts somewhere else. It begins when the venture starts behaving as though the company already exists while the market has not yet confirmed that it should. The team gradually treats its roadmap, funding, hiring, internal support, or early enthusiasm as evidence that the business itself is working.

The distinction is not between founders who believe and founders who doubt. It is between belief that remains exposed to evidence and belief that begins protecting itself from evidence.

A calibrated team can believe strongly in its abilities and still distinguish among what it hopes, what it assumes, what it has observed, and what it has learned. It can explain which parts of the business appear credible, which remain uncertain, and what evidence would cause it to change direction.

An overconfident team starts treating these categories as though they were interchangeable. Its assumptions acquire the language of facts, plans become promises, and internal activity begins to serve as evidence of external progress.

This matters because a startup is not simply a smaller version of an established company. It is a temporary structure operating under uncertainty and trying to discover whether a repeatable, commercially viable business deserves to exist.

The same is true of a corporate venture. A project inside a large organization does not become a business because it has a sponsor, a budget, a steering committee, or a place in an innovation portfolio. It may already look organized, but organization is not validation.

A venture is not yet a company seeking success. It is a project trying to earn the right to become a company through contact with the market.

This connects to the broader question of how a startup can earn its right to exist through evidence. User-level desirability is necessary, but it does not by itself establish that the venture is viable, scalable, or worth continued investment.

Confidence needs calibration, not suppression

It would be too simple to conclude that founders are generally overconfident and should become more cautious.

Entrepreneurial action requires people to make decisions before all relevant information is available. Founders need enough confidence to pursue opportunities that other people do not yet see, tolerate repeated rejection, attract employees and investors, and maintain direction long enough to learn something meaningful.

The research nevertheless gives us good reasons to examine entrepreneurial overconfidence seriously.

Daniel Forbes investigated why some entrepreneurs appear more overconfident than others and found that overconfidence varied with individual and organizational conditions, including age, the comprehensiveness of decision-making, and the presence of external equity funding [1]. His findings suggest that overconfidence should not be understood only as a fixed personality trait. It can also be influenced by the environment in which entrepreneurial decisions are made.

Robert Singh’s review of the entrepreneurship literature argues that entrepreneurs may overestimate both their own abilities and the prospects of their ventures, leading them to pursue opportunities that deserve more skepticism [2]. Singh’s article is primarily a conceptual review rather than direct causal proof that overconfidence produces failure in every case. Its value lies in showing how consistently overconfidence appears as a concern across entrepreneurship research.

Gudmundsson and Lechner explored how cognitive biases interact with organizational characteristics and entrepreneurial firm survival [3]. Their study suggests that the relationship is more complicated than a simple claim that confidence is always harmful. Optimism and confidence can support action, while excessive confidence can weaken the quality of decisions and reduce a venture’s willingness to respond to unfavorable information.

The problem is therefore not confidence itself. It is confidence that has lost its calibration.

A calibrated team can say that it believes a particular customer has an important problem while acknowledging that it has not yet established how frequently the problem occurs, who controls the budget, whether the customer would switch, or whether the value of the solution could exceed the cost and risk of adopting it.

An overconfident team often speaks differently. It says that it already knows the customer, that the market only needs education, that users do not understand the solution yet, or that sales will arrive after the next feature is completed. A positive pilot becomes proof that the business has been validated, while contradictory feedback is rejected because it supposedly came from the wrong segment.

Any of these explanations might be correct in a particular situation. The problem is not the statement itself, but the job it performs.

In a learning system, the explanation remains a hypothesis that can be examined. In an overconfident system, it becomes protection against evidence that might threaten the existing strategy.

That is the moment useful entrepreneurial confidence starts becoming a liability.

Overconfidence becomes more dangerous when it becomes social

Overconfidence is often discussed as though it exists primarily inside an individual founder’s mind. In practice, the more consequential version may be social.

Venture teams are fast-forming social systems. People develop shared language, assumptions, rituals, hopes, and explanations for why the project matters. This cohesion is useful because uncertainty is difficult to tolerate alone. Teams need trust and a sense of common purpose if they are going to continue working through ambiguity, setbacks, and disagreement.

The same cohesion can cause the idea to become part of the group’s identity before the market has confirmed the business.

Baumeister and Leary’s review of the need to belong argues that forming and maintaining meaningful social bonds is a fundamental human motivation [6]. Tajfel and Turner’s social identity theory provides a related explanation for how people derive part of their identity from group membership and begin distinguishing between those who belong to the group and those who do not [7].

Neither source studies venture teams specifically, so the application to startups and corporate ventures is an interpretation rather than a direct empirical finding. The theories nevertheless provide a useful lens for understanding why a venture can become socially important beyond its commercial prospects.

For founders, the venture may carry hopes of independence, wealth, recognition, or legacy. For corporate venture teams, it may carry sponsor expectations, professional reputation, career opportunity, and evidence that the innovation program is producing results. For employees, it may provide a role, an identity, and a group to which they have chosen to belong.

The venture gradually becomes more than a commercial experiment. It becomes a shared belief system, and shared belief systems have reasons to protect themselves.

Once this happens, evidence from the market no longer arrives as neutral information. Customer indifference may feel unfair. Pricing resistance may be interpreted as ignorance. Internal skepticism may be labeled negativity. A colleague who brings contradictory evidence from the field may be treated as someone who no longer believes strongly enough in the team.

This resembles some of the dynamics Irving Janis described as groupthink, in which cohesive groups protect consensus, rationalize warning signs, and make disagreement socially costly [8].

The concept should be applied carefully. DiPierro and colleagues’ later scoping review found that research on groupthink in professional teams remains conceptually inconsistent and that much of the literature is still based on commentary and theory rather than strong empirical measurement [9]. Their review concerned health care teams rather than venture teams, so it cannot establish that startup teams experience groupthink in the same way.

The narrower warning is still relevant. A group can become deeply cohesive around an idea while remaining far from evidence that the problem, market, and business model deserve that level of confidence.

The venture may still be searching for problem-solution fit while its social system has already moved on to execution.

A project can begin behaving like a company too early

Many ventures cross this line without noticing it.

They hire employees, assign formal roles, develop a brand, establish rituals, write roadmaps, manage stakeholders, and start discussing scale while the core business assumptions remain unresolved. These activities make the venture look serious. They create momentum, improve morale, and provide investors or executives with visible signs of progress.

They also increase the cost of discovering that the original idea was wrong.

Before a venture begins behaving like a company, it should have credible evidence about more basic questions. Who experiences the problem, and how important is it? What are people doing today instead? Why are existing solutions or workarounds not good enough? Who controls the budget, who influences the decision, and who can prevent adoption? What would motivate people to switch, and what evidence indicates that the apparent interest extends beyond polite encouragement?

When most of these questions are still answered by the team’s belief, the venture remains largely an assumption rather than a business.

That does not mean that the team should avoid all structure, refuse to hire anyone, or stop developing the idea. It means that structure should support learning rather than create the impression that learning has already occurred.

A roadmap can organize a sequence of experiments, or it can convert untested assumptions into delivery promises. Hiring can expand the venture’s capacity to investigate the market, or it can create a cost base that now depends on the idea continuing to look viable. A brand can help the team test whether a proposition resonates, or it can make abandoning the original concept feel like destroying something the team has already built.

The same activity can support learning or premature commitment. The difference lies in whether the venture treats the activity as a way of reducing uncertainty or as evidence that uncertainty has already been reduced.

Early market exposure is founder work

I believe founders should investigate the initial user, problem, and commercial assumptions themselves before hiring a large team or committing substantial resources.

This is not because founders should continue doing everything forever. Research, product development, sales, operations, and delivery will eventually require dedicated people with deeper capabilities. The reason is that direct market exposure shapes the founder’s judgment at the stage when the business model remains most uncertain.

Founders need to hear how potential users describe the problem in their own language. They need to understand what people have already tried, where money currently flows, what creates urgency, which constraints prevent switching, and whether the supposed struggle is important enough to change behavior.

An initial set of serious conversations with users, buyers, partners, or other relevant stakeholders will not validate an entire business. There is no universal number of interviews that proves that a market exists. The purpose of the first research cycle is more modest and more useful: it should reveal whether the original customer and problem assumptions deserve the next investment.

This work is difficult to delegate because the founder is not merely collecting information. The founder is developing the judgment required to interpret what the market is saying.

Hiring too early can turn uncertainty into obligation. Salaries begin, roles are created, and roadmaps become promises to people who need work to perform. Investors, sponsors, and managers expect visible progress. The venture is no longer only examining an idea; it is also maintaining an organization that now benefits from the idea continuing to exist.

When founders are unwilling to test their core assumptions personally before asking other people to build around them, they are not simply delegating execution. They are outsourcing their own overconfidence.

Corporate ventures borrow the appearance of certainty

Corporate ventures make the same mistake through a different set of incentives.

The people involved may not have founder identity in the same form, but they operate inside a system with its own pressures. A sponsor wants visible progress, a business unit wants strategic relevance, an innovation function needs successful portfolio stories, and a steering committee expects the team to communicate confidence. Budgets and careers may depend on the venture not appearing weak too early.

The project therefore starts collecting internal signals that look like validation. It receives executive approval, funding, strategic-fit scores, a formal team, a roadmap, workshop enthusiasm, pilot interest, and a polished business case.

These signals may be useful, but they are not market evidence.

Corporate sponsorship is not customer demand. Internal alignment does not demonstrate willingness to pay. Funding an initiative does not transform it into a business.

The corporate setting can make overconfidence harder to recognize because the venture borrows credibility from the parent organization. It has titles, meeting rooms, templates, governance processes, logos, and communications support. These elements make the project appear more substantial than an independent startup with the same level of external evidence.

Uncertainty does not disappear because the idea belongs to a respected organization.

Edison and colleagues examined lean internal startups in two large software companies and identified organizational conditions that could enable or inhibit their work [5]. Senior management support and cross-functional collaboration could help internal ventures, while the way the venture was initiated, governed, and connected to the parent organization could create additional constraints.

The study was based on two cases and seven interviews, so it should not be treated as a universal model for all corporate ventures. It nevertheless supports an important point: internal ventures do not escape uncertainty. They encounter it inside a more complex organizational and political environment.

A corporate venture may have more resources than an independent startup, but those resources do not tell it whether the business deserves to exist.

The market still knows more than the room.

The business model is not hidden inside the pitch deck

No founder, consultant, accelerator, investor, executive sponsor, or innovation team knows the complete business model in advance.

The business model is not contained in the pitch deck, the workshop, the financial model, or the roadmap. It must be discovered through contact with users, buyers, non-buyers, budget holders, procurement processes, partners, switching costs, pricing reactions, actual usage, and the operational realities of delivering the proposed value.

This is the practical contribution of hypothesis-driven entrepreneurship.

Eisenmann, Ries, and Dillard describe an approach in which an entrepreneurial vision is translated into falsifiable business-model hypotheses that can be tested rather than treated as a plan that only needs to be executed [4]. Their Harvard Business School material is a teaching note rather than an empirical trial, so it should be understood as a structured method rather than proof that Lean Startup practices always improve venture outcomes.

Its underlying logic remains valuable. The venture begins as a set of assumptions, and early action should determine which assumptions deserve further investment.

That sounds obvious, but it is difficult in practice because evidence is not only analytical. It is also social.

When evidence supports what the team already believes, it creates energy and strengthens cohesion. When evidence contradicts the belief, the team must decide whether it is willing to learn or whether it will defend the story it has already built.

That is where overconfidence becomes visible.

What I look for in startup teams

When I work with startup or venture teams, I usually begin with questions that appear simple.

What was the original idea, and which hypotheses followed from it? Which assumptions have been examined, and which remain beliefs? What evidence came from people outside the team? What did potential customers actually say, do, reject, ignore, or question? What changed in the team’s thinking because of that evidence?

I then examine the social system surrounding the venture. Which assumptions can be challenged openly, and which appear protected? Who is allowed to bring bad news? What happens when the findings do not support the current narrative? Is disagreement treated as useful information, or does it become evidence that someone lacks ambition or loyalty?

When confidence is high and market evidence remains weak, the appropriate response is usually to return to the field. The purpose is not to prove the team wrong. It is to determine whether the proposed business has commercial ground outside the room.

This is where the difference between learning and defending becomes visible.

A learning team may question the quality of contradictory evidence, but it also examines what the evidence could mean. It asks whether the original segment was wrong, whether the problem is less important than expected, whether another stakeholder controls the decision, or whether the cost of switching makes the solution unattractive.

A defending team uses every limitation in the evidence to protect the original direction. Weak signals are reframed as messaging problems, timing problems, feature gaps, customer-education problems, or mistakes in participant selection.

Any one of these explanations might be correct. When every contradictory finding produces an explanation that preserves the existing strategy, however, the team is no longer examining the venture. It is protecting its shared belief.

The strongest venture teams are not those that never doubt themselves. They are confident learners who can maintain ambition while allowing evidence to change their direction. They do not collapse when the market contradicts them, and they do not obey every customer comment without judgment. They evaluate the quality of the signal, update their assumptions, and become more precise about what remains unknown.

Early gates should be learning gates

This is why early investment gates matter.

A gate should not be a ceremony through which a team receives permission to continue because it has completed another activity. It should protect the organization against increasing commitment faster than it reduces uncertainty.

In the earliest stage, the gate should concentrate on the user and problem assumptions. Before the venture builds too much, hires too much, or spends too much, it should know whether the struggle is sufficiently real, important, specific, and underserved to justify further investigation.

Later gates should address other assumptions, including willingness to switch, willingness and ability to pay, the buying process, access to customers, delivery requirements, acquisition economics, retention, and the conditions required for scale.

Each step should earn the next one.

This is not bureaucracy. It is a way of preventing ambition from turning into premature commitment.

The question at an early gate should not be whether the team has produced enough visible work. It should be whether the venture has learned enough from outside the team to justify the next increase in cost, organization, and confidence.

Premature company-building makes honesty expensive

The deeper a venture moves into development, the harder honest reassessment can become.

The runway becomes shorter, the team has more to lose, and the founder’s identity becomes more closely connected to the venture. In a corporate setting, the sponsor has accumulated more reputational exposure, the story has been repeated to more stakeholders, and the organization increasingly expects progress.

At this point, the venture often asks for the wrong form of support. It seeks go-to-market advice while the underlying customer problem remains uncertain. It requests solution validation when it still needs to understand the user’s struggle. It asks how to scale sales before establishing why enough customers would switch.

Once traction remains weak, the next problem is how founders and stakeholders interpret weak traction. The same signal can support several role-protecting narratives, making continuation appear reasonable long after learning has begun to stall.

The claim that late-stage persistence is sometimes overconfidence is a practical interpretation, not a proposition directly tested by the nine sources used here. The research on entrepreneurial overconfidence, social identity, group cohesion, and internal venture constraints makes the interpretation plausible, but it does not prove that every persistent venture is overconfident.

Sometimes persistence is exactly what the situation requires. Difficult markets, long procurement cycles, unfamiliar technologies, and changing customer behavior can all produce weak early signals even when an opportunity is real.

The test is whether the team remains willing to specify what it believes, confront contradictory evidence, and explain what would change its mind.

Persistence that remains exposed to evidence is confidence.

Persistence that explains away every possible contradiction is something else.

The antidote is disciplined humility

The opposite of overconfidence is not insecurity, cynicism, low ambition, or endless analysis.

It is disciplined humility.

A venture can have a clear North Star while remaining willing to change its route. It can believe strongly in a customer struggle while abandoning its first solution. It can remain ambitious while acknowledging that the market has not yet confirmed the business model. It can move quickly without scaling commitment faster than evidence.

A calibrated venture team does not claim that it already knows. It explains what it currently believes, which evidence supports that belief, what remains uncertain, and what would cause the team to reconsider.

That is not weakness. It is the operating discipline required to keep a venture exposed to reality.

Founders and corporate venture teams do not need less confidence. They need confidence that points them toward the market rather than away from it.

Every venture starts with assumptions. The danger begins when those assumptions acquire the social status of facts, become embedded in roles and roadmaps, and eventually form part of the venture’s culture.

A startup is not yet a company. A corporate venture is not yet a business. Both are projects operating under uncertainty and attempting to earn the right to become something more.

That right is not earned through funding, hiring, internal alignment, a roadmap, or the elegance of the story. It is earned when market evidence becomes strong enough to justify the next commitment.

The market does not require the team to be right from the beginning. It requires the team to recognize when it is wrong before remaining wrong becomes unaffordable.

Build the company after the evidence begins to justify it, not before.

Paid application: The Venture-to-Company Gate

Read more

A recent exchange about user research stayed with me.

The original conversation was about a tool designed to reduce the operational friction of research. Recruiting appropriate participants takes time, arranging interviews can become a calendar exercise, conducting the conversations requires preparation, and making sense of what people said is rarely as simple as summarizing a transcript. Anyone who has tried to organize customer research inside a busy organization will recognize that friction.

The tool was intended to make all of this easier, and that is useful. Yet the part of the conversation that stayed with me was not the tool. It was the timing.

Teams do not postpone customer conversations simply because research is difficult to organize. Sometimes that is the genuine reason. At other times, operational friction provides a convenient explanation for a deeper problem: the project has already progressed too far, and worse, resources have already been invested in developing a solution for what I would call merely a “possible innovation candidate.”

By the time research is proposed, there is often more than an idea. A concept has been developed, a prototype exists, and a roadmap is beginning to take shape. Several internal supporters have attached their names to the initiative. Someone has written a business case, secured initial funding, or presented the opportunity to senior management. The team has invested time, the sponsor has invested credibility, and the organization has gradually started treating the project as something that exists rather than something that might deserve to exist.

Then someone asks for user research.

The activities may still look the same. Participants are recruited, interviews are conducted, observations are analyzed, and findings are presented. However, the job that research is being asked to perform has changed.

Early research asks what the organisation needs to learn before it commits. Late research is more likely to ask whether enough evidence can be found to justify what the organization has already started.

That is the moment research risks moving away from discovery and towards approval-seeking. It becomes solutionism with a research layer added afterwards.

The same interview can serve a different purpose

The difference between early and late research is not primarily methodological. The same interview guide, recruitment process, and analysis method could be used at either stage. What changes is the organizational environment in which the evidence will be interpreted.

Early in an initiative, negative evidence threatens an idea. Later, the same evidence may threaten a prototype, a roadmap, a team’s objectives, a sponsor’s judgement, and a narrative that has already travelled through the organization.

This matters because people do not assess new information independently of what they have already invested. Barry Staw’s foundational work on escalation of commitment showed that decision-makers can continue committing resources to an unsuccessful course of action, particularly when they feel personally responsible for the original decision [1]. Arkes and Blumer later described the sunk-cost effect as the tendency to continue an endeavor because money, time, or effort has already been invested, even though those past investments should not determine whether further investment is justified [2].

Late research enters precisely this environment. The team is no longer learning only about customers, markets, and business models. It is also negotiating with everything that has already been spent and promised.

This does not mean that the team deliberately manipulates the research. Most people involved will be sincere. They want to learn, they care about the project, and they may genuinely believe that further development will reveal its potential. Yet sincerity does not remove bias. A team can ask an honest question while unconsciously preferring the answer that allows it to continue.

The expense of late research therefore does not lie mainly in recruiting participants or conducting interviews. It lies in the amount of accumulated commitment that the findings must overcome.

Innovation work is learning before commitment

I have encountered this pattern several times in my professional work.

I have been invited into innovation and venture projects that appeared advanced from the outside. The teams had prototypes, presentations, roadmaps, market estimates, and a coherent story. Considerable work had clearly taken place, and the quality of the artifacts often created the impression that the initiative itself was equally mature.

Then we began examining what the project was built on.

Which assumption was the prototype intended to test? What were potential customers doing instead? What would make them abandon an established workaround? Who experienced the struggle, who controlled the budget, and who would carry the operational and political cost of switching? Which observations supported the current direction, and what finding would cause the team to reconsider it?

That is usually when the character of the conversation changes.

The problem is rarely that the team is weak or careless. Most teams are responding rationally to the system around them. They have been rewarded for building something, aligning stakeholders, making progress visible, refining the narrative, and defending the next stage of funding.

All of those activities can be useful. None of them proves that the initiative deserves to exist or continue.

They demonstrate that the team has been active. They do not demonstrate that consequential uncertainty of feasibility has been reduced.

This distinction separates innovation work from delivery work. When the customer problem is sufficiently understood, the relevant market mechanisms are known, the business model has been established, and the primary challenge is reliable execution, the organization is doing delivery. The work may still be difficult and uncertain in many practical ways, but the underlying direction is no longer the main question.

Innovation begins where material uncertainty remains.

A good innovator is therefore not someone who already knows the answer. A good innovator knows how to learn before the organization makes being wrong unnecessarily expensive.

That does not mean arriving without expertise. People responsible for innovation should understand customer research, business model logic, assumptions, experiments, evidence, and decision gates. They should know how to distinguish an interesting signal from a convenient anecdote. What they should not do is assume that their experience allows them to know the specific opportunity before reality has had a chance to challenge it.

This broader view matters because business model validation must test the whole system, not only the customer problem or the first solution. A promising signal in one component does not establish that the connections among demand, switching, delivery, revenue, and economic viability will hold.

Research by Camuffo, Cordova, Gambardella, and Spina supports this view. In a randomized controlled trial involving 116 Italian startups, entrepreneurs who were taught to formulate explicit hypotheses and test them systematically performed better and were more likely to pivot than those following more conventional approaches to market feedback [3]. A later replication across 759 firms and four randomized controlled trials found that the scientific approach increased idea termination and was associated with a more selective pattern of strategic change, rather than either refusing to change or pivoting repeatedly [4].

These studies should not be interpreted as proof that every experiment produces a better venture or that uncertainty can be eliminated. Their more relevant contribution is that explicit hypotheses and disciplined tests can help entrepreneurs recognize when an idea should be changed or abandoned.

The central innovation skill is not being right immediately. It is learning fast and early enough that being wrong remains affordable.

What an advanced project may still be hiding

Organizations often mistake the visible development of a project for the reduction of uncertainty behind it.

A polished concept can feel like evidence because it makes the opportunity easier to imagine. Internal alignment can feel like market validation because several influential people now support the idea. A prototype can create the impression that the team has moved closer to a viable business, even when the prototype has not tested the assumptions most likely to make that business fail.

Internal alignment can keep a weak project alive for a long time. It can protect the team, unlock further budget, and make the initiative appear increasingly official. What it cannot do is create demand outside the organization.

By the time research begins, the project may no longer be treated as a hypothesis. It has become someone’s work, someone’s quarterly objective, someone’s internal promise, and sometimes someone’s route to recognition.

That changes the politics of learning.

Early research asks whether the organization should commit. Late research asks whether the organization can still afford to be honest.

This is why positive feedback collected after a prototype already exists must be interpreted carefully. Such feedback is not worthless. It can reveal confusing language, missing functionality, unexpected objections, relevant use cases, and aspects of the customer context that the team has overlooked.

It is nevertheless easy to ask positive feedback to carry more weight than it deserves.

This is why user research can produce socially convenient answers rather than decision-grade evidence. The problem is not necessarily dishonesty; the interview setting itself can reward politeness, abstraction, and self-presentation.

People are often polite when they are shown a new idea. Some enjoy participating in innovation discussions and want to be helpful. Internal sponsors may naturally remember the statements that support the direction they already favour. Teams may interpret general interest as evidence of future adoption.

None of this is equivalent to a customer changing behavior, reallocating a budget, replacing an existing workaround, accepting the cost of switching, or taking a meaningful risk.

The later the research occurs, the easier it becomes to collect evidence that improves and protects the existing story instead of testing whether the story is true.

Early research does not need to prove the market

The argument against early user research is frequently framed in terms of cost and speed. Research is described as expensive, slow, or too academic for the pace at which innovation teams are expected to move.

Thorough research can certainly be demanding. Some questions require broader samples, careful recruitment, specialist expertise, quantitative analysis, or observation over an extended period. A few interviews cannot establish market size, predict adoption rates, prove willingness to pay, or demonstrate that a business will become commercially viable.

However, early research does not need to begin as a definitive study. Its first job is usually to reveal whether the team is building on assumptions that nobody has examined.

In many contexts, a focused team can conduct an initial set of exploratory conversations within a week. Participants may come from existing customers, prospects, professional networks, industry communities, or groups already using an alternative solution. Research platforms may reduce the administrative burden, but the value does not come from speed alone. It comes from asking a clear question of the right people before the answer becomes politically inconvenient.

Eight or ten interviews do not prove that a market exists. They can still reveal that the original problem is poorly framed, that customers experience it differently from the way the team imagined, or that the proposed solution conflicts with how purchasing and switching decisions actually occur.

Research on qualitative saturation is relevant here, although it is often applied too broadly. Guest, Bunce, and Johnson analyzed sixty interviews from a particular study involving a relatively homogeneous population. They found that basic elements of the main themes appeared within the first six interviews and that saturation occurred within the first twelve in that dataset [5]. Their findings do not establish a universal minimum or maximum number of interviews. Sample requirements depend on the question, the diversity of participants, the purpose of the research, and the quality of the analysis. The narrower conclusion is that focused qualitative research can reveal meaningful patterns relatively quickly under appropriate conditions.

That is the role of an early research cycle. It does not purchase certainty. It purchases a better decision about what should happen next.

Assume that two people spend five days preparing, conducting, and synthesizing an initial research cycle, at an internal or equivalent external cost of $1,000 per person per day. The cost would be approximately $10,000.

That amount does not buy proof, but it may buy an important decision point. It can show whether the problem is sufficiently important to justify further investigation, reveal what customers do today instead, and expose whether the struggle creates meaningful cost, delay, risk, frustration, or political difficulty. It can also reveal whether switching would be easy, expensive, unrealistic, or dependent on people who have not yet been involved.

Most importantly, it requires the team to make its assumptions visible.

The team must explain what it currently believes, which conditions need to be true for the initiative to deserve further investment, what would count as a meaningful signal, and what evidence would cause it to change direction or stop.

These questions appear straightforward, but they remove the places in which weak projects hide. Without explicit assumptions, teams can debate features, preferences, opinions, and optimistic projections for months. Once the assumptions are stated clearly, the conversation becomes more demanding because the team has to explain what it believes about reality before reality is asked to respond.

Research is a gate before it becomes a report

The value of early research does not lie primarily in the final report, the workshop output, or the customer quotations selected for a presentation.

Its value lies in the decision it makes possible.

The team may continue because the initial evidence supports further investigation. It may deepen the research because the problem appears material but remains insufficiently understood. It may change direction because a critical assumption has weakened, or it may stop because the opportunity no longer justifies additional investment.

This is a different way of understanding research. It is not an activity attached to a project once the project is already underway. It is a gate placed before the project becomes unnecessarily expensive.

Stage-Gate thinking is useful here, provided that it is not reduced to governance theatre. Its relevant contribution is the discipline of making an explicit decision before additional resources are committed. More recent descriptions of gating systems have also emphasized that these mechanisms need to become faster, more adaptive, and more compatible with iterative development rather than functioning as rigid sequential approval processes [6].

The gate I mean is therefore small, fast, and close to the evidence. Its purpose is not to demonstrate compliance with a process. It is to make it harder for a team or sponsor to hide behind the quality of a presentation.

The relevant cost comparison is not $10,000 for research against zero dollars for doing nothing. It is $10,000 bet now against months in which a multidisciplinary team continues moving in the wrong direction.

A team that keeps designing, building, coordinating, presenting, and governing a weak initiative consumes resources even when no separate research budget is visible. Depending on the organization, the cost of another months may include salaries, technology, prototypes, external partners, management attention, and the opportunity cost of not pursuing something stronger.

Early research appears expensive because it has a visible price. Continuing without learning often appears inexpensive because the cost is distributed across normal project activity.

That accounting illusion makes research look costly and weak projects look cheap.

The cost of not knowing compounds

A late diagnosis is rarely expensive only because the diagnosis itself costs more. It is expensive because the underlying problem has had time to grow.

The same pattern appears in product and innovation work. The later a weak assumption is examined, the more budget, identity, politics, and internal logic become attached to it. Stopping no longer feels like a useful learning outcome. It feels like failure.

Teams therefore continue improving the prototype, sharpening the narrative, and searching for favorable reactions. They find groups that respond positively and develop explanations for those that do not. They call the activity validation, although it may gradually become a negotiation with sunk cost.

A team can be sincere while protecting a weak project. A sponsor can request evidence while rewarding confirmation. An organization can celebrate learning while punishing the first person who recommends stopping.

For that reason, early user research is not only a research topic. It is a capital-allocation topic.

The relevant question is not whether the team has produced something. It is whether the next unit of capital, attention, time, and credibility deserves to be committed.

The sponsor’s real decision

Sponsors therefore have a different job from the one they are often asked to perform.

Their task is not merely to assess whether the team has built something impressive or presented a compelling opportunity. It is to decide whether the next investment will reduce consequential uncertainty or protect costs that have already been incurred.

That question changes the funding conversation.

Before approving a prototype budget, a pilot, a detailed roadmap, or another quarter of development, the sponsor should ask for the assumptions rather than the ambition. The market-size slide and polished concept can wait until the team has explained what must be true.

Which claims are supported by direct observation, and which remain interpretations? What do customers currently do instead? What would make them switch? Which stakeholder experiences the problem, which one controls the budget, and which one can prevent adoption? What finding would cause the team to stop?

An organization is allowed to place a strategic bet even when evidence is limited. Some decisions cannot be tested fully in advance, and uncertainty can never be removed entirely. The organization should nevertheless describe the decision honestly.

When critical assumptions remain unexamined, another round of development is not evidence-based progress.

It is a bet hidden inside delivery language.

Once a project has acquired a team, budget, roadmap, and story, it becomes difficult to stop for reasons that have little to do with customer demand. Escalation of commitment appears in meetings through phrases such as “one more iteration,” “we need better messaging,” “customers do not understand it yet,” or “we have already invested too much to stop.”

Any of those statements may be correct. The problem is that they are often accepted before being tested.

When everyone holds a hammer

There is also a team-design problem beneath all of this.

Many innovation teams are built predominantly around people who are good at creating solutions: engineers, designers, product managers, domain specialists, and business builders. These capabilities are valuable and eventually indispensable.

However, when a team is strong only at shaping solutions, it may remain weak at determining whether the underlying problem deserves a solution in the first place.

That is not a minor imbalance. It allows a team to move quickly in the wrong direction while looking highly productive from the outside.

Not every initiative needs a formal research department before work can begin. Yet someone involved must possess the competence and independence required to investigate the problem, question the framing, distinguish claims from evidence, and recognize when a plausible opportunity is not strong enough.

When those capabilities are missing, the organization should develop them or introduce them before its commitment grows. Otherwise, what appears to be speed may simply be the extension of a weak project’s life.

Early research is not expensive because it delays progress. It is valuable because it reveals whether what the organization calls progress deserves to continue.

Keeping uncertain projects alive without learning is expensive.

And when everyone is holding a hammer, the customer’s struggle has little chance of being understood as anything other than a nail.

Paid application: The Early Research Gate

Read more

A corporate venture team enters its investment review with a sharper market analysis, a broader competitor map, a polished business case and a credible experiment plan.

The work looks as though several specialists spent weeks producing it. Much of it was completed in two days with generative AI.

The presentation is impressive.

The evidence is not.

The team still has not shown that the customer problem is urgent, that customers will change their behavior or that anyone will pay. AI improved the quality of the artifacts before the underlying uncertainty fell. Because the work now looks stronger, another round of funding becomes easier to justify.

AI did not create output theatre.

It made it cheaper, faster and harder to detect.

Weak OKRs were already confusing completed work with achieved progress. “Launch the assistant,” “produce the market report,” “conduct 20 interviews” and “deliver the prototype” may all describe necessary work. They do not show that anything meaningful changed.

Generative AI can now produce these visible signs of activity at a speed that most management systems were not designed to handle.

The problem is not that AI makes teams more productive.

The problem is that many organizations were already measuring the production of work as though it were the purpose of the work.

AI has exposed the difference.

This creates a broader governance problem: innovation automation requires sponsors to raise the evidence standard. When plausible, evidence-shaped material becomes cheap, activity can accumulate faster than uncertainty falls.

The productivity gain is real

It would be a mistake to dismiss generative AI as a machine for producing inexpensive text and attractive presentations.

In a field experiment involving 758 Boston Consulting Group consultants, participants using GPT-4 completed 12.2 percent more tasks and worked 25.1 percent faster on tasks within the model’s capability frontier. The quality of their work also improved substantially.[1]

The effect was not uniform.

For a complex task deliberately selected to sit outside that frontier, consultants using AI were 19 percent less likely to reach the correct answer than those working without it. The AI did not merely fail to help. Its plausible but incorrect analysis pulled people toward the wrong conclusion.[1]

A second field experiment examined 791 professionals at Procter & Gamble working on real product-development challenges. Individuals using AI produced results comparable in quality to two-person teams working without it. AI also helped commercial specialists produce more technically balanced proposals and technical specialists produce more commercially balanced ones.[2]

This matters.

AI can give an individual access to some of the perspectives, analytical support and production capacity that previously required a larger or more diverse team. It can help someone examine an issue from another discipline, challenge an argument and produce work that would otherwise require much more time.

For innovation teams with limited access to specialist expertise, that can be a significant advantage.

But the advantage concerns the ability to produce and improve an output.

It does not establish that the output is correct, that the underlying assumptions are valid or that the work has created the outcome the organization needs.

The distinction becomes more important as the output improves.

A polished artifact can conceal unchanged uncertainty

At their core, large language models generate responses by predicting sequences of tokens from patterns learned during training. The GPT-4 Technical Report describes GPT-4 as a Transformer-based model pre-trained to predict the next token in a document and explicitly notes that the system is not fully reliable and can produce fabricated or inaccurate content.[3]

GPT-4o extended the approach across text, images, audio and video, but its system card continued to treat model behavior as something requiring evaluation, safeguards and human judgement.[4]

The mechanism does not make the output trivial. AI-generated analysis can be genuinely useful, original and better than what a person would have produced alone.

It does make one point unavoidable:

A plausible output is not self-validating evidence.

The model can draft an experiment plan. It cannot establish that the experiment tests the decisive assumption.

It can summarize customer interviews. It cannot determine whether the sample represents the market.

It can construct a business case. It cannot make the assumed adoption rate true.

It can generate a persuasive recommendation. It cannot accept the consequences when that recommendation is wrong.

The organization still has to judge the work.

Unfortunately, better presentation can make that judgement less critical precisely when it should become more demanding.

AI can increase confidence without increasing validity

The problem becomes sharper when AI does not merely recommend an answer but also explains why the answer should be trusted.

A field experiment involving 228 evaluators examined 3,002 decisions about 48 real early-stage innovations. Participants either evaluated the opportunities without AI, received AI recommendations without explanations or received recommendations accompanied by narrative rationales.[5]

AI assistance improved screening performance overall.

The explanations created a separate effect. Narrative rationales increased evaluators’ alignment with the AI recommendations by 19 percentage points without producing a corresponding improvement over recommendations presented without explanations. The effect was especially strong when the AI recommended rejecting an opportunity.[5]

The explanation made the recommendation more persuasive.

It did not make it more accurate.

That finding is particularly relevant for corporate innovation because market analyses, interview summaries, business cases and experiment reports are rarely neutral documents. They are part of an argument for what the organization should fund, stop or build next.

AI can now make those arguments more coherent, more comprehensive and more difficult to challenge.

The investment committee sees a well-structured market narrative, a clear problem statement, a detailed experiment plan and a professional financial model. The quality of the package raises confidence in the initiative.

But the critical assumptions may be exactly as uncertain as they were before the package was produced.

What improved was the argument.

What did not necessarily improve was the decision.

AI exposed what weak OKRs were measuring all along

The problem is not primarily the technology.

It is the management system receiving its output.

Objectives and Key Results are intended to connect work with observable progress. The Objective describes what the organization wants to accomplish. The Key Results indicate how it will know whether that state has been achieved or meaningfully advanced.

In practice, many Key Results describe work instead:

• launch the prototype;

• complete the market study;

• interview 20 customers;

• deploy the AI assistant;

• create the investment proposal;

• test three pricing models.

These items are concrete, measurable and controllable. They are also attractive because teams can complete them.

That does not make them evidence that the Objective was achieved.

The OKR literature distinguishes between inputs, outputs and outcomes. Inputs describe actions under the team’s control. Outputs describe what those actions produce. Outcomes describe the change created by the work. Outcome-based Key Results are often more useful because they preserve flexibility over how the desired change is achieved.[6]

Outputs can sometimes be legitimate Key Results. Delivering a defined capability may itself be strategically important. In highly regulated, infrastructural or operational work, completing something may be a necessary and material result.

The danger is not the presence of an output.

It is the absence of any connection between that output and the outcome it is supposed to create.

AI makes this weakness harder to ignore because it dramatically increases the supply of what is easy to produce and count.

A team can now generate reports, prototypes, summaries, recommendations, market maps and implementation plans much faster than before. If the OKR system rewards those objects, AI will make the organization look increasingly successful without necessarily making it more effective.

This is a familiar management failure. Research on goal setting has warned that narrow targets can focus attention on the measured objective while causing people to neglect important consequences outside it.[7] Steven Kerr described the broader organizational pattern as rewarding one behavior while hoping for another.[8]

Organizations say they want customer value, reduced uncertainty and better investment decisions.

They reward completed interviews, delivered prototypes and polished business cases.

AI did not create that contradiction.

It industrialized it.

An initiative can complete every Key Result and still fail its Objective

Consider an innovation team with the following Objective:

Build confidence that an AI assistant can improve how account managers prepare for important customer meetings.

Its Key Results are:

• interview 20 account managers;

• produce a market and competitor analysis;

• build a working prototype;

• pilot it with three sales teams;

• prepare a business case for scaling.

The team may complete every Key Result.

The Objective may remain unresolved.

Twenty interviews do not establish that the problem is urgent or that current preparation causes meaningful commercial harm.

A competitor analysis does not show that customers will adopt another tool.

A prototype does not prove that behavior will change.

A pilot does not establish repeatable value merely because people agreed to participate.

A business case does not become evidence because its calculations are detailed.

Every Key Result describes progress through a plan.

None necessarily demonstrates progress toward the decision.

AI can now help the team complete all five more quickly and professionally. The OKR score may improve while the uncertainty remains unchanged.

This is why an initiative output cannot automatically be treated as an innovation outcome.

The relevant question is not only:

Did we do what we planned?

It is:

Did the work change what we know, what customers do or what commitment is now justified?

Outcome-based OKRs need a different interpretation in innovation

Outcome-based Key Results should remain the default.

Early innovation creates a legitimate complication: final commercial outcomes may not yet be observable.

A pre-revenue venture cannot always measure recurring revenue. A discovery team may not yet be able to demonstrate retention. An early technical experiment may need to establish feasibility before customer behavior can be tested.

This does not justify replacing outcomes with activity.

It means that the organization needs stage-appropriate evidence.

A useful innovation Key Result may measure whether a decisive assumption has crossed a predefined evidence threshold.

Compare these statements:

Conduct 20 customer interviews.

and:

Demonstrate that at least 12 of 20 customers in the target role experienced the problem during the past three months, used a costly workaround and will commit time, data or budget to a next test.

The first measures activity.

The second defines evidence that could strengthen or weaken the problem thesis.

Compare:

Launch a prototype.

with:

Demonstrate that at least 70 percent of target users complete the critical workflow without assistance and choose the new process over their current alternative in repeated use.

The first measures an output.

The second measures observable behavior under defined conditions.

Compare:

Build the AI assistant.

with:

Reduce meeting-preparation time by 40 percent without reducing the accuracy, relevance or commercial usefulness of the resulting briefing.

The first says what the team will produce.

The second says what must become better.

The distinction is not semantic hygiene.

It determines whether the organization funds work because a team produced something or because the work created evidence that justifies another commitment.

AI can produce the output. It cannot own the outcome.

An AI system can draft, calculate, compare, classify, recommend and explain.

It can help a team formulate an Objective, rewrite a Key Result, generate possible thresholds and challenge whether the selected measure is vulnerable to gaming.

It cannot own the outcome.

Ownership requires more than producing the work. It includes deciding which trade-offs are acceptable, determining what evidence is sufficient, accepting responsibility for false positives and false negatives, and answering for the consequences of the commitment.

AI cannot carry that responsibility.

A model does not lose credibility when a venture receives another €2 million and fails. It does not explain the decision to the board, the employees who joined the project or the customers affected by the result.

The accountable executive does.

This is why inserting AI into an OKR system does not reduce the need for ownership. It makes ownership more important because the system can now produce a much larger quantity of persuasive work without increasing the number of people prepared to stand behind its validity.

AI did not break OKRs. It exposed whether they were measuring completed work or meaningful change.

When output becomes cheap, output-based confidence should become more expensive.

The organization needs a higher standard for what counts as progress, not a larger volume of visible production.

The Evidence-Based OKR Audit

Read more

I first saw Artisan’s provocative advertisement campaign while scrolling through social media.

Stop Hiring Humans.

The product behind it was Ava, an autonomous AI business development representative that identifies prospects, writes personalized outreach, handles replies and books meetings.[1]

Artisan’s co-founder and CEO, Jaspar Carmichael-Jack, later explained that the billboard referred to a category of work rather than to the people performing it. His argument was that AI should take over repetitive list building, email production and high-volume follow-up, while humans continue calling prospects, listening, adapting and building relationships.[2]

That clarification makes the argument more interesting, not less.

The relevant question is no longer whether Artisan literally wants companies to eliminate every salesperson. It is what a company is buying when it transfers the early stages of customer acquisition to software—and what happens to the human role, the learning system and the commercial capabilities that previously developed through that work.

AI sales tools are not simply reducing the cost of an existing process.

They are helping companies decide what selling will mean.

Acquisition is an unusually attractive automation target

Every business without sufficient inbound demand must identify and approach people who have not asked to hear from it.

Much of that work is repetitive. Teams search for companies, identify contacts, enrich account information, draft messages, schedule follow-ups, monitor replies and decide which prospects deserve more attention.

It is expensive to scale through headcount, relatively easy to measure and frequently disliked by both sides. Salespeople may find repetitive prospecting exhausting, while potential customers rarely welcome another unsolicited email.

This makes outbound acquisition an almost perfect automation case.

Software can process much larger prospect pools than an individual salesperson. It does not become discouraged after repeated rejection, forget a follow-up or require another salary each time the company expands the volume of outreach.

Artisan currently presents Ava as an autonomous system that can find leads, track intent signals, write and send personalized sequences, handle objections and book meetings. The company claims that teams using Ava generate pipeline at one-fifth the cost of a human business development representative.[1] That is a vendor claim, not an independently established result, but it shows what customers are being asked to value.

The unit of progress is cheaper pipeline.

That may be economically useful. It is not yet a complete business case.

A lower cost per lead does not prove greater commercial value

An AI system may reduce the cost of contacting a prospect. It may increase the volume of outreach, replies and booked meetings.

None of those results, on their own, establishes that the company is approaching the right market, solving an important problem or attracting customers it should want.

A reply is not demand.

A meeting is not necessarily an opportunity.

A message is not relevant simply because it contains accurate information about the recipient.

If the ideal customer profile is wrong, AI can reach the wrong customers more efficiently. If the offer is weak, it can test hundreds of polished descriptions of the same weak proposition. If the system is rewarded for booking meetings, it can improve that metric without creating customers who buy, remain or become profitable.

The technology may be performing exactly as instructed.

The problem is that the instruction may represent only one part of commercial progress.

A company therefore needs to distinguish between four different results:

• Activity: messages sent, accounts contacted and follow-ups completed.

• Engagement: replies, conversations and meetings booked.

• Commercial quality: qualified opportunities, conversion, retention and customer value.

• Market learning: improved understanding of why customers act, hesitate or decline.

Automation can improve activity and engagement without necessarily improving commercial quality or market learning.

The dashboard may show more movement while the company remains uncertain about whether it is creating a stronger business.

The human enters later, but not necessarily higher

The common promise is that automation removes low-value work so salespeople can concentrate on higher-value activities.

Research, account selection, outreach, follow-up, scheduling and early qualification move into the system. Humans spend more time on discovery, negotiation, relationship building and closing.

That can be a sensible division of labor.

It also narrows the salesperson’s role.

Before the salesperson joins the meeting, the system may already have:

• selected the account;

• identified the contact;

• interpreted available intent signals;

• chosen the message;

• made claims about the company’s value;

• handled initial questions;

• classified the prospect as qualified.

The salesperson receives a prepared conversation.

That saves time. It also means the system has shaped much of the commercial context before the human appears.

The person is still expected to build trust and carry responsibility for the relationship, but may no longer control who enters the funnel, what the prospect has already been told or why the meeting was judged worthy of human attention.

This is not automatically humans moving into higher-value work.

It may be humans performing the final stage that still benefits from a human face.

Higher-value work normally implies greater judgement and agency. A salesperson who receives a preselected prospect and follows a system-generated recommendation may be performing a more socially consequential task while exercising less control over how the situation was created.

Artisan’s argument solves one problem and exposes another

Carmichael-Jack argues that the apprenticeship value of business development did not come primarily from changing email templates or building prospect lists. It came from calling people, handling rejection, listening, adapting and learning how to create a real conversation.

Artisan has therefore built a human dialer alongside Ava. Its stated model is that software performs the volume work while people continue doing the work that depends on human connection.[2]

That is a stronger model than simply removing the entire role.

But it does not settle where commercial judgement develops.

Cold calls may teach listening and live adaptation. They do not necessarily replace what a salesperson learns while selecting accounts, researching markets, developing messages and interpreting the difference between interest and intent.

The strategic question is therefore not whether automation removes meaningless work.

It is whether the company has accurately distinguished meaningless repetition from the experiences through which people learn how the market behaves.

Augmentation and substitution create different learning systems

The strongest evidence currently available supports the value of AI augmentation more clearly than it supports autonomous substitution.

In a large field study involving more than 5,000 customer-support agents, access to a generative AI assistant increased productivity by approximately 15 percent on average. The largest gains occurred among less experienced and lower-performing workers, suggesting that the system helped transfer practices associated with stronger performers.[3]

That is a meaningful result, but the study did not examine autonomous sales agents. The employees remained responsible for the customer interaction and received AI-generated guidance while performing the work themselves.

The distinction matters.

When AI assists a salesperson with research, message development or qualification, the person may still examine the information, challenge the recommendation, change the approach and learn from the customer’s response.

When the system performs the entire upstream process and delivers only the result, the learning opportunity may disappear with the work.

The same customer-support research also suggests that the effects of AI differ according to experience. Less experienced workers benefited most, while the strongest workers gained relatively little and may have had fewer incentives to develop new approaches.[3]

This creates a potential tension.

AI can spread established practices across a workforce and raise the performance floor.

At the same time, an organization that relies too heavily on those practices may weaken its ability to notice when the market has moved beyond them—and limit how far its ceiling can rise.

The salesperson may lose the experiences that create judgement

Sales judgement does not begin in the closing conversation.

It develops through repeated contact with markets, messages, rejection and customers who interpret the company’s proposition differently from how management expected.

Researching accounts may be tedious, but it teaches how an industry is structured and where decision authority sits.

Prospecting reveals which problems generate genuine attention and which sound important mainly inside the company.

Qualification teaches the difference between politeness, curiosity, urgency and willingness to act.

Rejection can reveal that a segment is wrong, the timing is poor, the message is unclear or the supposed customer problem does not have a budget behind it.

These activities are not valuable merely because humans have traditionally performed them. Many individual tasks can and should be automated.

Their hidden value lies in the feedback they generate.

A company can automate a role more quickly than it can redesign the learning path that role previously provided.

If much of entry-level business development disappears, the organization needs credible answers to several questions:

• Where will future account executives learn how buyers respond before a meeting reaches their calendar?

• How will new salespeople develop an instinct for weak qualification?

• Who will understand how the market is structured when the system’s historical patterns stop fitting?

• How will experienced sellers continue encountering signals that do not match the current playbook?

The immediate result may look like higher productivity.

The later result may be a shortage of people capable of selling when the system’s assumptions become outdated.

That outcome is not inevitable. It becomes more likely when companies remove the work without deliberately replacing the learning.

More data does not guarantee more understanding

Autonomous sales systems can process more interactions than a human team.

They can compare response rates, test variations, classify objections, monitor signals and identify which combinations generate meetings.

That creates a large volume of commercial data.

It does not automatically create market understanding.

A system may show that one message performs better without explaining why. It may show that a segment does not respond without distinguishing between poor timing, weak positioning, channel fatigue, incorrect targeting or a deeper change in how customers understand the problem.

Optimization also favors what can be recognized and measured.

Prospects resembling previous buyers become easier to score. Messages resembling earlier successes become easier to recommend. Objections fitting existing categories become easier to classify.

That is useful while the current model remains valid.

It becomes restrictive when the market changes.

An unusual prospect, an unexpected objection or a conversation that does not fit the normal funnel may look inefficient to the system. It may also contain the first evidence that the company’s assumptions are becoming obsolete.

Humans do not automatically recognize such signals either. Salespeople also follow incentives, familiar patterns and existing categories.

The difference is that an automated system can standardize one interpretation across the entire acquisition process.

The company may collect more consistent data while exposing itself to fewer genuinely different readings of the market.

Responsibility can remain human while control moves elsewhere

Customers do not experience account databases, scoring models, message generators, reply systems and account executives as separate entities.

They experience one company.

When a salesperson joins a conversation, that person may need to recover from inaccurate targeting, an excessive sequence, a poorly handled objection or a claim generated earlier in the process.

The system selected the target and shaped the interaction.

The person carries the social consequence.

Research on algorithmic management describes a broader version of this organizational pattern. Digital systems can coordinate, direct and monitor work while narrowing employee discretion over how tasks are performed. European research has found that algorithmic management can create efficiency benefits while also increasing work intensity, standardization and managerial control.[4][5]

Autonomous sales systems are not identical to the platform-work or operational systems examined in much of that research.

The underlying governance question is still relevant:

Who controls the process, and who remains accountable for its consequences?

If salespeople can inspect the targeting logic, modify messages, reject qualifications and feed learning back into the process, the system may support professional judgement.

If they are expected to accept the prepared meeting and close it, the system is not merely assisting sales. It is managing the conditions under which selling occurs.

Dependency extends beyond software availability

Every business system creates dependencies.

An autonomous acquisition system creates dependencies on:

• the quality of its data;

• the definition of the ideal customer profile;

• the signals it has been instructed to recognize;

• the outcome used to optimize its behavior;

• the information supplied for handling questions;

• the organization’s ability to detect when these assumptions weaken;

• the vendor’s models, infrastructure and future choices.

The immediate operational risk is that the tool becomes unavailable or performs poorly.

The deeper risk is that the company gradually loses the ability to understand and operate the process without it.

As employees stop performing upstream work, fewer people see the complete acquisition system. Fewer understand why accounts are selected, how messages evolve or which customer reactions have been compressed into dashboard categories.

Replacing a vendor is easier than rebuilding commercial capability that no longer exists inside the company.

The relevant resilience question is therefore not only:

Can we continue prospecting if the software stops working?

It is:

Would we still know how to find customers if the assumptions inside the software stopped working?

Customers do not care what the message cost

From the customer’s side, automation may simply increase the volume of outreach competing for limited attention.

The recipient does not care how efficiently the message was produced. They care whether the interruption is relevant, credible and worth responding to.

This does not mean customers will always prefer human salespeople.

A 2026 meta-analysis covering hundreds of studies found that people often begin with greater skepticism toward automated agents, but that customer responses depend strongly on performance, context, task and agent type. Automated systems can produce customer choices and behavioral outcomes comparable to human agents in some settings.[6]

Research focused specifically on sales also suggests that the relative value of AI and human salespeople differs across stages of the buyer–seller relationship. AI may be better suited to some analytical and transactional tasks, while human salespeople retain advantages where the interaction depends on relationship development, complex interpretation and adaptation.[7]

The boundary is not simply human versus machine.

It is the fit between the interaction and the kind of judgement, trust and responsiveness it requires.

That boundary will move as the technology develops.

The strategic question is whether the company has placed it deliberately.

This is not a choice between automation and no automation

Companies will automate work that is expensive, repetitive, measurable and technically automatable.

In many cases, they should.

The important distinction is between automating a task and redesigning a capability without acknowledging that this is what is happening.

A company that automates account research changes how salespeople develop market knowledge.

A company that automates targeting changes who decides which customers matter.

A company that automates message creation changes how its value proposition is tested.

A company that automates qualification changes who interprets buying intent.

A company that automates objection handling changes where customer disagreement enters organizational learning.

A company that transfers all of these activities to software is not simply making business development more efficient.

It is redesigning the salesperson.

Sales automation should not be judged only by the work it removes. It must also be judged by the decisions, learning loops, capabilities and responsibilities that move with the work.

A company may still decide to automate almost the entire outbound process.

That can be a valid choice.

It should know which version of the salesperson—and which version of the sales organization—will remain when it is finished.

The Sales System Redesign Review

Read more

I do not remember the last app update note I read carefully.

Not because I am indifferent to what changes inside the products I use, but because most update notes have trained me not to expect meaningful information.

“Bug fixes and performance improvements.”

“Stability improvements.”

“We regularly update the app to make it better.”

These statements communicate that something changed without telling me what changed, which problem was corrected, which new risk was introduced or whether the product is now safer, faster or simply different in a way I will discover later.

I accept the update anyway.

That acceptance is the part worth examining.

We no longer use finished software. We live inside systems that continue changing while asking us to continue trusting them.

For much of consumer software, this arrangement has been enormously productive. Defects can be repaired quickly, security vulnerabilities can be addressed without waiting for the next major release, and products can respond to real behavior rather than relying entirely on assumptions made before launch.

But continuous improvement also changed the relationship between provider and user.

Software used to arrive with a clearer boundary between development and use. Permanent beta gradually dissolved that boundary. AI now dissolves another one: the boundary between software that performs a function and software that makes or influences a judgement.

That makes the old bargain much harder to evaluate.

Software used to have stronger edges

Earlier software releases were not necessarily better.

Bugs could remain unresolved for months. Installation was cumbersome. Companies delayed improvements until enough changes justified a new version. Enterprise releases often required testing, documentation, migration planning and nervous weekends for everyone involved.

The system nevertheless had a visible identity.

You installed a particular version. Changes occurred at recognizable moments. Someone had decided that the release was sufficiently complete and stable to leave the development environment.

The rise of internet services changed that rhythm. In his description of Web 2.0, Tim O’Reilly called one of its defining patterns the perpetual beta: software developed in the open and updated monthly, weekly or even daily.[1]

The product no longer needed to be complete before it reached the user. Use itself became part of product development.

This brought genuine benefits. Instead of attempting to anticipate every need, companies could release earlier, observe behavior and improve the product through feedback.

The user became a participant in the learning system.

Less visibly, the user also became part of quality assurance.

Features could be tested in production. Edge cases could emerge through actual use. Problems that had not appeared in controlled environments could be discovered across thousands or millions of customers.

In low-consequence settings, that can be a reasonable trade.

A music recommendation can be poor. A photo filter can distort the wrong part of an image. A productivity app can rearrange its interface and irritate users for a week.

The defect is visible, the consequence is limited and the next update can often reverse it.

The logic becomes more difficult when software is embedded in infrastructure on which other organizations depend.

When an update becomes the failure

On July 19, 2024, CrowdStrike distributed a routine content-configuration update to Windows systems using its Falcon security platform.

According to CrowdStrike’s own post-incident review, a defect in its Content Validator allowed problematic content to pass validation. When the affected file was processed, it triggered Windows system crashes. CrowdStrike reversed the update within roughly 80 minutes, but the consequences had already spread through organizations around the world.[2]

Microsoft estimated that approximately 8.5 million Windows devices were affected. That represented less than one percent of Windows machines globally, yet many of those devices were operated by enterprises providing critical services.[3]

Airlines, hospitals, financial institutions and public services experienced disruption.

The mechanism designed to protect infrastructure had become the infrastructure failure.

CrowdStrike is not an argument against continuous updating. Security software must respond rapidly to changing threats. A system unable to update quickly would create risks of its own.

The incident reveals a more important principle:

The faster and more widely a change can propagate, the stronger the release controls, containment mechanisms and recovery options must become.

Speed does not remove the obligation to prove reliability.

It increases it.

A product used by a few willing beta testers can tolerate a different level of uncertainty from software embedded across critical operational systems. The release mechanism may look technically similar, but the consequences are not.

Permanent beta therefore needs a boundary.

The difficulty is deciding where to place it.

The permanent-beta bargain

The bargain behind continuous software development can be stated simply:

The provider receives real-world learning. The user receives faster improvement.

The bargain remains defensible when several conditions are present.

The failure is visible. The consequence is limited. The update can be rolled back. A workable alternative remains available. The affected user can recognize the problem and seek correction.

When those conditions weaken, “we will improve it in the next release” becomes less reassuring.

A blocked payment may be corrected later, but the missed deadline remains. A patient may eventually receive the right appointment, but the delay has already occurred. A job applicant may appeal a ranking, but the hiring process may have moved on.

Not every error is erased by correcting the system that produced it.

This is the point at which permanent beta stops being only a product-development philosophy and becomes a governance question.

Who is permitted to learn in production?

Who carries the cost of that learning?

Which consequences can be reversed, and which become part of someone’s life before the next version arrives?

AI changes the shape of failure

Traditional software failures often declare themselves.

The application crashes. The button does nothing. The calculation produces an error. The payment does not complete.

The user may not know why the system failed, but at least the failure is visible.

AI can fail without appearing broken.

The chatbot responds. The ranking appears. The summary is concise. The recommendation is formatted correctly. The fraud alert looks authoritative.

Nothing crashes.

The failure may be an omitted fact, a weak inference, an outdated policy, a biased proxy or a confident answer derived from insufficient context.

The system continues operating, and the output looks like success.

This is what makes AI a different form of permanent beta. Its errors are often semantic rather than mechanical. The system does not merely change how a function is performed. It changes the information, interpretation or recommendation on which a person may act.

A customer-service system may produce an incorrect interpretation of a policy. A recruitment tool may convert limited historical data into a candidate ranking. An internal copilot may omit the one commercial risk that should have changed the recommendation.

The failure does not feel technical.

It feels cognitive.

Fluency changes trust before reliability has been earned

A clear answer is easier to trust than a confused one.

This is normally useful. Clear communication helps people understand reasoning and act on information.

With generative AI, clarity can become misleading. A well-structured answer may be based on incomplete evidence. A confident explanation may disguise uncertainty. A precisely formatted score may rest on a poor proxy.

Presentation quality and epistemic quality are not the same.

Research on automation has documented the risk of automation bias: people may over-rely on automated recommendations, particularly when their attention is divided or the system has performed reliably in previous interactions.[4]

AI adds natural language to that dynamic.

A conventional system might produce a number. Generative AI can produce the number, explain it, defend it and rewrite the explanation in the language of the organization using it.

The output feels less like a machine signal and more like judgement.

That makes human oversight more difficult, not less necessary.

The reviewer must ask whether the answer is correct, whether the evidence is sufficient, whether the model had access to the relevant context and whether the claim should be made at all.

In many consequential settings, the affected person cannot perform that audit.

A candidate cannot inspect the assumptions behind a proprietary hiring score. A customer cannot verify the training data behind a fraud decision. A patient cannot independently evaluate every medical inference generated by a model.

The system produces the judgement.

The person carries the consequence.

Capability is accelerating faster than inspectability

The Stanford AI Index reported in 2026 that documented AI incidents increased from 233 in 2024 to 362 in 2025.[5]

At the same time, transparency among major foundation-model providers declined. The Foundation Model Transparency Index rose from an average score of 37 in 2023 to 58 in 2024, then fell to 40 in 2025. Significant gaps remained around training data, compute, model use and post-deployment impact.[5][6]

This does not prove that every less transparent model is unsafe or that transparency alone ensures reliability.

It does mean that organizations are increasingly integrating systems whose behavior, provenance and downstream consequences may be difficult to evaluate independently.

A model can improve rapidly while the organization using it understands less about what changed between versions.

The interface may retain the same name while the underlying model, retrieval process, safeguards, system instructions and response behavior change. A workflow that was tested in March may no longer operate identically in July.

With conventional software, an update may alter the function.

With AI, an update may alter the judgement.

That requires a different release question.

It is no longer enough to ask:

Does the system still run?

Leaders must also ask:

Does it still produce sufficiently valid and reliable outputs in the context where we use it?

Post-deployment monitoring is necessary—and still immature

Pre-release evaluation remains important, but it cannot reproduce every condition a deployed AI system will encounter.

Inputs change. User behavior changes. surrounding processes change. Data distributions move. Model responses may vary even when prompts look similar.

NIST’s 2026 report on monitoring deployed AI systems argues that post-deployment monitoring is necessary to confirm real-world reliability, detect unforeseen outputs and identify unexpected consequences in changing contexts. It also concludes that common terminology, validated methods and monitoring practices remain immature and fragmented.[7]

This creates a tension.

Organizations cannot prove every aspect of AI behavior before deployment. Some learning must occur in use.

Yet the fact that monitoring is necessary does not mean every system should be allowed to learn through live consequences.

The appropriate question is:

Which uncertainty may be managed in production, and which uncertainty must be reduced before the system receives authority?

That distinction is missing from many AI strategies.

A prototype, internal assistant, customer chatbot and hiring recommendation system may all be described as AI use cases. They should not inherit the same release philosophy.

Human oversight cannot mean human decoration

The standard reassurance is that a human remains in the loop.

That statement is almost meaningless until the loop is examined.

Can the person understand the system’s relevant capabilities and limitations?

Can they recognize when the output may be wrong?

Do they have access to the evidence necessary to challenge it?

Do they have enough time to review it?

Are they permitted to override it?

Will reversing the AI recommendation create additional work, social friction or managerial suspicion?

A human who clicks “approve” because the system has already shaped the workflow is not meaningful oversight. They are the final interface element.

The EU AI Act’s Article 14 requires more for high-risk systems. Human overseers must be enabled to understand relevant capabilities and limitations, monitor for unexpected performance, remain alert to automation bias, interpret outputs and decide not to use, override or reverse them.[8]

This is not simply a requirement to place a person after the model.

It is a requirement to preserve human authority and make that authority operationally usable.

An organization has not created meaningful oversight merely because an employee is technically able to reject the output. The employee needs knowledge, time, evidence and institutional permission to do so.

Otherwise, judgement has already been delegated, even when the governance diagram says it has not.

Update culture has moved into judgement

Update culture trained us to accept instability in software.

The application may behave differently tomorrow. A feature may disappear. A recommendation may improve. A defect may be corrected after users discover it.

AI risks extending that acceptance into decisions.

The model may interpret the case differently tomorrow. A ranking may change because the provider updated the system. A summary may omit different information. A safeguard may become stronger in one context and weaker in another.

This is not automatically unacceptable. Human judgement also varies, improves and fails.

The difference is scale, opacity and authority.

An AI system can reproduce one weak assumption across thousands of decisions before the pattern becomes visible. The person affected may not know that AI influenced the result. The organization may not know that the system’s behaviour changed.

NIST’s AI Risk Management Framework treats validity and reliability, safety, accountability, transparency and explainability as characteristics that must be managed throughout the AI lifecycle, including after deployment.[9]

The underlying principle is straightforward:

A system should not be trusted because it is continually improving. It should be trusted only to the extent that its current performance, limitations and controls justify the authority it has been given.

Not everything belongs in the same beta

This is not an argument against updates, experimentation or AI.

It is an argument against applying one release philosophy to every level of consequence.

Some systems can reasonably operate in open permanent beta. Their mistakes are visible, limited and easily reversed.

Some require controlled beta. They may learn through use, but only within boundaries that include monitoring, escalation, rollback, documentation and a workable human alternative.

Some should not make live consequential decisions while still being treated as experimental. They require stronger evidence before authority is granted because correction after the event cannot fully restore what was lost.

The free diagnosis is complete:

Permanent beta is acceptable only when the organization has matched the speed of learning with the consequence of being wrong.

The central leadership decision is not whether a system may continue improving after deployment.

Almost every useful digital system will.

The decision is how much authority it may receive before its reliability, limits and recovery mechanisms have been demonstrated in the context where the consequences occur.

The Beta Boundary Review

Read more

I once drove two hours for a ten-minute venture capital pitch. And then two hours back.

The company I co-founded developed predictive software for collection and supply operations, addressing a vehicle-routing problem with multiple constraints. Instead of sending trucks with fixed loads along fixed routes on set weekdays, sensors measured container fill levels, predicted when containers would need to be emptied or replenished, and helped operators plan their routes accordingly. We found that transport efficiency could be improved by almost 40%, while greenhouse-gas emissions could be reduced by roughly the same amount and capacity freed up to serve new customers. So far, so good.

Ten minutes into the meeting, the investor stopped me.

“This IoT-sensor case has been tried before.”

He was not wrong. The technology was not entirely new. Sensors had been placed in containers before, route optimization had existed for years, and other companies had attempted similar solutions.

But that was not the argument I was making.

“Technologically, yes,” I replied. “But not now with this business model and not under these shifting market conditions.”

Fuel costs were increasing. Labour and industrial processing were becoming more expensive. Margins were shrinking. Recyclable materials that had once generated revenue were losing value and sometimes becoming a disposal cost. Fixed collection schedules had always contained inefficiency, but the economics of that inefficiency were changing dramatically.

The investor heard a familiar technology with a history.

I saw an old operating assumption becoming expensive and more and more inefficient for the future (inflection point).

My answer did not land well. It probably sounded offensive, even though it was not intended as a provocation. It was simply the compressed version of the question I wanted us to examine:

Driving back home and reflecting from this meeting taught me something I now tell founders when they show me a rejection email.

Not all investor feedback is market truth.

Sometimes it is the risk logic of an investment system expressed as though it were a verdict on the business.

What an investor’s “no” actually tells you

Founders often read a rejection as a judgement on whether their idea is good.

That is rarely the precise decision the investor is making.

The investor is deciding whether this particular opportunity fits a particular fund, portfolio, expertise base, risk tolerance, ownership model, time horizon and return expectation. The decision is made with incomplete information, limited time and no direct responsibility for operating the business.

A “no” may mean:

• I do not believe this market will become large enough.

• I cannot see how this reaches venture-scale returns.

• I do not understand the category well enough to price the risk.

• The timing does not fit our fund.

• The evidence is not yet strong enough.

• This resembles something that previously failed.

• I cannot explain the opportunity convincingly to my investment committee.

These are not the same statement.

Research on venture investment shows why the distinction matters. A study of more than 29,000 venture deals found that companies spanning less familiar subcategories tended to receive lower valuations. The penalty diminished as investor expertise increased. The issue was not necessarily that category-spanning ventures were objectively weaker. They were harder for less specialized evaluators to interpret coherently.[1]

This creates a structural problem for ventures built around emerging combinations.

A company may sit between waste logistics, industrial IoT, software and resource economics. Another may combine local-grid management, electric-vehicle charging, solar generation and decentralized prediction. The operating problem may be clear to an industry insider while remaining difficult to place inside the categories used by a generalist investor.

Markets require categories because categories make comparison possible. Investors need to compare opportunities, estimate returns and communicate decisions. The category is therefore not merely a limitation. It is part of the machinery that makes investment possible.

But categories are built from what has already existed.

When conditions begin changing faster than the category, the machinery starts misreading the opportunity.

“Tried before” is relevant—but incomplete

Founders should not dismiss the sentence.

Previous attempts contain information. Someone may have discovered that customers would not pay, integration costs were prohibitive, user behaviour did not change, procurement took too long or the economic advantage disappeared outside a controlled pilot.

Ignoring that history is not visionary. It is wasteful.

But “this has been tried before” is not yet an analysis. It is the beginning of one.

The useful follow-up is:

A previous solution may have failed because sensors were too expensive. That conclusion matters only if sensor economics remain similar.

It may have failed because diesel and labour were cheap enough that fixed routing was still acceptable. That matters only if the cost of the existing system has not changed.

It may have failed because the user appreciated the product but the buyer did not feel sufficient financial pressure. That matters only if budget ownership, regulation or operational exposure remains unchanged.

Technologies often return because the surrounding system changes. The underlying invention may be familiar while the cost of the old default, the availability of infrastructure, the buyer’s urgency or the viable business model changes substantially.

The question is therefore not whether the solution has existed before.

The question is whether the conditions that previously prevented adoption still govern the decision.

Answering that question requires testing the business model as an interacting system. A new cost curve can alter pricing, buyer urgency, adoption, delivery economics, and distribution at the same time.

The investor may be evaluating a category while the founder is observing an inflection

I encountered the same pattern later in a grid-technology venture.

From outside, the category could easily be labelled “AI for energy.” That framing made the opportunity sound broad, fashionable and difficult to distinguish from dozens of technology pitches.

Inside the operating environment, the problem was more specific.

Electric-vehicle charging and rooftop solar were changing assumptions about how much electricity a local distribution grid could absorb. The relevant constraint was not whether AI could optimize energy in the abstract. It was whether better forecasting and decentralized control could delay expensive grid reinforcement while allowing more electric vehicles and solar installations to connect.

The category hid the operating pressure.

This is common near an inflection. People closest to the system often notice a constraint before the market has stable language for it. They see the maintenance issue, procurement bottleneck, cost shift or behavioral change before it appears in market reports.

That proximity does not automatically make them right. Insiders have biases of their own. They can mistake local pain for a scalable market, confuse technical possibility with customer demand and assume that a change visible to them will matter equally to a buyer.

But an outside investor also operates with incomplete knowledge. A systematic review identified numerous biases that can influence venture-capital decisions, including representativeness, anchoring, familiarity and overconfidence.[2]

Another study of US venture exits found that measured VC overconfidence was associated with faster fundraising and shorter times to exit. This does not mean investor confidence is always misplaced, but it is evidence against treating investor judgement as a neutral measurement of market reality.[3]

Both founder and investor are interpreting uncertainty.

The difference is that the investor’s interpretation often arrives in the grammatical form of a fact.

What founders lose when they accept the verdict

The immediate cost of a rejection is obvious: no investment.

The more consequential cost can appear later.

A founder begins editing the opportunity to fit the feedback. The unusual combination is simplified into a familiar category. The difficult business-model insight is replaced with a comparable investors already understand. The company starts optimizing for fundability before it has established what would create customer value.

Sometimes this is useful. A founder may genuinely have communicated the opportunity badly. A clearer category can reduce unnecessary confusion.

But sometimes the business is gradually changed into a smaller and more conventional version of itself.

Years later, the founder is running a company that investors could understand but that no longer captures the inflection that made the original opportunity important.

There is rarely one dramatic moment when this happens. It occurs through a sequence of reasonable adjustments:

• make the market look more familiar;

• remove the part that requires explanation;

• avoid the business model investors disliked;

• pursue the customers that resemble existing comparables;

• add the features that make the company easier to categorize.

The founder eventually receives better feedback because the company has become easier to recognize.

Recognition and opportunity are not the same thing.

Where founders fool themselves

There is an equal and opposite danger.

“Investors do not understand it” can become a convenient defense against evidence.

Some founders reinterpret every rejection as proof that they are early. Weak demand becomes a market-education problem. Poor retention becomes a product-maturity issue. Unconvincing economics become evidence that the business model is disruptive.

This story can protect an idea for years.

This is the same interpretive problem that makes weak traction difficult to judge before scaling. The signal may be real, but its ambiguity allows each stakeholder to fit it to the narrative that protects their position.

Disruption research itself contains a warning. A recent academic review found substantial controversy around the predictive usefulness of disruptive-innovation theory. Many examples are easier to classify as disruptive after the outcome is already known, creating a risk that hindsight turns an uncertain opportunity into an inevitable historical narrative.[4]

Founders can make the same mistake prospectively. They tell the future success story so convincingly that the absence of current evidence begins to feel like part of the hero’s journey.

Being misunderstood does not prove that you are right.

Being early does not prove that the market will arrive.

A changing cost curve does not prove that customers will buy your solution.

The burden of evidence remains with the founder.

Feedback is data about two systems

A rejection contains information about the venture.

It may reveal weak evidence, unclear economics, an implausible distribution model or a market that does not justify venture capital.

It also contains information about the investor.

It reveals the categories they use, the risks they can price, the time horizon they require and the kind of opportunity they are equipped to support.

The mistake is treating feedback about both systems as though it described only one.

“This has been tried before” may mean the opportunity has a fatal historical problem.

It may also mean the investor cannot yet see why the current opportunity is different.

A founder’s job is not to reject the feedback or obey it.

It is to translate it.

The free diagnosis is complete:

The founder still has to determine whether the rejection contains market truth, fund logic, category blindness—or an uncomfortable combination of all three.

The rejection translation test

Read more

I read ’s Thinking in Bets a couple of months ago (I recommend reading it—and no, I have no affiliate incentive for doing so). It sat in the back of my mind the way good books do — not loudly, but present. Then something I saw this week brought it back, and I could not stop thinking about one image in particular.
Annie argues that Chess is played with complete information. Both players can see the same board, the pieces follow stable rules, and no card is dealt by chance. The position may be extraordinarily difficult to evaluate, but nothing relevant is deliberately hidden.

Poker is different. Players act without seeing every card. They infer what others may hold, update their beliefs as new information appears and make commitments without knowing whether the next card will help or hurt them. A strong decision can lose. A weak decision can win.

Most consequential innovation decisions are much closer to poker.

Leaders do not know how customers will behave, how competitors will respond, whether a partner will deliver or whether an emerging technology will mature at the right time. They make commitments using incomplete evidence and assumptions about a future that has not happened yet.

Yet organizations routinely evaluate those decisions as though innovation were chess: the outcome arrives, and management works backwards to decide whether the original move was good.

Psychologists Jonathan Baron and John Hershey demonstrated this tendency experimentally. Participants rated otherwise identical decisions more favorably when the reported outcome was positive and more negatively when it was adverse. They called this outcome bias.[1] A preregistered replication published decades later found the same basic effect: knowledge of the result continued to distort evaluations of the decision that preceded it.[2]

Duke calls the everyday version of this “resulting.”

The moment I encountered the term, I recognized much of what passes for innovation governance.

The organization sees the outcome, not the decision

When an innovation succeeds, the organization searches for the people, methods and decisions that supposedly caused the success. The team becomes a model. Its process is presented as a playbook. The executive sponsor is praised for conviction.

When an innovation disappoints, management performs the same exercise in reverse. It searches for poor execution, insufficient ownership, slow delivery or the person who should have recognized the problem earlier.

Both reactions are understandable. Both can be wrong.

A project may succeed because the market moved in its favor, a competitor withdrew, regulation changed, a sales relationship opened the right door or a customer need suddenly became urgent. The team may have made a series of weak decisions and still received a favorable outcome.

Another team may frame the problem carefully, test its most consequential assumptions and stop after discovering that customer behavior does not support the business case. The visible outcome is that nothing launched. The decision process may nevertheless have saved the organization from a much larger mistake.

The first project is celebrated. The second is often treated as a disappointment.

This creates a dangerous learning system. The organization rewards luck when it resembles success and punishes disciplined judgement when it produces an unattractive outcome.

It then repeats the wrong lessons.

Innovation is usually governed as deterministic execution

Most corporate innovation processes look reassuringly ordered.

There is a funnel, a series of stages, a business case, a roadmap, a steering committee and a launch plan. At each review, leaders ask whether the work is progressing and whether the next stage should be approved.

This architecture is not inherently wrong. It works reasonably well when the problem is known, the solution has been established and the central challenge is execution.

A production facility, regulatory implementation or proven product rollout still contains uncertainty, but the task is largely to deliver something the organization already understands.

Innovation begins from a different position. The problem may be misdiagnosed, the solution may not change behavior, the customer may not pay and the organization may not be able to deliver the model economically.

Under those conditions, a roadmap does not describe what will happen. It records what the team currently hopes will happen.

The mistake is not planning. The mistake is governing an uncertain opportunity as though completing the plan will resolve whether the opportunity was worth pursuing.

Projects then become very good at producing evidence of activity:

• interviews completed;

• prototypes delivered;

• pilots launched;

• milestones reached;

• partners contacted;

• features built.

None of those achievements necessarily answers the investment question.

The useful governance question is not only:

Did the team complete what it promised?

It is also:

What did the organization believe when it made the last commitment, what evidence has appeared since, and should that commitment now change?

Research on entrepreneurial decision-making shows why this matters. In a randomized controlled trial, entrepreneurs trained to articulate theories, derive testable hypotheses and evaluate evidence systematically made more precise decisions and were more likely to pivot away from weak ideas.[3] The method did not remove uncertainty. It changed how they responded to it.

A result contains more than the decision

An innovation outcome is rarely produced by one factor.

It reflects the interaction of:

• the original problem diagnosis;

• the evidence available when commitments were made;

• execution quality;

• the team’s ability to adapt;

• organizational support;

• customer and competitor behavior;

• timing;

• events nobody controlled.

This is why looking backwards from an outcome is so seductive. Once the result is known, the story becomes easier to construct. The winning move appears obvious. The ignored warning looks decisive. The failed assumption seems as though it should always have been visible.

Outcome knowledge changes how people remember and interpret the information that was available before the result. This is related to hindsight bias: after learning what occurred, people tend to see the event as more predictable than it appeared in advance.[4]

In organizations, this produces clean narratives after messy decisions.

A failed initiative is reconstructed as a sequence of warning signs, even if those signals were ambiguous at the time. A successful initiative is presented as the inevitable consequence of strategic clarity, while the near misses, fortunate timing and external help disappear from the account.

The story becomes useful for reputation management and dangerous for learning.

If leaders want better decisions, they must evaluate choices using the information available when the choice was made, not only the information revealed by the eventual outcome.

Most “knowns” are candidate beliefs

The poker analogy becomes uncomfortable when leaders examine what they actually knew before approving an innovation.

Organizations frequently say they know the customer when they know a segment description. They say they know the problem when they have a collection of internal interpretations, sales anecdotes and market reports. They say they know the economics when they have a spreadsheet whose most important cells contain assumptions about adoption, conversion and future scale.

These inputs are not worthless. They may be the best available starting point.

They are not all knowledge.

In uncertain work, a known should have survived meaningful contact with reality. A customer changed behavior. A buyer accepted a trade-off. A channel converted under plausible conditions. A technical constraint was tested where it actually matters. A partner committed its own resources.

Everything else remains a candidate belief with a level of confidence attached to it.

The distinction is important because commitment tends to turn candidate beliefs into organizational facts. Once a business case has been approved, the assumptions that created it are rarely revisited with the same energy used to defend the project.

Research on theory-driven entrepreneurial decision-making suggests that making the causal logic of an opportunity explicit can improve how entrepreneurs use evidence. A 2025 randomized trial found that theory-of-value training changed how entrepreneurs formed and evaluated their strategies, although the effects depended on the context and should not be interpreted as a universal recipe.[5]

The practical lesson is narrower: leaders cannot evaluate decision quality if the beliefs beneath the decision were never made visible.

Unknowns are not one category

Innovation teams often group uncertainty under a single heading called “risk.”

That hides important differences.

Some uncertainties are known unknowns. The team can name them: Will customers pay? Will users change their workflow? Can the solution be delivered at viable cost? Will procurement accept the model?

These uncertainties are useful because they can guide experiments.

Others are unknown unknowns. They remain outside the frame until the venture encounters a new customer, channel, regulation or operational condition. No workshop can identify all of them in advance.

A third category is more politically difficult: ignored knowns.

These are not missing facts. They are signals the organization has already encountered but does not want to include in the decision:

• customers are polite but not urgent;

• use declines after the novelty disappears;

• sales cannot explain the value without the product team;

• the economics depend on a scale the organization cannot credibly reach;

• the initiative requires behavioral or organizational change that nobody has authority to impose.

Ignored knowns are often reframed as execution issues because the alternative would be to reconsider the opportunity itself.

A board cannot eliminate unknown unknowns. It can, however, create conditions in which known unknowns are tested and ignored knowns are allowed into the room.

Good innovation teams do not avoid being wrong

Two teams can face similar uncertainty and behave very differently.

One turns its most consequential beliefs into explicit hypotheses. It seeks evidence while commitments are still small, defines what would reduce confidence and changes direction when the evidence no longer supports the original idea.

The other converts assumptions into a roadmap, secures resources and discovers the problem only after the initiative has acquired budget, people and executive identity.

Both teams were uncertain.

Only one designed the work to become less wrong before being wrong became expensive.

Camuffo and colleagues found that a scientific approach reduced the likelihood of continuing with false-positive opportunities while helping entrepreneurs avoid discarding potentially valuable ideas too early.[3] Later research has shown that such approaches can also produce more substantial strategic redirection by making alternative explanations and customer groups easier to consider.[6]

This is a more useful definition of innovation progress than activity or delivery speed.

The relevant measure is not how quickly the project moves through the process.

It is how effectively the process improves the next decision.

Learning from failure is not automatic

Innovation rhetoric often assumes that failure creates learning.

It does not.

A failed project may produce defensiveness, blame, a simplified story or a list of operational corrections that protect the original assumptions. A successful project may produce even less reflection because nobody feels an urgent need to question what happened.

Research in pharmaceutical R&D has found that organizations can learn from small failures, but the effect depends on the conditions under which those failures occur and are interpreted.[7] Failure provides information; it does not guarantee that the organization will use it well.

Experiments create the same problem. Their results are often noisy, multidimensional and open to interpretation. Emerging research suggests that decision-makers may respond more strongly to positive dimensions of ambiguous feedback, especially when the evidence contains conflicting signals.[8]

This means that running more experiments is not enough.

The organization must decide in advance:

• what it currently believes;

• what result would support that belief;

• what result would weaken it;

• what action should follow each outcome.

Without those commitments, experiments can become another source of retrospective storytelling.

The governance error

Most innovation governance is designed to approve work, not improve judgement.

Committees request plans, forecasts, milestones and expected returns because these make an initiative easier to compare with conventional investments. Teams learn that approval depends on confidence, so they present uncertainty as something already contained inside the plan.

Assumptions become forecast ranges. Experiments become pilots. Early possibilities become strategic priorities.

The governance system then evaluates the outcome without preserving a reliable record of what was known when the decision was made.

This is the organizational equivalent of seeing the final cards and pretending they were visible all along.

A better system would still care about outcomes. Outcomes matter because organizations cannot survive on elegant reasoning that never creates value.

It would simply refuse to use the outcome as the only verdict on the decision.

The free diagnosis is therefore complete:

Innovation leaders must judge two things separately: the quality of the outcome and the quality of the decision process that preceded it.

A good outcome can come from a weak decision. A bad outcome can follow a strong one.

Until governance can hold both truths at once, the organization will continue rewarding luck, punishing useful learning and scaling the wrong lessons.

If I had to reduce this article to a single formula, it would be this:

Innovation success ≈ decision quality × learning rate × adaptation capacity ± luck

The decision-quality review

Read more

“Give me ten ideas.”

It is probably one of the most natural ways to use GPT in innovation work. Add a market, a customer problem or a technology, ask for possible solutions and a few seconds later the screen fills with options.

Some are predictable. Others are surprisingly useful. Almost all of them are expressed clearly enough to create the impression that progress has been made.

I use GPT for this as well. There is nothing wrong with it. Generative AI is an excellent instrument for expanding a search space, combining familiar concepts and overcoming the uncomfortable emptiness at the beginning of a creative task.

The problem begins when the availability of ideas is confused with the reduction of uncertainty.

An innovation team does not become more likely to succeed simply because it can produce more plausible possibilities. It succeeds by discovering which possibilities deserve further commitment before the cost of being wrong becomes difficult to recover.

GPT has made the first part dramatically cheaper.

The second remains expensive.

The most obvious use is not necessarily the most valuable

The largest analysis so far of how consumers use ChatGPT examined 1.5 million conversations. It found that writing was the most common work-related use, while almost half of all messages involved asking the system for information, guidance or advice.[1]

This reflects the basic attraction of the technology. It can produce something immediately. A draft appears. A summary becomes available. A plan takes shape. An empty page is replaced by visible output.

In innovation work, the equivalent is ideation. A team can ask for customer problems, product concepts, business models, campaign ideas, experiment designs or alternative value propositions without organizing another workshop or waiting for inspiration.

Research supports the usefulness of this. Across five experiments, participants using ChatGPT produced ideas that evaluators rated as more creative than ideas generated without technological assistance or with conventional web search. The effect was particularly strong for ideas that were incrementally rather than radically new.[2]

Other studies have found a more complicated pattern. AI assistance can improve the average quality of individual ideas while making the collective pool of ideas more similar. In one experiment, generative AI improved individual creative output but reduced diversity across the resulting stories.[3] A later reanalysis of brainstorming experiments reached a similar conclusion: ChatGPT raised average creativity while reducing the variety of ideas available to the group.[4]

A large comparison published in 2026 examined more than 9,000 humans and over 215,000 observations from language models. Humans were only slightly more creative on average, but they showed greater variation and produced more of the exceptional ideas found at the top of the distribution.[5]

This does not make GPT a poor ideation partner. It makes it a particular kind of partner.

It is very good at rapidly producing coherent possibilities around a frame. It can improve an average response, combine established patterns and help a person search more broadly than they might alone. With careful human guidance, it can also produce solutions that compare favorably with human crowds in strategic viability and overall quality.[6]

What it does not automatically do is determine whether the frame is correct.

GPT answers the question inside the question

Suppose a team asks:

Give us ten ideas for an AI assistant that helps account managers prepare customer meetings.

The model can produce useful features: automated company research, stakeholder profiles, opportunity summaries, suggested questions, risk alerts, talking points and follow-up recommendations.

The result may be excellent.

It may also rest entirely on assumptions that nobody has examined:

• Account managers are insufficiently prepared.

• Poor preparation materially affects customer outcomes.

• The problem is caused by a lack of information rather than a lack of time, motivation or commercial judgement.

• Account managers will trust AI-generated preparation.

• They will change their current workflow.

• Customer and commercial data can be accessed legally and reliably.

• Better preparation will improve conversion, retention or account growth.

• The economic value will exceed the cost of integration, governance and maintenance.

GPT can generate the solution without testing any of these conditions.

That is not a defect. The model was asked to produce ideas, so it did.

The danger lies in how easily articulate output can make an untested premise feel more developed than it is. The idea now has features, a value proposition, perhaps even a name and a rollout plan. Each additional layer creates cognitive and organizational momentum.

The team begins discussing how the assistant should work before it has established whether the assistant should exist.

More plausible output can increase the cost of weak reasoning

Generative AI does not perform uniformly across every task. In a field experiment with consultants, AI improved speed and quality on tasks that fell within the model’s capabilities. On a task outside that frontier, people using AI were less likely to reach the correct answer.[7]

The important point was not merely that the model sometimes failed. Its capabilities were uneven in ways that users found difficult to recognize. A person could experience several impressive results, build trust in the system and then rely on it precisely where its performance became weaker.

The same problem appears in decision support. Experimental research has found that people can over-rely on AI advice even when it conflicts with contextual information and works against their own interests.[8]

Innovation creates particularly favorable conditions for this error because the correct answer is rarely available in advance as in any scientific field and approach. There is no answer key for a new market, an untested business model or a customer behavior that does not yet exist.

A confident recommendation can therefore survive for a long time without being proven wrong.

When GPT is asked to develop an idea, it helps the idea become more coherent. When it is asked to defend the idea, it can provide convincing arguments. When it is asked to create a business case, it can fill the familiar sections.

None of that is equivalent to evidence.

This becomes an organizational governance problem when innovation automation makes weak evidence easier to produce and package. A polished business case can pass a funding gate even though no external uncertainty has fallen.

The model may have improved the presentation while leaving the decision exactly as uncertain as it was before.

Innovation is not suffering from an idea shortage

Many organizations still design innovation work around the assumption that ideas are scarce.

They run challenges, workshops, hackathons and campaigns to generate more of them. Employees are encouraged to think differently, submit possibilities and explore what new technology might enable.

The resulting portfolios rarely fail because every idea was bad. They fail because too many ideas remain alive without earning their continued existence.

An idea gains a sponsor, a budget and a team. The team then becomes responsible for demonstrating progress. Evidence is collected inside a structure that already assumes continuation. Weak signals are interpreted optimistically because too much has become attached to the initiative.

GPT can accelerate this pattern. It makes it inexpensive to generate concepts, prototypes, narratives and business cases, but it does not make the later commitments reversible.

A prototype may now cost €5,000 instead of €50,000. The organization may still invest €2 million in scaling the wrong opportunity.

The economically important question is therefore not:

How cheaply can we create the next version?

It is:

What do we need to learn before the next commitment becomes justified?

This is where the best innovation prompt starts somewhere else.

Ask what would have to be true

Before asking GPT for ideas, features or strategies, ask:

What would have to be true for this opportunity to work?

The question changes the role of the model.

Instead of extending a preferred answer, GPT is asked to expose the conditions on which that answer depends. The output becomes an initial map of assumptions rather than a polished version of the idea.

The distinction matters because innovation decisions are rarely based on one large uncertainty. They rest on a system of beliefs about customers, behavior, technology, economics, distribution, regulation and organizational capability.

This is why business model validation must test the whole system. A change in acquisition, price, delivery, or customer behavior can invalidate assumptions that appeared credible when examined separately.

Some assumptions will be well supported. Others will be plausible but untested. A few may be carrying almost the entire risk of the opportunity.

The value of the question lies in making that structure visible.

Research on entrepreneurial decision-making supports the broader logic. In a randomized controlled trial, entrepreneurs trained to articulate predictions and test hypotheses more systematically made more precise decisions and were more willing to pivot when evidence challenged their original ideas.[9]

A larger replication involving 759 firms found that a scientific approach increased the termination of ideas and encouraged a more selective pattern of strategic change. The researchers argued that hypothesis-driven thinking increased “methodic doubt”: entrepreneurs became more aware that alternatives to their preferred explanation might exist.[10]

That is exactly the doubt that fluent AI output can otherwise remove too quickly.

The prompt is not the method

“What would have to be true?” is useful, but it is not a magic sentence.

GPT cannot tell you which assumptions are factually correct unless reliable evidence is available and supplied. It cannot interview customers, observe behavior or accept responsibility for an investment decision. It may overlook assumptions, invent evidence or rank risks according to a generic pattern that does not fit your situation.

Its role is to help make the reasoning inspectable.

The team still needs to decide:

• which assumptions are relevant;

• what evidence already exists;

• where the model is merely guessing;

• which uncertainty carries the greatest exposure;

• what could be tested;

• what result would change the decision.

GPT can support that work because it is patient, fast and capable of examining a proposition from several angles. It can ask uncomfortable questions without organizational status, sponsorship or sunk costs.

But it must be instructed to do so.

When asked to develop an idea, it tends to help develop the idea.

When asked to challenge the conditions beneath it, it can help the team think more scientifically.

The most valuable innovation prompt does not begin with the solution.

It begins with what the solution assumes.

Turn the idea into a decision

Read more

A colleague whose work I have followed for years recently described how he used AI to build a small interface for a task that an existing software product handled poorly. He did not wait for the vendor to improve its product or accept the friction as unavoidable. He described what he needed, worked with the model, evaluated the result and created something that made the task easier.

It was an impressive example of how generative AI can lower the cost and speed of turning an idea into a working tool. It would also be easy to draw the wrong conclusion from it.

The result was not useful because AI had made expertise unnecessary. It was useful because an expert was using AI.

He understood the work before he began. He could explain the problem, distinguish a relevant feature from an attractive distraction and recognize when the generated output failed to support the outcome he wanted. The visible production work became easier, but the judgement did not disappear. It moved into framing, directing, testing and deciding what was good enough.

This is the distinction many organizations are in danger of missing.

They see AI producing a report, a prototype, a summary, a strategy memo or a software interface and conclude that the task has been detached from the person who previously performed it. The output appears, often faster and at lower cost, so the expensive expertise surrounding it begins to look optional.

What they may actually have detached is the visible artifact from the invisible judgement that made it trustworthy.

AI is reaching work that was difficult to codify

Earlier waves of workplace automation were most effective when processes could be expressed through stable rules. A transaction met predefined conditions or it did not. A field was complete or missing. A machine followed a sequence that engineers had specified in advance.

Generative AI operates differently. It can draft, classify, synthesize, translate, code and propose options even when nobody has written an explicit rule for every possible input. That is why it is reaching occupations that previous automation affected less directly.

Research published in Science estimated that approximately 80% of the US workforce could have at least 10% of its tasks affected by large language models, while around 19% could see exposure across at least half of their tasks. Higher-income knowledge work is not protected; in many cases, it is more exposed.[1]

Exposure, however, is not the same as replacement. The same research evaluates tasks, not complete occupations. David Autor has made this distinction across several generations of automation: technologies substitute for some tasks while complementing others, changing the composition of jobs rather than simply eliminating an occupation in one move.[2]

This is where the managerial logic can become misleading. A company decomposes a role into visible tasks, tests which of them an AI system can perform and then calculates how many people it may no longer require. The analysis appears precise because tasks are easier to count than judgement.

A task list can show who drafts the document. It rarely shows who notices that the question behind the document is wrong.

The floor rises faster than the ceiling

One of the most important field studies of generative AI examined more than 5,000 customer-support agents. Access to an AI assistant increased productivity by 15% on average, but the benefits were distributed unevenly. Lower-skilled and less experienced employees improved substantially, while the most experienced and highest-performing agents saw little productivity improvement and a small decline in conversation quality.[3]

The study was conducted in one company and one comparatively structured occupation, so it should not be generalized to every form of knowledge work. Its pattern is nevertheless significant.

AI captured and distributed some of the practices associated with stronger performers. It helped less experienced employees move faster along the learning curve. That is valuable. It raises the floor of organizational performance.

Raising the ceiling is a different problem.

In a field experiment involving 758 consultants, participants using GPT-4 completed more tasks, worked faster and produced higher-quality results on assignments that fell within the model’s capability frontier. On a complex task outside that frontier, however, AI users were 19% less likely to reach the correct answer.[4]

AI did not become universally helpful because the users were intelligent or professionally trained. Its contribution depended on the task, the system’s capability and the user’s ability to recognize where that capability ended.

This creates an uncomfortable possibility for organizations. AI can make average work better while also making weak judgement harder to detect. The output becomes more polished, coherent and confident even when the reasoning beneath it remains incomplete.

The floor rises. The ceiling does not move automatically.

A(I)verage Land looks productive

A(I)verage Land does not look like technological failure. It looks efficient.

Reports are completed faster. Customer interviews are summarized within minutes. Presentations become more coherent. Campaign concepts appear in large numbers. Strategy documents use the correct language and follow a convincing structure. People who previously struggled to produce acceptable work can now produce it quickly.

This is real progress when the organization’s problem is inconsistent basic execution.

The strategic risk appears when similar companies use similar models to produce similar outputs from similar data. The efficiency advantage becomes a new operational baseline rather than a durable source of differentiation.

There is already evidence of this convergence in creative work. In an experiment published in Science Advances, access to AI-generated ideas improved the average quality and creativity of short stories, particularly for less creative writers. At the same time, the resulting stories became more similar to one another. Individual performance increased while collective diversity declined.[5]

This does not prove that every organization using AI will become strategically identical. A short-story experiment is not a corporate strategy process. It does show the mechanism behind the average trap: a tool can improve each individual output while narrowing the variation across the system.

That trade-off matters because organizations do not innovate by producing the largest number of acceptable answers. They need variation, dissent, contextual knowledge and unusual combinations from which stronger possibilities can emerge.

If AI helps everyone produce the most statistically plausible response, the organization may become more articulate without becoming more original.

Expertise does not disappear. It changes location.

The visible output is only one part of professional work.

A researcher does not merely produce a synthesis. The researcher decides which question matters, which evidence belongs in the analysis, which sources are credible and which anomalies should not be averaged away.

A strategist does not merely produce options. The strategist diagnoses the situation, recognizes trade-offs, understands organizational constraints and determines which uncertainty must be resolved before commitment.

A designer does not merely produce an interface. The designer understands the user’s job, the consequences of friction and the difference between a usable screen and a useful experience.

When AI performs part of the visible task, expertise moves into the surrounding system. It becomes more important in problem framing, context selection, exception handling, quality assessment and decision ownership.

The danger is that organizations see less visible expert labour and conclude that less expertise is required.

Research on automation bias has shown that people can accept incorrect automated advice, omit their own checks or stop searching for contradicting information. These effects occur among both inexperienced and expert users and are not reliably eliminated through simple instructions.[6] A 2024 behavioral experiment also found that participants followed AI advice even when it conflicted with available contextual information and their own interests.[7]

Over time, the risk extends beyond isolated errors. A longitudinal case study of an accounting organization found that reliance on cognitive automation weakened activity awareness, competence maintenance and the ability to assess outputs. The skill loss remained partly hidden until employees needed to operate without the system.[8]

The organization had not merely automated a task. It had allowed the capability to understand and verify the task to erode while human employees remained accountable for the result.

That is the road into A(I)verage Land: expert-shaped output expands while the organization’s ability to recognize when it is wrong begins to contract.

The job behind an AI investment

Leadership teams often frame AI adoption through the question:

Which tasks can we automate?

That question is useful for identifying efficiency opportunities, but it is too small for deciding how AI should change an organization.

The more consequential job is:

Help us increase the quality and reach of organizational judgement without losing the expertise required to recognize errors, exceptions and strategic alternatives.

Once the job is framed this way, the decision changes.

The objective is no longer to produce the same work with fewer experts. It is to remove the clerical and analytical drag that prevents expertise from being applied where it matters most.

An AI initiative remains operational when it only reduces the time or cost of producing an existing output. It becomes strategic when it allows the organisation to examine more evidence, consider more credible alternatives, detect weak assumptions earlier or make decisions that were previously too slow, fragmented or expensive.

Both forms of value are legitimate. Confusing them is not.

A company can become cheaper without becoming better. It can produce more without learning more. It can distribute expert-shaped language without distributing the judgement that gives that language meaning.

Before expanding an AI initiative, leaders therefore need to decide whether they are raising the floor, extending the ceiling or quietly removing the structure that holds the ceiling up.

The expertise separation test

Read more

Good writing takes real work to produce responsibly: checking facts, weighing conflicting evidence, deciding what actually matters, then rewriting the argument until a stranger to the topic can follow the reasoning without help. Journalists and independent writers cannot keep doing that work if readers expect the result to be free forever.

I can understand why a well-researched article should cost money (even using GenAI as co-writer). I have to admit, though, that I started myself using paywalls for my paid articles by simply copying industry standards blindly and always felt uncomfortable while placing them and where. I do not object to paying for writing. What bothers me, however—often even more than the price itself—is the product I’m apparently supposed to buy: an article behind the paywall that offers me little value.

I click a link because a headline raises a question I actually care about. The opening paragraphs set up the situation and get me invested enough to want the answer. Then the article simply stops. A paywall appears, and to continue I am asked to subscribe to an entire publication, even though I may have arrived because of one specific question and might not return for weeks.

From the publisher’s side, this looks like an article and a potential subscriber. From mine, it looks different. I did not click because I wanted access to an article. I clicked because I wanted help understanding something I did not yet understand. I may want to know why an industry is shifting, whether some new technology actually matters, or how a political decision will ripple through a wider system. In my own professional reading, I am usually trying to understand a subject well enough to connect it to what I already know, notice its implications, and make a sharper judgment call at work the next day.

The job I am hiring the article for is rarely “help me finish this article.” It is closer to something like: help me understand this subject in its wider context, connect it with what I already know, and become better able to judge what it means. That distinction changed how I think about paid writing, and it points to a broader product lesson than any single paywall decision.

Products Are Visible. Jobs Are Not.

Clayton Christensen and his colleagues argued that customers hire products and services to make progress in a particular circumstance.[1] Someone buys a drill, but the drill was never the desired outcome. Someone enrolls in a course, but sitting through lessons is not the progress they were after. Someone commissions a report, though owning another document was rarely the real objective.

Jobs to Be Done asks us to look past the visible transaction and into what is actually happening in the customer’s life at the moment they choose a product. What progress are they trying to make? What are they using instead right now? What has made the situation uncomfortable enough that they are willing to change their routine or spend money to fix it?

This sounds obvious until you try applying it to your own work. Companies describe what they produce almost by reflex. Software firms sell platforms. Consultants sell projects. Trainers sell workshops. Publishers sell articles and subscriptions. Internal innovation teams offer methods, processes, and support. Customers, though, rarely experience any of that as the job itself. They might be trying to avoid an expensive mistake, build confidence before committing to something bigger, settle a disagreement, cut down the time it takes to understand a complicated situation, or become capable enough to handle similar decisions without outside help the next time.

When the product and the job get confused, teams keep improving the thing they produce while the customer’s actual progress barely moves. A publisher writes more articles. A course adds more lessons. A software company bolts on more features. A consultancy hands over a thicker report. The customer ends up with more product, not necessarily more progress.

The Trouble With the Single-Article Paywall

A paywall can make perfectly good commercial sense. Journalism needs revenue, and outlets with distinctive reporting, a strong reputation, or an established reading habit among their audience can reasonably ask readers to pay for continued access.

Still, the wider market shows how hard this has become. The Reuters Institute’s 2026 Digital News Report found that the share of people paying for online news across the twenty countries it tracks held at 17 percent, and personal benefit was cited more often than any sense of civic duty toward journalism, though both played some role.[2] A separate study of 42 newspapers that introduced paywalls found daily page views fell by roughly 30 percent on average, with the size of the drop depending on the publication and how distinctive its content actually was.[3] A paywall can still lift revenue even as it costs a publication a third of its readers, but the pattern is telling: plenty of readers respond to a paywall by simply leaving, not by paying to stay.

It would be a mistake to conclude from this that readers just refuse to pay for knowledge. People spend real money on books, professional education, training, conferences, consulting, coaching, specialist software, and communities, all the time. They pay when they believe the offer will help them make progress that actually matters to them. The conventional single-article paywall usually makes a weaker case than any of those. It asks the reader to pay because the publisher has stopped granting access, not because a new and more valuable job is about to begin. The payment removes an obstacle. It does not, by itself, improve the outcome.

That was the discomfort I eventually had to admit about my own writing. I was trying to build a modest income from work that takes real effort, and yet I had backed into a model where the paid benefit was simply “the article keeps going.” I could justify why I needed to get paid. I had not yet explained why the reader should want to pay. Those turned out to be two very different questions.

Readers May Be Buying an Educational Journey, Not an Article

An article is a fine delivery format. It can raise a question, build an argument, and expose a reader to evidence they would not otherwise have encountered. But one article rarely builds real capability on its own.

When I pay for serious professional writing, I am not really after another piece of information. I want each piece to add something to what I already understand, to surface connections I had not noticed, to challenge an assumption I have been quietly carrying into my work, and to gradually sharpen the questions I know how to ask. The value is supposed to accumulate. The tenth article should be worth more than the first, precisely because I have read and applied the previous nine. Concepts should start to connect. Distinctions that once blurred together should become easy to tell apart. Examples pulled from different industries should build into a kind of repertoire I can reach for the next time an unfamiliar problem shows up.

Seen this way, the reader is not really buying access to a pile of articles. The reader is investing in an educational journey. The immediate job might be understanding one topic in its wider context. The longer job is becoming more capable of making sound judgments in that domain over time.

That reframing widens the competitive field considerably. A publication built around that job is not competing only with other newsletters or newspapers. It is competing with business schools, executive education, professional training, workshops, consultants, coaches, books, conferences, specialist communities, AI assistants, and plain lived experience. These alternatives look nothing alike on the surface, yet a reader might hire any of them for roughly the same underlying progress: help me understand situations I will keep running into at work and get better at handling them. That is a considerably higher bar than producing premium content.

Information Gets More Valuable Once It Enters the Work

Bloomberg is a useful example here precisely because it operates deep inside the information business without treating the single article as its core unit of value. Financial professionals can get news, market data, and company announcements from plenty of sources. Bloomberg instead weaves news together with data, analytics, communication, and tools, right inside the workflows where people actually investigate situations and make decisions. The company frames its news product around turning insight into action, not around producing more stories.[4]

The lesson here is not that every publisher should go build a terminal. Bloomberg serves a specialized institutional market at a scale that has almost nothing in common with independent writing. But there is a narrower, transferable idea underneath it: once information becomes abundant, paid value can shift from controlling access toward helping people actually use that information.

Research on service and value creation backs this up. Value is not simply manufactured by a provider and handed intact to a passive customer. It emerges in use, inside the customer’s own context, and it can be strengthened further through the interaction between provider and user.[5][6] An article can carry good research and an original argument, but its real value only shows up once a reader uses it to make sense of a situation, question an assumption, or change a decision they were about to make.

Which suggests the paywall might simply be sitting in the wrong place. The free article can do the intellectual work of helping a reader recognize and understand a problem. The paid product can start where the reader wants to apply that understanding, connect it to what they already know, and build better judgment through practice. A paywall should not charge someone to resume a journey that got cut off mid-sentence. It should mark the start of a different one.

A Test for Whatever You Are Selling

(I hope this is a fair place to put the paywall after you got enough value and insights)

Read more

That interpretation is too neat.

Netflix did not replace one business model once. It repeatedly changed whichever element was becoming the constraint on its next stage of growth.

Subscription removed transaction friction. Streaming removed physical distribution. Device partnerships expanded access. Originals reduced dependence on licensed content. Global expansion increased reach. Advertising, paid sharing, games and live programming created new forms of engagement and revenue.

Each adaptation solved a constraint. Each also created another.

The familiar story hides the more useful pattern

The familiar Netflix story moves cleanly from DVD rental to streaming. It is attractive because it compresses a complicated history into one decisive strategic move.

But the transition to streaming did not complete the transformation. It changed the constraint.

Physical distribution became less important, but access to licensed content became more important. Original programming reduced part of that dependence, but required larger and less reversible content commitments. Global expansion increased the potential market while introducing localisation, regulation and content-production complexity.

More recently, slowing subscriber growth moved the constraint again. Netflix responded with an advertising tier, tighter household access, games and live programming. The problem was no longer simply how to reach more viewers. It was also how to capture more value and increase engagement from the audience already within reach.

Four phases of adaptation

1. Remove transaction and distribution friction

The original subscription model replaced individual rental decisions, due dates and late fees with recurring access. Streaming then removed the delay and cost of physical fulfilment, while device partnerships made the service available beyond the computer.

2. Reduce dependence and differentiate the offer

Streaming gave Netflix a new channel, but much of the value still depended on content owned by others. Original programming made the service more distinctive and gave Netflix greater control over availability, timing and global distribution.

3. Expand the addressable market

International expansion turned Netflix from a US service into a global platform. This increased potential scale but required local content, language capabilities, market knowledge and a much more complex production system.

4. Expand engagement and revenue capture

Games broadened the entertainment proposition. Advertising introduced advertisers as a second customer group. Paid-sharing rules converted part of informal access into revenue. Live programming added urgency, appointment viewing and additional advertising inventory.

Three lessons from the case

1. Continuous adaptation includes reversals

Qwikster belongs in the chronology because business-model adaptation is not a clean sequence of correct decisions. Netflix separated DVD and streaming pricing, proposed a separate service and then reversed the brand split after encountering strong contrary evidence.

The reversal was not separate from the adaptation process. It was part of it.

2. Removing one constraint creates another

Streaming reduced fulfillment friction but increased dependence on licensed content. Originals created differentiation but increased fixed commitments. Global scale increased reach but also increased localization complexity.

Business-model adaptation rarely eliminates uncertainty. It relocates it.

3. The object of adaptation changes over time

Netflix initially changed how customers accessed and paid for entertainment. Later changes increasingly concerned content ownership, market scope, engagement and revenue capture.

The relevant question was not simply whether the existing model still worked. It was whether it could support the company’s next stage of growth.

Future cases will examine Adobe and other organizations that changed their business models as old assumptions became constraints. Subscribe for source-backed cases, strategic interpretation and practical decision tools.

Netflix — Continuous Business Model Innovation, Case 01

54.7KB ∙ PDF file

Download

A two-page, source-backed chronology of fourteen business-model adaptations, including a Business Model Canvas View, Core Pattern and Strategic Tension.

Download

What would you challenge?

Which Netflix adaptation created the most consequential new constraint?

I am particularly interested in interpretations that challenge the chronology, the business-model elements I assigned or the core pattern I identified.

Use this case with your team

I am developing Continuous Business Model Innovation as a format for executive briefings, strategy off-sites, workshops, bootcamps and teaching.

The purpose is not to copy Netflix. It is to help a team determine which part of its own business model has become a constraint, which assumptions require evidence and what should be tested before committing further resources.

If your organization is facing such a decision, send me the concrete situation you are working through.

This visual reflects my personal interpretation of Netflix’s business-model adaptations based on available public data and public sources. Netflix and related marks are trademarks of Netflix, Inc. This independent analysis is not affiliated with or endorsed by Netflix.

This morning I read a piece on SRF about a team at ETH Zürich that has spent nearly a decade building a chip to fight deepfakes. The chip sits directly on a camera sensor and generates a cryptographic signature the moment an image is captured. Anyone who alters the image after the fact invalidates the signature. Felix Franke, the professor leading the project, says he saw the problem coming ten years ago and decided to work on it rather than wait for someone else. The chip is still a prototype. The problem it addresses is not.

That piece landed differently than most I have read on the subject. Not because the technology surprised me. I have watched deepfakes improve steadily for years, and the trajectory is not subtle. What struck me was the framing: authenticity now needs to be verifiable at the hardware level, because human eyes passed their useful detection threshold some time ago.

My spam folder has been telling me the same story. What used to arrive as obviously fraudulent, misspelled names, impossible offers, transparent pretexts, has gradually become more careful. Some messages now use language calibrated to sound like a colleague, a trusted institution, or a service I actually use. The writing has gotten better. The targeting has improved. The cost of producing a convincing fake has dropped, and the volume has gone up. That combination is not an accident. It is the signature of a business model that found a technology it could use.

The question that tends to get avoided

Whenever deepfakes come up in public discussion, the conversation lands quickly on the technology: how realistic it is, how fast it is improving, whether detection can keep pace, and what regulators might eventually do. Those are reasonable questions. But there is a prior one that gets less attention.

Who owns a person’s face, voice, image, and identity? And who gave anyone else the right to use them for advertising, content, entertainment, fraud, or profit?

The law is genuinely unclear in some places. Enforcement is weak in others. Platforms move slowly, and by the time a policy is updated, the next version of the tool has already changed shape. But the basic question is not that complicated. It is about consent and about who carries the cost when something goes wrong. Creating fake celebrity investment pitches is not a gray area. Cloning someone’s voice to run a financial scam is not a gray area. Generating non-consensual images of real people is not a gray area. The law may be slow. The moral position on those cases was never unclear.

Neutral at the level of physics. Not at the level of the market.

We reach for “technology is neutral” because it feels true and because it lets us avoid harder questions. A camera does not decide whether it documents a family trip or records someone who never agreed to be filmed. A microphone does not decide whether it captures a podcast or a private conversation. An AI model does not decide whether it helps a student understand a concept or helps a fraudster replicate a trusted voice.

At the level of physics, yes. Neutral.

But once someone builds a business model around a technology, the neutrality ends. A business model decides who is served, who pays, who benefits, and who has no say in the matter. It translates capability into incentives. And incentives decide what gets built next, what gets repeated, what gets funded, and what gets scaled. The technology is the capability layer. The business model is the behavior layer. That distinction is what makes the deepfake conversation actually useful.

The productive version of this pattern

We know this mechanism from disruption, and its constructive form is not hard to describe. A new technology lowers the cost of something. A business model forms around that lower cost. The initial offer is simpler, less polished, and less profitable than what established players sell, so they ignore it. The margins are thin. The customers look marginal. The use case seems narrow. The new entrant serves those customers anyway, learns faster than anyone expected, and gradually improves until it reaches a market incumbents actually care about.

Christensen’s work on disruption describes exactly this: a simpler, cheaper, more accessible offer that reaches people who were overserved, underserved, or excluded entirely. The technology alone does not disrupt. The model around it does.

At its best, this serves society in a straightforward way. Lower cost enables a different offer. The different offer reaches people who were previously locked out by price, geography, or the complexity of the incumbent product. They do not need the full package. They need the job done well enough at a cost they can actually afford. That is not a compromise. That is progress.

The same engine, pointed differently

The mechanism does not care about intent. The same economic logic that powers useful disruption can power harmful extraction, and the structure looks nearly identical from the outside. A new technology lowers the cost of something. A business model forms around the reduced cost. The first version is rough but good enough for the target market. In this case, the target market is not underserved customers with a legitimate need. It is people who can be deceived, pressured, or defrauded before anyone notices.

Deepfakes fit the pattern precisely. The positive business model is real: better dubbing, accessible education, synthetic video for people who cannot appear on camera, language translation at scale, creative production at lower cost. These create genuine value for actual users. The harmful business model uses the same underlying capability to produce fake celebrity investment pitches, voice clones for financial fraud, synthetic identities for automated ID checks, and non-consensual images of real people. One side creates value with consent. The other extracts value from victims. The technology in both cases can be similar. The business model is not.

What makes harmful models economically durable is that they do not require repeat trust. A legitimate company needs customers to return. A fraud network needs one successful transfer, one click, one moment where a tired or distracted person fails to notice something is off. That asymmetry changes the economics entirely. The product does not need to be good. It needs to work once, on enough people, to generate a return. That is a far lower bar than building something people actually want.

Platforms are not passive pipes

This gets sharper when platforms enter the picture. A platform that profits from attention will optimize for what holds attention. A platform that profits from trust will protect trust. A platform that profits from frictionless distribution may find friction inconvenient, even when friction is what protects people from the content that travels fastest.

Shoshana Zuboff’s work on surveillance capitalism names the underlying incentive structure: a logic built around data extraction, behavioral prediction, and continuous experimentation. You do not need to accept every part of that argument to see the core point. If the system earns more when behavior becomes more targetable, the system is not neutral in practice. It favors what can be captured, measured, and monetized. In the best case, that produces convenience and relevance. In the worst case, it rewards manipulation at scale, because manipulation at scale is efficient.

The same question shows up in recruiting

AI in hiring shows the same split clearly enough to name. AI can help candidates write sharper applications, help teams handle large volumes, reduce repetitive administration, and surface patterns that manual review misses. That is the legitimate version.

The other version is an automated rejection machine with a professional interface. Hilke Schellmann spent years investigating exactly this in her book The Algorithm, documenting how AI hiring tools screen people out without explanation, hide weak assumptions behind a score, and make bias look technical. The research backing her findings is substantial: studies have repeatedly shown that algorithmic screening rewards candidates who know how to write for machines rather than candidates who can do the work, and that the systems encode the biases of whatever historical data they were trained on. Hiring gets faster. Accountability gets weaker. The EU AI Act classifies AI hiring tools as high-risk systems and requires human oversight, transparency, and a meaningful right to review for exactly this reason. Whether companies are meeting that bar in practice is a separate question, and a more interesting one.

Regulation arrives after the business model has already learned

Technology moves through experimentation. Business models move through incentives. Regulation moves through language, negotiation, enforcement, and courts. By the time a rule defines one harmful pattern clearly, the next version has already changed shape. That does not make regulation useless. It is necessary. But a label does not undo a business model built on manipulation. A watermark does not help much when the model depends on speed, scale, and low accountability. A consent checkbox does not make power symmetrical.

Regulation sets limits. The first decision still sits with the people building, funding, deploying, and monetizing the system.

Who actually decides

AI does not decide to scam pensioners with fake investment videos. AI does not decide to clone a voice for fraud or generate non-consensual images of a real person. People decide. Teams decide. Founders decide. Investors decide. Platforms decide what they tolerate. Boards decide what risks they accept.

The owner of the business model makes the real choice. And the business model reveals the real judgment, more clearly and more honestly than any mission statement, ethics policy, or press release.

So before adopting or funding any AI capability, the question is not whether you can use it. The question is what behavior becomes cheaper when you do, who benefits from that behavior, and who absorbs the cost when it goes wrong. That is what the ETH chip is really trying to answer at the hardware level: can we build a system where accountability is structurally unavoidable, rather than optional?

The invention opens the door. The business model decides what walks through it, and whether you can explain that decision in public three years from now.

Leave a comment

I’m currently reading one of those bestselling books that promises to explain how people should work with AI, and I have to admit that one part of it is hard to argue with. Large language models really are impressive creative partners. They can throw out ideas, variations, objections, concepts, and competitor moves faster than any workshop room full of smart people ever could, and in innovation work that speed is not a small thing.

I’d go further than the book does, honestly. AI is genuinely useful in the divergent phase of a problem, when you’re still trying to frame a situation, generate hypotheses, and figure out what struggles your job performers actually have. It widens the search space in a way a Tuesday afternoon workshop rarely manages, especially once you notice that most workshop rooms are filled with people from the same company, carrying the same incentives, the same vocabulary, and the same unspoken assumptions about what a good idea looks like.

It’s just as useful on the solution side. Ask it for analogies from other industries, prototype directions, business model variants, or the uncomfortable question nobody on the team wants to raise, and it delivers something usable within seconds. And it doesn’t stop at divergence. Feed it a stack of interview notes and it finds patterns you missed. Give it a pile of problem statements and it sorts and compares them. Hand it messy workshop material and it turns it into something structured enough to actually discuss, instead of a wall of sticky notes nobody wants to revisit.

It can even help you build something fast enough to test whether a solution offers real relief, and whether people would switch and pay for it, without pulling your best engineers off their real work or spending a serious budget on something that only exists to test problem-solution fit. Used deliberately, that’s a genuine accelerant.

AI can widen the room, but…

I’ve run experiments like this myself, and the claim holds up. With the right prompting, you can pull a broader, weirder set of ideas out of a model in twenty minutes than a group of well-meaning colleagues produces in an afternoon. You can ask it to argue the case as a skeptical buyer, a tired frontline employee, a regulator, a procurement manager, or a CFO with zero patience for elegant nonsense. You can also ask it a less comfortable question: how would our sharpest competitor attack this idea and make our life difficult? That’s a genuinely useful exercise, and most teams never bother to run it with a human, let alone a machine.

One prompt is not serious thinking

None of that makes it magic, though, and one prompt is not serious thinking. The value doesn’t come from typing a clever instruction and waiting for the model to reveal the future. It comes from pressure and iteration: squeezing out the obvious answers first, then forcing the system into less comfortable territory by changing the role, the constraint, the time horizon, or the failure mode you’re asking it to consider. That isn’t so different from a good ideation workshop. It’s just faster, cheaper, and doesn’t require booking ten calendars and ordering sandwiches.

The research on this is genuinely mixed, which I find reassuring rather than annoying. Some studies show large language models outperforming average human participants on divergent thinking tasks. Other work suggests that while AI assistance can lift an individual’s creative output, it quietly narrows collective diversity, because everyone ends up drawing from similar machine-generated patterns.[1] So the honest conclusion isn’t “AI is creative” or “AI kills creativity.” It’s something less quotable: AI expands ideation when it’s used deliberately, and homogenizes thinking when it’s used lazily.

Synthetic answers are still answers, not decisions

There’s a further point I think gets glossed over too quickly. Even a genuinely useful synthetic answer is still just an answer, not a judgment and not a decision. A model can give you a plausible view on users, jobs, solution directions, channels, pricing, objections, or adoption barriers, and it can do it fast. Sometimes that first answer is surprisingly sharp. Sometimes it only sounds sharp because the language is smooth. Either way, it’s built on probability rather than truth. It predicts what’s likely to fit your prompt and the pattern behind it, and that’s simply a different thing from being real, or relevant, or being decision-grade.

So the judging stays with you. You decide whether the synthetic customer response is plausible or lazy, whether the proposed job is specific enough to act on, whether the solution candidate actually addresses the struggle you set out to solve, whether the channel makes sense, whether the pricing logic deserves a real test, and whether the whole thing is strong enough to justify the next commitment or too thin to trust. None of that responsibility shifts to the machine just because the machine got faster. If anything it gets heavier, because the bottleneck has quietly moved from producing options to judging them. You were never short on answers. The question was always whether you knew what a strong enough answer looked like.

Where the argument breaks

This is where the book, and the argument in general, starts to bother me. Not because it overstates what AI can do, which is common enough by now, but because of the way it quietly treats innovation as though it were mostly about invention, creativity, and idea generation. It isn’t. I’d be far less bothered by this framing coming from a generic technology enthusiast. When it comes from people who teach innovation and entrepreneurship for a living, the shallow definition is harder to let slide. If we keep teaching innovation as creativity and idea generation, we shouldn’t be surprised when companies keep reducing it to workshops, sticky notes, prototypes, pitch decks, and demo days. The misunderstanding starts upstream, long before anyone opens a prompt window.

Ideas are inputs, not the work

Ideas are inputs. They are not the work. Innovation is the disciplined work of turning uncertainty into evidence-backed businesses, and in my experience it rarely fails because nobody had an idea. It fails because teams commit to weak opportunities, because they can’t turn a promising idea into a working business, because they build around a problem they never really understood, and because internal enthusiasm gets mistaken for market evidence. It fails because nobody wants to stop a project once it has a name, a sponsor, a budget line, and a slide template of its own. It fails when users, quite reasonably, don’t want to switch and don’t want to pay, and are perfectly content staying with whatever they already use. And sometimes it simply fails on the numbers, when the opportunity can’t generate enough financial throughput to justify the investment, the team, the sales effort, the marketing spend, the partnerships, or the next funding round. That’s where the easy story ends, and where the real work of innovation begins.

The work nobody wants to own

This is the part of entrepreneurship nobody particularly wants to own. Someone has to lead when things get uncomfortable. Someone has to push when the evidence is weak but the internal politics are strong. Someone has to spot when a pivot is overdue, and go find the alternative. Someone, eventually, has to kill a project, and has to have already tested the financials, the sales model, the marketing logic, the supply chain, the legal constraints, and the business model sitting underneath the product. None of that is the glamorous part of the job. It is, however, the actual job, and AI doesn’t fix it. If anything it can make it easier to avoid, because once idea generation gets cheap, a company can produce polished uncertainty at scale: concepts, opportunity areas, prototype directions, synthetic customer quotes, strategy language, plenty of activity that looks intelligent from a comfortable distance. None of it answers the harder questions underneath.

The questions ideation cannot answer

Does this opportunity matter enough? Who exactly has the problem, and is it urgent, frequent, expensive, or strategically important to them? What are people doing today instead, and what would actually trigger them to look for something better? Who pays, and why would they? Can you deliver the value at a cost that still makes sense, and can you capture a fair share of the value you create? What has to be true for this to become a real business rather than just an interesting product? Ideation, however good, cannot answer a single one of those questions, and the work of answering them starts well before anyone generates a solution.

Innovation starts before solutions

Before a team starts producing solutions, it has to earn the right to ask about them, which means looking honestly at what’s shifting in the market, the technology, the regulatory environment, cost structures, and competitive pressure, and asking whether there’s a real opening rather than just a fashionable theme. Then comes the user research, and I mean real user research, not a courtesy round of interviews run after the idea is already loved internally. The point of that research is to understand the job performers themselves: their struggles, their context, their constraints, the workarounds they’ve already built, and the outcome they’re actually trying to reach. You aren’t there to ask whether people like your idea. You’re there to understand the progress they’re already trying to make, and where their current options are failing them. Only once you’ve done that can you write a problem prompt that’s grounded in the field rather than in your own enthusiasm. Skip that step, and ideation becomes random noise dressed up as productivity, because a model will always produce something, whether or not you’ve earned the question you asked it. A fluent answer to a weak problem is still a weak answer.

Once the problem is real, AI becomes useful again

Once the problem is real, AI earns its place back in the process. It can explore solution candidates, suggest analogies from other industries, generate business model options, surface hidden assumptions, and play the competitor, the buyer, the skeptic, or the regulator on demand. It can help design tests and expose where a team is quietly hiding risk behind attractive language. What it still cannot do is validate the market for you, or replace real evidence with a convincing simulation of it. Sooner or later the team has to leave the prompt window and confront reality directly, through interviews, observations, smoke tests, landing pages, concierge tests, prototypes, pilots, pricing conversations, channel tests, sales friction, procurement delays, implementation cost, usage data, and churn. Innovation isn’t proven by how elegant the concept sounds. It’s proven by the quality of the evidence sitting behind the next commitment.

The business model is not an appendix

Which is why the business model can never be an appendix, and this is exactly the part that gets lost when innovation is reduced to ideation. A product without a working business model is a shallow answer to a real problem. It might create value for someone, but it doesn’t yet explain how that value gets delivered, paid for, defended, or captured, and that distinction is bigger than most pitch decks admit. A clever product can still be a bad business. A genuinely desirable feature can still be impossible to sell. A real user problem can still sit inside a market that’s too small, too fragmented, too regulated, too slow, or too expensive to serve well. A prototype can impress a room full of people and still tell you almost nothing about willingness to pay.

This, to me, is where the actual work of an innovator sits. Not in being the most inventive person in the room, not in producing the longest list of ideas, and not in running a workshop that makes everyone feel briefly creative. The core job is to connect the opportunity, the customer evidence, the solution design, the business model logic, and the investment decision into one coherent case, and to know what has to be tested before resources scale, what deserves another round of learning, and what should simply stop. If you don’t feel responsible for the business model, you’re not really doing innovation. You’re contributing to an invention pipeline, and that pipeline may still be useful, but it isn’t enough on its own.

What AI should actually be used for

So here’s where I’d position AI more honestly than the book does. It is not an innovation machine. It’s a leverage tool inside innovation work, and a genuinely good one. It can widen the search space, narrow it back down, generate alternatives, build opposing hypotheses, and simulate the perspectives missing from your room. It can translate a vague idea into a testable assumption, compare solution candidates, and draft interview guides, test plans, prototype variants, and business model options faster than any of us could alone. All of that is valuable. None of it should be mistaken for customer evidence, strategic judgment, or commitment quality. AI can help you think, help you see your options, and help you pressure-test a direction before you spend real money on it. It cannot take responsibility for the decision itself, because that was never its job.

The better leadership question

Which is why I think leaders are asking the wrong question. The question isn’t how AI can help a company generate more ideas. It’s where AI can help reduce uncertainty before resources get committed. That single reframe changes what AI is for. It pulls the technology away from brainstorming theater and toward learning discipline, and it quietly raises the bar for every innovation team using it. If idea generation is now fast and cheap, there’s less excuse for lazy opportunity work, weak assumptions, or building something because the concept looked good in a workshop. There’s less excuse for treating a prototype as progress when the business logic behind it is still missing. The loss here is real and worth saying plainly: attractive ideas will sometimes have to be killed before they turn into protected, well-funded projects. That isn’t a failure of innovation work. Done honestly, that is innovation work.

The real implication

AI makes ideation easier, and that’s genuinely useful. But innovation was never short on ideas. It fails when teams commit too early, validate too late, misunderstand the job to be done, ignore the business model underneath the product, and mistake activity for progress. AI doesn’t remove the judgment problem sitting at the center of all this.

It just makes it impossible to hide.

Leave a comment

The decision for boards and CEOs is no longer whether AI can speed up innovation and transformation work.

It can.

The better question is what that speed is being used for.

Is the organization reducing uncertainty, or is it only producing more convincing artifacts around uncertainty?

That distinction matters because the cost of producing things has fallen faster than the cost of choosing well. Prototypes, plans, research summaries, workflows, code, business cases, customer personas, pitch decks, and strategic options can now be generated at a volume most organizations are not designed to evaluate.

This changes the work. It does not remove the hard part.

The hard part is still deciding what problem matters, which assumption carries the risk, what prediction would actually improve the decision, and what evidence is strong enough to justify commitment.

That is the shift leaders need to see.

In many firms, the bottleneck is no longer the first version.

It is judgment.

AI lowers the cost of prediction, not the cost of being right

Agrawal, Gans, and Goldfarb make in their book Power and Prediction a useful distinction that many AI conversations still miss.

AI is prediction technology.

Prediction is not only about forecasting next quarter’s revenue or tomorrow’s demand. Prediction means using information you have to generate information you do not have. Is this customer likely to churn? Is this image showing damage? Is this transaction suspicious? Is this lead worth attention? Is this prototype likely to solve a real customer problem?

That is powerful.

But prediction is only one input into a decision.

A prediction does not tell you what outcome matters. It does not tell you which error is acceptable. It does not tell you whether speed is worth the risk. It does not tell you who carries the consequence if the decision is wrong.

That part is judgment.

And when prediction gets cheaper, judgment does not disappear. It becomes exposed.

A company can now produce more options, more simulations, more concepts, and more apparent evidence than before. But if nobody has defined the payoff, the trade-off, the acceptable loss, or the decision threshold, the organization has not become more intelligent.

It has become faster at generating undecided work.

More output does not mean more progress

A lot of organizations are mistaking lower production cost for progress.

The mistake is understandable. The outputs look credible. They arrive fast. They create momentum. A team can generate a market scan in an afternoon. A prototype can appear before the problem is understood. A board deck can look mature before the critical assumption has been tested.

This feels like acceleration.

But movement is not learning.

Right now, teams can create more options than they can evaluate. They can generate more scenarios than they can absorb. They can produce more answers than the organization has the discipline to challenge.

That sounds efficient.

It can also become expensive.

Because when output gets cheaper, weak thinking scales too.

The risk is not only that AI produces bad answers. That is the simple version. The deeper risk is that AI produces plausible work around weak questions.

A concept can look ready before the market risk is clear. A prototype can feel like evidence when it is still only a technical demonstration. A strategy can sound aligned because the language improved, while the underlying disagreement stayed untouched.

That is not transformation.

That is acceleration without enough judgment.

The scarce thing did not disappear

The common story says AI removes the need for expertise.

That is the wrong reading.

AI removes part of the friction around prediction, production, and execution. That matters. It can be enormously useful. It can help people draft, compare, summarize, classify, simulate, and generate. It can make early exploration cheaper. It can allow smaller teams to do work that once required more time, money, and coordination.

But it does not remove the need for diagnosis.

It does not remove the need to define the decision.

It does not remove the need to decide what kind of evidence should count.

In fact, it may make those tasks more important.

When a team can generate ten credible options in the time it once took to create one, the value no longer sits in producing option eleven. The value sits in knowing which option deserves attention, which one is attractive but hollow, and which one should be stopped before it starts consuming resources.

This is where many leadership teams still lag.

They ask whether people are using the tools.

They ask whether the organization is moving faster.

They ask whether productivity is improving.

These are not bad questions. They are just incomplete.

The harder question is:

What part of our uncertainty did this actually reduce?

If that question has no clear answer, the organization is probably producing artifacts, not evidence.

The decision must come before the tool

This is the more useful starting point for boards and executive teams.

Do not start with the technology.

Start with the decision.

What exactly are we trying to know before we commit more money, more people, more credibility, or more organizational energy?

Which assumption is most dangerous if we are wrong?

What prediction would improve this decision?

What evidence would change our next move?

Who has the authority to stop, continue, or scale based on what we learn?

These questions force AI back into its proper role.

The tool is not the strategy. It is not the judgment. It is not the decision. At best, it lowers the cost of learning something useful before commitment.

If it does not do that, it may still be impressive.

But it is mostly decorative.

This is where transformation work often goes wrong. Organizations use new technology to speed up familiar routines, but they do not change how choices are made. They automate production, but not reflection. They improve the flow of output, but not the quality of the questions upstream.

So visible activity rises.

The business effect stays thin.

The problem is not always that the technology is weak. The problem is that leadership applies it to the wrong layer. It speeds up what was already happening instead of raising the standard for what deserves to continue.

Cheap prediction changes workflows, not only tasks

One of the stronger ideas in Power and Prediction is that the deeper effect of AI is systemic.

The first wave of adoption usually improves tasks. A person writes faster. A support agent responds better. A developer gets help with code. A marketer generates variants. A product team summarizes interviews.

That is useful.

But the bigger change comes when cheaper prediction alters workflows and systems of interdependent decisions.

If you can predict demand earlier, inventory logic changes. If you can predict failure earlier, maintenance logic changes. If you can predict customer intent earlier, sales and service logic changes. If you can predict risk differently, governance changes. If you can generate and test options faster, innovation governance should change too.

But that only happens if leaders redesign the system around the new economics.

Otherwise, AI is simply poured into yesterday’s workflow.

That is the danger in a lot of transformation programs. They use AI to make the old system faster, but not necessarily smarter. The company gets more output from the same assumptions, the same approval logic, the same politics, and the same weak criteria for commitment.

In that case, AI does not transform the organization.

It industrializes its habits.

Three diagnostic questions for leaders

The most useful leadership questions are not about tool adoption.

They are about decision quality.

Are we using AI to test assumptions faster, or to create the appearance of progress faster?

Which parts of this initiative still require direct market proof, operational proof, or real customer behavior?

Where are we treating polished output as if it were evidence strong enough to justify scaling?

These questions are simple, but they are not soft.

They reveal whether the organization is learning or performing.

They also reveal whether leadership is willing to make judgment explicit. What are we trying to predict? What decision depends on it? What would we do differently if the prediction changed? What is the cost of being wrong? Which option are we willing to stop?

Without that discipline, AI becomes another productivity layer on top of unclear choices.

What matters now

There is a real reason to be encouraged.

More people can explore serious ideas without waiting for permission. More teams can make things tangible earlier. More expertise can be turned into usable experiments. More assumptions can be surfaced before large commitments are made.

That is good.

But the promise only holds if leaders protect the one thing the tools do not automatically improve.

Judgment.

The next advantage will not belong to the company that generates the most.

It will belong to the company that knows what not to believe too early.

The company that uses speed to expose weak assumptions before they harden into plans.

The company that treats AI as a way to sharpen choice, not as a way to avoid it.

That is the standard worth raising now.

Use the tools. Learn them properly. Put them to work.

But keep the hard part where it belongs.

The future will not be shaped by those who can generate the most.

It will be shaped by those who can still decide what is worth pursuing, what is not, and what must be tested before anyone gets carried away.

Leave a comment

I have worked on innovation projects and co-founded startups where the real difficulty was not the product.

The product mattered, of course. The prototype had to work. The value proposition had to make sense. The customer problem had to be real enough. But in hindsight, the harder question was somewhere else.

How much of the customer’s system had to change before our solution could create value?

That question is easy to underestimate.

When you are building something new, you naturally focus on the improvement you can offer. Faster response times. Lower costs. Better data. Better decisions. Less manual work. A clearer view of what is happening in the field. A way to connect people, assets, suppliers, customers, and information differently.

From the inside, this can feel obvious.

Why would a company not want that?

But companies do not adopt ideas in the abstract. They adopt changes inside existing systems. And those systems already have processes, incentives, budgets, departments, politics, vendors, data structures, risk rules, and people whose jobs are built around the current way of working.

That is where the real adoption problem begins.

When the change is only a task

A startup solution that improves a single task is usually the easiest to absorb.

A human does something repetitive or rule-based. The software helps that person do the task faster, with fewer errors, or with better information. The basic work does not change much. The company can keep the existing process and simply improve one part of it.

This kind of adoption is relatively modular.

There is still a buying decision. There may still be IT, procurement, legal, and security involved. Nothing is ever as simple as the pitch deck suggests. But the logic is clear enough.

Same task. Better tool. Higher output per hour. Lower cost per outcome.

That is a story most companies can understand.

The buyer does not have to redesign the company. The approval path is relatively narrow. The decision can sit inside one team, one budget, one operational pain.

The solution improves the existing machine.

When the process has to move

The next level is harder.

A solution may not only improve one task. It may require a process to change. Maybe information has to flow differently. Maybe decisions move earlier. Maybe one team has to document something in a different way so another team can act faster. Maybe the old approval step becomes unnecessary. Maybe a person who used to wait for a report now gets a signal in real time.

If that process stays inside one team, adoption can still happen. The manager sees the pain. The team understands the work. The benefit can be argued locally.

But the moment the process crosses team boundaries, everything changes.

Now one team has to change behavior so another team can benefit. Sales may have to enter better data so operations can plan better. Operations may have to trust a new signal before finance sees the savings. Customer service may have to change how it escalates cases before product management gets better insights. IT may have to integrate a system before anyone sees the full value.

The startup is no longer selling only software.

It is selling coordination.

That is a much harder sale.

The hidden cost of coordination

Each function looks at the same solution through a different lens.

One team sees efficiency. Another sees extra work. One sees opportunity. Another sees risk. One sees a better decision flow. Another sees a loss of control.

As a founder, it is tempting to interpret this as resistance. Sometimes it is. But often it is simply the company behaving like a system.

Every local change creates consequences somewhere else. And if those consequences are not owned by someone with enough authority, the decision slows down.

This is already difficult when the solution only changes a process.

It becomes much harder when the solution touches the business model.

When the customer has to become a different company

Some startup ideas do not just ask a company to do an existing job better.

They ask the company to rethink part of how it creates, delivers, or captures value. The change may touch pricing, channels, customer relationships, supplier logic, data ownership, incentives, partnerships, or even the role the company plays in its ecosystem.

At that point, the company is not adopting a tool.

It is being asked to become a slightly different company.

Most founders do not say it like that. They say the solution is strategic. They say it creates a new revenue stream. They say it enables transformation. They say it opens a new market.

All of that may be true.

But from the company’s side, the question sounds different.

Who has to change?

Who pays for the transition?

Who loses control?

Who owns the risk?

Which existing partner is threatened?

Which revenue line might be cannibalized?

Which internal team becomes less important if this works?

These are not side issues.

They are the decision.

The strange zone between interest and commitment

This is where startup conversations often enter a strange zone.

The company is interested. The meetings are good. The people are smart. The problem is real. The pilot is discussed. The deck is circulated. A senior stakeholder says the topic is important. Another team wants to be involved. Legal has a few questions. IT wants to understand the architecture. Procurement asks for details. Someone suggests a workshop.

From the outside, this can look like progress.

Sometimes it is.

Often, it is not.

It is movement without commitment.

The startup keeps delivering additional proof, customization, workshops, business cases, and alignment material. The company keeps asking for further evidence before it commits.

But the reason commitment does not happen is not always lack of evidence.

Sometimes the evidence is enough.

What is missing is willingness to absorb the change.

Why evidence is not always enough

That willingness rarely appears because a founder makes a better argument.

It appears when there is already pressure inside the company. A competitor moves. Margins decline. Customers shift. Regulation changes. A board gets worried. A CEO decides that the old model has to be challenged. A budget owner is prepared to fight for the change and carry the consequences.

Without that internal pressure, system-changing ideas get softened.

The company asks whether the solution can fit into the current process. It asks whether the business model impact can be reduced. It asks whether the new logic can be turned into a feature. It asks whether the risky part can be postponed.

The founder wants adoption.

The company wants digestion.

That difference matters.

If your solution only works when the customer changes its system, but the customer only has authority to buy a tool, you are not in a normal sales process.

You are in a structural mismatch.

The companies that built around the old system

This is why some of the most famous startup examples did not begin by asking incumbents to adopt the new logic.

Uber did not start by convincing taxi companies to redesign dispatch, pricing, payment, driver allocation, and customer experience around a new model.

Airbnb did not ask hotel chains to reorganize room supply around private homes, trust systems, host economics, and neighborhood distribution.

Tesla did not simply sell a better component into the traditional automotive system.

Stripe did not wait for banks to make payments easy for developers.

Salesforce did not ask enterprise IT departments to preserve the old software deployment model and somehow become faster at the same time.

These companies are all different, and none of them should be turned into a lazy template. But the pattern is useful.

They did not only offer an improvement inside the existing system.

They built enough of a new system for the improvement to make sense.

What MVP means when the idea is systemic

That is the part founders need to take seriously.

If your idea depends on system change, the minimum viable product may not be a smaller version of the product.

It may need to be the smallest complete version of the system in which the new behavior can happen.

That can include product, service, onboarding, trust, pricing, support, distribution, data, compliance, and partners.

This is inconvenient because it makes the work larger, not smaller. It also makes the early strategy less comfortable.

You may have to own parts of the value chain you hoped someone else would handle. You may have to bypass incumbents instead of selling to them. You may have to find users who can act without waiting for the whole industry to agree. You may need partners who remove a system barrier, not just customers who admire the idea.

And you may have to stop pretending that a successful pilot with a large company is the same as market validation.

A pilot can validate interest. It can validate technical feasibility. It can validate that a problem exists.

But it does not automatically validate adoption.

Especially not when adoption requires departments, incentives, budgets, and business model logic to move together.

The decision founders need to make earlier

That is the uncomfortable lesson.

Some ideas are too systemic to be sold as tools.

When that is the case, the founder has a different decision to make.

Either find a customer who is already under enough pressure to change and has leadership willing to push through the friction.

Or build the new system outside the old one.

The worst option is to spend years trying to convince an incumbent to adopt a future it has no real reason to want yet.

Because in that situation, the problem is not that the customer does not understand the value.

The problem is that the value requires a version of the company that does not exist.

Leave a comment