Rapid Learning Cycles can spread organically in a product development organization, once it’s been rooted in a team. Others see the team members building Visual Learning Cycle Plans, preparing to share their knowledge at Learning Cycle events and engaging with R&D leaders during Integration Events. They see the team designing and running experiments, talking with customers, building small-scale prototypes out of 3D printed parts or cardboard to test out ideas. They see the team getting better results right away.

Unlike many other changes that people have tried to drive into product development, Rapid Learning Cycles does not require a large “management of change” effort — the framework itself pulls the desired changes from teams, and it’s attractive enough to spread on its own. But someone needs to plant the seed. That is the job of the Rapid Learning Cycles pilot team.

What is a Pilot Project?

A pilot project is the first attempt to use a new process, tool or practice. People usually set up pilot projects when they already have a good idea that the changes will be adopted by everyone if successful, but recognize that they haven’t fully worked out all the details about how to do it. The pilot project demonstrates that the new methods will deliver the results that the organization needs, with the opportunity to make adjustments as the new tools bump up against the reality of product development.

The Rapid Learning Cycles pilot team is the first team to use Rapid Learning Cycles in an organization. They normally run this pilot in the context of the organization’s Product Development Process. They usually run Rapid Learning Cycles on a single product development program at first, unless the team runs only small projects.

The “process” objective of a pilot team is to demonstrate whether or not the Rapid Learning Cycles framework will work for their organization: will the framework resolve some of the persistent issues in product development that lead to disappointing results?

Pilot Teams Test Rapid Learning Cycles for the Organization

Until you have a team running Rapid Learning Cycles in your organization, you only have hypotheses about whether or not the framework will work for your company. It may be that you don’t have the problems that Rapid Learning Cycles solves. It may be that your industry is different in some significant way that makes Rapid Learning impossible.

However, we have had good experiences with Rapid Learning Cycles in industries like pharma and medical devices, specialty chemicals, automotive and aerospace — all places with long, slow development cycles that seem impossible to speed up. We have had good experiences in heavily-regulated industries, and in entrepreneurial start-ups. At this point, I can say that the only way to validate the hypothesis that Rapid Learning Cycles won’t work in a given company or industry is to try it.

Rapid Learning Cycles pilot teams work best when they test the framework cleanly, without trying to adapt or modify it too much. Teams often make assumptions about the elements of the framework that seem like they will be resisted by teams or by leadership. If we can get them to try all of the elements, they often find that the teams and leaders are not resistant to these parts at all, when they are presented as part of a coherent framework.

It helps to frame the pilot program as an experiment. That way, the PDP process owners, R&D leaders and key partners know this is a time to be open to new ways of doing things and no one has decided anything about the future of Rapid Learning Cycles for all teams.

The time to make adaptations will come after the team has experience with Rapid Learning Cycles in the context of their organization. They may find that some things that looked like barriers are easy to implement, and some things that look easy are hard to do within their teams. When they do make modifications, they’ll be doing it from a foundation of experience that the team builds by encountering the organization’s roadblocks.

Pilot Teams Encounter the Barriers to Full Adoption

Most organizations have some internal roadblocks that will need to be removed in order to make it feasible for all teams to adopt full-scale Rapid Learning Cycles. When pilot teams encounter these roadblocks, team members gain valuable experience on how to overcome the barriers. Partners gain experience with the need to adjust their processes to meet new expectations.

On a practical level, the team can overcome these barriers with waivers from the standard PDP: permission to delay Key Decisions if that would be best, earlier resource assignments from Procurement and other downstream partners as a one-time experiment, and access to modeling and test equipment, customer and supplier visits, and other resources needed to close Knowledge Gaps.

The typical organization’s PDP assumes that certain deliverables will be completed in early phases of the program. The process attempts to lock down requirements, specifications and system-level design decisions early out of the belief that this is how to make engineering and downstream partners more efficient. If that were true, product development would not take so long.

This is one area where almost every Rapid Learning Cycles pilot team will encounter mismatched expectations, because the framework encourages the team to delay Key Decisions until the Last Responsible Moment, which is often later than the date that these deliverables are approved. Downstream partners are often frustrated with design changes after things are supposedly frozen; now they will have to tolerate things that are not frozen at all. They will need to learn to work within the areas where the team has confidence.

Our experience shows that this is a better place for downstream partners: they can make better decisions about how to sequence their work when they understand which decisions have been made with confidence, and which ones are still outstanding. But they may not believe that until they experience it for themselves.

Pilot Teams Build Internal Proof that Rapid Learning Cycles Work

As a team begins to demonstrate that Rapid Learning Cycles delivers results, and that the barriers to implementation can be overcome, they build internal proof to show that Rapid Learning Cycles works for the organization. All the case studies, testimonials and conversations with peers from other companies cannot replace this direct experience of success.

As confidence grows in the framework, team members naturally decide to use Rapid Learning Cycles on other programs. Program managers decide that this is the only way they want to run programs going forward. Teams continue to use Rapid Learning Cycles after the pilot ends and the team moves into later phases of development. R&D leaders should capitalize on this enthusiasm!

These teams will experiment with aspects of the framework like the length of learning cycles, the way the team’s knowledge library is organized and how they run Integration Events. This is valuable experience to help the PDP process owner determine how to incorporate Rapid Learning Cycles into the organization’s PDP when the time comes.

A successful pilot program won’t quiet all of the skeptics, especially those who remain attached to the idea that locking down decisions early is the best way to accelerate development, and those downstream partners who don’t want to start anything until the teams ahead of them are completely finished. But a set of successful pilots will give the organization’s leaders the ammunition to decide that these attitudes and behaviors will not stand in the way of getting their products to market faster.

That’s when you know that you’re ready for full implementation of Rapid Learning Cycles.

Are You Ready for a Pilot Team?

If you’ve been experimenting with Rapid Learning Cycles in small ways, such as defining Key Decisions and Knowledge Gaps for one aspect of a program, and you’re happy with the results you’ve seen so far, then you’re ready for a pilot team.

If you’ve had a major product failure and your organization is desperate to avoid repeating this experience, then they are more open to new ideas than most people. This is a great opportunity to experiment with Rapid Learning Cycles, perhaps even to fix the product that was such a disaster.

If you’ve been trying to drive Lean Product Development and your efforts have lost traction or face a lot of resistance, Rapid Learning Cycles will pull many of the changes you desire without so much struggle. You could demonstrate this to yourself with a pilot team.

If you’ve been reading about Rapid Learning Cycles and you’re eager to give it a try on your next program, then go for it! Just make sure that you test the framework cleanly so that you build the best case for Rapid Learning Cycles at your company.