WHAT Does A Product Manager Actually Do?

(My Attempt To Map All The Things!)

This is my attempt to synthesize all the various things a Product Manager does. Not HOW we do it (the methods, tools, processes, etc.), but more broadly WHAT we do. Trying to keep all the information I had gathered “in my head” was proving a bit… challenging. So, I created this ‘map’ to make sense of it all, if only for me.

Note, while this looks a lot like a canvas tool, and I suppose you could use it that way, I’m thinking of this more like a map of the territory, to which specific things (like canvases) might align.

Before we jump into each section, here’s a quick overview/orientation:

There’s a center with Core Activities, ringed by Secondary Considerations, all of which sits between Customer and Business Priorities.

We’ll start with the Core Activities 🎯, and move out from there!

Manage Risks & Priorities

Managing priorities is at the core of what PMs do; the biggest priority to manage tends to be the the risks associated with any endeavor. “How do we know if we’re building the right thing?” feels central to all a PM does. This is where ideas from Lean Startup, Continuous Product Discovery, Testing Business Ideas, and other flavors of product discovery come into play.

Example Tools/Activities:

• Assumption mapping
• Hypothesis testing
• Learning backlogs
• JTBD four forces diagram
• Roadmaps (the good — outcome focused–kind!)
• Pre-mortems

This is where I’d ask questions like: “What assumptions do we have? What must be true in order for us to be successful?”

Even things that are less discovery oriented (e.g. the prioritizing the product backlog) tend to be about risk reduction — e.g. ‘What are the opportunity costs of focusing on this one customer fire, if it means delaying launch of that new feature?’

⬇️ Going down from this center, we have…

Clarify Unknowns

Second to managing priorities is clarifying all the unknowns–mostly technical (acceptance criteria, ticket details, etc.) and people related (who should be involved, and in what capacity?). Oh, and let’s not forget prioritizing the backlog! Things related to process might also go here. Also, all the exhausting documentation that comes with the job would go here. I’m sure there’s more that I’m not thinking of, but “Clarify Unknowns” feels like a good catch all for these tactical things. This is about spotting places where there is uncertainty that can be removed, and removing it, for your team and others. I arrived at this label after repeatedly asking myself “why” do we do things like write tickets or fill out RACI tables, with the consistent answer being to Clarify Unknowns.

Example Tools/Activities:

• Writing tickets and acceptance criteria (more at epic and sometimes theme levels, but story/task level guidance as needed)
• RACI/DACI stuff (you can also try to “Manag[ing] stakeholders more effectively with AAI”)
• User Story Mapping
• PRDs 😝, PRFAQs 🤩, release plans, and other written documentation
• All things prioritization (MoSCoW, Kano Modeling, RICE, ICE, Importance-Difficulty Matrix, Forced Pairing, etc.)
• High touch followups: Loom overviews, written messages, visual explanations, 1:1s, weekly updates and reports, etc.
• Coordinating new releases with product marketing, customer support, sales, and other affected groups

This is purposely placed south of this center, to suggest (conceptually) going deeper into the weeds/details. I also like the hand-off relationship suggested between the risk reduction activities at the core, and the passing on of validated or more clearly defined work of product delivery, here.

Understand, Work Within, and/or Challenge Constraints

Digging even deeper into the details, we uncover all kinds of constraints. These can be:

• technical (legacy code, vendor APIS),
• regulatory/legal (HIPPA, GDPR, SOX, etc.),
• political
• budget related
• related to team skills,
• calendar-oriented (verticals like EdTech, tax software, and eCommerce are all tied to seasonal events)
• security & privacy related
• process & approval related

…to name but a few constraints (thought there are many more).

I carefully chose the verbs Understand, Work Within, and/or Challenge. Understand, because well, if we don’t Understand these constraints, we’re going to get blindsided pretty quickly. Work Within is the normal response to constraints. But, ever the rebel I am, I feel many constraints can and should be Challenged. Mwuhaha 😈. Oh, and there’s another post I could write about separating out perceived constraints from legitimate constraints…

⬆️ Going up from the center…

Focus on Core XP

Identifying and focusing on the core experience is a something I’ve picked up (synthesized?) from several sources:

• Game design, where a singular, desired experience (feeling) drives every design decision
• Amy Jo Kim adopted this idea into her Game Thinking approach, where she talks about the Core Learning Loop (labeled below as ‘Habit Building’)

• While more content focused, The Core Model from Are Halland was one of the 1st times (2006?) I saw heard someone talking about paths into and out of a core experience.

The common idea is this: Once you know the core focus of your experience, you can use this to drive all kinds of activities:

• Adding features
• Eliminating features (!)
• Pushing back on customer requests
• Prioritizing the backlog
• How we design a feature
• Delaying Releases
• How and what we test

You want to ensure everything supports this core interaction loop. Else, you risk your product becoming a bloated kitchen sink of features, with no coherent purpose.

You can even end up with the same set of features, but how they’re designed can either reflect or overlook an awareness of what the core experience is all about.

Same features, but HOW they’re designed can make all the difference!

I might have first encountered this idea, if indirectly, from Alan Cooper’s book The Inmates are Running the Asylum, where he suggests we Design for Just One Person: “A minivan for Mom, a pickup truck for Joe, and a sports car for Seth.”

Reminds me of The Homer

That passage is about personas, but the end result is the same: Without a narrow design target (be that a person or a concept), we end up with an unfocused mess — something that tries to be everything to everyone, and in doing so satisfies no one.

While this is an exaggerated example, what tends to happen is we lose site of this core through the slow, steady addition of features… until… one day you find that no one can consistently articulate or agree what your product is about. As PM, I feel it’s important to focus on and be a champion for this core experience.

Support and Shape Product Vision

Of course, none of the immediate work of a product team is done in isolation. Your work should align to something bigger, either a future vision you’re building toward, or a broader constellation of experiences. This is where we have things like product strategy and program management. Understanding how the work you’re doing today supports and shapes the product vision is a fairly important consideration!

Obligatory Voltron reference. You know, because of how the 5 flying robot lions fit together to form Voltron?!

As with ‘challenging’ constraints, I want to call out ‘shaping’ the product vision. Too often, I see product teams who only support the vision, even when things don’t quite feel right. I believe there’s a reciprocal relationship between the larger intended vision, and what you’re learning, feet on the ground. A good vision is mutable, and will change over time, hopefully in responses to ongoing learnings, which come from the frontline teams. Hence, as much as a team should support a vision, they should also be contributing back, and shaping it. ‘Challenge’ isn’t the right word (too adversarial), but ‘shaping’ feels right.

A note on the placement/structure of these secondary considerations: I like the placement of and symmetry between the Product Vision area and Constraints. They’re not necessarily immediate concerns, but they are both part the broader, extended, system of concerns we work within. One (constraints) is about diving down into the weeds/details; the other (product vision) is more about elevating your perspective, getting above it all, to see the big picture.

All off this work sits between the business and customer priorities.

⬅️ Let’s slide to the left, and talk about customers…

Identify Ideal Customer(s)

Here is where we focus on WHO we’re serving with our product or service. I use the term “customer” as a general term for all external stakeholders. While I’m primarily thinking about the the person who gets value from what we’re building (user), we would also consider other roles, such as when the person paying for the tool (customer) isn’t the person using the tool, or when there’s a constellation of people several degrees removed from the immediate decision who set budgets and approve all IT purchases. But, let’s stick with the customer as user persona.

For new product discovery (what I tend to focus on), I’ve found these fundamental questions invaluable:

• What is the problem?
• Who has it?
• Are they aware they have this problem?
• How are they solving it today?
• Are they looking for a solution?

All of this can come from direct interactions with customers, but I’ve also found sales and customer service teams to be good sources for staying close to customer needs.

When the big idea comes from within (e.g. the CEOs brilliant idea!), I love asking the simple question: “How do we know this is a problem?’ This is a non-confrontational way to either surface assumptions (that we can test), or learn what we don’t know about how this is actually a problem.

This is also where I’d place useful frames like “Is our product a pain reliever or vitamin?” or more activity focused approaches like that of Jobs To Be Done.

Identify Need(s)

This is where we dig deeper into the problem, and the needs sitting behind that problem. Needs can be functional, but also aspirational, emotional, social and so on. Lots of needs! This is where really great research can uncover the latent needs that really drive engagement. There’s often the stated need (give me this feature!), then the actual, deeper need (here’s what I’m actually trying to do…). There are timeless needs, the kinds of things futurists use to drive innovation. There are physical needs, often in the more tactical form of accessibility requirements. There are the needs we can identify by reframing the problem in terms of Jobs to Be Done. Going old school, there are the different types of needs identified by Jump Associates: Common Needs, Context Needs, Activity Needs, Qualifier Needs. Oh, and we haven’t even mentioned Maslow, or my own Hierarchy of UX Needs model!

Various ways to think about needs!

And if you really want to go off the deep end, we could start talking about deeper Drives and Motivations 😳 — we won’t!

Needless to say, needfinding is a rich and complex thing. 🤪

This is also where I’d place activities like Customer Journey Mapping, as an actionable representation of these needs, and a guide to where we can support or intervene.

A Customer Journey Map. Source

Assess Possible Solutions

Yes, this is about “Competition.” But, I intentionally do NOT label this as competitive analysis. Why not? From a customer perspective, people look for potential solutions to a need. They don’t think about competition, per se. At least not like we do.

I favor this customer centered perspective for at least 2 reasons:

1. This perspective does include direct competition, but also adjacent, indirect, potential, and emerging competition. For example, I spend a lot of time thinking about visual collaboration tools — while Miro and Mural are big players in this space, I find myself looking out at things like PKM software and visual programming for novel ways to use an infinite canvas.
2. This perspective also lets us think about competitive experiences, that competitive analysis tends to overlook. If you work in the travel industry, for example, your competition isn’t just with other travel services; you’re competing for discretionary income, which could be spent on a vacations or a new big screen TV. This broader thinking about competition comes from literature on disruptive innovation.

Adopting a competitor mindset closes us off from seeing all these other customer choices; focusing on solutions to needs opens us up to more possibilities — and new ideas.

I’ve also learned, especially for larger established companies, you’re competing against your ability to satisfy current customer needs. Listening to your customers, and reducing churn can create more value than chasing after that new feature your “competitor” just announced. I’m kind of with Bezos on this one: “If we can keep our competitors focused on us while we stay focused on the customer, ultimately we’ll turn out all right.”

➡️ Shifting back to the core, then, the primary customer related job for the team is to…

Gather & Monitor Feedback

This is where we listen and learn from our customers. Depending on the situation, this can be qualitative or quantitative feedback. It could be about attitudes, behaviors, or performance. Really, any mechanism for learning from or about customers could go in here, from monthly Customer Councils to monitoring usage data. It’s frustrated me for years that when it comes to learning about (or from) customers we have at least three, traditioanlly siloed areas: Product analytics. Customer Research. Lean experiments. Years ago, I created this simple visual to think about the menu of ways (regardless of origin) we can gather customer input:

This includes upfront customer researcher. But this is also where we think ahead of time about the types of activities we’ll want to monitor, and how we’ll set up code to do so.

➡️Let’s slide all the way over to the right, and talk about the Business…

Support Business Goals

“Does solving this problem serve the longer term business strategy?”

We do all of this work to support business goals. We need show how this will make money, or save money, whether indirectly or directly, now or later. For all of the day to day challenges and pressures, it’s critical to never lose sight of the fact that this project, this team, your position — these are all of this is an investment, in hopes that it will pay off. In the same way that your work aligned to broader product strategy, that vision in turn should support a business strategy. You should be able to articulate how your work supports the stated business goals.

Trying to bring a bit of a mission focus, I like to add this question for consideration: “How is the world better (or worse?) if we’re successful?”

Champion For and Support Team & Vision

Honestly, I wasn’t sure where, exactly, to place this section, but… I know from experience that a vital part of the PM role is being an internal champion for your team and for the work you’ve been assigned. Your team needs to know that the work is seen and valued by other groups, that it’s meaningful to the business. This includes a never-ending road show, where you repeat the same message, share metrics and learnings, and generally listen to other teams to make sure the work is attuned to everything else that’s going on. More than just outward broadcasting, the teams needs to know you’ve go their back, and are also working to clear obstacles that would slow them down. You need to be champion for the vision and the “Why?” of it all — both externally (within the org) and within your team. It’s all too easy to drift into focusing on tickets and sprint releases, and lose sight of what we’re really after with all of this work.

The Three Bricklayers’ story illustrates the power of purpose. Source

⬅️ Shifting back to the core, then, the primary business related job within the team is to…

Drive Toward Outcomes

This is where we answer the question: “How will we know if we’re successful?” We do this by bridging business goals (and product vision) with measurable outcomes. Depending on the nature of your team, this can be OKRs, KPIs, Desired Outcomes (with minimal and ideal conditions of satisfaction), or some other quantifiable way to hold your work accountable to some agreed upon measure of success. This is also where I’d include things like vision narratives and experiential prototypes, stories that clarify how the work of this team fits into a broader strategy; while not as quantitative, this still serves as something we can check ourselves against at a later date.

Finis?

And… that’s it!

This is how I am (currently) making sense of WHAT (again, not HOW) a PM does. Agree? Disagree? See room for improvement, or something I’ve missed? I’d love your feedback!

One final note: As I was writing this post, Christina Wodtke posted a simple reminder:

Interpersonal skills will always be at the heart of the most important role of PM: getting every one pointing in the same direction and working effectively together.

💯

100% agree! While you can see traces of this in a few of the areas (e.g. Champion For and Support Team & Vision), I would say that interpersonal skills show up in how you do just about everything I’ve listed here. Interpersonal skills aren’t confined to a single box! 😜

A bit on the structure and origin of this…

This began as a post on Mastodon:

I’ve been thinking about what a Product Manager does. I was reviewing frameworks like CIRCLES, but felt like that was incomplete/off and (more to the point) doesn’t show relationships between different activities. I whipped this up (in preparation for a job interview).

Thoughts?
Pink stuff = what exists
Blue = what we (mostly) control
Purple = where those things overlap

(Detailed description in the alt text)

ALT TEXT: A visual model illustrating relationships between various activities that a product manager does. At the core, a PM will Manage Priorities, Manage Risks/Assumptions, and Manage Experiments, while also Focusing on the Core Experience. This is done while being pulled to Align / Shape the Product Vision(s), and while being dragged down to Work Within/Alter Constraints (e.g. team, technology, regulations, timing, etc.). None of this is in isolation though; it’s all situated in an external Context, where you must consider your Target Customer (and their identified needs) and Possible Solutions (competition, alternative experiences, etc.). At the intersection between what a PM owns directly, and the external context, are two sets of things that must be continually monitored, as they feed into the core duties: Ongoing Feedback (Qualitative and Quantitative), and Outcomes (Metrics, OKRs, KPIs, etc.).

What I didn’t say is I’ve been interviewing for PM jobs, and got tired of trying to memorize all the useful things about how I work, etc. Frustrated by this, I took my own advice about organizing information for understanding, and decided to structure the various questions, tools, activities etc. into a map of sorts. That’s the real story behind this! Making sense of things, if only for myself. 😛

After working on this more I realize I’ve answered a question I kept asking when I first (formally) transitioned into a PM role: “What should I be doing as a PM?” Yes, I know the mantra: You are not your title. But, as I was finding my way around, I kind of wanted to understand basic expectations (?!) of someone in this role <cough> Imposter Syndrome <cough>. This was something I’d bring up with my team, and my manager. My manager was really good about emphasizing that I was in the role for who I was — just keep doing what I do well 😊. With my team, I tried to look for the unmet needs that I could help with — regardless of my title. But, given how broad and rich product management is, and all the many — MANY — things that a PM touches, I never did feel like I had a good grasp on the scope of the role. Now, I feel I can confidently answer what it is a PM actually does. And yes, the specifics will vary with every team and org!

Speaking of which…

Did I mention I’m looking for my next PM role? If you know of a position that could benefit from my kind of thinking, let me know!

Link to my LinkedIn Profile