What’s a product manager and what do they do?

In software companies and other places where software is built, some people describe themselves as ‘product managers’. What do these people do? What do you have to know to be one, what should be on your radar?

Here are a few bullet points I’ve collected from the on-line course Becoming a Product Manager: A Complete Guide on LinkedIn Learning. I took that course because I wanted to consolidate what I thought I already knew about product management. I’ll talk about my own experience in this field at the end, but before that, let’s dive in. What do product managers do?

• Managing things, not people. A product manager is not the same thing as project manager or team leader. A product manager is not a manager of people and isn’t anybody’s boss. A product manager’s day job is to worry about the well-being of a product (an app, a website or something like that) and push for its success by exercising soft power and getting all stakeholders to understand one another: engineers, management, customers, end-users. Product management is a multidisciplinary job description which emerged only recently and which cuts across roles that had previously been separate (eg. engineering versus sales). A product manager “owns” his or her product from all angles; in fact, ‘product owner’ is a synonym for product manager in the scrum framework (about which we’ll have more later).

• Product lifecycle. A product manager understands where in the product lifecycle their product currently is. Once a product has been launched (and assuming that it is a successful, unabandoned product), it is useful to have a mental map of its lifecycle subdivided into stages like introduction → growth → maturity → sunsetting.

• Product development process. If the product has not been launched yet and is only just being developed, its product manager has a clear picture of which stage in the product development process we are at. What the stages are and what they’re called depends on whose books you’re reading, but it always start with stages where we are just “ideating” and researching whether there is a need or a market for the product, continues through “hot” stages where we are actually getting our hands dirty and building the thing, and eventually stages where we launch the product and watch how it’s doing, with a view to deciding whether we want to continue developing and pushing it along its lifecycle, or whether we should abandon the idea before it’s too late.

• Scrum, kanban and all that. A product manager is familiar with agile software development practices, especially scrum. These practices can help you get through the product development process with as little effort and risk as possible. In scrum there are things like code sprints, daily stand-up meetings and kanban boards, and product managers are called ‘product owners’. A product owner’s job is exactly what we have already said about product managers: to talk to users and other stakeholders outside the scrum team, to act as a representative for them inside the scrum team, and to “own” the big-picture success of the product. It’s the product owner’s call to (soft-core) decide which features to work on and when. A product owner is not the team’s boss though, not a manager of people: that is the job of somebody called ‘scrum master’ – although scrum masters aren’t bosses in the traditional sense either, scrum teams are supposed to be consensus-based and self-organising.

• Analysing what users want. It is the product manager’s job to understand and analyse feature suggestions, user needs and requirements, and translate them into doable tickets (that maybe go on the kanban board, if you’re using one). A good product manager knows that, in order to build a product users will love, you need to read between the lines: as someone famous once said, people often don’t know what they really want until you give it to them. A bad product manager only takes the users’ requests at face value and passes them on to the engineers. A good one analyzes why they want what they say they want, what problems they need solved. A great product manager is one who has a foot in the users’ own camp, one who knows the domain for which we are building the product: for example, if we’re building a language learning app, it’s great if the product manager knows from their own experience what it’s like to be a language learner. Another trait that helps is empathy, being able to see things from another person’s perspective.

• Sizing up the market. A product manager has an idea of how large the market or target audience is for their product. How many people could potentially need or want the thing we are building? Are we talking about hundreds of people, or millions of people, or what? And how much percent of this potential audience do we have a realistic chance of converting into users of our product? This is not just for commercial products, either. Non-profit apps, public-service websites and governmental e-services have “markets” and target audiences too. It is the product manager’s job to figure out whether there are enough likely users out there to justify the effort.

• Keeping tabs on competitors. A product manager knows and follows their competitors, both direct and indirect ones (direct: we are a bike sharing app and so are they, indirect: we are a bike sharing app and they are a taxi app, i.e. they are meeting the same or similar user need as we are, but differently). A product manager probably keeps a feature table which compares their product to those of competitors. A product manager is able to explain why and how their product can claim to be better than competing ones. Again, this is not just for commercial products. Even in the public service and in e-government, where we often don’t have competitors as such, we still need to justify our existence against alternatives that existed before or that would exist without us. When digitising a government service, our competitor is how the same service was delivered before, and we need something like a feature table to show that we have actually made an improvement and met some previously unmet need.

• Hypothesis testing. A product manager understands that you can’t just “build it and they will come”. When you have an idea for a new product or feature, what you have is a hypothesis which you need to verify. The hypothesis is that people will want the product or feature, that it solves a problem they want solved, that they will even pay for it. And how do you verify this hypothesis? By talking to potential users and customers (this is called customer development, about which see below) and by testing initial versions of the product on people (this is called building a Minimum Viable Product, an MVP, about which also see below). This attitude of treating your idea as a hypothesis which needs to be verified is part of the Lean Startup school of thought.

• Customer development. A product manager is good at understanding the product’s (actual and potential) customers and users. He or she has a deep understanding of what it’s like to be them. The way I undertand the phrase customer development is not “I am developing customers” but “I am letting customers develop me” or “I am developing my idea of who the customers are”. And to clarify, the concept of customers does make sense for non-commercial products too: a customer is not necessarily a paying customer, it’s simply anyone who can decide to use your product.

• Customer interviews. One part of customer development is having conversations with customers and users. This includes indentifying potential customers/users in the wild you might want to talk to verify your product hypothesis, getting them to talk to you (how do you cold-mail somebody in a way that actually makes them want to answer?), and eventually asking them the right questions (the good ones are open-ended so that the customer can vent freely). The purpose of the conversation can be as open-ended as exploring the customer’s challenges and pain points, or as specific as validating that a specific feature does actually solve the problem it is intended to solve – there are many different types of customer interviews.

• User personas. People who design digital products often like to categorise their actual and potential users into personas. Personas are fake people with fake names we have invented in order to “capture” typical users, to describe clusters of actual users in our user-base. For example, if we have a reason to believe – based on our customer interviews perhaps – that some of the users of our language-learning app are working single parents who only have time for learning in the evening, then we give this profile a name (“Sally”) and this gives us a mental picture we can interrogate. What does Sally need that other users don’t? What challenges does Sally face that we could solve? The point of imagining a named persona instead of just abstract demographics is to mind-trick yourself and your team into more empathy for the end-user, to acquire the magic power to see how your product fits into the user’s world.

• Minimum Viable Products. Building a Minimum Viable Product (MVP) is seen as another step in the validation of your hypothesis. The idea is that before you commit to building the whole thing (before you even have a clear idea what the “whole thing” is), you build a minimalistic version to verify that there is enough interest to justify further effort. Product management people often talk about MVPs as “MVP experiments”: every MVP is an experiment whose purpose is test whether the idea has legs. If yes, great but if not, then at least we can call it off before we’ve burned all our resources and while we have enough steam to pivot to some other idea. In my experience, there are two levels of understanding what an MVP is. For some people, an MVP is an actual product (a website, an app) which, while limited to the barest minimum of features, is nonethess functional and usable. For other people, an MVP is something more “fakey” than that: perhaps just a landing page with a “coming soon” message and a sign-up button, or an explainer video showing a mock-up. In this second, more light-weight sense, an MVP is basically a mechanism for gauging interest, an exercise in customer development (see above).

• Wireframes, mockups and prototypes. A product manager is good at conceptualising the on-screen experience of products through wireframes, mockups and prototypes. What’s the difference between them? They’re points on a continuum between very rough and very detailed. Wireframes are rough line drawings whose purpose is to show the structure and function of each screen. Mockups are graphically designed proposals of what the screens will look like, with colours, icons and all: mockups look almost like screenshots off of the finished product, but they only look that way, they are static images with no interactivity. And finally, a prototype is a mockup with some rudimentary interactivity where you can click on hotspots to more from one sceen to another, in order to simulate how the final product will behave: a prototype is getting close to an MVP (in the more “fakey” sense). Making mockups and prototypes is usually delegated to graphic designers and UX professionals, but wireframes are something a product manager should be able to produce by themselves, it’s not something that requires tech skills. You don’t even need any software at all, wireframes can be and often are sketched by hand.

• Metrics. Product managers are obssessed with measuring the performance of their product, from classical web metrics like sessions and page hits, to business-level ones like: growth metrics (eg. number of new visitors), activation and conversion metrics (eg. number of users who actually signed up or bought something), retention metrics (eg. number or returning users), engagement metrics (how often are people doing some specific action, how much time they’re spending etc.), happiness metrics (“yes they’re using us but are they happy with our service?”) and revenue metrics (how much money does each user generate for us). Which metrics matter and which don’t depends on the product. If our product is a social networking website, then engagement metrics matter a lot, we want people to stay on our website as long as possible. If on the other hand our product is some kind of public service, then engagement metrics are irrelevant because keeping people glued to their screens isn’t part of our mission: we exis in order to help people get something done as quickly as possible (apply for a passport, register as a voter, find the nearest recycling centre...) and that’s it. But, whatever the product, there will always be a lot of metrics you could be tracking, so product managers sometimes use a metrics framework such as HEART and AARRR to guide their thinking on which metrics to track. Last but not least, a good product manager is aware that keeping records of how people are using something has privacy implications, so the data we are collecting about people’s behaviour must never be personally identifiable.

• Specs and epics. Product managers write specifications (“specs”) for products, features and “epics”. An epic is a popular concept in agile software development circles, it’s like a feature but more general: an epic is any bundle of functionality we are planning to bring into the world which is likely to consist of several scrum-type ticket, might take one or more code sprints to build, and may or may not result in user-facing “features”.

• User stories. When product managers are writing specs for features and epics, they often do it in terms of user stories (“as a user, I want to do X, so that I can achieve Y”) and acceptance criteria ("I see a button which, if I click it, does X”).

• Project management software. Even though product managers are not project managers or team leaders, they do use project management software such as JIRA and ClickUp. It’s the place for all their epics, user stories, tickets and code sprints.

• Estimating. Product managers can be responsible or co-responsible for estimating how long something is going to take to build. Estimating is notoriously difficult in software engineering. In scrum the usual approach is to measure something called the velocity of code sprints: basically, you score tickets on how “hard” they are (let’s say on a scale of one to five points) and then you observe, over several sprints, how many points you manage to get done in an average sprint.

• Prioritising and roadmapping. Product managers may have to make decisions about what to build next versus what to leave for later – perhaps using a formal prioritisation method such as MOSCOW (“Must, Should, Could, Would”).

So, this is the story of probably everything a product manager needs to have on their radar. Not everybody who does product management has “product manager” in their job title. You may well have some of these resposiblities on your plate already even if you are officially something else, perhaps a software engineer, a UX person or a product designer.

That is certainly the case for me: I come from a background some people call product engineering, I’m basically a hands-on software developer who often “owns” entire products (in a scrum-like sense of “owning” a product). I only discovered recently that all the non-core, non-engineering work I do has a name: product management. I think I am not alone. Many of us are product managers without even knowing it.