Applying Leverage as a Product Manager

Brandon Chu
The Black Box of Product Management

--

I get every new PM I manage to read (or re-read) High Output Management by Andy Grove within the first month of joining my team. It’s a timeless, no bullshit overview of what a manager is and how to think about being one. Most PMs do not have people reporting into them, but in all cases they are still managing outcomes that are executed through a team.

There are two critical concepts in that book that I aspire for PMs on my team to internalize: the first is how to measure managerial output, and the second is the idea of managerial leverage.

Managerial output is what you produce as a manager and is succinctly explained the book:

A manager’s output = output of their team + output of the surrounding teams that they influence

Managerial leverage is the idea that some things a manager does creates more output than others, and for each possible thing, the amount of output created per unit of time is its leverage. That’s the basis of how you should decide whether to do activity A or activity B.

When internalized, these concepts impart on PMs a sense of what matters most in their role. They have lots of choices in what they can do everyday — all of which produce some positive output- but developing awareness of where they have leverage is critical to their long term impact.

Here’s a framework that I share with PMs on thinking about leverage in their roles (which coincidentally turns out to be one of my highest leverage activities as their manager).

Some definitions:

  1. Vision describes where you’re going; the aspiration or goal
  2. Strategy defines how you plan to get to your vision in the context of the market/company/customers/product
  3. Scope defines what you need to ship to execute your strategy
  4. Backlog represents the units of work to achieve a scope

What I hope PMs take away from this framework is simple:

Product managers exert the most leverage through vision and strategy — the rest is optimization

Vision and Strategy are foundational. They provide the direction, the inspiration, and enable a group of people to execute as a team.

Scope and Backlog are optimizations. They accelerate progress towards a known destination.

Both are important, but going faster in the wrong direction is far worse than going slower in the right one. When prioritizing their focus, a PM should first ask themselves if they’ve built a solid foundation for their team to operate in. If not, that’s where they need to start.

First Principles of PM Leverage

This framework was built upon an early aspiration of mine as a PM to create the conditions where:

1. Any individual on my team knows how their work directly contributes to achieving the company’s vision. [Vision]

2. Any individual on my team can explain the rationale behind why we’re approaching the goal the way we are [Strategy]

This aspiration is rooted in leverage. Your team is full of smart engineers and designers who know better than you how to build things, so if you start focusing on the implementation details, not only are you exerting less managerial leverage, you’re also diminishing their leverage.

You’re making 1+1 into 0.5 + 0.5.

In contrast, when a PM drives vision and strategy, their breadth of expertise accross the product makes them the best suited to process all the context, and subsequently make better decisions about the direction of the team.

The easiest way to test for good product management on a team is to ask any engineer or designer on that team to describe the vision and strategy for their product. The coherence of their answers will give you all the feedback you need.

Building the Foundation

Vision and Strategy are often seen as wishy-washy concepts, the domain of MBAs with no hard skills. They are in fact critical, and in my experience, most PMs don’t actually know the distinction between the two, nor how to utilize them effectively.

Vision

Vision is used to describe the end state of your team’s efforts. Its primary importance is to provide the organization a succinct understanding of what a team cares about. It represents the heart, the raison d’etre, of that team.

A good vision influences the everyday micro-decisions being made by a team. It should also be the basis of alignment between a product team and their stakeholders.

I won’t go too deep in this post about how to establish a good vision, but I will share one thing that I always remind PMs I manage, which is that the vision they create has to fit into the bounds of the company’s vision (and in bigger organizations, any parent group vision).

Make sure your vision fits into the company’s.

I’ve seen too many PMs come in guns blazing, trying to be the CEO of the product and do epic shit. I love the energy — and their vision should still be ambitious, exciting, and strongly opinionated — but it can’t deviate from the bounds of the global vision, or else they run the risk of a blow-up down the line.

PMs should always be spending considerable time talking to the leadership team in their company to internalize the nuances of the vision. This is true of new PMs and ones that have been there for a while, as the process of vision alignment never really ends. The forces of growth and technology continuously spur up new situations which push a vision — one that was established in much simpler times — into new territory and debate.

At Shopify, we call this staying on the green path.

Strategy

Strategy describes the chosen approach towards achieving the vision. Its primary importance is to intersect the goals of the vision and the realities of the world into a gameplan for action.

Building a strategy is hard because the world isn’t like this:

Instead, there are tons of things to consider that influence your path forward. Should we do feature A, B, or C first? Who should be the first customers we target? How likely is competitor X to do the same thing, and in what time frame? A good strategy incorporates questions like these into a decision about how to proceed.

Again, I won’t deviate into the making of a strategy here, but will leave one thought I see PMs often trip up on.

A strategy is not a roadmap. Roadmaps should be an output of strategy, and good ones will always clearly tie back to one. Real strategy answers what we’re building and why, who we’re going to target and why, how we’re going to grow and why, and how the end result will put the company into a better competitive position relative to alternatives. And why.

Leverage Enables PMs to Scale Efficiently

The final benefit of operating under this framework is that it enables a product manager’s impact to scale more efficiently as they grow in a company. By becoming great at setting the foundation for a team, a single PM can have significantly more impact within an organization by doing that work accross a set of teams.

Next-level pyramid use.

Admittedly, there are still times when PMs do need to drive the optimization portions of the pyramid, particularly in high priority or time sensitive projects where there is lots of executional risk. In those cases, refinement of scope and sequencing materially increases the likelihood of success and value to the company and a PM should be capable of doing it.

Generally though, when headcount is growing quickly and there are more teams ready to build then there are visions to execute, it makes most sense for PMs to build foundations for as many products as they can and then just trust their teams to execute.

At Shopify, we’re now seeing the median PM manage 2–3 products, which in most places would be untenable. I believe this is possible in large part because of the appreciation of managerial leverage within our organization, and because of the incredible team we have in engineering and design.

Are you doing the highest leverage work you can?

If nothing else, I strive for PMs to take this question and make it a mindset.

Make your next hour the most impactful it can be, and assume creating output through your team is the best way to do it. Ask yourself if you’ve established the right foundations for your team to operate in, and if not, build them.

Before you go, some things to consider:

  1. Recommend or share this if you found it useful. It gives me 🔋 to write knowing people find value in it.
  2. Checkout and subscribe to The Black Box of Product Management if you want more reads like this.
  3. If you have something interesting to say about product management, consider submitting to it so we can share your story.

--

--