Most fixes need money or authority. Susana Jurado Apruzzese had neither, plus a two-month deadline. She changed the one thing she could control: what teams had to answer to get funded.

In September 2025, Telefónica merged several independent technical teams into one new unit inside its digital innovation arm, called Innovation Labs. Susanas’ mandate was to build an innovation governance model over the combined group.

Up to then, the teams had been running on their own, each optimizing for its own technology. Leadership wanted the merged unit pulling in one direction and producing business impact, not just more “interesting demos”.

The engineers in those labs had developed the habits that all independent technical teams tend to develop. They focused on the solution and paid little attention to whether there was a real problem behind it. They prioritized projects by coolness: “this technology is very cool, so let us test it”. And they defaulted to building everything themselves — the part of the job engineers most enjoy.

When you give talented technologists a free hand and no measure of business impact, they will only optimize for the thing they can control — which is the quality of what they build. No one, up to that point in time, had asked them to optimize for anything else.

That was the problem Susana had to solve. The mandate for a new innovation governance model came with three big constraints: the model had to be live in two months, it had to push the teams toward business impact, and it had to do that without smothering the speed and flexibility that made the teams worth keeping.

That third constraint was the most complicated one to tackle. A heavy approval process would slow the teams down, while a long change program would blow the two-month deadline. Susana had to urgently introduce discipline the teams would not blow off as bureaucracy.

Usually, team behavior changes through training and mentoring. You run sessions, sit with the people, and coach them through the new way of operating until it becomes habit. Susana says this was the ideal: the approach she would have chosen if she could.

But she couldn't. She was doing this on her own, with no extra budget and no extra people to run that kind of program. Ordering the change from the top was off the table too, because heavy-handed mandates would cost her the speed she had been told to protect.

Both these options were not available. There was no money to teach the engineers a new way of working, and no authority to simply demand it.

Susana was left with a third option that shaped her entire governance model. If she could not change the engineers directly, she could change what they had to hand over to get the two things every team wants: funding, and the right to keep their project alive.

The logic was simple: change your thinking and behavior, and funding will follow. Everything else in her model exists to make that simple logic work.

The first checkpoint the engineers run into is a filter that decides whether their idea is even allowed in. To build that filter, Susana makes an important distinction: innovation strategy is not the same as the strategy of innovation.

The strategy of innovation is the set of vehicles a company runs to do innovation: the venture builder, the accelerator, the corporate venture capital arm, the research group. Telefónica has run at least fourteen of these over the years, among them Wayra (its corporate venture capital arm), a mergers-and-acquisitions team, the Lean Elephants intrapreneurship program, an experience-design lab, and a moonshot unit. This is an impressive list of vehicles — but it does not tell you what the company is actually betting on, or why.

The innovation strategy is actually the bet itself. It answers a different set of questions: which areas will we invest in, how much, how do we split that across a portfolio, who decides, and which capabilities do we build ourselves versus buy or partner for because we can't build them. To make the bet usable, Susana writes it out as an innovation thesis.

Most have seen an innovation thesis before, but two things make hers worth copying: how she handles the antithesis, and an asset box she adds that most leave out.

Susana writes out the antithesis explicitly. Alongside what the company will invest in (across problem spaces, business models, and technologies), she states what it will not. Most strategies leave the "won't" implicit, which means everything stays arguable and nothing gets filtered. Naming the antithesis is what gives the thesis teeth: it lets the board reject a project by pointing at the document, instead of arguing for each one from scratch.

Then, she adds an assets box for a corporate setting. A company like Telefónica has things a startup doesn't have: infrastructure, data, distribution channels, customers, partnerships, decades of know-how. The asset box makes each team name which of those its project will use. This gives the strategy a real advantage; by naming these things, a team will use them in their project. If they are not there, a startup will end up doing the job better than the corporate.

With this, the engineers' behavior bends for the first time. They understand that a project picked purely because the technology is exciting, with no fit to what the company will fund, does not pass this checkpoint.

The instinct to chase the coolest idea doesn't get argued with in a meeting. It hits a gate it has to pass, and "cool" is not one of the criteria.

Telefónica's innovation funnel does not differ from your typical funnel. A project moves through five phases, with three decision gates between them:

Each gate is a Go, No-Go, or Pivot call: is this ready for the next phase, and is it promising enough to deserve more money?

Here is where Susana did something most innovation leaders skip.

For every gate, she wrote down exactly what a team must deliver and what evidence it must bring, scaled to how mature the project is. She calls this document the Rosetta Stone, because it lets the teams (in this case, the engineers) and the decision-makers finally speak the same language.

The moment a team sees that the next batch of funding depends on understanding the customer and the business case, the work starts shifting toward that on its own.

The Rosetta Stone covers five things a project is judged on. For each one, the bar gets higher as the project matures, moving from soft evidence early to hard evidence:

While all five matter, two do the real work of changing how the engineers operate: one forces them to justify how they build, the other forces them to win a business unit's backing:

Every innovation leader has watched someone win the company hackathon, and then nothing happens with their idea. A project gets incubated for six months and stalls because no one set aside the budget to carry it further. A funnel that stops halfway wastes the work inside it, and teaches the best people not to try again.

It is also what keeps the engineers' new behavior alive: they only keep doing the hard work the brief demands if that work reliably ends in a launch. When it doesn't, they go back to building whatever they want.

Telefónica releases funding stage by stage instead of committing it all up front. A project earns its next tranche only by clearing the gate, which means producing the evidence the Rosetta Stone asks for. In a unit full of teams that used to pick projects by coolness, this is the necessary correction: money stops rewarding the most exciting pitch and starts rewarding the strongest evidence.

Releasing that next tranche is a portfolio decision, not just a project one. Two factors weigh on it:

The gates catch the projects that quietly stall, too. This matters for engineers as much as for the board: nobody likes being trapped on a project everyone has silently given up on.

Once the model has run long enough to build up history, one simple measure starts to flag trouble: how long a project has sat in its current phase. If an MVP usually takes six months and a project has sat there for eight, something is wrong. Susana pairs that hard signal with a soft one she calls the “boredom” metric. You meet a team, then meet them again two weeks later, and you realize they are telling you exactly what they told you last time. The work has stopped moving, and boredom is evident. This is the cue to act before the project becomes a zombie.

The thesis, the funnel, the Rosetta Stone, the metered funding: that is the model. But every company has a model that sits in a slide deck, while the teams work exactly as they always did. What caused the behavior change for Telefonica’s engineering teams is that Susana shrank the whole thing down to one brief the teams had to fill out themselves.

Every team that wants to take a project through a gate, to ask for more time, more money, and the right to keep going, has to complete such a brief first. The brief goes to the innovation board ahead of the decision. She built it with a single move: she took the Rosetta Stone, the grid of what each gate demands, and rewrote every requirement as a question the team has to answer. No pitches, demos, charisma: these are all skipped.

A team has to answer things like:

A team can't move forward without answering them. So to get the funding, the engineers must dig into the customer, the business case, the sponsor, and the build-versus-buy decision.

Nobody trained them and nobody ordered them to do this. But since the questions stood between them and the next round of funding, they found a way to answer them.

The advantage of a brief like this? A leader working alone can build their own version of this in an afternoon. Start with the basics, adding to it as the unit matures, rather than waiting for the budget for a full transformation.

The brief changed what the engineers do. A team that once measured a good day in lines of code now starts by asking who the customer is, what the business gains, and whether the company is even the one that should build it. The strategy comes first and the build follows from it.

It is too early for a revenue line on the model itself. But this is not the first time Susana has run governance this way, and the track record is impressive: an earlier program she built on the same principles, Lean Elephants, ran twice as fast as the process it replaced, tested 45% more ideas on the same budget, and incubated more than 70 internal ventures, one of which seeded a whole new business unit.

That is the lesson for any innovation leader without the budget to train people or the authority to command them. Susana had neither. She had a set of questions and control of the funding, and it was enough to change how an entire unit of engineers works.

The lever is not more budget or authority. It is a simple, well-built governance model. Set it up properly, and the behavior changes on its own.

When a team fights for a next funding round, its presentation often turns into theater: glossy slides with little substance. The real culprit isn’t in the deck, but in how the board works: it engages too rarely, and offers very little when it does.

Almost every company blames stage gates for results that never come: "too slow," "too bureaucratic," "too political." The frustration is everywhere — teams are disheartened, leaders are exhausted and boards still don’t get what they want.

Dan Toma, who has spent years advising large companies on how they govern innovation, argues the problem is not the gates per se. Gates are necessary: innovation spends real money under deep uncertainty, so someone has to decide when a project keeps its funding and when it stops. Stripping the gates out to hand teams a blank check only makes the outcomes worse.

The problem lies in how the board uses them. It engages with a team only at the formal review, a few times a year, while the team keeps learning in between. Here are three changes to how the board works close to it, simple enough to try at the next review.

In most companies, the formal review is the only time leadership really engages with a team. However, learning won’t wait for a review. It happens all the time, consistently, between the gates. So when the only moment that counts comes around a few times a year, problems surface too late and money keeps flowing to projects that should have stopped. This leads to a high cost of failure, low conversion, slow decisions, and long time to market.

The fix is to add short, regular reviews between the formal gates, so the board meets the team while the work is still moving. Dan calls this kind of review a venture board. A gate review asks one thing: is the team ready to advance? A venture board review asks what the team has learned since last time, and what it still needs to find out.

Every review runs on the same four questions. They replace the progress update as the meeting's agenda, and focus on the learning aspect:

How often the reviews happen depends on how fast the team is learning, and that can vary. For example, a biotech team working part time on a regulated product might learn something meaningful every few weeks. A full-time team in retail banking, consumer goods, or software might learn something useful every few days. The rhythm should match how fast the team learns, otherwise things go wrong: a slow-learning team meets the board with nothing new, or a fast-learning team lets months of learning pile up unreviewed.

Meeting the boards continuously means that teams stop pouring weeks into one big presentation, and leadership sees real progress as it happens, stepping in early while a problem is still cheap to fix. And the board itself can change direction the moment the evidence turns. The politics fade, and the board makes faster, clearer calls on what to fund.

Meeting more often fixes the timing, but it leaves a second problem in place: the decision the board makes when everyone is in the room. A gate is a yes or no with real money attached, so the team plays until they win. They smooth over the risks, polish the story, and spend their energy looking ready. This often leads to the review becoming a theatrical performance.

The fix is to give the board a third decision. Most gates offer two choices: move forward, or stop. The third, which Dan proposes, is to persevere. Persevere is for the team that is clearly doing good work, learning fast and reducing uncertainty, but hasn't yet proven enough to earn the next round of funding. In this case, the board holds the project at its current stage and asks the team for more evidence. That keeps a promising project from being cut too soon, and the budget from being committed before the case is proven.

Dan watched persevere take hold at a large energy company he worked with. At first, the option made no sense to the leadership team there. After every presentation their instinct was to push the project to the next stage — if a team was clearly making progress, why hold it back? It took meeting after meeting, and steady reinforcement, before they came to separate activity from evidence: a team could be working brilliantly and cutting uncertainty, and still not have the proof it needed to advance. Once that distinction sank in, persevere became a normal part of how they govern. The team no longer had to oversell to survive, and the conversation shifted from defending the project to working out what evidence is still missing and how to get it.

Here is when the board reaches for each decision:

Putting these three fixes in place means that stage gates stop being high-pressure stress tests. Instead, they become a collaborative checkpoint on learning the board has already been tracking, week by week.

The same team that once spent endless hours polishing a deck to survive the gate, now brings the right evidence to clear it.

The best projects rarely die in one blow. Bad governance habits kill them slowly.

Funding decided on conviction instead of evidence. Reviews run on a calendar instead of real progress. Status updates standing in for actual decisions. Noel Sobelman has spent years watching these patterns separate the governance boards that get it right from the ones that don't.

In this newsletter, we've looked at how one leader redesigned a funnel from scratch, and how another fixed the rhythm of the board itself. Here are Noel's do's and don'ts — whether you're the one sitting on the board, or the one walking into the room to defend a project.

Every decision a growth board makes sends a signal to the organization about how serious it is about the discipline. So before the inevitable hard calls show up, Noel gets board members in a room to agree on how they'll handle them: a team arriving with thin or questionable evidence, a review that surfaces a strategic issue bigger than the project itself, a member who quietly pulls resources after changing their mind outside the meeting, a team that recommends killing its own project. Agreeing on the response in advance means the board can hold each other accountable later — "we said we wouldn't do that" — instead of improvising case by case.

Too often, the loudest or most senior voice in the room wins the argument — the so-called HiPPO, the highest-paid person's opinion. The fix is to replace that with evidence of how real customers behave. Teams start by naming their leap-of-faith assumptions — is the solution desirable, feasible, viable, adaptable — and run small experiments to test the riskiest ones first. A call-to-action experiment, like a landing page or a mock pre-sale, shows whether real customers will commit to something, which gives the board hard numbers to look at.

Not all evidence carries the same weight, though. An email address is light evidence of interest; a testimonial is stronger; someone putting down real money is the strongest signal there is. Setting clear guidelines for evidence strength gives the team and the board a shared bar for "enough."

Noel learned this one the hard way. Early in his career, as a product manager, he spent a year and real money taking an MP3 player called the Hip Zip all the way to market without real contact with customers first. The player died on the vine.

Metered funding — small tranches released as a team hits pre-identified investment readiness levels — brings risk down gradually instead of betting it all at once, and lets executives say yes to the next small step instead of the whole thing.

This is also why asking a transformative project for an ROI or payback period too early backfires. At that level of uncertainty, it pushes teams toward overselling instead of learning.

Event-based reviews — triggered when a team hits a real investment-readiness milestone, or is about to run out of funding — keep the board's questions anchored to where the project actually is. Most companies default to scheduled reviews instead, every month or every twelve weeks, because it's familiar. The trouble is that reviews on a clock tend to drift into status updates, instead of a funding decision.

Handle status and detailed questions in advance, one-on-one — Noel's rule of thumb is that no functional leader should hear something for the first time in front of their peers. A facilitator with real organizational clout keeps the meeting focused on the funding decision. Status updates have other places to happen: staff meetings, dashboards, pre-reads. The moment a growth board review starts covering that ground too, it stops being a decision meeting, and that's when theater creeps back in.

Ask the ownership question early: does the project fit neatly inside an existing business unit, or does it need to sit outside, funded and governed centrally because it could benefit several units at once? Either way, the underlying tension — a business unit owner being asked to give up resources for a project that may not directly benefit their unit — needs surfacing at the highest level of the company, up to the CEO.

The mistake most teams make is waiting until a project is ready to scale before asking who's going to own it. Handing it off too late, after the team has built momentum but found no internal sponsor, is one of the most common ways promising projects stall.

All of this only works if the CEO has set a real ambition for building the company's future, not just optimizing its current business. That ambition doesn't have to be framed purely as growth — it can be purpose-driven — but either way, it has to be explicit, and it has to come with actual budget and people behind the exploratory portfolio.

But when times get tough, the exploratory portfolio is usually the first thing companies cut, in dollars or in people, because it has no near-term revenue to point to in its defense. The idea is to continue to fund a promising project even though it hasn't shown an ROI yet, and sometimes even saying no to a safer, more predictable bet in the core business to keep it moving. Skip that, and the company has no new businesses ready when it eventually needs them.

Different leaders, different fixes, but the same underlying lesson: what separates good governance from bad is whether the board stays close to the work happening between the gates.

That’s it for today.

For me personally, diving into “boring” topics like governance offers a reminder that no shiny AI tools will deliver great results until or unless the innovation process underneath, and the humans doing the work, are in good shape.

Next week, we’ll look at running always-on startup collaboration programs (and getting the org ready to embrace what is coming out of those efforts).

Hans Balmaekers
Founder, the Compass and Chief @ Innov8rs

PS- repeating my earlier PS, lol… ping me if you’d like to be featured in this newsletter.

PPS- for those of you that are bummed to have missed our in-person conference in Toronto last week, the next opportunity to connect and collaborate with fellow innovation leaders face to face will be in Manchester, Sept 15-16th. Would be great to see you there.