[dropcap size=small]"I[/dropcap]nnovation fails because of a lack of discipline, not because of a lack of ideas.”

I don’t know who first said this, but they certainly understood innovation better than most people.

In recent posts, we drilled deeper into the process of product innovation, up to the point of building prototypes for customers to test our hypotheses. This is where most innovation falls into the moat.

Moving from prototype to product requires strategy, investment, and people who are different from the innovators who got you this far. To gather those resources for the next stage of product innovation, leaders must build the business case.

When I talk about the business case at this stage of the innovation process, I get two primary reactions. I get excitement from process-oriented business people who enjoy building spreadsheets and making predictions. I also get tomatoes thrown at me (good thing hippos like tomatoes) from technical innovators focused on building really cool prototypes that their companies’ leaders just don’t understand yet.

Of course, there is a middle ground, but these are the bookends of the reactions.

The truth is that the technology needs to be novel and exciting for customers to want to buy it and use it. It’s solving a problem in new ways. But if it’s not aligned to the things that the business cares about, then chances are remote that you will get the funding to move it beyond prototype and into market.

This post is going to focus a little less on the tools used – although we will mention a couple – and more on collecting the proper inputs throughout the early design process so that the story remains viable.

Up to this point, ideas were collected from all parts of the company, restructured into problem statements, and prioritized by the company’s innovation council. The innovation team had started to build some hypotheses, created experiments to test them, and put the prototypes in front of customers. Over a relatively short period, the innovation team effectively and efficiently built dozens of prototypes, constantly reacting to customer feedback, test cases, mistakes, and market opportunities. For each prototype, the team was quantitatively collecting this feedback for future use. Not only were they using this feedback to make better and more viable minimum viable products (MVPs); they were keeping this data to show the process and evolution of the product.

How often to technical leaders hear from business leaders, “Why did you make that change?” There is no more powerful answer to that question than, “The customers we were testing with wanted us to because it made the product better.”


Now you have a prototype functional enough to bring to that next level of development, and scalable enough to test it with more people. This is called the beta stage, where we test unfinished products in market.

Any technical developer or leader will tell you there is a wide gulf between building a software prototype and building something scalable for thousands of users. Any hardware developer will tell you there is a big difference between designing a product for a 3D printer and designing one to be sent to a custom manufacturing shop overseas. The required rigor and testing are much greater, and therefore the cost is much higher.

If the innovation leader wants to see some of her products in market, she needs to be able to make a viable business case to the innovation council. And the innovation council should demand a viable business case to provide the proper governance and structure to repeat this in the future.

It’s not rocket science, it’s discipline

The Business Model Canvas is a great tool to use throughout this process. By running multiple iterations of a BMC, the team can show the evolution of their thinking by inserting customer data and feedback at each level. The section on customer segments is a great example.

The innovation team has built personas for their target customers, made and tested some assumptions, and over the four months, they have seen that the product resonates more with a different customer than they expected. In their BMCs, you can track how they changed their customer segment from X to Y. Documenting those decisions along the way ensures that the changes were data-informed. It doesn’t guarantee success – nothing does – but it shows the discipline to use the process and come up with a reasonable solution.

Finally, the innovation leader has enough data and a good enough story to build the business case and take it to the innovation council. In each section of the BMC, the evolution is shown: what assumptions were tested, what pivots were made, and what the prototype looked like at each stage. They are also making assumptions on the costs side. What is it going to cost to move that prototype to a beta project and how did you come up with those projections?

The business case in innovation is less about a spreadsheet and more about how the rigor of the innovation process created the conclusions being presented.

The innovation council now must decide if the story is compelling enough to fund it. This is where council members use their insider knowledge to see how to get it through some of the funding challenges that exist in a large company. This should not be the role of the innovator; this is the role of the executive champion that put up his hand to say the project is meaningful and he is willing to support it. It’s now his job to get that funding approved and put the strategy in place to build that beta product.

The innovator’s job is to get to the next project and start the process over again.

Lessons learned in this post:

    • The discipline of following through the process creates the data required to build the business case.

    • By collecting data at each stage of the prototype, the innovation leader can show why the product evolved as it did.

    • By being data-informed and customer-driven, the business case tells a compelling story of why more investment in the product is necessary.

    • It’s the innovation council’s job to secure that next level of funding so the innovator can get back to the prototypes.



Related posts: Commit to the process, not the outcome; Your team has great ideas, now what?

Illustration: Zen View by jenkinson2455 is licensed under CC BY-NC 2.0/modified from original


The Nimble Hippo looks at how large organizations can build innovative cultures and disruptive strategies by taking the best lessons from startup ecosystems and applying them in a big-company context.