I've been mentoring people that are new to product management and more than a few times lately have found myself giving an hour long crash course on what the heck I think product management actually is. So, after a few attempts, I've boiled down all of the things a product manager should do into 6 things. In reality, a product manager does a million things, or at least way more than six. These are more like 6 categories of things a product manager does. In truth it's a bit of an arbitrary number of buckets, but I've found it really useful when trying to boil it all down. I'll give you a quick pithy definition of each thing, and a suggestion of an artifact to create to get started in each domain.
1) Own The Strategy and Roadmap
A product manager has to be own the Strategy and Roadmap of their product. The word "own" might mean different things in different situations. Almost everyone has bosses, and different roles have different levels of ownership and autonomy. But, at the end of the day, whether you're the Chief Product Officer of a 5-person tech startup and own the whole decision, or a product manager in a big tech company and own part or all of the decision, you're practicing the same discipline.
Strategy
When creating a strategy, you're trying to answer a few questions:
Where are we now? Where do we want to go? How do we get there? What might happen along the way? What is your product's purpose? Who are your customers? What are you finances? What is the competition? What resources do you have?
Required Artifact: To get started defining and/or communicating your product strategy you may create a strategy deck or one-pager. There are many schools of thought around strategy definition which I won't go into here. The important thing to do is pick one, and write it down. Writing down your strategy in an artifact is part of the table stakes of being a product manager.
Roadmap
A roadmap is a graphical representation of what features your product will have over time. Usually the x-axis is time, and you're showing customers and/or stakeholders what will be built into your product over time.
Required Artifact: A roadmap! Fire up PowerPoint and use a roadmap template, or find one on google. Pick one, and write it down.
2) Be The Voice of The Customer
It can't be stressed enough: Product managers should know their customers. Like really know them. What's important to them? What do they spend their time on? What do they like? What don't they like? What do they eat for breakfast? Ultimately it's the product manager's job to ensure their product works well for the customer, and the only way to do that is to know what customers need. There are two kinds of customers: Stakeholders and users. You should know both.
Stakeholders
Stakeholders are people that represent a contingency of your users. For example, if your product is an HRIS system, your end users might be employees, but your stakeholders might be the HR managers that decide which HRIS system to use and which features are important to their business unit.
Users
Users are simply the people who are actually using your project day-in and day out. They're the ones logging in, pressing the buttons, and presumably getting value out of your product. If we continue with the HRIS example, they're the employees that have to log in to change their address, or download their W2, or check their goals for the quarter.
Product managers typically write user stories in the backlog to represent features that users want. (Hey, that's number 3!) The user is a major component of a user story, and it is extremely important to understand what your user wants, and why, so that you know why your product exists. Did you learn all about your target user? Write that down.
Required Artifact: User Persona Document
3) Manage the Backlog
What's a backlog? It's an ever-evolving list of all of the work there is to do on your product. Ideally, it's stack-ranked with the most important work to do at the top of the backlog. As a product manager, it's your job to define what features your product needs to have, and to order those features in priority order.
User Stories
If you're managing a software product, the written work is usually represented in the user story format. There are many user story templates. Pick one, adopt it, and iterate that template as the needs of the team change. Fundamentally the story should contain 5 things:
The user - Ideally, the "user" that is referenced in the user story is a documented persona that you wrote down in number 2 above!
Description of what the user needs to do - This can range from simply a plain description to a fully-designed UI with components that should be used and mocked up screens for how it should look.
The value that it will bring the user - In other words, why the heck does the user want to do this?
The definition of done - This tells the engineer implementing the feature what success criteria they must meet in order to call this work complete.
Required Artifact: A stack-ranked list of user stories for what features you need to build for your product. This is usually housed in an issue tracker like Jira, GitHub, Azure DevOps, Asana, etc. But, you can start with Excel if that seems overwhelming. The point is you have to write down and decide what features are most important.
4) Market and Evangelize
So you built an amazing product. How the heck to people know that it exists? That's where you come in! Users and stakeholders have to find out about your product. This can look different depending on what kind of products you build, who your users are, and what sort of organization you are in. If your organization is a profit center and you have consumer-facing products a product manager often works on marketing campaigns to acquire new users through ads, often called acquisition funnel marketing. If your organization is a cost center and you make products that support internal groups of a company then you need to figure out how to message your target users and stakeholders. For stakeholders, hopefully you have some cadence of meeting with them like a quarterly business review, or 1on1s with key stakeholders, where you can showcase what your product is, what's coming, the strategy, etc. For end-users, you might need to create newsletters, or post on internal company social media, etc.
Required Artifact: Product Onepager - a product onepager should be a one-page document that at a glance communicates key details about your product
Product Description - a plain-English definition of what your product is in a few sentences
Key Features - Expand a little about what are the important aspects of the product
Use Cases - When and why would users get value from your product?
SLAs - What level of service do you guarantee?
Cost - How much does it cost?
How do I sign up? - Where do I go to buy, get, or request the product?
5) Understand the Market
You should aspire to be an expert in the market space that your product occupies. What products compete with your product? What are your product's differentiators compared to the competition? What products are adjacent in the market or in the user's experience? For example, you might be a product manager for observability tools for a large organization. Are you aware of the big hitters in the market and their features? You might use market research firms like Gartner to brush up on the market space. Which vendors make the Gartner listings and Observability Magic Quadrant? Are your customers using these products? Might it make sense for you to sunset an existing product for one of it's competitors? What's the cost difference? This helps in many ways. If you're competing with these products you can understand what your competition has done, what features are differentiators, and what space of the market might be ripe for your product positioned against theirs.
Required Artifact: Market positioning onepager - a onepager that describes how your product is positioned in the market against competitors or adjacent products
6) Own the Business Metrics
Business metrics define how your product is doing. They can be broken down into two broad categories: Financials and Performance.
Financials
If you have an external-facing product, you super care about your Profit and Loss (P&L). What's your profit this year? What's the loss? What is your burn rate? Burn rate, simply put, is negative cash flow—the amount by which expenses exceed revenue. How long can your product go on in this manner?
If you have an internal-facing product, you super care about your budget. Do you have enough budget to deliver on the promises to the business you've made? How are you tracking the budget? What is the cost model for your product? Maybe you have to show back costs to business units that use your product, or maybe you have a chargeback model where you literally charge those business units based on consumption. The product manager must define these.
Performance
Aside from financials, how is your product performing? You probably guarantee some level of service to your customers. Sometimes that guarantee is in a contract or agreement with your customers. This called a Service Level Agreement How do you know whether or not your product is providing that service? Customers might access your product over the web and you guarantee that the page will load in less than 5 seconds. Do you have monitoring in place such that you know when you breach that agreement? What's your product's current average pageload time? When should you start sounding the alarm to your support team? At 4 seconds? At 4.9 seconds?
Required Artifacts:
Financial - Budget or P&L
Performance - A list of SLOs and KPIs
Comments