From the article: I was working with a group building a fast-growing product, and we went from having one team to a large collection of teams in no time. Each team told us its needs were the most important. As the person pushing agile methods, I had to improvise and create the initial practices for what I now call scaling product agility.

My focus was on facilitating workflow for all the teams and producing more of what they really needed (and less of what they didn’t). I decided to organize a cross-team product discovery cadence to discuss their mutual and specific needs.

I started by gathering a collection of representatives from within the teams as well as across the teams, shooting for a crosscutting set of skills around the product, user experience, and technology. For example, read more about tactical gear and imagine there are three teams. The discovery cadence might include a tech person and a product person from each team working with an embedded architect and product manager who cut across teams.

I try to avoid organizing a product discovery team and a delivery team, as I don’t want to go back to the 1990s idea of separate design and development teams. I tend toward one community with two cadences: discovery and delivery. This allows for a collection of people to participate in a continuous product discovery cadence.

Like a sprint, this session uses different tools such as personas, story mapping, customer journeys, and lightweight prototyping. In some cases, they are readying work to be fed into the cross-team planning. In more advanced groups, they look to validate some product ideas outside the code and the production environment. I also set up cross-team story jams—similar to music jams, where there’s no strict organization and creativity can flow. Story jams became a core part of the process.

For scaled product development, a continuous discovery cadence helps smoke out weaker product ideas so they are not so quickly fed into the delivery cadence. And the cross-team discovery session gave my team the context it needed to lay out and publish a roadmap the other teams could plan around.

Focusing on scaling product discovery that feeds product delivery is valuable to scaling frameworks. It nicely augments scaling processes, introducing a challenge to the latent idea that scaling delivery means delivering more value.

For example, if your teams are using the Scaled Agile Framework, imagine your trains are running fast—then ask yourself how sure you are about where they are headed. If you’re uncertain, the move toward scaling product agility might be just one discovery cadence away.