Conversations that destroy your PMs' credibility
Types of conversation that destroy the Product Manager's credibility and collaboration with stakeholders.
As a Product Manager, building strong working relationships and collaboration with engineers, designers, and other stakeholders is critical to delivering your jobs. Better credibility helps build better collaboration. There are red flags that destroy your credibility if you keep doing so.
"Hey, Mr. Engineer, it's just removing a pop-up. Why does it take so long."
You look at the engineering team's estimation and think it takes too much time for such easy improvement. Then you ask the above question.
What the f*ck are you doing with your career?
Never judge the features' complexity by how it looks. Complexity is also about the constraint around it. It is similar to a simple banner when working with designers. From the professional perspective, When you underestimate how hard it is to finish a task, you minimize your teammate's effort to deliver it. You make them look stupid after doing their best to provide the vision you set. Nothing destroys your reputation more than this.
They are not stupid. You are.
You should talk to your engineer or design partner, understand the dependencies and consequences, and align on the plan. If you have concerns about the estimation or their project, ask clarifying questions to understand the task breakdown. Make sure you and your team have the same expectations. Do the trade-off if needed. Then, move with the mutual decision.
This thread tells interesting stories about feature complexity.
How hard can it be to remove a single pop-up? A line or two of code? What makes software engineering hard is all the other complexity around seemingly small changes. Looks simple from the outside: hard from the inside. (Removed my previous quote tweet which amplified dunking)
You might argue that you read somewhere that Steve Jobs and Elon Musk did that, and they have the most successful product on Earth.
Yes, they did. But you are neither Steve nor Elon.
Becoming a tasks forwarder
You finish a meeting with action items aligned with your CEO. You sit down with your team to plan for the release. An engineer asks you many questions to understand why we need to do this feature other than another, and you cannot convince her. The team look agrees with her. You decide to get them in the same boat as you by saying something like, "Mr. HIPPO already made the decision. I think we cannot change his decision. I'm afraid I also have to disagree with him on some points, but I think blah blah blah. So I suggest we move on to plan for this cause we only have eight days to make it"
Whatever you said, the only thing others take away is, "Oh, now I know, this is from the boss, and he has nothing to do with the decision."
Another version: "Shit, why don't you say it earlier? Talking to you is a waste of time".
In this case, you are only the forwarder who takes the input from someone and then delivers it to other stakeholders. I am sure no PM jobs have the line "An experienced forwarder with an excellent track record on delivering requests to the team" in the JDs.
Do you remember the reason you started your PM career? Is it building new things, attacking new user segments, changing people's lives, or something similar? To do any of those, you need to deal with ambiguity. And you, as a Product Manager, are the one who makes it more transparent. People expect you to make them see things less ambiguous. Then, one day, they find out that you cannot do that. So why do you still need to be there?
Ideas and feature requests come from many people other than just your users: the salesman, another engineer, the designer, the CEO, and more. People come to you expecting you to help them clarify, give feedback to solidify the idea, and bring those initial thoughts to the users. In the case of the CEO, she hires you for that reason. Then, one day, they find out that you cannot do that. So why do you still need to be there?
In collaboration, you take the ideas, analyze them, improve them, and surprise the requester with the idea of version 2.0. Ask questions and challenge their points until you are clear.
After that, you share it with the team and credit the requester. This clears their concerns and makes the team happy because they have a partner who helps them understand more about the vision and the product day after day.
Of course, it's easier said than done. Some points will remain unclear, and you cannot make the team 100% agree. In this case, you must make a firm decision and ensure you will do everything to make it the best. To make sure you know, you are the decision maker. Decision makers are those who make decisions and take responsibility for them.
Deciding to do something and letting others take bad credit when things go wrong makes you a shit-forwarder, not a decision-maker.
Act like you are the victim in challenging situations
Here are the scenarios:
-
You come to the sales team bringing bad news about a committed launching schedule. It's a difficult conversation since the deal is important. You want them to know you are on their side and do not want this to happen. You say, "I pushed the team so hard, but they cannot deliver it. I asked them to add more buffer on their estimation, but they were too optimistic back then. It's bad. I'm not happy with their way doing planning."
-
You are in a design review session. There is a feature that cannot be implemented in the way the designers want due to technical constraints. You must seek an alternative and agree that the original design is better from the UX perspective. You need to make a trade-off. You emphasize, "So sad that we cannot move with the first option. It is going to be a great improvement. I tried to ask the team and debate a lot to find a way, but they couldn't find the solution. I think this is the limitation of our current engineering team, so we have to accept that. Let's come back when we have someone in the future who can handle it."
-
You join the planning session with engineers and bring an urgent feature that the sales team committed to a critical customer. The schedule is tight. You and the team reprioritize the features list, plan for the new item and try to deliver it. You share, "I did debate very tough. I disagree with this way of working when new items appear without any plan and at the last minute. I don't like how the sales team commits without discussing optimizing their number. They commit, they hit their sales target while we work day and night to deliver their commitment, but they never know."
In all those cases, you become the victim in a difficult situation and, at the same time, blame other people. You will feel more comfortable in a specific conversation, but it destroys the culture and your credibility.
First, the Product Manager jobs intersect with different function teams like engineering, design, and business. The silos between those functions get more prominent when the company grows. Your job is to close that gap, make the information flow, and bring mutual understanding to all parties. What you did in those examples widened the gap, made the team look bad, and made you outside of all the teams' efforts. Collaboration always works differently.
Second, there is no victim in those complex situations. When things fall apart, the worst thing you can do is define who did the right job and who didn't, then blame them together. You need to do that in the post-mortem or to find a way to turn around the situation, not to find empathy or cool down an atmosphere in a specific conversation. It's too political to play the victim game.
So, communicate the bad news by saying it like it is. Focus on analyzing the current situation and discussing the B-plan. Put yourself in the driving seat to deal with the problem. Save the post-mortem later and learn about the root cause in a way that can give you lessons learned for the next project. Never blame anyone cause it doesn't help move the needle. When things fall apart, it's a chance for the team to learn and move faster later on.
Manners maketh man. Candor maketh PM.