Innovation at Scale, #8: Managing Innovation Funding
How to assign funding as projects progress
This week, I want to talk about one important component of how to manage innovation teams: Who gets funded? For which projects? And how much?
The hardest of these variables, for managers of any team focused on Product discovery, is understanding if a team needs an additional tranche of funding, what the correct amount of funding is, and what it should be used for.
My overarching principle here is that funding should come in stages, and be tied to pre-agreed milestones.
What is the goal?
When embarking on any project - it’s important to ask what success looks like. You need to know in advance the answer to the question “What is the goal?” There’s a related tactical equivalent question that needs to be your practical north star: “How will we know if we’ve succeeded?”
This latter question builds every project into an attempt to accomplish something beyond just “project delivery,” and goes a long way toward motivating and empowering teams.
Using this question, we can also build in intermediary milestones that signal whether we are ready to progress from one stage to another. We can think about each stage as representing a new way to answer the question “How will we know if we think we can succeed?”
Stages enable progressions
At a macro level, I’ve succeeded with 4 main stages, each with different objectives:
The research phase is where a team learns if an idea seems like fertile ground across our three main criteria of Desirability, Viability, Feasibility. (I’ve previously promised a deeper dive on the DVF model, and will deliver this in the coming weeks). Evidence at this phase is usually centered on understanding that there is a key User Need, and finding ways to suggest that a given solution will work to solve for this need.
“No Plan Survives First Contact With Customers” - Steve Blank
The Prototype phase is where ideas for a solution are first able to receive customer feedback. The idea is to present an actual (working) solution to customers, in some form. This could be a paper prototype, or a fully working website (often with dummy data in it). Prototypes are typically tested in controlled settings, by User Researchers, Designers, or Product Managers. The feedback received lets those teams iterate on their solution designs, or know why and how they should go back to the drawing board.
The Minimum Viable Product Phase is the first time that the solution goes out to customers in real-world settings. The solution is deployed, and intends to actually work to solve a real need for users. This is still primarily focused on learning, in order to understand if and how the solution solves for user needs, and what would be required to reach the Scale phase.
Turning the MVP into a wider solution for full deployment. This has two components. Firstly, it means deploying the MVP at scale. This often requires a technical rebuild of either the MVP or an existing technical platform/solution, so that it can reach a wider user base. Secondly, it means making the MVP less minimum. Starting to add features to make the solution more full-service. This part of the scale process is not just iterative, it also is continuous.
Milestones for each Phase
For each phase, each project should have pre-agreed milestones that unlock funding for the next phase. These milestones should be tied closely to the nature of the experiments from that phase, should be quantitative where possible, and (in a larger org) should be judged by a management process that exists outside of the team. Startups often have the same people judging the success as trying to achieve the success metrics, but this is a disadvantage; it’s very tough to be honest with yourself about a solution’s Product-Market fit when you have to be both the jury and the defense attorney.
What is a good Milestone?
Each phase will require different concrete milestones, and each project will of course have different success criteria depending on their experiment plan.
Success criteria must be agreed before the start of the phase. Those criteria need to be minimum thresholds for greenlighting the next phase. If your success criterion is “100 signups,” then 99 signups means that you have to Pivot your idea, or Perish the project. You can’t Persevere based on your agreed criterion. (I’ll explain this 3-P model in a future issue)
In the Research, phase, you want to be able to tell a compelling story that says “This problem would be Desirable, Valuable, and Feasible for us to solve.” This evidence is typically qualitative, even if some of the data points might be quantitative.
In the Prototype phase, having good feedback from users is a good demonstration of Desirability, but before embarking on building an MVP you should also have a demonstration of Viability in some way. There are lots of tools for assessing commercial value without building a product, and I recommend you design experiments to test this quantitatively. Keep in mind that asking someone “How much would you pay for this?” fails The Mom Test. Focus on designing experiments that look like real decisions for your users. Imagine a “Buy Now!” button that goes to a page that says “Sorry, we’re sold out” - you can track how many people tried to buy, or how many leave their details to be notified when it comes in stock.
The MVP scale metrics should be the same as you’d design for a Product. It’s probably that you’re using some version of “Pirate Metrics” at this point; you likely want to focus on engagement as a leading indicator of the potential for scale, because it implies that you are truly solving deeply-felt user needs.
At Scale, you should be thinking about mature Product metrics, and validating that your MVP success can scale to customers beyond your early adopters. By this point, progress should be iterative and continuous.
For every phase, one of these milestones should be “Have a plan for the next phase, including suggested milestones.”
Funding for each Phase
Because each project will have different requirements at each phase, it’s hard to set absolute boundaries for how to set budget limits. In general, project budgets will increase for each phase, but the best way to think about allocating budgets for a given phase is to think about the following:
What is the objective of this Phase? That is, what do we need to learn to confidently move to the next phase?
What is the most effective way to meet this learning objective?
How much does it cost to run this experiment well?
Juggling that with the constraints of your organization’s budget is the key to right-sizing a budget for a given phase.
Each week, I'll include links to articles, books, or podcasts related to corporate innovation, that can help you accelerate the knowledge and progress of your teams.
Ben Holliday's Everything is hypothesis driven design is a short, excellent introduction to moving toward hypothesis-driven decisionmaking, and adopting the principles of Lean UX. (Ben on Twitter). Next week I’ll have more to say about Lean UX, and how it can help drive effective design decisionmaking.
I linked to The Mom Test above; it’s one of the essential tools in how I teach teams to conduct effective customer research. The book’s tagline is “How to talk to customers & learn if your business is a good idea when everyone is lying to you.” That should strike a chord.
Inside the Story of How H-E-B Planned for the Pandemic dives deep into how HEB has built up the capability to be responsive when unexpected disasters strike. It’s especially worth noting that they have a full-time, year-round emergency preparedness team, precisely to learn how to foresee and prepare for crises like this. This article is a great followup to Issue #6 of this newsletter, where I discussed some of the tradeoffs between efficiency and resilience. There are also some important lessons about keeping customers at the heart of everything you do, and building loyalty through service.
A personal note
I’m currently looking for new, interesting projects to explore, and people to meet. I’m especially interested in working with very large companies on building and leading innovation teams, and in helping startups to scale from a nascent Product function to a high-performing larger team. Please don’t hesitate to reach out to discuss either of the above.
A question for those who made it this far: Which concepts would you like me to explain in further detail in future issues? Thanks for reading.