The first time I killed a project that was working, my team thought I'd lost my mind. It was a payment feature pulling in steady revenue. Nothing was broken. But it was eating two senior engineers who could have been building the thing that actually mattered, and I had the numbers in front of me. So we shut it down. Two months later, that freed-up capacity shipped the product that now carries more than half our roadmap. The lesson wasn't "kill things early." It was that innovation management is mostly a portfolio problem, not an idea problem. Everyone in a tech company has ideas. Almost nobody has a system for choosing which ones deserve your scarce engineers.
That's what this piece is about: the unglamorous machinery of managing innovation inside a technology company, where cycles are short, talent is thin, and the wrong bet doesn't cost you a quarter, it costs you the market.
Key Takeaways
- Innovation management fails most often at selection, not at ideation. You probably don't need more ideas.
- Budget your innovation portfolio in three buckets with fixed percentages, then defend them.
- Kill criteria decided before a project starts are the only ones you'll actually use.
- Tech companies have a specific enemy generic frameworks ignore: technical debt and talent scarcity pulling everyone toward the safe work.
- Measure learning velocity and time-to-decision, not just revenue from new products.
Why innovation management strategies for technology companies usually fail
Most frameworks you'll read about assume the bottleneck is ideas. It isn't. I've sat in brainstorming sessions where we generated 40 concepts in an afternoon and shipped exactly one of them eight months later. The other 39 didn't die because they were bad. They died because nobody owned the decision to move them forward, and the default in any busy engineering org is do nothing and keep the lights on.
Here's the thing that took me embarrassingly long to see: innovation initiatives compete for the same people as maintenance and customer work. They don't get a separate queue. So when a framework tells you to "foster a culture of innovation," it's skipping the hard part, which is resource allocation under scarcity.
The real constraint is decision speed
A project that sits in limbo for a quarter costs you the same as a project that fails fast, except you learn nothing. In my experience, the gap between a tech company that innovates well and one that doesn't is rarely talent. It's how fast someone can say yes or no. I watched a competitor announce a feature we'd prototyped five months earlier. We hadn't shipped it because it kept sliding down a backlog nobody was allowed to reorder. That stung.
The three-bucket portfolio (and the percentages I actually use)
Stop treating innovation as a single pool. Split it, and put hard numbers on each split so the split survives contact with reality.
| Bucket | What it covers | My allocation | Kill horizon |
|---|---|---|---|
| Core improvements | Incremental gains to existing products | ~70% of engineering capacity | Quarterly review |
| Adjacent bets | New features, new segments, extensions | ~20% | Two quarters |
| Transformational | Things that could replace your product | ~10% | Rolling, judged on learning only |
The percentages matter less than the discipline of not raiding one bucket to feed another when a deadline slips. Which it will. Every time.
Why the 10% bucket needs its own rules
Transformational work evaluated on near-term revenue is dead on arrival. You'll kill it in month two because it hasn't earned anything, and the incremental stuff always looks better in a spreadsheet. So I judge that bucket on a different scorecard entirely: how many assumptions did we invalidate, and how fast. A transformational project that concludes "this market doesn't exist" in six weeks is a win, not a failure. It bought you the right to stop.
Kill criteria decided before you start
Avouons-le, every founder I know is emotionally attached to their own ideas. I am too. The only defense I've found that actually works is writing the abandonment conditions into the project charter before the first line of code.
- A specific metric that would prove the hypothesis false (not "low traction," an actual number)
- A date by which that metric must appear
- One named person, not a committee, who owns the kill call
- And a rule that the decision gets made in a single meeting, not three
Sound familiar? The committee version is how projects die slowly instead of cleanly. I've been on both sides of that, and the committee version always costs more.
The talent problem nobody puts in the framework
Your best engineers gravitate toward the safe work. Not because they're lazy, because the safe work is where they get praised and promoted. If your promotion criteria reward shipping reliable features, your transformational bucket will quietly starve no matter what the org chart says. I had to change how we evaluated our senior people before that bucket stopped bleeding talent. That was uncomfortable and, honestly, it took me a year to admit it was necessary.
Technical debt is an innovation tax
Every hour your team spends working around a legacy system is an hour not spent on anything new. In a codebase I inherited, we estimated roughly a third of each sprint going to workarounds. A third. That's your real innovation budget, and generic frameworks never mention it because they're written for companies that don't ship software daily.
So one of the highest-leverage innovation moves I've made wasn't a new idea at all. It was paying down the debt that was silently taxing every experiment.
Measuring innovation without lying to yourself
Revenue from new products is the metric everyone wants and the one that tells you the least in the short term. It's lagging by design. The leading indicators I track are more uncomfortable to report but far more useful:
- Time from idea to first user-feedback loop
- Percentage of experiments that get a documented verdict rather than drifting
- How many decisions were made this quarter versus deferred
That third one is the one I watch closest. A pile of deferred decisions is the clearest signal your innovation strategy exists only on paper.
What I got wrong
Early on, I ran a full-scale build on a bet before validating demand, because I was sure. We spent about four months and a meaningful chunk of runway before the first real user touched it. Nobody wanted it. If I'd forced a two-week disposable prototype first, I'd have learned the same lesson for a fraction of the cost. I still cringe at that one.
The part most strategies leave out
You can copy a roadmap. You can borrow a canvas, a scoring rubric, a stage-gate template. What you can't copy is the willingness to say no on a Friday and mean it, to let a project die while it still looks fine on the dashboard because the criteria you set in advance told you to.
The tech companies that manage innovation well aren't the ones with the most ideas or the cleverest frameworks. They're the ones that decide fastest and bury their dead without ceremony. Everything else is decoration. So the real question isn't whether you have an innovation strategy. It's whether you have the stomach to enforce it when a project you love comes up for review.
