Most startup programs run in bursts: a flurry of activity, one good pilot, then quiet until the next cycle. The organizations pulling ahead make collaboration continuous instead — and that comes down to four changes in how the work is done.

Every innovation leader has “that” startup that survives in their memory: the one that fit perfectly, that a business unit was genuinely excited about, that felt like it could change the category. But after running the pilot, it died in the slow, undramatic way these things die in innovation: a reorg, a shifted priority, a sponsor who stopped replying, a budget cycle that quietly passed it by.

The idea was fine — in fact, they almost always are. What is missing is a system built to carry these from successful pilots into the business. One-off programs produce one-off results, and after a few years of running them, teams are left with a stack of promising tests that never went anywhere and a portfolio that looks active while it scales almost nothing.

Nowadays, accelerators, incubators, and venture arms are standard equipment: running a program alone doesn’t put an organization in the forefront. The organizations leaping forward are the ones that turn collaboration into an “always-on” capability, producing new partnerships and deploying several innovations every year, instead of one shiny pilot per program — or even none.

The gap between a program that deploys nothing and one that deploys several innovations a year comes down to four moves in how the work runs. VentureFuel, a firm behind more than 100 corporate-startup partnerships, points to these four moves, and its VP of Innovation, Pritam Bhattarai, has watched them separate the programs that build on themselves from the ones that flatten out.

The first move changes when the work happens: discovery runs all year, piloting happens in two concentrated windows.

Innovation tends to start like a lit match; there is a burst of energy around a promising technology, and it is hard to sustain once the surrounding system was never built to carry it. What looks like fading interest is usually a timing problem: discovery and execution running on the same clock.

Most teams keep both discovery and execution in always-on mode. The moment a promising startup surfaces, they try to move it straight into a pilot. This is what then stalls the whole thing: nothing gets prioritized, and resources scatter across too many tests at once.

Therefore, the fix is to run the two activities on different clocks. Discovery stays on all year. Execution, the actual piloting, splits into two 90-day sprints, one in spring and one in fall.

During the sprint, the work moves through a clear sequence:

Each sprint runs six to eight pilots at once. Running fewer means the concentrated effort goes to waste; running more means the organization cannot keep up.

VentureFuel's finding across its programs is that companies which separate the two clocks, searching all year but piloting in two bursts, get roughly twice the output for meaningfully less effort than they did when they “activated” on everything as it arrived.

There are four reasons why the twice per year sprint approach produces better results:

But here is a real concern: what if a great startup surfaces the day after a sprint closes? This is an obvious risk in this approach: a potential winner left waiting while the calendar runs down. Don’t forget that getting any pilot off the ground takes months regardless. During the gap, the startup moves through the funnel: scoping, lining up a sponsor, and defining the one thing the pilot must prove, so the next sprint opens with the pilot ready rather than starting from scratch.

This rhythm keeps startups flowing into pilots on a predictable cadence. But a full pipeline of pilots is not the same as a pipeline of things that scale: plenty run their 90 days cleanly and still go nowhere. Closing that gap is the second move.

A working pilot with a strong proof of concept still goes nowhere more often than not. The reason is usually the same: no one checked early enough whether the company could actually sell or deploy it at scale. The pilot ends up neither killed nor funded — just stuck

To fix this common culprit, apply a simple change to how a pilot gets scoped: before the pilot starts, the team writes a “commercialization thesis”: the specific set of assumptions that would all have to hold true for the innovation to reach full-scale deployment.

In practice, this starts with one question the team answers while scoping: what would have to be true for this to become a repeatable business, not just a working demo? The assumptions that follow are mostly commercial and operational rather than technical, covering how the thing would actually sell, who would run it, and whether enough customers have the problem at all. The team answers it in the pilot's scoping document before work begins, so the pilot has a plan to land on.

These assumptions are hard to pin down at the start. A team can list ten of them that might need to hold, and working through them takes real effort before anyone even knows whether the technology is worth chasing. Still — this is crucial work, because the pilot that skips listing its assumptions is the one most likely to stall in purgatory later.

A building-materials company spent $30k proving a drone-scanning idea worked — then got turned down for the $300k proof-of-concept, because no one had checked whether sales could actually run the motion it would produce.

The idea was sharp: send a drone to scan a building, flag its vulnerabilities to the owner without being asked, and turn that scan into the sales pitch. The owner would see the building's problems and the products that fix them in one place, without being pushed to buy.

The team did strong work on the technology. It identified the right startup, mapped the ideal case, and worked out how a scan could recommend the correct products and route an owner toward a purchase. It spent $30k testing the startup's technology, then went to management for $300k to build a full proof of concept, carried by their enthusiasm for what the drone-driven sales motion could do for customers. However, leadership turned them down— because no one had written a business plan or asked what would have to be true for a drone scan to become a repeatable sales motion

Had they asked, they would have found the bottleneck sitting downstream in sales, not upstream in the technology: the sales function did not have enough staff, and it lacked a reliable CRM to carry the motion the scans were meant to feed. The team had built exciting capability upstream, with no commitment on the deployment side.

After this event, the team mapped the assumptions — and that revealed the real shape of the work. They urgently needed to build up parts of the sales organization in parallel with the technology, and to answer basic questions they had skipped, such as how many buildings actually carried the kind of issues the drones could detect.

The team had gotten so absorbed in the potential, that the commercial picture slipped away too late in the process. Had it written a commercialization thesis at the start, the sales bottleneck would have surfaced before the spend rather than after it, the team would have known to build sales capacity and a working CRM alongside the technology, and the 300k conversation with leadership would have looked very different.

The thesis does not have to be 100% correct on the first pass; don’t wait for it to be perfect. Even a rough version pulls more of the organization into the vision before the pilot runs and extends the chances of early buy-in.

The thesis also changes how the money gets spent. The first pilot is kept small on purpose: 10 to 15k spent over 90 days, sometimes 25k. That is enough to test whether the idea works, without a big bet from either side.

The bigger money, six or seven figures, only comes after that first pilot has proved itself.

That is when the innovation team goes to leadership for the larger investment and opens the serious intellectual-property and commercial-roadmap discussions with the startup. By then, the value proposition is proven and the partnership is real.

But even with the thesis written out, assumptions listed and questions answered, pinning everything on one solution is still risky. That is the next problem: relying on a single bet.

A single bet on a single problem carries a hidden cost: when the pilot wobbles, no one can tell whether the idea is weak or the organization is just resisting it. Yet teams still default to the single bet, because it is easier to get budget for one solution than for several. Most innovation teams, especially now, are too cautious to spread wider, afraid that betting more will leave them with nothing to show at year-end.

In fact, the opposite is true. The single bet is the riskier one: when it dies, there is nothing else on the board. This is why many teams have been moving to a portfolio approach in the past few years: several solutions against the same problem, so no single failure sinks the effort.

But there is an even sharper version of the portfolio approach: the balanced cohort. In this approach, for a problem that matters to a business unit, innovation teams bring six to eight solutions into a single sprint, chosen to differ in four ways: the problem they target, the technology behind them, how soon they could ship, and the kind of innovation they are (product, business-model, AI). In order for this to work, those differences have to be real. Six startups with the same tech and the same timeline are a single bet with six logos, not a balanced cohort.

Run this way, a pilot that works tells the team more than "this startup was good." It shows which problem, which technology, and which timeline the market actually responded to.

A $17B building-materials manufacturer was under real margin pressure. Their core products had become commodities, new growth was hard to find, and traditional R&D was too slow and too expensive to reliably produce anything it could take to market. The gap they needed to close was between its own R&D and the innovation happening outside the company.

So they built a co-development accelerator: a program to build solutions that did not yet exist, together with outside startups. They ran the accelerator across two to three batches of six to eight startups each, applying the same “balanced cohort” discipline every time. When a project was not working, the company cut it and brought in the next batch. That kept the program's cost predictable, rather than open-ended.

The outcome of running it this way? More than 80 commercialization opportunities identified, 16 prototypes and 25 experiments built in a fraction of the usual timeline, 9 partnerships formed, and 4 provisional patents filed. The sales pipeline it generated came to roughly $326M in projected value, at one-fifteenth the cost of traditional R&D.

Running startups as a cohort proves the innovation function can pick winners. Getting a winner to market is a different job — one that sits with the business units, not the innovation team.

The fourth and final move is addressing the ownership gap: getting a business unit to take the result and run with it — something which teams most often attempt at the wrong moment.

Teams often sit down with business units to have a genuine conversation about their bottlenecks. “What matters to you is what matters to us” - innovation leaders know that their work has to solve problems that BU’s actually care about.

The catch is that picking the right problem is harder than it sounds. When the team comes to the business unit at the start, the unit often cannot say which problem is even worth solving. The conversation stalls, buy-in slips, and the handoffs that follow leave innovations stuck.

That breakdown takes three forms: each needing a different, clear response by the responsible innovation team.

The first is no clear direction. The unit cannot say what it needs, so the team ends up piloting whatever use case the unit happens to name, with no way of knowing it is even the right problem. Or, the unit says it is not sure and will come back to them in six months, but that follow-up never happens.

The response is to show the unit where it could focus, using a radar scan. A radar scan works like an insight report or a strategy deck the company already produces: it lays out where the unit's biggest problems sit, where the market and the startup ecosystem are heading, and a handful of startups that could change how the unit tackles a given problem. It also gives the unit a way to survey the field without committing to anything, and turns "we don't know what we want" into a concrete starting point for a pilot.

The second is fragmentation across brands. A team responsible for something horizontal, (for example AI implementation across the whole company) runs into brands that each think about that capability differently, so there is no single problem statement to work from.

The response is to pressure-test the unit's own portfolio of brands. The team brings the brand presidents into a portfolio review and works through three things together: which categories face the greatest risk of disruption, which are the growth areas the brands want to push, and which complaints their consumers keep raising. Out of that review, the problem statement becomes the portfolio's own direction, and the cohort of startups gets built around it. Several options arrive at once, aimed at the categories in decline that need a revamp and the segments looking to grow.

The third is the hardest: the units will not engage at all, and no problem statement is coming from anyone. The response is to stop pushing technology at the units and get them to pull it instead. The innovation team asks every unit to submit the kinds of problems they are facing, then waits for a common theme to surface across the submissions. When enough units name the same gap, the team builds a program around it and opens it to all of the BU’s.

The pull move fits large, multi-brand organizations especially well: one program gets many units to commit at the same time, rather than winning one contact at a time. After one or two of them land, the dynamic flips: rather than the innovation team chasing units, the units start calling the team first to describe their problems, so they do not miss what comes next.

The one move that looks unaffordable on its own — six to eight pilots against a single problem — only works because the other three carry its cost. Two sprints cap the load. The commercialization thesis and staged funding stop money going to dead ends. Early business-unit ownership means someone is already committed to run the result. Remove any one and the system breaks: a portfolio with no landing strips fills with pilots in purgatory; a full pipeline with no BU pull produces demos nobody wants.

A $17B building-materials manufacturer doesn’t reach a $326M pipeline with one strong pilot. It reaches it by running the same discipline across every batch: search all year, pilot in two sprints, write a commercialization thesis before spending, fund in two steps, back six to eight different solutions against each problem, and hand results to the business units that would run them. When a project stalls, they cut the project and bring in the next batch, which keeps the cost predictable rather than open-ended.

This is what produces commercialization opportunities, partnerships, and provisional patents at one-fifteenth the cost of traditional R&D. For an innovation leader, the practical payoff sits in the calendar: with the four moves running as one system, the pipeline feeding next spring's sprint is already filling while this one runs, and the business units are lined up to deploy before the work starts.

Startups queued, funding staged, owners waiting to deploy: this is what truly turns a program into an always-on engine.

One secret stakeholder caused weeks of work to disappear overnight. A handful of habits, set early, keep that from happening — and make pilots stick.

Katie Teuber, director of startup engagement at Comcast NBCUniversal's LIFT Labs, describes a pilot that had everything going for it. The KPIs were strong, the rollout was smooth, and the employees using it were positive.

Then, at the finish line, a team inside the company that had never been brought in surfaced and blocked it. Weeks of non-stop work over the idea vanished into thin air. One team, left out of the loop, was enough to sink a pilot with strong KPIs and a smooth rollout.

That kind of breakdown is avoidable. Running a pilot so the business unit adopts what works comes down to four habits Katie's team sets before the work starts: agreeing what to measure up front, keeping the right people looped in, and bringing a senior sponsor and the frontline users in early.

Pilots that stall often have the same problem: no one agreed what success looked like at the start. Without that, the team just keeps pushing to the next step, with no way to prove the last one worked.

LIFT Labs sets the measures first. Every pilot opens with clear, measurable KPIs tied to real business outcomes: error reduction, time to resolution, usage rates.

What matters is who writes them. The business unit helps set those KPIs rather than receiving them, so the people who will live with the result have already agreed on what a win looks like. Progress then stays visible through dashboards, reports, and regular email updates, which keeps everyone aligned rather than guessing between milestones.

Between kickoff and demo, a pilot can drift, and by the time a problem surfaces, weeks are often already gone. The fix is a communication cadence set before the work starts.

LIFT Labs holds biweekly touch points with stakeholders to track progress and surface roadblocks early, runs reviews with champions at the start and midpoint so the team can course-correct while there is still time, and closes with final presentations to sponsors and cross-functional teams, tailoring the message to each audience so it lands with people who care about different things.

When a pilot produces a clear win, the team amplifies it internally so other groups across Comcast and NBCUniversal know the solution exists and can use it. That is how one proven pilot becomes the next adopter's starting point, and how several LIFT Labs pilots (with companies like Waymark and Coactive) have moved from multi-phase testing into long-term master services agreements, often pulling in business units that do not normally work together.

Getting a tool adopted has to come from two directions at once — and the first comes from leadership.

The team lines up executive sponsors early and ties the pilot's goals to those leaders' own priorities. Then it keeps them involved past the sign-off, in sharing the story and the results, so the sponsor stays visibly behind the work instead of just approving it.

One of the largest pilots of Katie's career opened with the chief marketing officer kicking it off personally, in front of the entire employee group that would be testing the tool. That mattered because those employees were being asked to spend extra time on a solution that was not yet in production. The CMO showing up told them leadership was watching and the work was a priority. This makes people put real effort into a test rather than treat it as a chore.

The second direction comes from the frontline. LIFT Labs treats frontline users as co-creators, not test subjects.

It gathers their feedback quickly and uses it to change the tool fast. It also invests in onboarding and support, so users can succeed from day one instead of being left to work the tool out alone.

The two directions reinforce each other. Support from leadership gives the pilot cover to keep running, and buy-in from the frontline users gives it the daily use that turns a successful test into routine. Neither one gets a tool adopted on its own.

Finally, even with the measures shared, the cadence held, and both directions moving, one gap can still undo a pilot: a team that was never brought in.

The pilot from the opening of this piece is a prime example of this: it was working, there was no friction, and enthusiasm was everywhere. The trouble appeared only at the finish line. An entire organization inside the company had never been part of the project, and its leader had shaped none of the early testing. Because the work had gone ahead without them, it could not hold, and weeks of it broke down overnight.

The cause was not technical. Too little of the organization knew what was being tested or had a hand in shaping it. The takeaway Katie draws from this is to build that awareness from the start, so the people who can influence a pilot's direction are in the room in the first week rather than reacting to it at the end.

Stopping a hard-won pilot from dying after the demo can become an innovation team's full-time job. A few changes made early can save months of avoidable pain.

After all the effort (a clear value proposition, a demo that landed, months of iteration) the pilot gets the green light. Then come the questions that decide whether it goes anywhere: who owns it now, who pays to scale it, who runs it once the lab moves on. But no one has those answers yet.

When the pilot stalls, the innovation leader is left explaining why, and the idea usually takes the blame. In reality, the problem doesn't lie with the idea — but with a funding path and a handoff that no one designed, until it was too late.

A Partnerships Lead at a multi-billion corporation in the FMCG industry works right inside that gap. Their innovation lab gathers business problems from across the company, builds AI solutions with an external tech ecosystem, then has to move them into an organization built to run at scale. They call the reaction that the lab often meets "corporate antibodies": the organization treating a new, unfinished tool as a threat and pushing it back out.

The pattern is fixable, but not with a better demo. It comes down to three tips on funding and handoff that keep what the collaboration produces alive long enough to scale.

Innovation work usually gets funded one project at a time. The business unit paying for it is asked to cover two very different things in a single budget: the cost of exploring and building the pilot, and the cost of scaling it across the company later. Early on, though, no one can say what scaling will cost or what the return will be, so that second number is a guess. Committing to it up front means signing off on a figure nobody can stand behind. It also creates friction, because the business unit that paid wants the product rolled out fast, while the real scaling cost only becomes clear much later.

The fix is to treat these as two separate funding decisions. The first budget covers exploration: enough to build the pilot and find out whether the idea actually works. Only once that is de-risked, and the cost and payoff of scaling are clearer, does a second, larger budget get approved to roll it out.

The one condition on that first budget is that it has to go toward reducing the uncertainty on a specific bet, proving whether a promising idea holds up, rather than chasing the next shiny object that lands on the team's desk.

One approach is to plot every project on two axes, impact and certainty, so a team can see the pattern and correct it. That gives four quadrants:

Most investment ends up in that last quadrant. The wins there are easy to measure, so they are easy to fund, even though they are worth the least. A typical example: someone asks a lab to automate an existing process, and no one stops to ask whether the process should exist at all. The team ships seventeen agents to speed up a task that maybe one agent could have handled. Funding the first budget against real de-risking is what moves money out of that corner and up toward Horizon 1, where the payoff actually is.

Turning a working pilot into a tool running across the company is a genuinely unique job — and a big one, too. It means wiring the tool into enterprise systems, connecting it to live company data, redesigning the workflows around it, training the people who will use it, and clearing governance. That work does not fall to the lab that built the pilot. It falls to the enterprise team that runs things at scale, a separate group that often sits in another part of the business or another country, and had no part in creating the thing it is now asked to adopt.

Usually, the people who built the pilot are reluctant to let go of it, and the people receiving it feel no ownership over something they did not build. So the pilot is about as likely to be quietly shelved as it is to launch. This rejection is what the "corporate antibodies" label captures: the organization treating an unfinished, ungoverned tool as a threat and pushing it back out.

The better approach is to design the handoff at the very start, rather than scrambling for one after the demo. At kickoff, leadership sets the strategy, the lab takes on building the solution, and the path to deployment is mapped out then and there, so it is clear from day one who owns each part and when. To make it hold, both sides get a stake early: some of the people who build the pilot travel with it into the enterprise team, or the eventual owners join the build from the start. Either way, the team receiving the tool is not meeting it for the first time on handoff day.

A common mistake is to judge the innovation team by how many of its projects end up scaled. As covered above, the lab does not run the scaling; a separate team does, often in another part of the business entirely. Measuring the lab on an outcome it does not control teaches it one thing: stop taking risky bets, since those are the ones least likely to survive a handoff the lab cannot influence.

The lab still has to estimate what a solution could be worth once scaled, so leadership can judge whether the rollout is worth funding. But the rollout itself belongs to the enterprise team — that's the boundary. It answers for the quality of the bet and how well it de-risks it, not for whether a separate team's scale-up succeeds.

That principle is the core of the fix: each team is held to the part it controls. The lab gets judged on how well it de-risks ideas, the enterprise team on how reliably it runs them at scale. Then both teams are judged on the one thing that only works if they cooperate: the handoff itself, and how cleanly ownership, budget, and timeline pass from one team to the other. The two teams are built to operate differently, and that is fine. What matters is setting the incentives so a smooth handoff is in both teams' interest, instead of assuming goodwill will carry it across.

Overall, scaling an innovation is never one clean move: it needs the strategy, the funding, the teams, the incentives, and the deployment plan lined up at the same time. That alignment has to come from senior leadership above both teams, since it is the only level that can steer funding, people, and incentives across the innovation lab and the enterprise side at once. It is not something the innovation team can arrange on its own. When the alignment holds, the pattern of the dazzling demo and the shelved pilot stops repeating, and the work the collaboration produces actually makes it into the business.

That’s it for today.

Next week we’ll dive into storytelling for innovation… internally as well as externally. One more edition before we’ll be taking a summer break- not just to rest, but to work on improvements for this newsletter. As mentioned last week, you’ll be invited to share your feedback next week as well, so we know what to improve for once we’re back after summer.

Hans Balmaekers
Founder, the Compass and Chief @ Innov8rs

PS- feel free to forward this newsletter to all the innovation leaders in your company and network. Sharing is… indeed!