To be a product manager is to be in a constant state of trying to clarify what your role is to yourself and everyone around you. It’s relatively new, it’s squishy, and it can look quite different from organization to organization.
There are great books and articles on the subject (e.g. Inspired, The Build Trap, and others in this interactive guide I created) — I’ll let those talented folks go into the details of what product management can look like and how to do it better. In this post, I’d like to humbly introduce a metaphor and visual to help think about the role:
Just as a bridge creates new value by connecting previously unconnected pieces of land, a product manager creates new value by connecting previously unconnected user needs and organization-supplied solutions. - Me (I think)
Product managers help organizations answer questions like:
- What groups of people do we think should / will use it, and how often?
- At what points on either side should the bridge land (i.e. which need <-> which solution)?
- What should be the scope of the bridge (size / type / materials / cost)?
- How much to charge for access, and how to collect the payment?
- What is its build out and maintenance plan in terms of timelines, cost, etc?
- How might the usage and/or landscape on both sides change in the future?
Product managers sometimes have the authority to make some of these decisions, but more often than not, their job is to frame them - i.e. present tradeoffs to decision makers based on the collection and synthesis of information from a wide array of colleagues, such as:
- UX researchers, designers, marketers, sales teams, data folks, etc. to understand user needs and market dynamics on the one side
- engineers, designers, content folks, strategists, etc. to understand the possibilities / complexities around solutions (UX, technology, distribution channels, etc.) on the other side
- executives, finance folks, analysts, etc. to ensure that the type/size/etc. of bridge being proposed is financially doable and that the toll cost is reasonable
The metaphor breaks down (as all good metaphors do eventually…) when we consider malleability. Bridges typically require a bunch of upfront planning time and capital investment, and then more or less stay as-is for a long period of time. For many products, we have the luxury of adaptability — we can (and should!) iteratively approach the build:
- What if it looked like this vs. that? (blueprints / mockups)
- How are users reacting to early versions of it? (scaffolding / prototypes / MVPs)
- How can we continually improve it after the initial build-out? (iterations)
There are other variations of this bridge metaphor that can be useful. For example, strategic versions of the product manager role might center on bridges that "connect the current state of our product / organization / industry to a better future state." More tactical versions might center on bridges that "connect lots of disparate details in order to keep things moving forward."
Regardless, to do the job well requires a ton of coordination and alignment work, and great product managers invest in the smaller bridges that make that possible: between people, departments, conflicting ideas, etc. A helpful way to span these types of bridges is to leverage storytelling elements — I wrote about that in a post about product managers & underpants gnomes – and I hope that this bridge metaphor and visualization prove useful to you in that capacity for your next meeting with the Bobs from Office Space.
“If you are good at building bridges, you will never fall into the abyss!” — Mehmet Murat Ildan.
PS - As I was about to publish, I found this article by Nichole Elizabeth Demeré, which uses the same metaphor but with a focus on the smaller personal bridges involved in the job. You should check it out!