When innovators use Rapid Learning Cycles in early development, they get acceleration for their best ideas as the others fail faster. The ability to accelerate your best ideas pays off in a number of ways:

• Greater schedule predictability and faster time-to-market.
• More profitable products with more predictable costs.
• Better relations with customers and channel partners, with fewer post-production surprises.

Rapid Learning Cycles deliver these benefits by improving the quality of decision-making, especially in the early phases of development when the team sets direction around product/market fit, architecture and production that are difficult to change later.

Rapid Learning Cycles help innovators make better decisions.

Innovators making tangible products — products that require industrialization and distribution — have many decisions that need to be right because they will be difficult to change later. These decisions feed into capital equipment purchases, partner investments, supply chains, reseller commitments and other areas where the cost-of-change will skyrocket. Those decisions don’t reach that point at the same time.

If innovators rush to make these decisions, they are much more likely to make decisions that need to be changed later, eating up time and money when the company can least afford it. Yet many on the technical and business sides of innovation assume that making decisions early will make innovation programs go faster. This could not be further from the truth.

Waterfall methods don’t work well anywhere.

Diagrams showing the waterfall method depict a smooth flow from requirements to specifications, designs and testing before launch. This method assumes that we can know all the requirements up front, and then translate those requirements into specifications perfectly, even if we’ve never done something before. It embeds the false belief that getting the up-front work done to near-perfection will lead to near-perfection in execution. 

We’ve known since at least 1990 that this method doesn’t work well for anyone. Customers can’t tell us what they need a new technology to do. Technologists can’t predict how well new technologies will perform, or what all the failure modes might be. Successful innovators learn early on to develop iteratively, getting feedback from customers and other partners early and often. Among software developers, these iterative development methods came to be known as Agile Software Development.

Agile Software Development replaces waterfall for software teams.

Agile development methods evolved to support software teams, and apply well in contexts that look like software development for apps or SaaS models. In this model, the cost-of-change is very low, and can be driven even lower with things like automated regression testing. Since the cost-of-change is so low, teams don’t need to pay attention to getting everything right in the beginning. In fact, the fastest way to learn in this space is to put stuff out there, and see what reactions come back. The first-pass version will be wrong, but that’s OK. Teams will learn a lot and can turn around fixes fast.  

They run into trouble if they can’t fix things quickly, or can’t validate their decisions right away. When building a physical product, it can be months between the time when a decision gets made and the first natural point to find any problems with that decision. Then fixes can also take a long time, especially if PCBs or manufacturing tools need to be fixed. The result can be weeks or months of delays, or the need to drastically cut scope or profitability expectations to meet a fixed release date, all of which affect complex dependency chains of downstream activities. Cost-of-change and plan complexity skyrockets this late in development, and yet there is nothing the team can do because the seeds of the problem were planted in early development..

Rapid Learning Cycles helps hardware teams achieve agility.

Rapid Learning Cycles is tailored for areas of innovation development that have high cost-of-change and high uncertainty.

Teams recognize that some of their decisions (Key Decisions) need to be made with high confidence because they will be difficult to change later. So teams set out to pull learning forward about these decisions so that they have fewer surprises. Then they push these decisions as late as possible to give them more time to learn, and for new information to emerge.

This also ensures that the decision will be validated closer to the point in time when it was made. If the team does have to make a decision like this without all the knowledge they need, at least they know the risk they’re taking. When teams make these high-risk decisions with greater confidence, the uncertainty of the overall program goes down.

Eventually the team reaches a point when they spend most of their time executing decisions that have already been made. Since supply chains, production and distribution have complex dependencies, teams use traditional tools to manage late development.

Traditional tools have their place when used appropriately.

Traditional development methods work well in areas with high cost of change — but low uncertainty. They have robust tools for managing change and risk, while keeping track of complex dependencies between different activities. Most teams that build a physical product use these tools to manage the execution phases of development, once the product design has frozen.  

The diagram above shows that a well-rounded innovation program leader building a product that is a bundle of hardware, software and services, needs to be familiar with all three styles of program management.

The earliest phases will use Rapid Learning Cycles to define and set direction for the overall program. Hardware developers will use Rapid Learning Cycles to make Key Decisions related to their design, and then move to traditional tools. Software and service developers will use Rapid Learning Cycles on some Key Decisions of their own, and then migrate to Agile Software Development.