When I am asked for help in hiring a product manager, I typically ask the person to force-rank this list (or something similar). I keep re-writing it, but this is what I used last week.
Force ranking is important, because you can never “have it all”. I suggest they reflect on their actual work-environment…not an imaginary, rosy, future environment. I also suggest they don’t overthink the exercise: certain options are ambiguous by design (and might also rub them the wrong way). The results tell me a good deal about the environment, and who might thrive there.
Note: This applies less to Director level and above PMs, but can be useful for those roles as it helps define the overall product culture. Also…these options don’t necessarily reflect my own perspective on the PM role.
— Force Rank This List —
We are hiring the PM:
- To shield their team from requests and interruptions, while managing external stakeholders and keeping everyone in the loop
- To ensure predictable and timely delivery of features and capabilities
- To translate business requirements into technical requirements
- To build a deep understanding of customer needs and pain-points
- To manage their product and team as a CEO might manage a startup and team
- To formulate, test, revise, and communicate a product strategy
- To act as the “glue” for a team of talented designers, developers, and [other roles like data science, marketing, etc. ]
- To hit measurable and specific goals tied to short, medium, and long-term business outcomes
- To make the final call on design and technical decisions. To make sure the team makes the right technical and design tradeoffs
- To troubleshoot and figure out why their team is not delivering more quickly
- To collect requests from inside the company, put together a roadmap, and make it visible to the rest of the company
- To field external customer requests, prioritize them according to value and level of effort, and then make sure they are delivered quickly without sacrificing quality
- To own the prioritization of the roadmap and backlog
- To delight our customers and make sure we are always improving the product experience
- To call “bullshit” on team estimates, and basically hold them accountable
- Define the “right things” so that the team can “build them right”
- To manage projects from definition all the way through to release
- To provide the necessary context to the team so that they can make reasonably good decisions, reasonably quickly
- To maximize the ROI of the team’s efforts
- To develop a deep understanding of business goals, and then figure out how to leverage design and technology to meet those goals