Product management has grown in popularity in recent years, with thousands of people trying to get into the role.
Product management looks like an amazing profession from the outside, but it’s not all roses.
To give you a fuller picture of what product management entails, I decided to list the good, bad, and unexpected ugly things that come with the profession. It’s by no means an exhaustive list, but it should cover the broad strokes.
I hope this guide will help you weigh the pros and cons and determine whether the positives are worth putting up with the negatives.
Let’s kickstart the conversation by reviewing the good things about product management. These are usually the reasons why product management positions are so coveted:
One thing product managers can’t complain about is the salary and benefits associated with the position, especially those working in the software industry.
According to Glassdoor, midlevel product managers earn around $130,000 in the U.S. For comparison, the average salary of a midlevel React developer is $90,000. And that’s just a starting point; principal product managers might get around $220,000, while directors of products can secure as high a salary as $300,000.
On top of that, product managers are often among the first people who get the stock option or any other ownership perks. Many can also hope for lucrative performance bonuses based on their product key metrics.
Since product management is still considered a nontechnical position in most companies, the salary brackets are among the highest in the non-tech job market.
Of course, expected pay and benefits vary widely and depend on the company, region, market, and countless other factors. So take the above with a grain of salt.
Have you ever dreamt of starting your own company? Or are you just tired of supervisors telling you what to do? Maybe you believe the team you’re working on focuses on the wrong thing altogether.
The great thing about being a product manager is that, often, you can feel like a startup founder. What I mean is that you can explore whatever direction you wish as long as you drive the desired outcome.
OK — that may be a slight exaggeration.
You still have your bosses, you still have to align to company strategy, and there’ll always be things you have to do whether you like it or not. But, for most of the part, you have a high degree of ownership over your objectives.
That means you can explore various approaches, pivot direction, and start/drop ideas as you wish. At the end of the day, your stakeholders are mostly interested in the impact you make, not the exact path you have chosen.
To some extent, it’s like combining the benefits of being a VC-funded startup owner with the benefits of a steady corporate paycheck.
I have yet to meet a PM who is downright bored with product management.
Since it’s a generalist role, product managers practice various skills every month. A product manager’s daily activities might include tasks as varied as:
There are just so many things a PM can (and must) do that it’s hard to get bored. Again, PMs can often choose their own path. Ultimately, it’s about the results.
If you chase your goals by being a data-savvy PM, so be it. If you are tired of crunching numbers, why not switch your focus to UX and design topics for the next year? It’s OK to shift your focus as time goes by.
If you get bored as a product manager, there’s either something wrong with you or the company you work for.
To make sound decisions, product managers must understand the inner workings of the product, its business model, and cross-department dependencies. It makes them one of the most informed people in the company because they get to see how the sausage is made.
If you combine this with the leadership role the PM often has and their ownership over outcomes, you get a perfect candidate to sit at the grown-ups’ table.
Product managers are usually engaged in strategic discussions and they get to have their say when it comes to big decisions. After all, they understand the context around product decisions best.
As a result, product managers have a noticeable impact on the whole company’s direction.
Product management is not all sunshine and roses. There are plenty of dark sides to the position that you should be aware of as you develop your career as a product manager:
The sense of ownership that comes with the role also has a flip side. Namely, there’s constant pressure.
You can’t just say, “So and so told me to do it,” or, “It’s not part of my job” anymore. Because you’re responsible for driving specific outcomes, if you don’t reach them, it’s mostly on you.
Correctness of decisions, market conditions, external factors, team members taking sick leave, underperformance, and numerous other factors impact your ultimate objective, and you have to manage them all.
As rewarding as it can be, this makes product management one of the most stressful jobs out there. When everything is fine, it might feel like no one really notices. But once your metrics start to fall short — regardless of the reason — suddenly, all eyes are on you.
Product managers are surrounded by uncertainty all the time. You never know which idea will work, whether stakeholders will approve your concept, or how your metrics will look in a quarter or so.
You often don’t even know what your team will do next month. After all, it depends on how the current month evolves.
Although many product managers derive some enjoyment from this ambiguity, let’s be honest — who wouldn’t appreciate the peace of mind and certainty that everything will be OK?
There are parts of the job that are rarely talked about. They seem to somehow escape from all the “bad sides” lists of product management. As a result, people often realize it in practice once they are already on the job. And if they weren’t prepared for these, it gets ugly:
If you believe that your skills, experience, and sound-decision making will guarantee positive outcomes, you have another thing coming. In most cases, there are multiple external factors influencing your performance.
Let’s take COVID, for example. Imagine we have two product managers:
When COVID-19 strikes, demand for PM A’s product shrinks significantly while the remote collaboration tool managed by the ambivalent PM B observes 10x growth. Suddenly, product manager B becomes the most important person in the company.
Of course, this is a very extreme example — and, in this example, hopefully, the company would account for the impact of the pandemic — but the point it illustrates is still relevant.
External factors might influence your product more than you do. Yet, at the end of the day, you are still expected to meet your objectives.
Product managers disappoint those around them, over and over again.
There’ll always be someone who didn’t get what they wanted. Perhaps you decided to choose another solution, prioritize collaboration with another department, or simply didn’t even have time to consider a colleague’s favor. There’ll always be someone who is at least slightly disappointed in you at any given time.
Contrary to many other roles, you can’t just put in more hours to cope with this issue. If, say, a UI designer has multiple requests, worst-case scenario, they can work slightly longer and slightly harder to make everyone happy. But when it comes to decision-making for product managers, there’s rarely an option to work harder.
I’d go so far as to say that, for a product manager, stakeholder management is all about deciding who to disappoint next.
Although the product culture looks different in different companies, one thing is sure — you won’t always be the most likable person in the room.
Featured image source: IconScout
LogRocket identifies friction points in the user experience so you can make informed decisions about product and design changes that must happen to hit your goals.
With LogRocket, you can understand the scope of the issues affecting your product and prioritize the changes that need to be made. LogRocket simplifies workflows by allowing Engineering, Product, UX, and Design teams to work from the same data as you, eliminating any confusion about what needs to be done.
Get your teams on the same page — try LogRocket today.
Maksym Kunytsia talks about Ideals’ code of conduct for collaboration, which is combined with continuous discovery and continuous delivery.
Over the last years, tech people became resistant to Agile frameworks because their expectations of empowerment didn’t materialize.
Andrew Cheng, VP of Product Management at WellSky, shares examples when he’s made short-term trade-offs for long-term career opportunities.
Chris Holland talks about how his teams develop a model for project teams to render their own evaluations or conduct their own user research.
Learn more →
One Reply to "The good, bad, and ugly of product management"
Product Managers without the software engineering skills and experience have been a disaster to the software industry. In decades past, successful software engineering teams were led by a senior software engineer, who managed the project, understood the product and the market for it, had good “people skills” in dealing with customers, managers, and team members, and understood business and the financial sides of the software business. Non-technical project managers reported to the senior team leader who offloaded the non-technical paperwork to that project manager (usually needed on larger projects, but not smaller ones).
The team lead also handles the Agile methodology applied to the project, usually applying the Agile Manifesto principles according to the attributes of the team and project, not any of the modern “agile methodologies” that are really only workable in manufacturing.
Even today, that process works. I know because 1) I understand how it works across disciplines, and 2) because I’ve “been there, done that”.
The benefits to the employer, when the process is used in software development properly:
1 – Project is completed on time or before.
2 – Project is completed with better quality and fewer bugs.
3 – Project is usually delivered with more features, even in the minimum viable product (MVP stage.
4 – Project is built with fewer people, and little to no non-technical people.
Creating software is not a bunch of coders assembling widgets where most everything is known at the time of assembly (where modern agile principles work fairly well). At the time software is written, it involves about 60% research, 30% creativity and artistry, and 10% actually coding. That is why hiring developers by assessing their skills by some “code challenge” quiz is such a bad idea. Do you want to hire those who memorize trivia well, but are not skilled at deductive reasoning so they can’t figure out their projects very well, or do you want to hire developers who learn, adapt, know where the answers are found, and are strong in deductive reasoning – so they can solve the unique problems of each project and adapt faster to newer technology?