Increasingly product managers are expected to think and operate “strategically”, but, as this post will reveal, it’s a requirement that can lead to misaligned expectations and be full of traps for the unwary.
Surely we’ve all noticed the increased emphasis on “strategy” as a core competency for product managers? Of course, keeping tactical work aligned with company goals and vision is a critical part of any successful product manager’s job, so this trend to ask for more “strategic thinking” from product people can feel like an invitation to take on more meaningful and high-status work. For company leadership too, encouraging product managers to operate strategically can feel like a way to optimize both accountability and empowerment for an often-ambiguous role.
But the actual work of product strategy is neither straightforward nor glamorous, and often leaves ample room for misaligned expectations. What happens when company leadership fails to provide actionable high-level goals? Or when the conversation around “strategy” comes at the expense of understanding tactical trade-offs?
Here are some common traps we’ve seen product teams fall into when asking product managers to take on “strategic” work:
The Autonomy Without Direction Trap
“Teams, you’re empowered!” Frequently with good intentions, leadership decides to empower teams and tell them that they now have the autonomy to solve big problems. During this process however, they fail to give teams direction through a concrete team charter. This results in teams not knowing what goals they are responsible for working towards, and, more often than not, different teams working to solve similar problems. Given the lack of direction, the organization ends up with gaps and duplications. The teams then end up demoralized since they do not feel like their work is valuable to the organization, and do not understand how they fit into the vision. It is leadership’s responsibility to ensure that teams are empowered and that they have clear direction.
The “This List of Things to Build is a Strategy”
Here, leadership is so involved that the teams feel suffocated and have no space to decide what the right thing is to build. CTOs are giving updates at team stand-ups. A line-by-line strategy is handed off to the team, generally with good intentions, but this strategy represents the ideas of the CTO or CPO, it’s not the team’s ideas. Leadership micromanages the team as opposed to empowering it through an actionable vision to guide execution. Micromanagement incurs the risk of very technically complex solutions that do not solve real user problems. Leadership should guide, not dictate.
The “Strategy Theater”
Since strategy work is generally considered to be important and high-status, those tasked with doing this work often like to do it with a great deal of fanfare. Here, the “new company strategy” is rolled out at an enormous town-hall event, accompanied by a beautifully formatted presentation (or, if you’re really going all-out, a beautifully formatted booklet). The message is clear: this strategy stuff is important, and the people who work on it are important. But all this pomp and circumstance can serve merely to reinforce a divide between the more visible “strategic” work and the less visible “tactical” work, even though the primary purpose of strategic work should be to drive tactical trade-offs and prioritization decisions.
The “yes, and” Trap
We want revenue! And growth! And profitability! And efficiency! Oh, and innovation, too! We want to crush our existing competition, AND to expand into new categories! Here, strategy amounts to “make all the numbers go up and to the right all the way forever,” without any consideration to how those numbers might be in tension with each other. This leaves teams unable to prioritize work that might affect these goals in different ways. For example, a piece of work that might increase revenue per user versus a piece of work that might increase the overall number of users. And when it comes time to evaluate whether something was successful, it’s as easy as finding whichever number went up and saying, “that was part of our strategy!” In other words, a strategy of “everything” is functionally equivalent to no strategy at all.
The “Throw it in the Backlog” Trap
Here, every single request is transformed into a ticket or user story, regardless of its importance. The hard work of prioritizing, understanding how each request might affect the user and the business, does not happen. The icebox or backlog becomes unusable since it is cluttered and in no logical order. Everything in the backlog creates overhead and needs to be talked about, so teams should think very thoroughly if something deserves to be there. The backlog and icebox should only encompass the work your team actually plans to do.
The “I am the Strategy” Trap
A good strategy gives teams the tools they need to make important decisions without asking company leadership to weigh in on each tactical trade-off. This puts some leaders in an uncomfortable position; after all, if the strategy is giving teams what they need to get work done on the ground, what is leadership supposed to do all day? Here, leaders constantly intervene to redirect, contradict, or “clarify” their own strategies, in effect making themselves – rather than an agreed-upon and accessible set of goals – the arbiters of what is valuable to the company and why. The resulting bottleneck can leave company leaders feeling like invaluable and irreplaceable oracles of company strategy while making it impossible for teams on the ground to feel confident and safe in their own decisions.
Has your team fallen into any of these traps? Are there any other similar anti-patterns you’ve observed, or ways to avoid or escape these anti-patterns? Leave a comment below and let us know!