Don’t talk to the developers.
I have written quite a bit about the importance of communication in Product Management.
You should be generous with your time and information and share as much as you can as often as you can with your product stakeholders. You should listen and relate to the people around you to inform your decisions and build relationships. But there are some times when communication can spill over the levees of appropriate channels and cause significant confusion and chaos in a product delivery.
___
I have three children.
Children are monsters.
Not always, but often enough.
Even when they aren’t being outright villains, they can be sneaky and manipulative.
One of the things my kids used to do regularly was to walk up to their friend’s family and ask them if they could come over for dinner, while we were standing right there.
Now, sometimes this was with a family that we were close friends with, but often it was with people we had just met, or worse, with people we were actively trying to distance ourselves from (in a nice way… but sometimes you just don’t click with people).
Me: “Sorry sweetie, we already have plans tonight.”
Sweetie: “What plans?”
Me: “We have some things we need to take care of around the house.”
Sweetie: “What things?”
Me: “Just some things.”
Sweetie: “How about tomorrow”
Sweetie’s Friends Parents: “We’re free tomorrow!”
Me: “Let me check my calendar… I’ll let you know.”
And then I would go to new playgrounds, shop at different stores, and wear a disguise for the next few months.
Ultimately we created a new rule: If you ask to make plans with friends, in front of the friends, the answer will always be “no.”
This happens at work too.
The topic is rarely about getting together for dinner, but the premise is the same: People will ask for things from people they shouldn’t be talking to, and it puts people in difficult and awkward positions, and can threaten the overall product success.
The most common situations I have encountered have to do with customers or customer-supporting teams (Sales, Business Development, or Support), reaching out directly to the Development team to ask for a new feature or for delivery of a specific fix. This is virtually always a disruption to the existing roadmap and forces the Development team into an awkward position.
___
The Product Manager is often called the quarterback of the organization, taking the football (product) from the Development team and passing it to the Sales teams. The Metaphor gets a bit messy when you try to cover the rest of the job of a Product Manager…
Sales will pass requirements back to the Product Manager to pass to the Developers, and sometimes the Sales team will blitz the Developers directly, ignoring the Product Manager altogether and tackling the Junior Systems Engineer. I don’t know football very well, but I’m pretty sure I’ve never seen a play like that at the professional level.
One of the biggest parts missing from the quarterback analogy is that the Product Manager defends the development team from direct requests. You are not just building products, you are protecting the developers from distractions and conflicting priorities.
___
The most effective strategy I have seen to ensure that all requests and requirements are funneled through the Product Manager is to be the bad guy.
No, that doesn’t mean you should be angry and mean.
No, it does not give you license to throw chairs and burn bridges.
However, if you are going to effectively manage a product roadmap, you need to be able to say “no.” Thing is, people don’t like to say “no.” It is awkward and painful, and it creates conflict. It has to be you. You need to be able to say “no” to Sales, to Customers, and maybe even to your own executives.
It can be uncomfortable, and you will need to have very good reasons to justify your response, but the fact remains that there are always more requests than capacity to deliver, and you need to enable the developers to focus on the most important and valuable products.
___
In order for a “no” to be productive and beneficial, there are two main considerations.
First, you have to be honest and open.
You should only say “no” if the request does not align with the product goals, or conflicts with the current priorities, or if the team simply does not have the capacity to support it.
You also need to be able to articulate this to the requestor. You are the bad guy because you are saying “no”, but if you can explain why you are saying it, help the requestor understand the reason behind your answer, and give them insight in the product’s goals and priorities, saying “no” does not burn a bridge, it builds credibility.
Second, you need to have confidence that when you say “no” it means “no.”
I have written previously about the power dynamics of Product Management; specifically, about how product managers don’t have power, they have influence built on relationships. These relationships are what will give you the authority to say “no” and have it stick.
In this case, the key relationships are with the development teams, and your goal is to get them to defer to you on topics of the product roadmap and priorities. Make sure that they know and believe that you will only ask them to deliver valuable and important things. Then give them permission to use you as the bad guy.
Most development teams want to say “no” but they don’t have the information and authority to do it. If you can gain agreement from the developers that they don’t have to do anything that you don’t specifically request, then they can point at you and say “I would love to build the feature you are asking for, but the Product Manager says “no”, and I can’t do anything that’s not on the roadmap. You should go ask them.”
If the developers go along with you saying “no”, then you have authority and credibility when you say it.
___
Sales will take their requests directly to the developers if it works, and they will keep doing it if it keeps working. Logically, this also means that they will stop doing it if it stops working.
You can give the developers to power to defend against these unwanted advances by routing them to you, but you need to be ready to receive them.
It is important to establish and enforce a process by which requestors can provide details about the request and the motivation behind it. Provide a template to fill out with information that will help you evaluate:
Technical impact and complexity,
Customer impact
Business impact
Whenever possible, ask for hard numbers:
How many more units will we sell?
How many more customers will we reach?
How much time will our users save?
Etc…
When teams are in the habit of providing this information, you can be quick and consistent in evaluating the request and providing a response. You will also have the information you need to prioritize this request against others in the backlog.
___
What do you do when a customer escalates their request, or when your own executive team says “do it anyways”?
More often than not, you do what they ask.
Does this break the process? Not exactly.
When a customer escalates, you should work with the account managers to understand whether this is likely to affect the long term relationship with the customer. The answer to that question is part of the “business impact” in the request template. It is valid to consider strategic and relational impacts when evaluating requests.
When your own executives tell you to implement a request that you initially reject, you need to diplomatically provide an update to them on what the development team will have to drop in order to support the request, and how that will impact the existing product plans.
In this case you are not just pushing back on your executives, you are giving them the information they need to make an informed priority call.
This updated priority becomes the justification that you take to the development team. Hopefully you were able to defend their overall capacity, but sometimes you will have to give the development team more work without being able to take something else off their plate. You can’t do this often without burning out the team, but it can occasionally happen without too much downside if the developers know and trust that you are doing everything you can to protect them from unreasonable requests.
So you are the good guy.
… and the bad guy.
… and the quarterback.
… and… uh …Sports.
