Pilot Teams

NOTE: This article is by SVPG Partner Chris Jones. He specializes in helping organizations and teams transform to raise their game. This is the first in a series he’s writing on this critical topic. This technique is fairly straight forward, but is one of the most powerful tools to introduce substantial change.

At SVPG, we often work with product leaders who recognize that the way their companies create products needs to change. Oftentimes this happens with a leader who has inherited an organization that needs to be realigned or even turned around. At the same time this leader is creating products, she is also transforming her entire organization and processes around new models of product discovery and development. This realignment can be complex and often impact organizational structures, product planning, delivery processes, and culture.

Adoption Life Cycle

If you’re in this situation, you should consider the rollout as carefully as you consider your desired end state. The technology adoption lifecycle also applies to organizational change. Some people in the organization love change, some hate it, some need higher levels of evidence, and some just need time to digest the change. If you get too excited and roll out a significant change to everyone in the organization at once, then the laggards (those that hate change) may resist or even sabotage your efforts.

Pilot Teams

Readers of these articles understand that great products are seldom planned, designed, developed, and delivered all at once in a huge waterfall. Just like creating a great product, successful organizational transformation requires that teams experiment, iterate, validate, and leverage what is learned into the wider rollout. In other words, it requires being agile (that’s agile with a small “a”).

One of the simplest techniques for facilitating transition is pilot teams. Pilot teams allow the roll out of one or more aspects of a transformation to a limited part of the organization before implementing it more broadly.

Perhaps you are implementing a process of dual-track agile and continuous discovery. Or maybe you want to make individual teams accountable for delivering against business impact goals rather than features or roadmaps. Rather than roll out these changes to the entire product organization all at once, start with a small number of pilot teams (often just one) and leave the rest of the organization to operate status quo.

Choose the Teams

You can modify existing teams or form brand new ones. Selecting the teams depends on your specific goals. Consider these criteria:

People: The success of any pilot team starts with the team members. A dedicated product manager, UX designer and lead developer are usually critical, and depending on your goals there will likely be additional roles. Consider the specific individuals who will be filling those roles. Do they have the skills and mindset to drive the pilot team’s success? Most importantly, are they enthusiastic about the change?
Location: Effective teams need close, cross-functional collaboration. Are the members of the team able to sit together? This means not just in the same city or office, but physically next to one another.
Charter: What is the scope of the product team’s responsibility? To what extent can the work of the team be framed in terms of business outcomes vs. features or tasks?
Autonomy: How much will the work done by the team be dependent on other parts of the organization? Can you set up your teams to minimize dependencies?. Fewer dependencies allow the team to focus on the actual models or techniques you are piloting.

Learn

Once the teams are selected, let them run in the new model for one to two quarters. During this time, it’s important to insulate the pilot teams from legacy processes. This is not always easy, but it’s mandatory for giving the pilot teams a chance to succeed with the new model.

Pay close attention to what’s working and what’s not. Adjust your course (and iterate!) accordingly. Your specific success measures will depend on your goals, but ultimately you’re looking to compare effectiveness in delivering business outcomes, i.e. – how much do the pilot teams movex the business metrics they are are responsible for? How does this compare to your status quo?

Given the nature of the experiment, your comparisons will often be qualitative, but that doesn’t make them any less compelling. After one to two quarters the benefit of the new approach should be clear and the pilot teams will either lead the way to a broader transformation or tell you what’s in the way of change.