Innovation Management

I spend a lot of time at the intersection of “business modeling” and “lean startup” and have been looking for the right category label to describe this type of work. It’s not enough to simply call it one or the other.After much deliberation, I’ve settled on the label: “Innovation Management” .
Yes, I am aware that “innovation” is an already overloaded term and more corporate sounding than startup sounding. The other alternative I considered, “Entrepreneurial Management”, is a mouthful and I’m willing to temporarily risk losing you — provided I win you back by the end of this post.

Invention, Innovation, and Innovation Management

An invention is simply a new device, method, or process. Innovation, on the other hand, is the application of an invention for the purpose of creating and delivering customer value. In business modeling terms, inventions live in the realm of solutions, while innovations live in the realm of the business model.
Most new ideas fail because we entrepreneurs prematurely fall in love with our inventions or solutions. When hit with a new idea, we spend a disproportionate amount of time either building out our solution or chasing investors, so that we can acquire the resources to build out our solution — only to find out after months of effort, that we’ve built something nobody wants.
This build-first or investor-first approach is backwards and what I refer to as the Innovator Bias. It takes discipline to turn potential inventions into innovations which is where management comes in.
Innovation Management is the disciplined process of turning inventions into innovations.
And, it is just as applicable to startups as it is to the enterprise.

The Business Model, Not Your Solution, is THE PRODUCT

I have been an entrepreneur for over a decade and throughout that time I’ve launched dozens of products. While all my ideas started out as awesome solutions, not all of them went on to become awesome business models.
Sure, like anyone else, I wanted more of my ideas to succeed but I knew that good ideas are rare and hard to find. You have to go through a lot of stuff that doesn’t work, before you find the ones that do. So I was prepared for the search. What I wasn’t prepared for was the cycle time between searches.
At the time, I was averaging 1.5–2 years between ideas. This was simply too long. At some point I realized that I had more ideas than time and my personal mantra became: “ Life’s Too Short to Build Something Nobody Wants ”. My focus shifted towards finding a better and faster process for vetting new ideas and doubling-down on only the best ideas.

“If you can’t describe what you are doing as a process, you don’t know what you are doing.”- Edwards Deming

I already knew how to build products so viewing the business model as a product was particularly empowering. Metaphors are powerful because they help you transpose concepts from one domain to another which is exactly what I did in describing a business model development process.

From a Product Development Process to a Business Model Development Process

Let’s say you have 6 months to deliver a complex project, it would be prudent to start with some kind of a rough sketch or plan. In that plan you would probably prioritize testing what’s riskiest, versus what’s easiest, so you aren’t thrashing like crazy at month 5. Finally, you might employ an iterative development process (like Agile or Scrum) to balance uncertainty with quick learning feedback loops.
The business model development process is no different.
1. You create a quick sketch of your business model using a tool like the Lean Canvas.2. You identify what’s riskiest in the model, and3. Systematically test and refine your plan using experiment feedback loops.
This 3-step business model development process is the same one I outlined in my first book: Running Lean . The first step here is business modeling. The third step is lean startup. Business modeling helps deconstruct big ideas into their component pieces, while lean startup techniques help test those component pieces through experiments. But there’s been a missing gap — the glue that connects steps 1 and 3: A systematic framework for prioritizing which components you test first.
Identifying starting risks is usually easy. Most products need to first validate their customer and problem assumptions. If those fall apart, everything else in the business model also falls apart. But beyond starting risks, identifying what’s riskiest isn’t always obvious. This is the core problem I tackled in my second book: Scaling Lean .
The way we do this in product development is by recognizing that product development is a system.

A system is a set of interconnecting processes with a single constraint.- Eliyahu Goldratt, Theory of Constraints.

We start by defining the output of the product development process (build velocity, in this case), map the steps that lead up to the output, and search for bottlenecks or constraints (where work is piling up). Once you identify the constraint, you identify what’s riskiest.
The same approach can also be applied to business model development. But the output of a business model is not the same as a traditional product.

Traction Velocity, Not Build Velocity, is the Measure of a Working Business Model

The job of a business model is to create, deliver, and capture value from customers. Capturing monetizable value back from customers is particularly key as there is no business in a business model without revenue. The output of a business model clearly isn’t just building a great solution then, but rather capturing monetizable value from its customers — measured as traction. All businesses share this goal which makes it universal. All businesses also share the macro steps for creating traction which is shown below:
In the picture above, I’ve redrawn Dave McClure’s pirate metrics (AARRR) as a system which I find has advantages over a funnel representation. I’ve covered this here . This picture assumes a one actor model where users become customers. It is fairly easy to extend this model for multi-actor models like multisided and marketplace models.
Business model development, like product development, is also a system. Once you map out the steps leading up to traction, and search for constraints, the riskiest assumptions reveal themselves.
Another best-practice adapted from the product development playbook is scaling up in stages. Much like we don’t (or shouldn’t) attempt to staff a product development team from zero to a hundred people immediately, we shouldn’t attempt to ramp up a business model from zero to a million customers immediately.

Premature scaling is one of the top killers of innovation.

The 10X Staged Business Model Development Lifecycle

Trying to scale up from day one invites all types of risks at the same time: customer risk, market risk, and technical risk. A staged approach, on the other end, lets you focus on the right risks at the right time. Most products fail due to customer and market risk (not technical risk), so it makes sense to prioritize those first. A great strategy for deliberately doing this is employing a 10X rollout. In other words, you give yourself permission to develop your business model in stages where each stage is separated by an order of magnitude (or 10X).
So for example, when you first launch a product you should- Only focus on early adopters.- Only focus on a handful of customers.- Race to deliver value.
I call this hitting the “easy button”. If you can’t deliver value to a handful of your best potential customers, what makes you think you can do this at scale? If on the other hand, you do demonstrate that you can deliver value to a small subset, your next challenge isn’t doubling, but 10x’ing that number. The 10X rollout strategy automatically works to prioritize the riskiest parts of your business model.
When you embrace a staged rollout strategy, you find the business model lifecycle starts to look something like this:
The picture above highlights the 3 stages of the business model development process: Problem/Solution Fit, Product/Market Fit, and Scale, but also emphasizes the search versus execution nature of business model development.
You start out with a wide array of business model possibilities that you iteratively narrow down through experiments (search) in to a single business model that you take to scale (execution). Each of the 3 stages share the same goal: increasing traction. What differs is the throughput rate (or milestone goal) of each stage and the specific set of strategies and tactics you employ to achieve those milestones.
While this picture is showing the evolution of a single big idea with multiple variants, it could just as easily be showing the evolution of a portfolio of innovation products pitted against achieving a big business model outcome. More on this in a future post.

Our Implementation and Toolkit for Innovation Management

Putting all this together, here’s a summary of the process and set of tools we’ve been working on:
Did I lose you or win you back? Leave a comment below…