Four Stages of Innovation Delivery

“I have not failed. I’ve just found 10,000 ways that won’t work.” Such is the quote most often associated with America’s most prolific inventor, and for good reason. It perfectly captures the attitude someone who’s trying to change the world must adopt if they want their ideas to find commercial success. Failure is always part of the journey, but triumph depends on setbacks happening fast, and happening often.

The subtleties of his statement reveal that Thomas Edison had built that expectation into his mental approach. He viewed failure as an unvarying part of the process and, in so doing, could press on unfazed. As far back as the Second Industrial Revolution, the tenets for successful innovation delivery were already being established.

Delivery is truly the ‘Black Art’ of the innovation puzzle, and more often than not it gets derailed by fear. Not fear of failure, per se, but fear that progress will stall. The focus skews towards questions of “How can we build this out?” and, “How do we get to point ‘B,’ faster?” Lost in the calculation is the possibility you’re building something prospective buyers won’t like or adopt. Innovation doesn’t fail because of a lack of ideas. It fails because enterprises are unable to build the idea and even when they build it, its market fitness has been based on false assumptions and misguided biases, not on truth.

Across 3.5 million development man hours and 400+ successful projects, M3hive has been able to assimilate what it really takes for enterprises to go from innovative concept to successful product. We call it the “Innovation Delivery Framework,” and companies like McKinsey have come to rely on our proven process to bring not only their own, but also their clients’ digital innovations to fruition.

M3hive Innovation Delivery Framework consists of four distinct stages that an innovation must pass through if it’s going to position itself for sustainable market success, every time. They are:

Stage 1: Ideate – Get to the bottom of why an innovation is important;

Stage 2: Prototype – Find the innovation’s most viable niche in the market and expose all the ways it might fail;

Stage 3: Build – Iterative development through M3hive, agile sprint-based blueprint; and

Stage 4: Scale – Move into full-fledged production, and open for business.

Each of these stages, in turn, holds a distinct set of parameters that will not only move the innovation along more smoothly, but also indicate when and if it is ready to progress to the next stage. The finer details will vary from idea to idea, but the basic progression always holds true:

1. Ideate

Innovation first requires a problem and a desire to solve the problem. Trouble is, when it comes to identifying problems, many innovators take it on blind faith that a problem they perceive translates to a monetizable market. For reasons due to fear or ego, they shy away from face-to-face research with customers.

To be sure, ideation is the end point of Phase 1 in Innovation Delivery. The starting point, however, is empathy. Successful innovation always depends upon validating a problem in the market, and doing that requires cultivating a sense of empathy. This is not merely a matter of finding out what a customer needs — you must determine what they are struggling with. Find a common grievance, and you have your kernel of innovation.

For example, the Uber phenomenon happened for one simple reason: Its founders talked to customers. They found that incumbent taxi companies were satisfied with current supply and demand dynamics, and had never considered asking users how they felt about pricing, and what they were willing to pay for livery services. Uber disrupted an industry because it thought to give customers a voice.

In the ideate phase, you:

• Find a problem through empathy
• Define the prevalence of the problem
• Once defined, propose solutions for the problem through ideation

2. Prototype

At its heart, prototyping is the validation stage, where the team puts an innovation in front of users, obtains early feedback about the concept, and confirms how a solution shall be used.

The trick, however, is to do away with thinking about how the solution will work; instead, teams need to put their energy behind discovering all the ways it will fail. Identify the friction points that will keep a product from functioning, and find solutions to those.

Many innovation teams overlook the critical role that building prototypes plays in exposing big mistakes early, and thus enabling those mistakes to carry forward to production. Getting early versions in the hands of 20 to 50 unbiased potential users, then interviewing them and hearing them out as they discuss their experience, provides invaluable insight.

For example, not too long ago we were involved with the launch of a large home retailer’s mobile app for residential service providers, which we unwisely sent to market without research. It only took one week after launch to discover that contractors hated the application’s UI, which we developed in lock step with Android UI guidelines with a UX that everyone loved internally. So, what caused the backlash? We did not create personas or user journeys to identify and relate with the people who would actually be using the app, to determine how they would be using it. Had we taken a research based approach, spoken to some of the service providers and built the prototype based on their user decision journeys, we would have discovered the app’s projected users wanted bigger, bolder buttons as well as an automated verification every time they interacted the app.

Why is this stage so often overlooked? Because of the perceived volume of cost and time involved. However, when you know at the outset that prototypes will be put in the hands of early testers and customers, these perceived hurdles disappear. Prototyping becomes just another critical step for aligning all stakeholders (innovation champions, investors, customers, development teams).

In the prototype phase, you:

• Define personas of the users of the particular innovation
• Create customer decision journeys
• Design experiences that allow users to grasp the value of a solution
• Only then, build prototypes
• Validate that users love it or hate it
• Decide whether to iterate again, abandon, or move to the Build stage

3. Build

This stage will always comprise of a combination of internal IT teams and external development resources, but it is where M3hive truly puts its experience to work. We’ve given great thought to our Build=>Operate=>Transfer model in order to ensure the enterprise can re-assume ownership of innovation once it’s out the door. In fact, planning for the transition back to full internal control begins at Day Zero of the build phase. We are already thinking about the internal teams, training, and workshops that will be necessary to smoothly transfer ongoing operations, support and maintenance back into the hands of enterprise IT. We do not want be there indefinitely!

Look for more details about this critical aspect of M3hive Innovation Delivery Framework in a future post, but consider it a red flag if your innovation partner is not bringing in ‘build’ capabilities and is not asking transition questions early on.

Back to brass tacks. M3hive organizes the build stage around iterative development, broken into three, one-month sprints. Each sprint contains approximately three weeks of development work followed by one week of testing. Anything that requires more than three development iterations is assigned to the backlog for future release and, more importantly, the process is set up such that each sprint pegs to a focused end objective for working software. Even if product-market-fitness shortcomings get revealed during the course of a given sprint, change orders will be held for a future sprint.

In the build phase, you:

• Organize an Agile development team
• Set expectations around future support and transition plans to internal resources
• Execute sprints to release early and often
• Test market-fitness with customers
• Decide to go live, continue iterating, or abandon

4. Scale

In a word, the scale phase begins once you’ve made the decision to go live. Expectations for your innovation partner should be based upon their ability to manage the production environments, run a 24/7/365 DevOps team, perform security and penetration testing, and take complete responsibility of the cloud infrastructure. At the same time, you will be setting up new business units, creating marketing campaigns, and building out the ops and support teams.

An important factor to note about scaling innovation: It typically costs 5 times as much to scale as it does to build. Once systems demonstrate efficient, self-sustaining production for two to four quarters, it is time to implement the established plan to move full control back to internal teams.

In the scale phase, you:

• Design a scalable cloud infrastructure environment
• Setup a 24x7x365 DevOps team
• Operationalize the venture with business, finance, marketing and tech support
• Go live, engage in continuous improvement
• Transition innovation back to internal teams

M3hive Innovation Delivery Framework holds sacrosanct a singular outcome: to minimize execution risk for enterprises. It is only over time and across countless projects – both successes and failures – that these Four Stages crystallized into a process to ensure the most important decisions get made correctly, and that innovation gets used at the intended frequency by its intended audience (and makes money).

The difference between Edison and modern-day innovators? Today’s innovators generally do not have as many irons in the fire, and are thus less able to absorb a mismatch between the market and their obsession. To blaze a purer path from spark of brilliance to market success, consider the Four Stages of Innovation Delivery as your guideposts.