Innovation management for growing companies: what actually works when you have 40 people and no R&D budget
The first time I tried to run a proper innovation process, I was working with a 30-person SaaS company that had just closed its Series A. The founders wanted "a pipeline of new ideas." What they got, six months later, was a Notion board with 214 sticky notes, three abandoned prototypes, and a genuine sense of resentment from the engineering team. Total spend: somewhere around €40,000 in salaries for meetings that produced nothing shippable.
That failure taught me more than any framework I've read since. The problem wasn't a lack of ideas or a lack of ambition. The problem was that we'd copied an innovation management strategy designed for a company with a dedicated department, a portfolio committee, and a CFO who could sign off on speculative bets. None of that existed. Innovation management for a growing company is a different discipline than it is for an enterprise, and treating them as the same thing is where most scale-ups quietly waste their runway.
Key Takeaways
- Growth-stage companies fail at innovation mostly because they run enterprise processes with startup headcount.
- You need three things before any framework: a named owner, a budget line, and a decision cadence.
- Stage-Gate works, but only if you compress it. Full gates kill small teams.
- Track four metrics maximum. Anything beyond that won't get reviewed.
- Portfolio thinking beats project thinking. One good idea in ten is a realistic hit rate.
- Killing projects on schedule is the hardest and most valuable habit to build.
Why enterprise innovation frameworks break when your company is still growing
Most of the frameworks you'll find described in innovation management PDFs were built for organisations with a certain shape: a central innovation function, a formal stage-gate process, a portfolio review board meeting quarterly, and enough cash to absorb failed experiments without anyone getting fired.
A 25-person company has none of that. What it has instead is a founder who is also the head of sales, an engineering lead who's already stretched across two roadmaps, and a finance person who spends most of their time on payroll. Adding "innovation" on top of that is not a resource problem. It's an attention problem, and attention is the scarcest thing in a growing company.
The three constraints nobody talks about
When I look back at the projects that actually shipped something meaningful versus the ones that died in a spreadsheet, the difference came down to these:
- Decision latency. If an idea sits for more than three weeks without a yes/no, momentum evaporates. Small teams can't hold ambiguity the way a corporate innovation lab can.
- Opportunity cost, not cash cost. A €10,000 experiment is cheap. The two engineers pulled off the main roadmap for six weeks are not.
- Political fragility. In a 40-person company, one failed bet is visible to everyone. In a 4,000-person company, it's a line item.
Which brings up an obvious question: if the standard playbook doesn't fit, what does?
What growing companies should borrow instead
Borrow the discipline, not the ceremony. From Stage-Gate, keep the idea of defined checkpoints and kill criteria. From lean startup, keep the short build-measure-learn loops. From portfolio management, keep the concept of allocating across bets of different risk levels. Throw away the review boards, the innovation charters, the "innovation KPI dashboards" with 30 metrics nobody reads.
What remains, once you strip it down, is surprisingly simple: a small number of active bets, each with a named owner, a time box, and a defined kill date. That's it. Everything else is scaffolding.
Building your first innovation management system: a practical sequence
You don't need a six-month transformation. You need about four weeks of deliberate design work, done by two people, before you run anything.
Step 1: name one owner, and make it a real job
Not a committee. Not a rotating responsibility. One person, with innovation explicitly written into their role, who spends at least 20% of their week on it. In a 40-person company, that's half a person, and that's fine. What matters is that when something needs a decision, there's an answer to "whose call is this?"
I've seen this fail twice because the founder "kept an eye on it." Founders keep an eye on everything and own nothing, which is exactly the problem.
Step 2: set a budget you can afford to lose entirely
A workable rule of thumb for growth-stage companies: between 3% and 8% of your engineering and product capacity, ring-fenced. Not cash from the marketing budget, not "time when people have slack" (they never do). Actual allocated capacity.
If you're at 50 people with 15 in product and engineering, that's roughly one full-time person plus some fractional support. That's enough to run two experiments at a time. It is not enough to run eight.
Step 3: compress the gates so they fit a quarter
Classic Stage-Gate has five stages over 12-18 months. For a growing company, cut it to three stages over 8-12 weeks:
- Signal (weeks 1-2). Does this problem actually exist, and do people pay to solve it today? Talk to five potential users. If you can't find five in a week, the problem isn't real enough yet.
- Prototype (weeks 3-6). The cheapest artefact that can be put in front of a paying customer. A Figma file is not enough. A scripted demo call is.
- Commit or kill (week 8-12). Either it gets real roadmap resources, or it dies here. No extensions. Extensions are how a portfolio becomes a graveyard of half-finished things.
Real talk: the kill decision is the one that gets skipped. Every single time. The team is emotionally invested, the demo "went well," and nobody wants to be the person who pulled the plug. Fix that by making the kill date non-negotiable in the calendar at the moment the project is approved, before anyone cares about it.
Step 4: pick four metrics, then ignore everything else
You'll read a lot about innovation KPIs. Most of them are unusable at this scale. Here are the four I'd actually track, based on what I've seen reviewed consistently versus abandoned:
| Metric | What it tells you | Realistic growth-stage target |
|---|---|---|
| Idea-to-test conversion rate | Whether you're generating noise or actual candidates | 1 in 8 to 1 in 15 ideas reach a prototype |
| Time to first customer feedback | Speed of your decision loop | Under 21 days from approval |
| Kill rate on schedule | Whether your process is real or theatre | 60-70% of bets killed at the checkpoint |
| Revenue from new products | Lagging, but the only one the board cares about | 10-20% of ARR within 24 months |
That third row is the one that separates functioning innovation management from a nice deck. If you're not killing most of your bets, you're not running a portfolio. You're running a wish list.
Which innovation management framework should you actually use?
Here's the honest answer most consultants won't give you: for a company under 150 people, the framework matters far less than the cadence. But if you want a starting point, this is how the common options map to growth-stage reality.
| Framework | Best fit | Where it breaks at growth stage |
|---|---|---|
| Stage-Gate (compressed) | Hardware, regulated products, anything with real build cost | Full five-gate version is too slow; needs cutting |
| Lean Startup / build-measure-learn | Software, services, anything cheap to prototype | Can become an excuse for endless testing with no commitment |
| Three Horizons | Companies above ~100 people planning beyond 18 months | Abstract at small scale; hard to allocate real capacity to H3 |
| Jobs-to-be-Done lens | Any size; useful as a filter, not a process | Doesn't tell you what to do operationally |
My own combination, after several rounds of trial and error: compressed gates for the process skeleton, lean loops inside each gate, and a Jobs-to-be-Done framing to decide what enters the pipeline in the first place. Three Horizons is worth reading about and probably not worth implementing until you have a dedicated innovation lead.
The mistakes I made, so you can skip them
I'll be specific, because the vague version doesn't help anyone.
Mistake one: running innovation as a hackathon. We ran a two-day event with prizes. It generated 60 ideas, three prototypes, and zero shipped features. Hackathons are good for morale and culture. They are not an innovation management system, and conflating the two wastes a quarter.
Mistake two: letting the innovation budget be "reclaimed" during a busy quarter. Once that happens, it happens every quarter. Ring-fenced means ring-fenced, and you need the founder to defend it when sales is screaming for engineering time. This was the single biggest reason our first attempt failed.
Mistake three: measuring activity instead of outcomes. For four months I reported "number of experiments run." Nobody ever asked whether any of them changed a decision. Report outcomes or don't report at all.
Mistake four: no external input. Every idea in our pipeline came from the same 12 people who were already working on the same product. Innovation pipelines fed only from inside tend to converge on incremental improvements, and incremental improvements don't open new markets.
What are some factors to consider when using a strategy of innovation?
Before you commit to any innovation strategy, run it past these questions honestly. If you can't answer them in one sentence each, the strategy isn't ready.
- What is this innovation supposed to do for the business? New revenue, retention, cost reduction, defensive positioning? Each leads to a different pipeline.
- Who is accountable for the outcome, not the activity?
- What are you willing to stop doing to free up the capacity? Innovation is rarely additive.
- How will you know within 90 days if it's working?
- What happens if it fails visibly? If the answer is "someone gets blamed," your culture will quietly kill the programme.
That last one matters more than most people admit. In growing companies, everyone watches everyone. If a failed experiment becomes a political liability, you'll get safe ideas, which means no ideas worth having.
The thing that actually moves the needle
After all the frameworks, the tools, the dashboards and the retrospectives, the companies I've seen do this well share one trait: they have a short, boring, reliable rhythm. Every two weeks, the same four people look at the same five bets, using the same four metrics, and make one decision per bet. Approve, adjust, or kill.
No offsites. No innovation days. No quarterly "innovation review" that becomes a presentation contest. Just a recurring half-hour where the honest question gets asked: is this still worth the capacity it's consuming?
The uncomfortable part is that this rhythm exposes you. When you kill things on schedule, you can't hide behind a pipeline of promising future launches. You have to say out loud, every two weeks, that most of what you're trying is not going to work. That's the price of building something that actually reaches the market instead of living forever in a Notion board.
Most companies aren't willing to pay it. The ones that are tend to be the ones you've heard of a decade later.
