3 things to avoid saying as a Product Manager
Do you ever lie awake at night thinking of something dumb you said and wishing you could take it back? I’ve done this plenty of time, often in a work context and especially as a junior product manager.
In this article we’ll go over three scenarios where I made communication mistakes and then review how they could have gone better to help you avoid some common PM pitfalls. Let’s get to it!
1. Saying Yes straightaway
Here’s a conversation I remember from my first month as a new product manager:
CEO: Hey John, I was thinking recently about our onboarding funnel, and I think all our new signups should watch a video so they understand how to use our product. Can you work on this for me?
Me: *oh my gosh, it’s the CEO* Yes, that sounds like a great feature. I’ll get to work on it right now and will hopefully have something for you to try in 2 weeks.
After the conversation, I told my tech team to drop everything they were working on and start building a video onboarding solution. 2 weeks passed and my team was getting frustrated that we had made zero progress, I realized it would take another few months to get something actually working. I went back to the CEO to tell him this, and he said “Oh, you didn’t have to build it now. I just wanted to tell you my idea.” 🙄
What should I have said instead? Here’s how I would replay the conversation with a couple more years of experience:
CEO: Hey John, I was thinking recently about our onboarding funnel, and I think all our new signups should watch a video so they understand how to use our product. Can you work on this for me?
Me: That’s a great idea! Can I just check, do we have any evidence that our current onboarding is a problem? Also, just to inform you, our team is currently working on Feature X - would you like us to drop that and prioritize this?
CEO: Well, I actually haven’t heard any complaints, I just thought it was a cool idea. Feature X is more important, definitely finish that first.
What I’ve done here is a) acknowledge the idea, b) dig deeper into the context and problem, and c) ask the CEO to prioritize. It turns out that this isn’t actually an important problem to solve right now and our team can get on with completing our existing work.
Takeaway: don’t say yes to anything right away before you’ve had a chance to validate if it’s solving an actual problem. Even if it’s coming from the CEO.
2. Saying No straightaway
Remembering my previous mistake, I spent the next few months focusing very intensely on our roadmap, leading to this conversation:
Operations team member: Hey, I wrote this doc about an idea to improve user retention, basically we can send emails to —
Me: (interrupting) Sorry, we have too much on our roadmap right now and besides, emails aren’t really my team’s responsibility.
Ops: Oh, okay. Sorry to bother you.
A few months later, user retention surfaced as a major issue in the company. I spent some time researching the problem and sketching out a solution, and happened to check the doc my team member had sent me. She described almost the exact system that I was proposing. In this case, the consequences weren’t as drastic (focus is almost always a good thing), but it did come with a relationship cost and opportunity cost.
In the two examples I’ve given so far, you’ll notice that my initial response ended the conversation. This is often a mistake, as you miss out valuable details and ideas. Asking questions is a great way to clarify meaning and extend the conversation — let’s see how it could work in this scenario.
Operations team member: Hey, I wrote this doc about an idea to improve user retention - basically we can send emails to users who haven’t been active for a certain time.
Me: That’s a really interesting idea, why do you think it’ll make a difference?
Ops: We’ve already tried with this one email manually and found that it led to a 5% increase in user retention. To roll it out fully, we’ll need support from the product team to send these out automatically.
Me: Those are pretty good results, and I’ll make sure to review your doc. Just a heads-up that my team is busy with several other projects right now, but I’ll discuss this with the other product teams and let you know.
Note that I still haven’t said yes to this idea, but I have acknowledged it and now have the opportunity to review it at leisure. By asking questions and being open to ideas, you build a much deeper understanding of your field and are more likely to come up with effective solutions. This is also a good way to build relationships across your organization, which always come in handy — as a PM you’re constantly relying on other people to get things done.
3. Giving tasks, not context
A final mistake is one I often still make, especially when I feel busy or rushed for time. In this case I was trying to find out where our new signups were coming from:
Me: Hey analyst, can you estimate what percentage of our app signups found our website on Google Search?
Analyst: Mmm, it’s tricky because they are different data sources. What is the max amount of time from viewing the website to installing the app that we count as a valid conversion?
Me: I don’t know, 24 hours maybe?
Analyst: What if someone used different devices?
Me: *gosh, this is getting complicated* …
We continued back and forth for several minutes and came up with a wonky but working definition. Presenting this data to my manager later, he said, “But why did you come up with this whole new estimate? We just ask new users where they came from during signup.”
This is what is known as an XY problem, meaning the end user asks for a solution to problem X, which is actually caused by problem Y. In this case, I didn’t share why I needed the data, or what problem I was trying to solve, meaning we wasted time on the wrong thing.
Giving context upfront makes it easier for others to help you because they spend less effort figuring out what you really want. Let’s include that and see how the conversation goes:
Me: Hey analyst, I’m trying to figure out where our users are coming from so we can help our marketing team prioritize their budget across different channels. Could you tell me what information we have on app signup sources and how we could estimate it?
Analyst: Sure, we ask people for that information directly during signup — here’s an existing dashboard on it.
In this case, I’ve gotten what I need more quickly because I shared more about my underlying goal. Making the request open-ended and asking the other person to think of potential solutions also taps into their creativity. If you’re only ever a task-maker, your team will be limited by your own understanding and imagination.
Conclusion
What unites a lot of these examples is that they were caused by a lack of thoughtfulness in communication. As normal people, we communicate in a hurried way all the time and it’s fine. However, the bar for product managers is a lot higher, because communication is literally 90% of the job. Good communication requires taking the time to write (or say) a thoughtful response that considers the other person and the situation at hand. And it can turn a confused set of individuals building random features, into an energized team solving real problems.
I’ve found it helpful to think of communication as a hard skill for PMs , meaning that a) it can be quantified, and b) it can be taught. By not saying yes to anything straightaway, asking questions, being open to ideas and sharing context, you’re well on your way to becoming a more effective product manager.
Bonus: Recommended Reading
If you’re interested in learning how to improve your communication skills, see my two favourite books on the topic below. As with all great books, their lessons can be applied in many areas of your life.
- How to Win Friends and Influence People by Dale Carnegie
- Difficult Conversations by Douglas Stone and Sheila Heen
