Yehong Zhu is the founder and CEO of Zette, an early stage consumer technology startup that aims to make journalism more accessible to the general public. Previously she was a product manager at Twitter and a reporter at Forbes.
As a former product manager, bright-eyed and bushy-tailed out of college, I remember clearly coming into the role with a set of rosy expectations that did not align at all with reality. I want to share my experience of what product was like for me, and a smattering of the various ironies that I experienced on the job.
Without further ado, here are 9 ways my expectations of product management differed from reality.
Expectations: “PMs are always meeting with leadership—wow, that’s so cool!”
Reality: While it’s true that PMs are frequently interfacing with senior managers, stakeholders, and executives at the company, these conversations can often be high-pressure, stressful, or frustrating. Stakeholders are often asking why features are behind schedule, incomplete, or not performing as well as projected.
Expectations: “PMs are the CEO of the product!”
Reality: PMs have little to no direct control over the outcome of a feature or product.
Even if PMs can design or code, this is typically outside the scope of their role. PMs are also not the managers of non-product folks, merely collaborators in a different reporting chain. They often have to ask (beg) others to do their jobs faster, cut nonessential features to save engineers and designers time, or try to run around unblocking blockers—giving new meaning to the idea of servant leadership.
Expectations: “We have so much headcount and so many ideas! We can build soooo many cool features!”
Reality: PMs quickly learn that no matter how many resources or product ideas you have, only two out of the following three can be true at any given time:
Expectations: “Product is a social job!”
Reality: Product is social insofar as your day consists largely of meetings. However, product roles are almost always structured so that there is one PM per multiple engineers. This means that by default, there are fewer product folks and more of everyone else.
Engineers and designers can collaborate and get feedback on each other’s work, but PMs have fewer peers and are not always able to collaborate with them, particularly if other teams—even within the same company—have divergent roadmaps competing for the same scarce development resources and stakeholder attention.
Expectations: “I read “cracking the PM interview” and passed a competitive PM job interview—I know what I’m doing, no sweat!”
Reality: There is no one path into product. Either you enter the role as a new grad from college, or you transition in from an adjacent field (startups, consulting, MBA, etc). There is also no surefire way to “test drive” PM skills before getting hired; it’s something you have to learn on the job.
Either way, it takes 6 months to become useful as a product manager, and longer to become truly efficient. Onboarding as a PM is an investment that only pays off later down the line.
Expectations: “I’ll just manage the product—how hard could it be?”
Reality: Product management is anything but clear. In fact, the purpose of your job is to provide clarity and vision where there is often only chaos. Product roadmaps are a mix of intuition, data, and user research. Sometimes these roadmaps lean on “product intuition” more than you might think.
Expectations: “We are going to innovate on the product and create something entirely new!”
Reality: There is never enough time for “blue sky” thinking in product.
Somehow you always have a million emails, another meeting around the corner, and your team is already several weeks delayed on an existing feature. Many feature builds are often derivative of other successful apps or competitors in the market until the market is quickly saturated with the same feature, even if it only came out recently—after all, normal years are essentially dog years in tech.
Perhaps imitation is the sincerest form of flattery—or at least the easiest to justify and build.
Expectations: “It’s totally reasonable to ship this new product on time, feature complete and with all the cool bells and whistles that we discussed!”
Reality: There is never enough time to get to “feature complete,” and prioritization is often ruthless—to the point where features originally marked as “P0” are marked down to “P2” just to get the product approved for headcount.
Those cool bells and whistles you thought would come out in the first iteration of the product might never come out at all, and sometimes headcount can be axed for maintaining products that are already shipped in order to support new shiny products that don’t yet exist. Either way, you might have to save the crazy animations and advanced color settings for another day.
Expectations: “Being a PM is the best job in the world!”
Reality: Somedays (and we all have these days), being a PM is the worst job in the world. Yet because PMs are often the face of the product, they cannot afford to be sad, visibly stressed, or dejected, lest you will transmit these negative emotions to your team through osmosis.
During hard times, your team will look to you for strength, guidance, and clear communication. As the emotional cheerleader of the team, you have to be a beacon of light and smile through the pain, regardless of how you might be feeling internally.
Being a PM is an awesome job, and learning how to PM software development is a skillset I’ll forever be grateful for. But be careful not to idealize the experience too much; the real world constraints are very real and can quickly box you in!
The best PMs know how to balance idealism with pragmatism in order to get stuff done—they bring their best to work on good days, bad days, and all the days in between. So the next time you see your PM, make sure to thank them for all that they do!
If you're a PM reading this and are interested in joining Courier, let us know! We're currently hiring for a PM based in San Francisco.
In this post, we will start diving into the internals of Postgres to understand how replication works an...
January 20, 2022
In the bigger picture, observability ties your technological infrastructure to your overarching product ...
December 15, 2021