Adapted from a presentation originally shared at Yeshiva University’s Katz School of Science and Health.
When starting as a Product Manager, knowing the responsibilities and goals is only the first step. The responsibilities of a PM can vary drastically from team to team or project to project. It is important to have different ways of thinking about the role in order to properly orient yourself. This is a sample of my toolkit that serves as a baseline for how I think about the Product Manager role and any problem, feature request, or new initiative I encounter.
CEO of the Product
One of the common mental models for thinking about product management. Being the CEO of the Product sounds enticing, but it is important to consider what this does not mean.
This model does not mean you will be:
- making unilateral decisions on the direction of the product
- making hiring and firing decisions
- managing cross functional direct reports
It does mean you will be:
- coordinating across the company – regularly talking with legal, marketing, customer service, PR, finance, operations, UX, engineering, etc.
- balancing projects based on current and future needs
- working to understand the market and competitive landscape
- discussing priorities and projects with company leadership
CEO of the Product is a useful model to remind a product manager they have a uniquely comprehensive view of the product. Don’t take this to mean that the product manager is ‘the boss’ though.
Sh*t Umbrella
In the sh*t umbrella model, the Product Manager is acting as protector – protecting the engineers and designers building the product, or even protecting the product’s users. A good sh*t umbrella is a blocker or filter – preventing well intentioned, but harmful, forces from negatively impacting the product. This often comes in the form of incorrect metrics or goals, an incorrect balance of short vs. long term thinking, or inappropriate executive intervention.
For the product team, the umbrella ensures that the changing whims of an executive don’t change the daily priorities, or that engineers aren’t being distracted by daily requests from partners. The PM should be ensuring the team is working on the right projects, that requirements are defined before development starts, and that any change in focus is warranted. Often an engineering team is a company’s most valuable resource – preventing throwaway or busy work is a high leverage task for the PM.
Similar can be true for protecting customers. A PM should be making sure fixing one problem doesn’t cause another and that the product keeps all of its target user groups in mind when maturing.
Bring the Donuts
Made famous by Ken Norton, Product Managers both literally and figuratively bring the donuts.
PMs can have a huge impact on the morale of a team, and the right cheerleader can create or kill a team’s momentum. This is definitely true for the product team – the engineers, designers, and PMs building the product – but, from my experience, it is equally true with business and operations teams. A product manager might be the only one focused on keeping customer service teams motivated to help solve a tricky problem or building excitement among sales teams for an upcoming enhancement.
Bringing the donuts isn’t just acting as a cheerleader though – it is facilitating conversations between the right stakeholders and doing the dirty jobs that won’t get done otherwise.
PM Project Lifecycle
Especially at a large organization or with a mature product, it is important to define what stage a specific project is in. All stages definitely overlap, but thinking through this lens will help inform what the key areas of focus should be for at that time. Many products or features will not survive every transition from one stage to the next – it is important for a PM not to get too far into solving tomorrow’s problems.
Ideation
A PM should always be spending some time with projects in this stage. Understanding customer pain points, defining a problem space, and the beginning of solutioning.
Socialization
For an idea to move forward, you’ll need to properly socialize it. Everything from hallway conversations, formal meetings, or sharing documents falls in here. At Amazon, this is often centered around a PRFAQ.
MVP
Once everyone is aligned on the problem space and solution, organizational concerns like putting the team together and defining ownership are resolved (to some degree of certainty) then you’ll have reached the minimum viable product stage. At Amazon the concept of “minimum lovable product” is also used – the smallest, quickest set of functionality that can be delivered for a customer to fall in love with.
Scale
Once a feature or product is in the hands of customers and we have some data showing it is addressing the problem we are targeting, it is time to transition into scaling and maturing. The team will have to balance paying down tech debt while expanding to support new use cases, new users, and so on. A product lucky enough to survive to this stage may be a going concern for a long time, and a good product managers will already be ideating and socializing what the next steps will be.
Using Mental Models
I find these mental models useful for making sure I’m focused on the right tasks for any given project or team. They are a useful way to train myself to quickly understand a product, and what my focus should be for a specific project. I also use these often when talking with early career PMs to understand their perspective. Product Management is an ambiguous role, and these frameworks help build a shared language.