How product managers can learn to balance tactical and adaptive performance

One of the most profound articles I’ve read recently is this one about the differences between tactical performance and adaptive performance, published in HBR. It’s profound because the findings are, in hindsight, so obvious. People who are more adaptive tend to perform better. People who follow strict processes and rules (rather, tactics) tend to perform reasonably average.

If there’s one thing every product manager should care about, it’s high performance. Without that, every measurable outcome of your product will suffer.

So, if adaptability leads to higher performance than process and tactics alone can, why do product managers spend so much time discussing process and tactics (e.g. Scrum, Waterfall, Kanban, etc.) versus concepts like ownership, self-management, and learning, some of the hallmarks of adaptability?

Product Teams are Better When They Can Adapt

Being adaptive doesn’t happen at the expense of being tactical. Instead, being tactical in the right way opens teams up to become more adaptive.

Tactical performance is required when you need consistency or scale — for example, every barista should follow the same recipe for a caramel macchiato, and every engineer should follow the same process for checking in code. Where you need tactical, ask if you’ve created the tools, checklists, and process flows that help you operate as efficiently as possible, freeing up some of your people’s time to focus on being adaptive and improving their work.

Scrum, for instance, provides teams with ceremonies. Each ceremony is designed to accomplish a few specific tasks that, when taken as a whole, can help product teams deliver high-quality software. But, not every team practicing Scrum delivers a high-quality output. That’s because the content of the ceremonies is left up to the team. I’ve watched stand-ups devolve into a back-and-forth between devs and QA about defects that aren’t even part of an active sprint. I’ve participated in sprint plans that ended way too early, only to have everyone wonder what they were supposed to be working on the very next day.

We had the process right in front of us, but we chose to fill it with unhelpful content.

I’ve also been part of sprint plans where every member of the team took ownership over the entire product’s quality. Instead of blindly estimating stories based on the requirements I wrote, the team freely discussed what needed to be done to build the best product and estimated what work needed to be done to accomplish our objectives within our timeframe.

Why Product Managers Get This Wrong

I hear more horror stories from dev teams that position the product manager as an evil dictator than I do tales of product managers who ruthlessly defend the user and position the user’s needs as requirements. More often than not, product managers are siloed from dev and design, taking orders from stakeholders further up the ladder than they care—or are paid—to challenge.

In these environments, it’s simpler to understand your role, discover the boundaries within which you should play, and grow tactically within those confines. When everyone on a team thinks this way, it becomes impossible to be adaptable. Following rules becomes more important than solving problems. Individual performance is more highly valued than team delivery. Time spent working is more important than the outcomes of the work.

Only when a major issue with the product is discovered in production or golden features fail to achieve the company’s KPIs do product managers begin to question the quality of the team’s performance.

What Product Managers Can Do to Help Teams Become More Adaptive

Product managers alone cannot force teams to become more adaptive. Adaptiveness is a characteristic embodied by the team. It can’t be ordered any more than a company’s CEO can suddenly change a company’s culture overnight. The authors who published the study written about in HBR suggest three principal objectives teams can put in place to help balance tactical performance and adaptive performance. Here are some hypotheses about how product managers can apply them on their product teams.

Identify where you need adaptive performance

Not kidding, this quote is taken directly from the HBR article: “[D]o your people know … that it’s OK to challenge the product design if an engineer has a better idea?” In many product organizations, design happens well before dev ever gets involved. Following a tactical performance mindset, product development happens somewhat like a factory assembly line. But, adaptive performance encourages questioning and experimentation.

What if sprint planning were a time to question design decisions? What if, instead of implementing one design, developers implemented two or three experimental solutions? What if we wrote experimental hypotheses directly into our user stories? What if those same stories documented what we thought could happen instead of what we demand must happen.

Implement metrics (without myopia)

If you practice Scrum, then you’re probably pretty good at collecting metrics. Scrum encourages constant estimation and velocity tracking. But, it doesn’t necessarily help us understand the best ways to use the data we collect, nor does it prescribe any methods for tracking post-delivery quality.

For velocity, consider how collecting velocity data across your organization can help you grow and build more effective teams. When teams are siloed from one another, it can be difficult to share performance insights and ensure everyone at the company is growing together.

For post-production quality tracking, consider making a member of your company’s research team an integral part of your sprint ceremonies. When researchers understand—and can help formulate—product hypotheses during development and design, they can set up proper tracking for those features that’s tied to business goals or expectations of the UX.

Set learning goals

Setting learning goals is by far the most difficult activity to comprehend within most Scrum environments. The cut and dry nature of Scrum and its product increments make the idea and outcome of learning seem like an ineffective use of time. However, research has show that, in complex scenarios, setting and achieving learning goals can increase individual performance.

But, how in the world do you do this? In one experiment designed to test the different effects of strict performance goals versus learning goals, a learning goal practiced by participants was to come up with (e.g. “learn”) at least six strategies to achieve market differentiation and implement them. For some people, this may not sound all that revolutionary. But, what the research tells us is that, especially for complex tasks, many of us still have a lot of learning to do before we’re able to master the tasks required to complete something well.

For designers, a learning goal could be to uncover ten different ways that other products (inside and outside of your industry) have solved a particular problem through UX or UI design. For developers, depending on the problem, there can be multiple ways to build a feature or a component of a digital product, and seeking those ways out will break convention and help teams become more adaptive over time.

Let’s Wrap It Up

As a product manager, you can’t force everyone on your team into adaptive mode. What you can do is begin to socialize this knowledge with your teams and encourage others to practice some of these adaptive tactics with you. By being adaptive yourself, you’ll model the necessary performance achievements for your team and, in doing so, showcase how powerful an adaptive mind really can be for doing great work.