Principles of Product Management
Ian Hellström | 27 August 2019 | 16 min read
Over the years I have worked with some good product managers, heard of a few great ones, and endured others who were less than stellar. From these observations and my own experience, I have distilled a set of principles for product managers, a collection of dos and don’ts.
The principles are based on my own experience in data teams and working with various product teams outside the data realm. The principles are not in any order of importance. What I have not listed are general characteristics and responsibilities of a product manager. You can read more about these here.
A PM serves as compass needle. The product manager is not the compass itself, as the true north and orientation are provided by the company and market, respectively. Instead the product manager needs to align the team with the company’s overall direction, to convince people of new opportunities that may lead to course adjustments, and to ensure the work being done in the team contributes to the general direction of the entire organization.
The PM creates the product vision, the overall strategy, and owns the team’s road map. The PM therefore understands the customer’s needs, be they internal or external. With a team that buys into the product vision, the product manager already has a group of strong allies in the company. And in return, the team get to execute a vision and shape an actual product they perceive as both valuable and worthwhile. A product manager who lacks a vision and cannot inspire a team often ends up running around in circles after whomever has an urgent need that can bridge the sprints between larger feature requests; the team is consequently dragged down by mostly reactive work, unless they push back.
Embedded in the role of visionary is the product manager’s preference to ask for forgiveness, not for permission. Without taking any risks, there can be no innovation.
Because risk often entails failure, the product manager is crucial in establishing a culture that sees failure as an opportunity to learn rather than a chance to assign blame. Experience is, to paraphrase Oscar Wilde, merely the accumulation of our mistakes. Any cul-de-sac you walk up and down on your journey to success today, you can entirely eschew tomorrow. Phrased differently, as long as you learn from failure, the time spent is not wasted but rather future time saved.
Impact > Action > Talk
Talk is cheap. It’s better to act and maybe fail than to talk but never succeed. It’s also better to ask a customer or build a prototype to answer a question than to talk indefinitely about it and without (reasonable) certainty.
‘Just do it’ is a good start, but for a team to truly be successful it’s preferable to have a positive impact. One good idea done well is worth more than many brilliant ideas executed badly. Activity for the sake of looking busy is worthless; talk without action is pointless.
One of the key roles of a product manager (PM) is to be the team’s shield, lest the organizational back-and-forth weigh down too much. Why? Because the team needs to focus on their work.
It’s important for the PM to set the priorities of tasks according to the company’s. The PM should also ensure that tasks are not re-prioritized or re-distributed within the organization within sprints. A sense of continuity is important for productivity and morale. Someone else’s emergency does not automatically make it yours. This is not at all meant to encourage an ‘us vs them’ attitude, but rather as a way to protect the team from too many short-term changes. Too often product managers give in to whomever shouts loudest. That’s a lousy way to do business.
It’s not always needed or desired to keep the chaos at bay, but in most cases, the team appreciates a product manager who can aggregate and filter information from various sources inside and outside the company. Team members ought to stay informed of major product-related decisions within the company, but it’s often not clear to team members, who may not have the full context, what impact said decisions have on the team’s workload and near future.
A standard technique in root cause analysis is to ask ‘Why?’ five times. The same applies to feature or support requests. Always ask what’s behind the request to figure out if what people are asking for is really what they need. The PM needs to be ruthless: no matter who requests a feature or needs the team’s support, ask for the reasons behind each request.
When the team proposes a new framework, tool, component replacement, or similar, ask whether that’s really in the best interest of the product. Does it truly solve many of the existing problems? Does it introduce any incompatibilities? Why should it be introduced now?
Too many ‘alternatives’ are introduced that over-promise and under-deliver. At the very least have a time line for deprecation agreed upon with the team that’s communicated well ahead of time to all stakeholders. The team does not want to maintain two functionally equivalent systems. For each new tool, at least one old and equivalent must go.
This persistent questioning also applies to the PM: instead of regurgitating whatever flashy feature has been mentioned in some magazine, ask not what that feature can do for you, ask why that feature is important, irrespective of its novelty. Unfortunately, I’ve seen too many (product) managers swayed by the latest fad.
And if that all checks out, ask ‘Why our team?’
Tasks handed down from other parts of the organization are sometimes landmines: it’s too late to change anything about it once you’ve accepted and stepped on such a task. Be sure as a PM you can identify these ahead of time and avoid them.
This also means to be vigilant for dump-and-run schemes: promises made by team(s) who suddenly claim to be unable to comply, and they are now dropping their tasks on another team for completion. It’s rare for people to fight for an idea yet leave the glory to someone else. It’s been my experience that these are nothing but dump-and-runs: ways to get rid of ignominious tasks that sounded nicer than they really turned out to be.
A team that is not a support or service team should not establish themselves as such by taking on hand-me-downs. Never agree to be the landmine clearance squad. Trust but verify.
That does not mean a PM should be blind to what happens in the organization, other product areas, competitors’ products. It’s important to know what’s going on to anticipate future needs of the market and be in tune with industry trends.
Within the team there is a lot of knowledge about technology, industry best practices, competitors’ solutions, and often plenty of ideas to improve the product itself. Be sure as a product manager to have your own team’s collective brain on the radar too.
You do not want to end up as the company’s designated bulldozer. In a similar vein you do not want to back over backwards to please others either. Strike a balance: stand up for the team and the product vision without seeing the rest of the organization (and perhaps the customers) as a nuisance that needs to be squashed.
Just because the higher-ups have made a decision does not mean you have to say yes all the time or not talk back. Make sure the team focuses on the important, not necessarily obvious things. Upper management is neither omniscient nor in a position to bark orders for others to execute. Five times ‘Why?’ also applies in these situations. A decent PM knows when and how to say ‘No’.
And avoid being a bulldozer towards the team too: software developers love to solve puzzles, so do not offer ready-made solutions. Instead, describe the problem in detail and offer guidance: let the team decide how to best solve the issue. The PM needs to have faith in the team.
But of course that does not mean the PM has to become the mouthpiece of the team and have the tail wag the dog. The PM needs to be clear on the vision and have a sensible road map. Involve the team in the creating the vision, but it’s the product manager who is ultimately responsible for said vision.
Doc, or It Didn’t Happen
Related to ‘5x Why?’ but more formal is to always ask people to show the documentation on decisions. If there is none, it’s a good policy to declare it never happened. No meeting minutes? Sorry, no can do.
A paper trail is not there to cover the team if and when things go awry. It’s about having a decision-making process visible to everyone. The team needs to know it’s working on important matters that have been properly scoped and prioritized. It’s also helpful to explain why certain decisions were made to the team based on actual details that are available to anyone who wants to look at them.
This principle also applies to the product manager and the team. While the team may use lightweight architectural decision records (ADRs) to log technical design choices, a PM can and in my view ought to write product decision records (PDRs), preferably in a similar format to ADRs: in a team repository and with minimal overhead. That way, the team have immediate access to all product-related decisions. At the very least each PDR contains the status, context, decision, and consequences of said decision. PDRs may link to various relevant documents (e.g. slide decks, RFCs, mock-ups, and user research reports). Think of it as a portal to all product decisions, but accessible to the team rather than distributed across many tools with an almost negligible probability of discovery.
While ‘5x Why?’ is about continuity for the team, “Doc, or It Didn’t Happen” is about transparency. Transparency is essential to establish trust in the PM’s ability.
No Santa Claus Tasks
As a corollary, nice-to-have features discussed during chit-chat near the water cooler should never appear on a team’s task board. A product vision is not a collection of other people’s wish lists.
No Crystal Balls
Not all tasks end up on the teams’ to-do list based on what the PM says. Maintenance and support (‘keeping the lights on’) tasks are often team-internal. Still, that does not mean the team’s task board is an accumulation of private post-its.
If someone cannot be bothered to write down what’s needed, don’t expect others to care to pick up these tasks. And if tickets are personal before they move from the backlog to ‘in progress’ they are not team tasks.
The company gives out laptops, not crystal balls. Don’t expect people to know what you meant. Say who wants it, why (background), when they need it, and what’s needed to be considered ‘done’. This comes back to “Doc, or It Didn’t Happen”. A task board is not a collection of personal reminders or post-its. It’s for well-defined and prioritized tasks. A certain level discipline is required. A product manager needs to lead by example. As a developer, I have spent too many hours tracing the person(s) who had originally expressed a fuzzy desire for a feature in a random conversation with a product manager who had made a loose promise and afterwards decided to turn the attempt of ingratiation into a genuine but ill-defined feature request. Such organizational ping-pong can be avoided with a clear trail of documented decisions.
No Wishing Wells
If you follow the rule “Doc, or It Didn’t Happen” you’ll probably not have to go back for clarification, but in case some matter is still vague, it’s important to listen carefully to the rationale. In case the explanation starts with “Well, …” leave it be. These tasks are wishes, not specific needs.
Furthermore, if people refer to “Some people …” in relation to a feature request, ask for at least five names. This is not to be annoying, but if they cannot name five, it’s probably not worth the effort anyway or just someone else’s gut feeling about other people’s thoughts about the product. That’s way too many levels of indirection.
And if they have five names, you can go directly to the source and ask what these customers actually need rather than filtered and reinterpreted by someone else. Hearsay is not considered valid evidence in a courtroom and neither should it be considered a feature request by a product manager (or team).
Do Not Disturb
The team needs plenty of time to focus on their tasks. To assist, reserve blocks in their calendars where they can do the work and nothing but the work. It’s also important that no one distracts or interrupts the team during these times, so set up a sign, or even better (if at all possible): close the door with a ‘Do not disturb’ sign dangling from the handle.
Of course, if some developers need to have a chat about technical details, let them do so in a separate room, so that they do not interrupt the rest of the team. Emergencies can happen, but they rarely affect everyone, so there is no need to have an emergency disrupt the focus time of the entire team. A rotating goalie system may be of assistance here: a designated person who is responsible for dealing with incoming ad-hoc requests and any emergencies. How are ad-hoc requests handled by the goalie? They are properly logged and left for the product manager and team to review at a later time: they are not acted upon as they arrive. If bugs are discovered, it depends on the severity of course, but the overwhelming majority lands in the backlog, where again they await review. An operations manual, which is updated and refined every time an emergency occurs, is also a great way to share knowledge within the team.
PMs who carve out time to refine strategic documents, analyse product usage data, or talk to their experts about concerns and ideas are often more focused too. A bit of quiet time to mull over ideas can do wonders. For everyone.
Another principle is to be three ‘scopes: telescope, microscope, and periscope. The telescope looks far afield and into the distance to see what the future may hold. This often does not mean to come up with far-fetched ideas; few people are good at predicting the (near) future. Instead, think about what will stay the same and use that as a guide rail to continuously improve the core of the product. This should not be taken too far but serve as a reminder that not all great things have to change to stay relevant: some things will stay the same for a very long time. Get those things right!
The microscope is more introspective and zooms in on details. If maintenance and support are increasing, it’s time to think about strategic ways to deal with tech debt or shield the team from too many new requests. This comes back to being the team’s shield or ‘shit umbrella’. PMs tend to think about the big picture and may forget that details matter, especially for established products.
A periscope looks around while ‘swimming with the fishes’: observe your users or (pretend to) be one. I’m not a fan of businessspeak such as ‘dogfooding’, but a product’s defects often do become obvious when you use the product as a customer would.
Related to that is to learn to love your data, if you don’t already. It can reveal where people stay, what they do, how they get lost while navigating, where and when they leave the platform, what the response and load times are on key company metrics, and so on. Often people focus on engagement (E), adoption (A) and retention (R) because they are easy to measure, but happiness and task completion are as important as the others. Measure the whole HEART, not just the EAR.
Data as Code
Since data is your ally in figuring out what bits of the product need tweaking, ensure the data the product generates is governed properly: it must be accurate, complete, and timely. Treat the data as code: features cannot be shipped without proper logging, and therefore logging needs to be versioned and tested at the same time as the product. If you don’t make data part of the QA process, you’ll only find out about issues after shipping the product; it’s much cheaper to address defects as early as possible. If you do not have a data engineer or scientist in the team, please involve such an expert as soon as possible to ensure the intended access patterns needed for analysis are compatible with the data itself. Establish code and data standards within the team (or beyond if that’s at all feasible): clear specifications of the semantics of events and triggers, unit tests for individual log entries, unit tests for entire logs, integration tests, and so on.
The guitar virtuoso Steve Vai says he ignores his weaknesses and instead focuses all his attention on his strengths. The same can be done in product teams: make the good even better and leave the bad for someone in the company who’s actually good at it. This can either mean a collaboration with other teams (or outsourcing) or acquiring resources to have the team become good at it. In the meantime, the core team can still focus on what they know best and improve the product even further.
I am not advocating for forbidding team members to broaden their horizons. Instead, it’s about making sure the team does not waste valuable resources trying to solve a problem badly when you know someone else can solve it more efficiently. If you need help, ask for it.
Be a Mentor
If a person on your team shows potential for technical leadership or an aptitude for product management, nurture it. Too often product managers have a non-technical background, which means it’s a constant translation from customer requests to implementation details. Experienced developers with a business (development) sense can indeed make excellent product managers.
If certain engineers have an aptitude or desire to grow into such roles, please support and mentor them. These individuals may grow into technical experts with both depth and breadth.
The PM is not a glorified secretary, who attends countless ‘sync’ meetings all day with no discernible outcome. Some of the principles in what follows may not seem as if they ought to apply to a single product manager per se. The reason I mention these is that a product manager can set the right example within the organization. It’s also about establishing proper meeting hygiene to ensure the team’s time is not wasted by those who lack a sense of the value of other people’s time.
Calendar invitations that have no agenda or desired outcome specified are to be treated in the same way as unspecific tasks: automatically decline. A meeting is there to either inform or decide, it’s not tea and cake with the vicar on Sunday afternoon. In conjunction with the earlier principle of “Doc, or It Didn’t Happen” this implies meeting minutes are kept and available to anyone who attended.
Too many meetings without agendas end up as disorganized ramblings where the organizer opens the session with “I’m not sure how to start. Any suggestions?” If you invite people, make sure it counts. Waste 10 people’s time for 30 min and you’re really wasting 5 hours of company time, excluding the time it takes to go from one meeting to the next and the time it takes to resume tasks.
Status updates are often cast into meetings but, honestly, that’s a waste of time. If the team is on track, an email, Slack message, or update in a central planning tool is sufficient. If the team is behind schedule or stuck due to unforeseen obstacles, it needs to be communicated as soon as possible, not when the status update is requested.
Show Me The Data
If decisions are to be made, they should be done based on analyses and data that are freely available to anyone. Everyone in the meeting ought to be able to verify the claims stated: no massaging data and touching up charts in spreadsheets or presentations laden with GIFs. I love SAP’s vision for the boardroom of the future, but I do realize that may not be realistic for many companies at the present time or any time soon.
So, have the data and code needed to generate the charts available for everyone ahead of time. If someone else wishes to verify claims, they can do so without asking for the code and before it’s time to make decisions. State assumptions and data quality issues clearly up front for everyone to see and understand. It also enables others to peer-review the code and conclusions drawn from the data, which is better for everyone. This is all about transparency, not lack of trust.
Slide decks are often filled with text that’s simply read out loud by the presenter. That’s not a presentation, but a reading.
Very few presentations must be more than 30 minutes, so keep it short. Why not have 5-10 meetings to make decisions? If all the code, data, analyses, and suggestions are available beforehand, then decisions can be made quickly. And if there are any concerns, these can be voiced and the decisions can still be made or adjourned. That should not take more than a few minutes.
Furthermore, few meetings really need more than a handful of attendants. PMs who lack technical expertise often invite various team members or even the entire team, so they have backup. This is a reversal of the role of team shield: if experts are needed, make sure they have all the context and come prepared with questions or the data that may be required. Do not waste the entire team’s time with just-in-case invitations.
At Amazon, staff meetings have no slide decks. That may be too harsh for many companies and people, but it’s good to limit the amount of slide decks. I’m not sure I agree with the 30 minutes of silence in meetings as proposed by Amazon. Complex topics require more than half an hour of deliberate thought and may very well involve discussions with experts. Again, a review of code and data as well as the conclusions drawn from these is often sensible. Sure, the default assumption is often that you should trust your coworkers to do the right thing, but when it comes to important decisions I do not believe trust goes before sanity checks. Bad decisions do not become acceptable because of good intentions. Due diligence is every organization’s responsibility.
How does this relate to product managers? Too many PMs (ab)use slide decks for everything, from specs to product demonstrations and road maps. Choose the right format to communicate; PowerPoint is rarely the best format, especially when slides are filled with text. Static charts on slides void the ability to interact and see it differently, which means the conclusions of the talk are essentially foregone. That does not mean a speaker cannot highlight salient bits in a visualization, but others in the meeting should be able to verify the main claims themselves. Remember slide decks are for conveying stories, not reading out loud.
This principle has less to do with product management and more with the product manager setting an example: treat everyone’s time with equal respect. Keep time and be harsh to anyone who likes the sound of their own voice. No one wants to listen to a meandering monologue. It’s a software company, not a bakery, so no waffles.
Of ‘brainstorming’ meetings I am not a great supporter. In many cases brainstorming is just a euphemism for brain farts blowing in the same direction. A significant amount of software engineers are introverted and they often require time to contemplate matters before they have an informed opinion they are willing to share. Dropping a load of novel ideas onto them may be overwhelming and therefore not lead to the best response. That does not mean all developers are like that. Tailor the session to the audience: allow people who need it to come prepared, and give an opportunity to those who want to think out loud to do so. This allows both introverts, extroverts, and anyone in-between to participate successfully.
Just make sure the session has a purpose and agenda; it should not start with “Any ideas on how to structure this meeting?” If the meeting lacks structure, take a look at the ‘double diamond’ from design thinking. It provides structure to open-ended meetings.
Last but certainly not least: blow the team’s horn as much as sensibly possible. It’s the only way the organization can recognize the efforts of the team. Become the team’s number-one fan.
If people do not know about the team’s latest and greatest, the basic assumption is that they are not doing anything of any importance. The team deserves to be lauded for their efforts and the PM is the one to make that happen. Also share recognition whenever it comes: let the team know their work is valued.