April 19, 2022
Editor’s note: This is the fourth in a series explaining the common beginner-steps needed to get an innovation practice off the ground or improve an existing innovation practice. Find our first post, explaining the goals of implementing a structure to guide innovation and training workers how to use it, here. The second installment, on how to create an innovation thesis to guide your team’s activities, is here. The third piece, on how to assemble the right team for the job, is here.
Steve Blank, the godfather of Silicon Valley, says that “for innovation to contribute to a company or government agency, it needs to be designed as a process from start to deployment.” At the start, you need a steady influx of new project ideas to replace and restore eroding capabilities. Investors refer to this influx as “deal flow,” and it is considered the single most important factor in their success. Here are the key principles and practices to generate the deal flow your innovation practice needs to succeed.
It’s cliche to say this, but get comfortable with the uncomfortable. It may take hundreds of initial problems to find a few dozen pilot projects, and only a handful of successful programs may result from those pilots. A rigorous process, like the Innovation Pipeline®, ensures you manage the risk and uncertainty of innovation along with your finite resources. When venture capital investors raise a fund, they initially invest only about 40 percent to 60 percent of it. Cash reserves, known as “dry powder,” are held back so investors can quickly invest more in the early bets that pan out. Translating this to the government, resources are first invested in validating a project (explore). Only after validation are significant investments made in deploying a new capability (exploit).
To get started, you must first understand what you’re doing and where problems will come from. Are you gathering problems from your organization’s workforce (if you’re trying to improve your structure, processes, and culture), your customer base (if you’re trying to improve their job), or both?
If the former, you could use or create an internal portal, akin to a digital comment box with more rigor. If the latter, you could use a tool like SurveyMonkey or something more sophisticated. If that’s not feasible right away, just do it manually. An innovation pipeline needs a lot of inputs at the beginning in order to produce disruptive solutions at the end. It’s the fuel for innovation, so walk the halls of your organization, cold-call your customers, or deputize people already embedded in key places to be your eyes and ears, spotting and assessing opportunity by collecting problems for you.
You will need to see a lot of problems, and rigorously assess them, to find the needs that will lead to transformative change. You cannot be too selective up front, so prepare for the volume by using a simple framework to deconstruct problems into their atomic units.
A Key Beneficiary has a basic need in order to achieve a desired outcome. This problem-centric approach will help you scope and prioritize all the in-bound opportunities so you can easily focus on certain beneficiaries or certain desired outcomes.
Do not leave hundreds or thousands of people hanging if you collect their problems. If your problem sourcing is yet another black box in a large organization, apathy will quickly set in and your projects will dry up. Rather than leave problem-submitters guessing, be honest with them about (1) how you will decide what will get worked on, and (2) that not everyone’s problem will get worked on directly. This communication can be as simple as a Senior Leader announcement at a town hall, or it can be memorialized in an Innovation Doctrine that lays out the fundamental principles that guide coordinated action in your organization.
Not every problem will get worked on. Even with infinite resources, you must prioritize based on your innovation thesis. However, seeing patterns in hundreds or thousands of problems, even the ones you set aside, will reveal the root cause of something greater. For example, you may find lots of problems related to testing new software. Instead of fixing each one, fix the process for testing, evaluating, and approving new software tools, eliminating an entire category of problems in one project.
Your success or failure is based on a disciplined commitment to problem-centric innovation. The best way to keep yourself honest is to initially frame projects as problem statements that provide sufficient background on the origins of the problem to be solved. This kick-starts the next stage of innovation (Curation) and ideally identifies (for the purpose of recruitment) at least some of the key stakeholders around a problem, their basic needs, and an early definition of success.
Next, you’ll rigorously assess and prioritize your problems, and you’ll begin to interview and observe people affected by them. In the next post, we’ll share more insights on how to do it, so you know you can trust the data that results and amplify the confidence in your decisions.
Brian Miller is VP of Strategic Development at BMNT, an innovation consultancy and early stage tech accelerator for government agencies and public service organizations. He writes about innovation based on what's worked in large, public sector organizations tackling the world’s toughest problems.