Blog
ENGINEERING

9 Ways Product Management Expectations Differ from Reality

Yehong Zhu

September 01, 2020

PM Post Header

Table of contents

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.

1. Facetime with leadership is not all that it’s cracked up to be.

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.

2. “Influence without authority” is real.

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.

3. Product is hard to do well.

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:

The Triangle of Product Management

4. Product is lonely.

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.

5. Good PMing takes time to learn.

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.

6. Product is rarely ever clear cut.

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.

7. True originality in product is rare.

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.

8. Cutting corners is the norm.

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.

9. PMs can never be sad.

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!

Similar resources

state management
GuideEngineeringUser Experience

Cross-Channel Notification State: Why Read Receipts Are Harder Than They Look

When a user opens your email, does your app know? For most products, the answer is no. Each channel tracks its own state. Email has read receipts. Push has delivery confirmation. In-app has its own unread count. They don't talk to each other. Users notice. This guide covers the three approaches to notification state management (channel-first, central-first, event-first), when to use each, and how to implement cross-channel sync without overengineering. Includes state diagrams and practical implementation patterns.

By Kyle Seyler

February 03, 2026

Building Notification Infrastructure with Claude Code and Cursor
GuideEngineering

Terminal-First Development vs. IDE: Building Notification Infrastructure with Claude Code and Cursor

AI coding tools split into two camps: terminal agents (Claude Code) and IDE-augmented editors (Cursor). This guide compares both approaches using Courier's CLI and MCP server as the test case. Covers installation, configuration, and practical workflows for building multi-channel notifications. Includes code examples for user management, bulk operations, and automation triggers. Also explores agent-to-agent communication patterns where AI systems need notification infrastructure to coordinate tasks and escalate to humans.

By Kyle Seyler

January 29, 2026

notification platform for developers
EngineeringNotifications Landscape

The Notification Platform Developers Choose

Most notification platforms built dashboards first and added developer tools later. Courier did the opposite. With a CLI that handles real workflows, MCP integration with setup management, typed SDKs in seven languages, and SOC 2 Type 2 certification, Courier is built for teams that ship. This isn't marketing copy: Twilio chose Courier to unify notifications across their 10M+ developer platform. LaunchDarkly uses Courier to power feature release workflows. When the companies that build developer infrastructure choose your notification platform, that says something about the technical foundation.

By Kyle Seyler

January 26, 2026

Multichannel Notifications Platform for SaaS

Products

Platform

Integrations

Customers

Blog

API Status

Subprocessors


© 2026 Courier. All rights reserved.