Thinking Like a Product Manager

Eleanor Stribling
productized
Published in
5 min readSep 30, 2019

Part II — Containing Complexity
If you missed Part 1, you can read it here.

Complexity, and how to manage it, is one of the toughest things a Product Manager needs to do in order to be successful. This is especially true entering the Senior PM and above ranks where projects become more multi-faceted and dependent on other teams, technologies and market factors. Crafting a message that will encourage stakeholders to fund the project, promote the product and partner with you on making it better is essential, but it is HARD.

In this post, I’ll show you a straightforward framework that I have been using to help me create better comms.

What is containing complexity and why is it important for PMs?

If you’re an engineer or a designer, you already contain complexity all the time as you develop products by doing things like refactoring your code, writing docs and copy, and paring down the plan for UX by showing the most important information. If you work with a PM, you’ve probably worked partnered with them on tasks like these, and I’ll write about this in a future post.

For PMs, containing complexity extends into the vast and unpredictable world of buy-in from the rest of the organization. Even the most beautifully crafted, strategically important product risks failure if the PM can’t get the rest of the organization to support it.

Think about what it takes to get to a product launch. Unless you work in a tiny company where everyone is doing three jobs, you need other product teams, the executive team, marketing, sales, support/customer success, partners and possibly half a dozen other departments to be both on board and not running in a dozen directions. Each direction adds complexity, confusion and risk.

If the PM does not manage complexity effectively within the company, you could confuse customers, create unnecessary communications gaps and delays internally, and ultimately lose market share and customers.

Some of this can be mitigated in the design and development stages — a confusing and poorly built product makes everything harder — but in this post, I’m going to focus on what the PM does beyond that process.

It’s fundamentally about de-risking your project with two things: aligned incentives and messaging.

An unlikely starting point

When I first had trouble with complexity, hearing comments around the office that a new product was in “bad shape”, I assumed it was a problem with what the dev team and I had built, especially since I was also the designer at the time. After a number of deep dives with the engineering manager into how everything worked, I began to realize the problem wasn’t there — it worked completely to spec, the interface was clean, the data was correct, it was performant and documented. The problem seemed to be about how we were positioning what we’d built. When people in different parts of the company thought we were building something else, or didn’t understand why we were sinking resources into something that didn’t help us grow the company directly, minor chaos ensued. The chaos increased after some of this confusion got to our customers. We were able to contain and reverse it, but it was a close call.

I fell back on my business school training, going back to my notes on the course I’d TA’d years before, but also strategic frameworks, templates that management consulting companies come up with to work with their biggest multinational conglomerate clients to contain complexity on huge business decisions.

The one I’ve kept coming back to is surprising because it has been around for decades and was built for a totally different use case: the Balanced Scorecard.

Here’s an example of what the balanced scorecard looks like, with content that looks relevant to a big manufacturing business:

Source: Harvard Business Review — https://hbr.org/1992/01/the-balanced-scorecard-measures-that-drive-performance-2

The goal of the Balanced Scorecard is to focus on the most important objectives and measurements for the company’s performance in a way that’s streamlined enough to absorb but still comprehensive enough to be meaningful.

The four boxes in the picture above represent four perspectives, listing goals and measures for each:

  • Financial/Shareholders
  • Customers
  • Internal business/Operations
  • Innovation and learning/Continuous improvement

Adapting the Balanced Scorecard to Product Management

While maybe the details in the boxes maybe aren’t as relevant to a PM as they may be to an exec in a Fortune 500, here’s how I think the themes translate into questions a PM should be asking…

Translating the scorecard boxes into PM questions

There are two broad themes on the diagonals:

  • Stakeholder Communications: addressing how the organization engages with the product and customer pain; and
  • Delivering Business Results: how the project will help the company grow and move the whole organization forward into its next phase.

In the most PM-y way possible, I turn this into a worksheet, like so:

Framework updated for PM use

Looks simple enough right? Here’s how I use it:

  • Create a row for each segment of customers — for example you might have companies of different sizes, in different regions, etc.
  • Create row for each department in my company that needs to be involved — depends on your company size, but in most cases the exec team, (product) marketing, sales, support/success and relevant G&A groups (e.g. Accounting, Finance) should be there.
  • For each stakeholder group, fill in the value proposition and what they can measure to know the product is helping them be successful.
  • Run this by key individuals in each group to get their input on if the value and measurements are likely to resonate.
  • Use your updated doc to put together your communications strategy.

As always, with frameworks, the value of this to me is that it focuses my thinking on what information I need to have to get to the next step. Rooting it in the Balanced Scorecard categories helps me make sure I didn’t miss anything fundamental.

What do you think — would you use this framework to contain complexity for customers and colleagues? If not, how would you modify it?

Are you looking for a steady stream of insights for building better tech? Need help understanding how these pieces fit together in a real life situation? Or in translating the data you gather in the empathy map into a vision and strategy for your product?

Click here to join the newsletter list and learn more about the upcoming online course, and click here to follow productized on Medium.

--

--

Eleanor Stribling
productized

Product & people manager, writer. Group PM @ Google, frmr TubeMogul (now Adobe), Microsoft, & Zendesk. MIT MBA. Building productmavens.io.