Looking after your mental health as a product manager
Product management is a mentally taxing job. Whilst software engineers can afford to put their heads down and focus on one task at a time, PMs have to juggle different things, maintain different points of view, and deal with many different functions. There are plenty of articles about being more effective in all of those. But we don’t talk enough about maintaining energy and caring for your mental health as a PM.
Every now and then I would come across a confession in some PM communities: ‘I’m thinking to switch away from product management. I don’t want to deal with {insert all the shite we need to deal with} anymore.’ I have been in that boat before. I still sometimes feel that way.
As years go by, though, I learned to accept the reality of being a PM. Frustration and disappointment come from the discrepancy between expectations and reality. The more you’re aware of the reality of product management, the more you can manage your own expectations, and reduce your chronic disappointment about the profession.
1. The CEO of the product isn’t the same as the dictator of the product
Many people are lured into product management due to its sexy title. A PM is the CEO of the product is one of the most commonly told notions (and what some other people have strongly disagreed with). Depending on how tech-led your company is, a PM can actually be the CEO of the product. However, you need to realise that being a CEO isn’t the same as being a dictator.
Talk to any CEO of a good company and nobody will say that they can do whatever they want just because they’re the CEO. As a CEO, they need to consider a hell lot of different factors to make a decision. They have to make money for the shareholders, retain their talented employees whilst trimming down the operational cost, and maintain their regulatory obligations. They do things they don’t like all the time.
2. You won’t get the resources that you need to build the version of the product you want
You will always have to cut scope and compromise. You won’t get all the time and resources you need to build what you want. There’s never enough time to address all the bugs and product/design debt. These constraints will force you to prioritise 20% of the things that will deliver 80% of the result, which is a healthy thing to do.
3. The building phase will take longer than expected
When your engineers tell you that something will take x amount of time, they usually mean x amount of dedicated coding time. What they don’t usually count is:
- The amount of time they spend in unavoidable company meetings
- At least one person in the team will either be on holiday, sick or have to take some time off for whatever reason
- Code refactoring they might need to do
- Pull requests review process that could be overly long depending on the organisation set up and the responsiveness of other engineers
- etc
Whatever your engineers tell you, double it in your head (but don’t tell your engineers that).
4. You will face issues with the stakeholders
There’ll always be some jerks in any company. There’ll always be somebody with good intentions but annoying you for some reason. There’ll always be a hotshot in another team, maybe dreaming of becoming a PM themselves, trying to do your job for you.
Think of it this way: if all the stakeholders are aligned, agreeable, and require no management, maybe the company doesn’t need to hire a PM. You’re there because there’s a job to do.
5. No matter how much you’ve communicated, there will always be somebody who says they don’t know what’s going on
Yes, it’s their fault they don’t read your email and Slack message. Yes, you’ve even bookmarked it in the Slack channel and repeated it multiple times in different meetings. Don’t take it personally or let it annoy you for too long. We live in a noisy world, people aren’t listening to you most of the time, and this will happen.
6. The product/feature you release won’t always have the impact you want
9 out of 10 startups fail. At Google, only about 10–20% of experiments generate positive results. Avoid adding a label to what happened, e.g. ‘I failed as a PM’, or ‘maybe I’m not good at doing x’. Keep it as factual as possible, e.g. ‘I tried x and it didn’t work out.’ You can learn and move on.
7. There’s an inherent conflict between different business functions
Designers want to build the most beautiful, usable, accessible product. Engineers want to build a clean code. Stakeholders want to launch as soon as possible. Your manager doesn’t give you the resources you need. The marketing team wants a more jazzy product they can shout about. The PR team thinks this feature might be picked up negatively by the cynical press.
Don’t get too frustrated when that happens. Everyone is only doing their job. It’s not a sign of a dysfunctional organisation — it’s a necessary discourse that will produce a balanced product.
8. You might not change the world
There are very few products that actually change the world. The likelihood of you building one of those is very thin. You can still take pride in the fact that your product is helping the lives of your users a tiny bit better.
(If you’re not proud of your product, though, or the impact it brings to your users, maybe it’s time to find another company.)
9. It’s okay to rest and stop learning for a while
There are PLENTY of resources out there about improving your product management skills. I’m guilty of creating an additional one with my Medium blog. But it’s okay to shut your laptop off, go on a holiday where there’s no Internet, read some fiction, or watch Friends for the twentieth time. Do things with no purpose other than pleasure.
And if reading tweets from the so-called product thought leaders is exhausting you or making you feel inadequate, you have the power to unfollow them. Let me tell you a secret: they don’t always walk their talk. Some of them make money by spreading the ‘wisdom’ without having proven themselves by building good products. Be wary: check their credential and portfolio before following them blindly.
👋 Hi, I’m Debbie. I’ve been building products and solving customer problems in tech companies for over a decade. I write about how a PM can bring 10x value to their company, not just 10% improvement. Stay ahead of the game and get insights delivered straight to your inbox — subscribe to my newsletter today!
