Effectively shifting gears between the different phases of the Innovation Pipeline

In our work with Fortune 500 companies, we channel innovation processes through a pipeline to achieve just that. One of the big challenges in this Innovation Pipeline, is to know which tools to use, at what moment, and when to switch from one phase to the next.

The Innovation Pipeline

An innovation pipeline is typically split into problem fit (is the solution desirable to customers?), solution fit (is there a way to capture value back?) and growth fit (is the solution technically feasible and scalable?).

First you uncover the right problems to solve, then you propose ways to solve them. Once validated through experimentation, you scale-up. Below methodologies typically converge with different stages in the innovation pipeline.

One of the big challenges in this Innovation Pipeline, is to know which tools to use, at what moment, and when to switch from one phase to the next.

Design Thinking is a mindset that allows teams to explore customer-centric insights, needs, and problems through abductive thinking and inductive qualitative research methods in order to inform the starting point for a risky project. This is the phase where you ask yourself if you’re building the right things.

Lean Startup is a mindset that enables teams to further de-risk the innovation process whilst exploring and validating core beliefs, assumptions and hypothesis in a systematic scientific way through fast evidence-based learning loops.

Business Model Innovation is a mindset that allows teams to prototype value creation, capture and delivery exchanges amongst stakeholders whilst defining clear assumptions and hypothesis to validate in further evidence-based learning iterations.

Finally, you’ll ask yourself if you’re building things right. Agile Development is a development mindset that builds upon the customer-centric feedback loops and allows for continuous adaptability during the building or execution phase of an innovation project (see the Agile Manifesto for more info).

De-risking is key

Each phase in an innovation project comes with its own varying degrees of risks in terms of known knowns, known unknowns and unknown unknowns. Tools and methodologies such as Design Thinking, Lean Startup, Design Sprints, Prototypes or Minimum Viable Products (MVP’s), Business Modeling and Agile Development do a great job of de-risking the process.

Together, these methodologies provide a simple and accessible set of tools for teams to manage uncertainty. They help close the distance between what we think we know and what we actually know. They enable evidence-based iterative decision-making and they enable us to learn in each stage of the innovation process. As more becomes known, they help a team to uncover flaws and dead ends as early on as possible.

Each phase in an innovation project comes with its own varying degrees of risks in terms of known knowns, known unknowns and unknown unknowns.

The challenge for organizations and project teams, however, is to understand how to use these methodologies  optimally and when to shift up and iterate back and forth from one to the other. For their decisions, teams must rely upon specific innovation accounting, pre-defined KPI’s and experimentation validation metrics.

Learning to switch gear – best innovation practices from around the globe

Smoothly running through each phase of the ‘Innovation Pipeline’ compares to learning to drive a car. It’s not enough to know where the gear stick and the pedals are, it’s about knowing when to gear up and down. And that takes practice. But you can build on the experience of others. Below best practices have been collected from innovation teams across the globe.

When you’re in the Design Thinking phase:

• Who should be trained first?
  Senior leadership should first be trained and must have bought into Design Thinking, Lean Startup, Business Modelling and Agile approaches in terms of must-win strategy so they clearly see and value the strategic importance of the approaches for future business growth.

• Which tools & methods should project teams learn?
  Project leads must have a good working knowledge of how Design Thinking, Lean Startup, Business Modelling and Agile Development processes, tools and methods work in practice, either from previous experience or by shadowing other coaches. This will prevent teams from simply passing over the baton from one way of working to the next.
• When to include technical profiles in design thinking?
  Technical Agile profiles must be included in the project teams during Design Thinking, Lean Startup and Business Modelling phases without pushing any technical constraints on the team. They should silently think about the types of technologies, skills and resources that could be needed once market-fit has been reached in the future.

• Who should own the project?
  Project teams should have a single product owner throughout the entire innovation pipeline phases from execution to implementation phases. This is essential to prevent loss of momentum, motivation, ensure stakeholder management and deep knowledge of the project ins and outs. The project owner should also have a clear understanding of the vision, the customer, the business and the developer profiles whilst behaving like a ‘corporate intrapreneur’ ideally with a broad T-profile.

• Should the same project owner remain until agile development?
  The initial project owner during Design Thinking & Lean Startup stages should continue as owner into the Agile Development phase so that implementation is not just ‘thrown over the fence’ at Agile teams and will also keep the teams stable.

• How should teams be formed?
  Multi-disciplinary project teams must be setup spanning as many functions as possible, for example: HR, sales, marketing, technology, finance, legal etc to ensure multiple perspectives are included as well as driving more creative ideas.

When in the lean startup phase

• Consider customer desirability first and foremost
  Teams should think in this order: (1) customer desirability, (2) business model feasibility and then, and only then (3) technical viability. Teams typically instinctively think about how can we build it at the operational solution level first. Once you have validation customers actually want your solution (and there is a validated business case where you can capture value back), you can then look at how to build it. There is no point building a business case or technical feasibility analysis if you don’t know with evidence that your customers actually want your solution in the first place.

• When should MVP/prototypes be production coded?
  Dumb prototypes should be used for as long as possible, ideally until after the business model has been prototyped and tested. This will allow them to be easily and quickly updatable without wasting time and resources on unvalidated production code.

• Kill your own solutions
  Eleventh commandment: ‘thou shalt not fall in love with thy solution’. Project teams must be aware of their loss aversion, ambiguity, anchoring, bandwagon and conformity biases (to name a few). Team members should be their own most critical critics. More about that in our article about 16 cognitive biases that can kill your decision making.

• Who should be accountable for failures?
  Product owners and teams should be accountable for when failures happen, not if they happen (read: fail fast, fail often, fail early). You should celebrate your failures, they will save you unnecessary resource wastages.

• Should I test customer validation at scale?
  Dumb prototypes or MVP’s should enter into a scale-up sandbox phase in order to test and validate assumptions quantitatively before entering into the business model prototyping and testing phase shortly before Agile development starts. This will ensure your validations hold at scale as you know what knowledge and insights you are looking to validate at this stage.

When in Business Model Innovation phase

• Run workshops in parallel
  Design sprints and business model innovation sessions should be run in parallel to prevent the project becoming stalled. For instance, when at the provisioning for resources at the inception phase for Agile Development which can often take time.

• When should a technology feasibility check be done?
  Before making the transition from Design Thinking, Lean Startup and Business Modelling, a technology feasibility or ‘sanity-check’ must be carried out. It is extremely difficult for operational teams to accept, but there is absolutely no point in considering technology feasibility before customer problems and business case have been fully validated with evidence. More on how to do this can be found here in our validation guide.

• Allow projects to move back as well as forward
  If the project fails a technology sense-check just before Agile Development resource allocation, it should be allowed to re-enter into the ‘knowing what to build’ or ‘problem/solution discovery’ phase again for a limited time before facing a final pivot or kill meeting.

• How to keep project team momentum going?
  In order to keep the team together and keep momentum if there is an anticipated delay (for instance from shifting between CAPEX/OPEX) the team should: (1) Further refine the minimum viable product (MVP) or dumb prototype in short 3-day design sprints to gain additional validated learning from customers about critical assumptions. (2) Run additional business model innovation workshops to test outstanding assumptions through clearly defined experiment cards.

Transitioning to the agile phase

• Seamlessly transitioning to agile development
  Designers and prototypers developing minimal viable products (MVP’s) or ‘dumb’ clickable prototypes should pre-define workflows using tools like Sketch, Invision, Zeplin, Marvel, Supernova and many others in order to prevent duplicate coding efforts across phases. There are for instance many new and emerging tools that can export full production code or working assets. Make sure you have your prototyping MVP tools and processes clearly defined up-front.

Special thanks to thank Katrin Wellman & Florian Weiss for contributing their valuable experience and insights to the discussion across Design Thinking to Agile.