By Ahmet Abaci and Beth Somplatsky-Martori
In the first blogs in this series, we talked about how to get started with innovation and ideation, and building a business case – essential components in what we are calling the “Stage Gate Lite” approach to fostering and accelerating new product and service ideas within your organization.
Now it’s time to talk about what happens when the rubber hits the road. And trust us – this can be a very messy part of the process. We are reminded of a quote from that famous innovation guru, Mike Tyson, who once said that “everybody has a plan until they get punched in the face.” At this point, though you may have some glancing blows aimed in your direction, we hope in this blog to give you some processes on how to handle this turmoil and maintain your course.
Committing to innovation can be a test of a company’s culture – because you likely will fail, and fail often (remember, if you’re not failing, you’re not innovating). You’ll need cross-company buy-in to this iterative process – accepting failure, learning from it, identifying vulnerabilities, and ultimately fostering success.
So let’s talk about a couple of ways to organize your cycles of innovation. One method that has become quite popular is Agile methodology – a process that gained favor with the rise of digital product innovation. We’ll also take a look at a more old-school process called the waterfall method, which many of us used in our roles at durable goods, consumer products, and hardware companies.
The waterfall method – as depicted in the accompanying graphic -- tends to be very linear. Each previous step must be completed – and signed off by executive management -- before advancing down the waterfall. As a result, this approach tends to be a slower, more deliberate process, where change can be difficult. In this method, you’ll be looking at things like scope creep, project timing considerations (including the impact of delays), and a process for making changes in midstream.
A much more circular process (see image), Agile values rapid iteration and bestows upon the innovation team broad autonomy and flexibility. Though executive leadership has a say in top-level priorities, the team has full responsibility for deliverables, project management, and ultimately, outputs – delivered in two-to-four week sprints. The goal of Agile is to deliver value to the customer fast – and it is customer acceptance (or rejection) that determines the fate of the innovation.
In order to make the most informed choice regarding your methodology, we consider four factors --
company culture, team skills, the nature of product that you're developing, and your company’s location in the industry lifecycle.
If your product offerings can be hazardous when they fail – for example, like a light bulb that, if it explodes, could cause a fire; or a new aerospace component that could cause a crash if it is not thoroughly vetted – then the Waterfall method likely will rule the day.
As an example, Beth was an executive for a garage door opener company, and The Company had undertaken a fairly complex, multi-million-dollar effort to develop an “Internet of Things” interface for several lines of openers. Though they wanted to innovate quickly in order to maintain a competitive advantage, the garage door market is more complex than it may seem: There are safety and regulatory considerations; the door itself can weigh close to a ton; and the spring that regulates the opening action is under high tension and has been known to cause deaths when it breaks.
With such complex considerations, it can actually can take longer to provision and order components than the length of the development cycle itself. Plus, with all of the steps that were needed to take to mitigate risk, it required the waterfall method to ensure what was developed would be not just acceptable, but 100 percent safe for consumer use.
On the other hand, most B2B SaaS companies freed of most of these constraints – are able to embrace Agile as a core component of how they innovate and how they bring products to market. Agile – always an expedited process – has become even speedier with resources such as the public cloud, platforms as a service, JavaScript libraries, and code repositories available to accelerate enhancements. Even browser enhancements make digital innovation a much faster iterative process.
Agile advocates like this speedy process, as well as the way it favors individuals and interactions over processes and tools; working software versus comprehensive documentation; customer collaboration versus contract negotiation; and responding to change versus following a strict plan.
As an example, today, it’s expected that within a two-week sprint, that multiple “user stories,” or product attributes, should be able to be developed. If an individual user story ends up taking longer than expected, it serves as a signal to the team that the story may be too complex or too fraught with challenges to make the final cut.
In the final analysis, you may find that both methods make sense, given the goals for the product release, the amount of data needed to drive the process, and, of course, the company culture.
With either method, you should be mindful of key dependencies – things like hardware releases or included features. Ultimately, both Agile and Waterfall have striking similarities – both are ways to accelerate the process of delivering value to the customer, and both are fueled by customer requirements and customer feedback, in the form of test-driven development. We’ll learn more about this in the next section.
Regardless of the selected method, a robust test plan needs to be put in place – and rigidly adhered to. This is the make-or-break point for your innovation. Whether it’s a physical product or a software innovation that is put into consumers’ hands, you need a series of testing steps to shake out bugs or problems, address usability issues, and button up any quality issues.
Conducting these so-called alpha and beta tests is little easier today than even a decade ago – often, a prototype can be printed on a 3D printer rather than fabricated, for example. But several absolutes remain: You must actually fix what you find (no exceptions should be allowed to slip through to production); you must be prepared to support delays to make these fixes; and you should be prepared to accept failure at any point in the process.
We have actually come to favor an innovation in the testing process – applicable in this example to software development – called test-driven development. This turns the development and test ethos on its head and promotes the creation of the test protocols concurrently with (if not before) the development of the code itself. This ensures testing and QA don’t get the short shrift in the process.
It’s also at this phase where Ahmet shared that you can develop some additional researched-backed finding that will support the product once launched – determining expiration dates, for example, for some perishable products, or figuring out the breaking point for sporting goods. He recalled one time when they drove over a new basketball in a minivan – truly, where the rubber met the road!
Remember, at the end of the day, you are looking to solve consumer pain with your innovation – not cause more. That’s why developing, and adhering to, iterative methods and rigorous testing standards are so important in the final analysis. It is said that you have one chance to impress a customer – with the “Stage Gate” process, we hope to take it a step further and capture their excitement and energy that comes with an “aha” moment.
Check out our LinkedIn Live video on innovation:
Full series on innovation:
Authors: