The unromantic side of the PM hustle — What you actually end up doing
You can also read our content on substack. Subscribe here.
Less than a decade ago, it was rare to find a new grad product management position or internship. Now it seems every company is spinning off its own new grad position, internship, or APM program. And even as the job openings continue to grow, it still doesn’t seem enough for the growing popularity of the role. What makes the role particularly competitive compared to other jobs in tech is that there are relatively few open positions. Compared to software engineering jobs, there is usually about only one PM per handful of devs. Depending on the company and the stage it’s at, there may be only one PM per 20+ or more engineers.
The role of PM has a lot of appeal— you’re setting charter for your team and the company on how to grow your product further for your users. The PM role takes a lot of leadership. But it’s not all rainbows and butterflies and today we shed light on the parts of the job that are less talked about.
Not truly “CEO” of the product
[Kay] There’s a lot of administrative parts. You often end up picking up the odds and ends, work other people don’t want to do. Your work is practically never “done.”
Okay, maybe this is going to sound really naïve, but before I switched to PM (I used to be a developer), and honestly even when I was still just starting out as PM, I thought my main job would just be to write specs and then hand them off to the devs and they would take care of it from there. Obviously, this got me into a lot of trouble a fair number of times because the PM’s role doesn’t just end when you review a spec with your team.
After a spec review with the dev team and once they started working on it, I’d kind of just be sitting there like a waiting duck, my arms up in the air “I guess my job is done now,” and pat myself on the back for finishing my job.
But there’s so much in between stuff. Maybe in terms of output deliverables such as specs, reports, etc, a PM’s workload seems light, especially compared to a dev’s. But the non-deliverable work you could be doing (more customer interviews, more data analyses, more Product Requirement Docs (PRD) proposals, etc) is endless. You can always be applying yourself more to understand your product, your space, and your customers more deeply. There’s never really an end!
Additionally, you also can end up with odd or random pieces of work no one else wants to do. Going around getting necessary approvals before a release, collaborating with marketing and field technicians to understand the technical details of your product. No one wants to waste an engineer or designer’s time on these things.
This is one of the main reasons even defining what the PM job is notoriously tricky. You are likely doing something totally different each day.
[Amanda] Another way that you are not the ‘CEO’ of the product is that as the product manager, you do not have any managerial authority. You typically work with other functions (engineers, designers, user researchers, marketers, customer support, etc.) who are not in your reporting chain. As a result, you will often hear the saying “influence without authority.”
Influence includes: getting the team onboard with a new product direction, pivoting away from a risky or low-impact project, etc.
Interviews focus on “blue sky” thinking. In reality, it’s usually not that way.
[Kay] Everyone has heard of “Design a clock for the blind,” but no one talks about how in many cases the actual job is more like “Design a clock for the blind, specifically out of this sundial since this is what we’ve been using.”
Interviews tend to emulate “greenfield” projects — projects that are starting completely from scratch. In reality, many, if not most positions, are “brownfield” projects — projects that have already been started and are being handed off to you. In brownfield projects, you’ll likely have less resources, more technical constraints, and potentially less say in the overall vision of the product you’ve inherited. (I don’t want to be a total Debbie Downer though; these factors are additionally heavily influenced by the overall product culture of your company/team).
In the day to day job of your job, you may be hampered down by many more resourcing, budgeting, tech-debt constraints, partner pushback, and more. Typical product design interview questions highlight the main vision you want to achieve, but overlook the burdens of the day-to-day work to get there.
PM as a filter
[Amanda] As the PM, you will often be the first person many people talk to, to provide feature requests, ask questions about the product direction or vision, or to understand the roadmap.
You also act as a kind of filter for the rest of the team, so they are not randomized by loads of incoming questions. At the same time, you don’t want to ‘play telephone’ — routing questions from person A to your engineering team, then sharing the responses of the team back to person A, as an unnecessary intermediary.
How do you know when to field the questions yourself, and when to loop in the engineering team?
[Kay] I agree, this is a bit of an odd and very common situation PMs and especially new PMs find themselves in. The Product Managers at Work publication has a great article covering striking this balance and how to establish yourself as a subject matter expert especially when you’re new to a team and don’t have all the answers yourself.
What did we miss? What are the less ideal sides to the popular role of product manager many people get wrong? Let us know in the comments. :)
