Your Innovation Team Is a Startup (Design It Like One)
- Susie Braam
- Jan 13
- 7 min read
A practical tool for turning your innovation orientation into an operational team model.
In previous articles in this series, I explored why innovation teams fail, introduced six dimensions of organisational readiness, and helped you identify your team's primary orientation: Architect, Builder, or Enabler.
Now comes the practical challenge: how do you actually build the team? If you’re unsure how to structure, resource, and connect it to the rest of the organisation - or something about your current set-up isn’t working - this is for you.
Think Like an Internal Startup
Here's a mindset shift that's served me well: treat your innovation team like an internal startup.
Startups rarely get their business model right the first time. They test, learn, pivot, and iterate. The model they launch with is almost never the model that eventually works. The same is true for innovation teams.
The team structure you design today should be a hypothesis, not a permanent fixture. Build in the expectation that you'll revisit and refine it as you learn what works in your specific context.
This isn't a sign of poor planning — it's walking the walk. If you're asking the rest of the organisation to embrace experimentation and iteration, your own team design should embody those same principles.
The Innovation Team Model Canvas
To help with this design work, I've adapted Strategyzer's Business Model Canvas into an Innovation Team Model Canvas. It provides a structured way to think through the key elements of your team's operating model — and crucially, how they all fit together.
The canvas has eleven sections, and I recommend working through them in a specific order:
1. Business Problems/Opportunities
Start here. What specific problem(s) is your team hired to solve, or what opportunities are you pursuing? This should connect directly to the Jobs to Be Done work from Article 1 and your organisational context from Article 2. Be specific — "drive innovation" isn't a problem statement.
2. Value Proposition
What are the services or products you’re going to provide to solve those business problems or to enable the business to seize those opportunities?
3. Beneficiaries/Customers/End Users
Who benefits when you succeed? This might be internal customers (business units, employees) or external customers whose experience you're improving. Understanding who you're serving shapes everything else.
4. Early Adopters
Who are the people or teams most likely to engage with your innovation work first? Who’s already looking for the type of support or service you can offer? Where can you demonstrate value quickly and build credibility for broader adoption?
5. Key Stakeholders
Who has influence over your team's success? This goes beyond your direct sponsor to include budget holders, business unit leaders, and anyone with influence who can accelerate or block your work. I'll cover stakeholder strategy in depth in a follow-up article.
6. Customer Relationship
What type of relationship will you have with customers/beneficiaries? Will it be hands-on and customised (e.g. 1-2-1 coaching, finding and supporting start-ups) or will it be more transactional (e.g. running one-off training)?
7. Business Impact
How will you know if you're succeeding? What metrics matter? This connects to the "accountability" element I'll cover in my next article, but you need to start thinking about it now. Impact should link back to the problems you're solving.
That covers the centre and right-hand side of the canvas (the external facing part). Now let’s look at what’s happening behind the scenes.
8. Key Activities
What does your team actually do? For Architects, this might be designing frameworks and governance. For Builders, running discovery sprints and prototyping. For Enablers, delivering training and coaching or scouting for startups. Be honest about where your time goes.
9. Key Resources
What capabilities, tools, data, or access do you need to offer the service you propose in your value proposition? See note on whether to build, buy or partner below.
10. Partnerships
Which key resources don’t you currently have access to but need to deliver your value proposition? External partnerships might include consultancies, technology vendors, academic institutions, or startups.
11. Budget (Financial and People)
What resources do you actually have? Be realistic. This section often reveals gaps between ambition and reality — which is useful information.
Here's the critical constraint: the cost of your key activities and key resources can't add up to more than your budget. It's tempting to design an ideal operating model and then go cap in hand asking for more money. But that's not going to win you friends when you haven't yet demonstrated value. Instead, work within your constraints and bring creative thinking to your model.
This is the beauty of business model thinking — it forces you to understand how everything integrates. If budget is tight, where else on the canvas do you have flexibility? Can you reduce scope on certain activities? Partner instead of build? Focus on fewer early adopters? The canvas is holistic; changing one element affects others. Use that interconnection to find a model that actually works.
A note on categorisation: People sometimes get anxious about whether someone belongs in Partnerships, Stakeholders, or even Beneficiaries. Don't overthink it. So long as they're on the canvas somewhere and you're thinking about them, you're in good shape. Remember — this isn't your first and last iteration.
Leverage, Build, Buy, or Partner?
As you work through Key Activities, Key Resources, and Partnerships, you'll face a recurring question: should we build this capability internally, buy it from outside, or partner with others?
In their MIT Sloan Management Review article "The Missing Discipline Behind Failure to Scale," Andy Binns and Christine Griffin identify four approaches to acquiring assets for scaling ventures: leverage (use what you have), build, acquire, and partner. While their focus is on scaling new business ventures, the same logic applies to designing innovation teams. How you source your capabilities shapes what's possible within your constraints.
This isn't a one-time decision. It's a portfolio of choices that should evolve as your team matures.
In my second Head of Innovation role, we started as Enablers with a focus on building innovation skills across the organisation. Initially, we built and delivered all training capability in-house — we had subject matter expertise we could leverage immediately and we wanted to maintain control over quality and context.
But as we developed relationships with external partners, we realised something important: our internal team's real value wasn't in delivering training content. It was in coaching and architecture work that required a deep understanding of our business context. External partners could often deliver training more efficiently, while we focused on where we added unique value.
So we pivoted. We shifted to buying in training delivery and redeploying our internal resource toward coaching and systems design. Same overall mission, but a different operating model that played to our strengths.
Consider leveraging when:
You already have the skills and capability within your team or organisation
You have the capacity to deploy those skills and capabilities
Speed matters and you can deploy immediately
Consider building when:
The capability requires deep organisational context
You need to iterate rapidly based on internal feedback
The work is core to your team's identity and differentiation
Consider buying when:
Specialist expertise is needed that you can't develop quickly
The capability is mature and available externally
It frees your team to focus on higher-value activities
Consider partnering when:
You need credibility or access you don't have
The work benefits from external perspective
Risk is shared appropriately
Iteration Is the Point
The first version of your canvas will have gaps and uncertainties. That's fine. The purpose isn't to create a perfect plan — it's to make your assumptions visible so you can test them.
Sometimes iteration is proactive — you learn something and adjust. Sometimes it's forced on you. Both are valid.
A global energy company I'm familiar with initially invested heavily in innovation capability, building a large network of agile innovation coaches, many of them external contractors. The model looked impressive on paper. But when leadership shifted and the team was asked to demonstrate impact, they struggled to show returns proportionate to the investment.
Budget cuts followed. The team was forced to rethink their operating model. They reduced their coaching cadre to internal employees only — building capability rather than buying it. And those coaches evolved from pure enablers into a hybrid role: part coach, part builder, getting hands-on with innovation projects rather than just supporting from the sidelines.
The result was a leaner, more focused team that could demonstrate clearer value. The iteration wasn't comfortable, but it produced a more sustainable model. Their canvas changed significantly — fewer resources, different activities, shifted partnerships — but the mission remained intact.
I recommend revisiting your canvas quarterly, asking:
Are we still solving the right problems?
Have our customers or early adopters shifted?
Are our key activities actually delivering impact?
Is our build/buy/partner mix still optimal?
Connecting the Diagnostic Work
The canvas doesn't exist in isolation. It builds on everything you've done so far:
Your Jobs to Be Done (Article 1) inform the Business Problems/Opportunities section
Your Organisational Readiness Assessment and Innovation Context Canvas (Article 2) provide the strategic context that surrounds all of this and shapes what's realistic.
Your Architect/Builder/Enabler orientation (Article 3) determines the focus of Key Activities
If you've skipped the diagnostic work, go back. The canvas is far more useful when grounded in honest assessment of your context.
What To Do Next
Download the Innovation Team Model Canvas and spend no more than an hour on your first draft — imperfect as it may be. You've done the groundwork. Now it's time to move from design to action.
Check the maths. Do your activities and resources fit within your budget? If not, where on the canvas can you find flexibility?
Identify your biggest uncertainties — which sections feel most like guesswork?
Plan your first iteration checkpoint — when will you revisit the canvas to refine based on what you've learned?
In the next article, I'll cover how to prove innovation value when everyone wants results yesterday — including the leading and lagging indicators that help you demonstrate progress before the big wins arrive.
This is Article 4 in a series on building innovation functions that actually work. Subscribe at www.yellow-cat.co.uk for early access to tools and future articles.
Comments