Product management (PdM) is a flexible discipline. It means different things to different people for a few reasons.
-
Different organizations require their product teams to do different things. Sometimes you find yourself in an environment that appreciates SAFe while others are fully “Empowered” with everything in between as well.
-
Your day is never the same twice. If I asked one PdM to list ten things they did this week and another one to do the same, the lists likely won’t match up, even if they’re both in the same organization.
-
There is no discrete output. Engineers produce code, designers produce experiences, and salespeople produce revenue. Product, however, can do any of these things, depending on the circumstances.
I could continue a list like this for quite some time. The theme would remain the same for each item on it, however: Product goes where it is needed. So, with so much variation in its day-to-day practices, how do we define, at a high level, the role of the product manager and the work it entails?
After several years of doing the job, I’ve landed on the following definition: “Product managers should help their organizations make better decisions over time.” For us to support the teams that deliver the outputs that make companies successful, we have to take charge of improving the quality of decisions that everyone in the organization makes.
PdMs should spend time prioritizing issues based on business and technological need, and then come together with different parts of the company to solve those problems. This process becomes a cycle. The longer product people work in this cycle, the better and faster they get at understanding problems and using the right tools to solve them.
In my article on survival metrics, I talked about the need for teams to be fast, data-informed, and politically safe, and I think these are three modes of operation that allow product managers to get comfortable with the change that comes with focusing on complex problems. Your job as a product manager relies on dealing with complexity, and your value to the business is in how you can help it navigate those decisions over time.
So, what constitutes fast, data-informed, and politically safe decision making? And how can you draw on these principles to remain flexible so that you and your organization consistently improve in the quality of your decisions?
What Does a Product Manager Do?
Fast, Data-Informed, Politically Safe
Don’t think of the concepts fast, data-informed, and politically safe as having fixed definitions like everyday words do. When you incorporate them into your thinking, you’ll find that they’re flexible enough to fit several different situations.
So, what does each of these principles mean in practice?
Fast
How might I increase the speed with which I make any necessary choices? In product development, and especially in agile product development, the shorter your decision cycle, the sooner you can adjust to the changes that dealing with complex problems necessitates.
Data-Informed
How might I improve how closely our team performs to reality instead of the ideal? Teams often make decisions in workshops or based on what comes from the boardroom rather than what’s really happening in the business and the marketplace. Better decision-making involves taking the influence that the stakeholders wield and pushing back with data based on reality.
Politically Safe
How might I enhance the psychological safety of the team around me? When people feel heard, they feel safe, which means they’re willing and able to take risks. Political safety extends that concept to the team level so that teams feel better with interpersonal tension. As a product manager, the more trust you can foster across teams, the better the decisions you’ll all make.
Operating with these frameworks allows you to make better decisions over time. Think through some of your past decisions to see how you can improve your processes in these three ways. Doing so will help you define the role of a PdM to your team.
The frameworks are important to lean on because you are going to be fighting a lot of fires. In fact, I’m sure your Slack is going off right now.
Fires, Fires Everywhere
Put down your laptop. I’m sure no one is going to come around the corner and threaten you for not immediately answering that incoming Slack.
Why did I ask you to do this? You have to stop reacting. You need time to think. You need time to respond.
Let me know if this sounds familiar to you:
-
Stakeholders are pounding on your door, demanding “innovation.”
-
Bugs threaten the viability of the next release.
-
Sales added something to the roadmap again.
I bet you’re nodding your head. Well, sorry to break it to you, but this kind of adversity is the nature of the job. Product classes usually leave out that, although managing all of those things and more is important, your primary job is to facilitate better decision making. And this happens when you are able to respond rather than react.
Responding Versus Reacting
Responding means that you’re thinking about the outcome you want instead of whatever is ahead of you. As a PdM, you must keep the outcome in mind so you can remain flexible and apply the fast, data-informed, and politically safe principles.
Let’s go a little deeper here. Imagine that we have two product managers, one named Jeff and the other Anna. They are both dealing with a push for innovation from leadership, a hyper bug tracker, and pressure from sales on the upcoming release. Everyone wants a meeting. Jeff says yes to them all and finds himself in meeting after meeting, dealing with every single one of those fires.
Anna pushes back on the request and promises a response in three hours. She then takes those hours, looks at all of the requests, sends some probing questions via Slack to those involved, and creates a list of tradeoffs and possible outcomes based on company strategy.
Who would make a better decision about what to do next: Jeff or Anna? The answer, I think, is clear. This hypothetical illustrates the difference between reacting and responding. Those that simply react will find themselves being output-driven. They can’t see past the next fire. Reactionary teams are always trying to figure out how to “launch” the next thing.
By contrast, those that respond are able to take a step back and adjust to the entire picture. They’re able to communicate in a data-informed way that helps teams gain trust in one another. Responsive teams are focused on the “why” behind the outcome. Those responsive teams focus on the big picture since they spend time thinking about strategy.
How does this make a team faster? Well, PdMs who take time to think before they act understand the priorities of the business better. So, once they have a better grip on what’s important, they can ultimately move faster without getting bogged down in details.
Remember That You Do a Lot
A lot of your work happens in the background. There isn’t a day-to-day PdM map to follow. Because of that, this job gets frustrating. Moreover, proving impact is hard since a lot of your time can be devoured by people asking you to put out their fires. Creating the space to respond is incredibly important to help you improve the decision making in your company.
That said, implementing this kind of culture is also the most rewarding part of the job. Helping teams dig through ambiguity is the essence of product management. Making sure everyone is making better decisions shows up not just in the releases, but the overall efficacy of the company.
