Training Banner

Thursday, May 28, 2015

Product Manager: You Are a Keystone

I have an overview presentation on product management that I've been refining for years. One of the most interesting slides is entitled "Why product management is hard". Reviewing the slide recently, a theme emerged that I had considered previously but I hadn't thought about deeply: one of the key sources of complexity and confusion for product managers and those who must work with them is the fact that product management spans so many boundaries that are much clearer for other professionals. While I often refer this delicate situation as "bridging" different worlds, I now prefer the analogy of a keystone. In case you're not familiar with the term, a keystone is "a central stone at the summit of an arch, locking the whole together." I like the idea that the keystone sits between two opposing forces, making the entire structure stronger. In this post, I'd like to enumerate some of the ways that a product manager acts as a keystone.

Product managers are a keystone between:

The Functional and Technical Perspectives

In a previous post, I described how the "outside in" functional perspective, which defines the "why" and "what" of a product, is fundamentally different from the "inside out" technical perspective, which defines "how" something gets built. Even though product management accountabilities are functional, in highly technology-oriented domains such as software product management, it is important (if not critical) for PMs to have technical knowledge relevant to their domain and to understand how software is built and tested. Bridging these worlds can be difficult as technology changes rapidly and too much familiarity can constrain what a product manager perceives as possible.

The Problem and Solution Spaces

I've also written about the problem and solution spaces and the product manager's relationship to them. If you read this blog, you know that I think a thorough understanding of the problem space is absolutely critical for product managers. In terms of our relationship to the solution space, you need look no further than our title! We *are not* problem managers; we are product managers! As a product manager, you must identify a compelling market problem and address it with a solution that will generate expected business results.

"On the shelf" and "off the shelf" Professionals

I've previously used the analogy of a shelf as a simple model to demonstrate the traditional accountabilities of a product owner. In my experience, product managers are primarily responsible for getting the right product "on the shelf", or available to the market at the right time at the right cost. Marketing and sales are more often accountable for getting the product "off the shelf". As a product manager, we are often in a unique position to keep these worlds communicating and aligned. I typically use "business reviews" as an opportunity to bring the "on the shelf" and "off the shelf" folks together. I'll write a bit more about this practice in a future post.

Outside the Firewall and Inside the Firewall

Although all members of the product development team should be exposed directly to the "outside world" (including customers), there's no denying that the product manager plays a special role in brokering this communication and making sure each "side" is aligned and in balance. Regularly sharing your experiences with customers and partners is a great way to increase your credibility with engineering and keep them in the loop. Taking a developer or quality professional with you on customer visits from time to time can make development feel more involved and improve your relationship with technicians in general.

Product strategy definition and execution

As a product manager, you're not only accountable for defining your product's vision and strategy (with the help of others, of course!), but you're responsible for making sure it gets executed! On the definition side, you should be working closely with executive leadership and other disciplines to define the right vision and a plan for achieving it. On the execution side, you should be making sure you're doing something strategic every day and "orchestrating" the efforts of others to execute your plan.

Would you agree with my assessment? Are there other "keystone" roles that product managers play?

See more information on me (including upcoming training dates) at


  1. Great post, Greg, as usual.

    After reading your post I've reminded myself of the following statement: "If the product team doesn't do its job, other departments will fill the void". When product management is not established in an organization, other departments might feel frustrated with PMs. They don't understand the value these generalists are bringing.

    And as you say it takes time and hard work to prove the value we're bringing being "the bridge" or the "keystone".

    1. I'd never thought of it like that Daniil. I really like that way of expressing it!