One thing I constantly hear from product managers (PMs) is that they are buried in requests from all over their organization. Whether it’s feature requests from sales, bug escalations from support or feature trade off decisions from engineering, all these requests show up and everyone thinks that their thing is the most important thing.
For many PMs, this leaves them stressed out, working insane hours trying to please everyone. It can lead to burnout and I’ve seen good PMs leave the profession because of the stress.
That’s a shame, because most of the time this is a fixable problem.
As a PM, you need to be in charge of your own fate. You are the leader of the product team and thus you make the rules. Of course, some organizations are just broken and you can’t fix them, but my experience is that most orgs want to do the right thing; they just don’t understand how to do things properly.
So, you need to train your organization on how to interact with product management properly.
I wrote an entire course about this for my sales team years ago. I called it “How to Operate Your Friendly Neighborhood Product Manager.” I intentionally made it a little funny and whimsical because I didn’t want to preach to them or give them the impression that they were doing anything wrong. The point was, they wanted something from PM and I was going to tell them how to ensure that they got what they wanted. The training was focused on them and their needs.
And that is the first lesson. In the vast majority of cases everyone is trying to do the right thing. However, they have their own goals, their own motivations and their own bias on what needs to happen when. Because of the nature of our role, PM is not and cannot be focused on just one customer at a time. We need to service the entire business. Thus, we have to say “no” to people who need something counter to that larger purpose. This can cause friction for organizations like sales where a salesperson may have only a few accounts. If you are a major account rep with only one customer and that customer has a critical bug, then fixing that bug is THE ONLY THING. However, if the product has ten thousand customers and only that one customer has the problem, then PM may not prioritize the bug. Hence, there may be conflict in the goals of the two teams.
You address this with radical transparency. I am maniacal about stack ranks. I love them. Every PM team I’ve ever led has had a public stack rank. It is precisely because I can’t please everyone that I insist we do this. The point is that I can easily have a conversation with anyone in the org about what we are doing and why we are doing it. They may disagree, but it’s super clear what we’re going to do and what we’re not going to do. No surprises. This cuts out at least half of the noise around things that sales wants but isn’t going to get. We debate the stack rank, we decide, we publish the result. Done. Your customer is not going to get the special magical feature they want. Move on.
The second lesson is about scale. Most PM teams are relatively small. In my career, PM teams averaged between ten- and twenty-to-one with engineering (that is, 1 PM for every 10-20 engineers). Similarly, there are normally more salespeople and more support folks than PM also. This means that PM resources are quite scarce. I can’t just take a PM and put them in charge of stack ranking all the support cases that come in every week. I don’t have the staff for that. This means that the other larger teams have to take responsibility for communicating with PM effectively. For support, this means that they need to review open support cases and report back to PM what they are seeing. They need to tell us where the product is weak and where it is strong. All this information is in their systems, they just need to summarize it to us on a regular basis.
This means that senior PM leadership needs to negotiate this directly with the other orgs. As a Senior Director of PM, it was my job to make sure that the working agreements between my PM teams and the supporting teams (customer support, design, marketing, sales, engineering, etc.) were in place. I didn’t want each of my PMs going to them one at a time. I wanted to have a default agreement in place. If you are a senior PM leader, you should be doing the same. If you are a PM individual contributor, you should push your leadership to do this for you.
The third lesson is about results. Everything that someone asks you to do as a PM should be about outcome, not about opinion. I cannot tell you how many times senior folks have told me to build feature X because they thought it was a good feature. I could not care less about their opinion. What I wanted to know was the desired outcome. If we build feature X what happens? So, for sales, if I build X, how much revenue will we get? How much will customer satisfaction improve? What happens if I don’t do it? In the vast majority of cases, they didn’t actually know. So, it came down to opinion: “I think you should build it.” That’s nice. Not going to happen. Instead, tell me the outcome you want. For example, “We need to improve churn rates by 50%.” That is a proper request to PM. I have no idea how to do this, but it’s fair to ask me. I need to go do my research and come back with a plan to achieve this result.
To keep opinion-based requests to a minimum, you need to train your supporting organizations like sales how to pitch you things. They need to do their due diligence first. Then you can take action. So, if they claim “Everyone wants feature X” then they should come to you with at least five opportunities that didn’t close because of this. Show me the deal that was affected. I’m going to go talk to the customers. Give me a list of who to talk to. Frighteningly, they often can’t. Sometimes this is lack of discipline; sometimes it’s because there is actually no evidence that we should build the thing they want you to build. Help sales understand what you need and why. Give them some examples. Provide a template. The smart ones will figure out right away how to use the system to get what they want. Which is the entire point of the exercise.
The final lesson is to have no fear. As a PM, you need to be the one that says “The emperor has no clothes”. If the data says the thing we are doing is wrong, we say so. If people don’t want to hear it, too bad. Trust me, if you get fired for telling the truth, they just did you a huge favor. You don’t want to work there. There are big incentives, especially in larger organizations, to simply ignore hard truths. Don’t do that. Yes, you have to be polite and no, you can’t be an oracle of doom every day, but the facts are the facts. Stick to your guns and fight the good fight. The type of PM leaders you want to work for will defend you and promote you for doing that.
This is vital, because when PM says no, people have to believe you. If they think that your decision can easily be overridden by leadership, then your life will be very painful. As I said at the beginning, some orgs are just broken and you can’t fix them. When I join a new team, I always discuss with my senior leadership what our role as a team is and what I need from them. Of course, I work for them and will ultimately accept their decisions, but they need to publicly support me and my team or I cannot do the job I was hired to do.
