What is Product Management?
It's not what the job descriptions say. It's about reducing the right uncertainties.
Every product team faces the same terrifying question: Are we building the right thing?
Engineers can tell you if it’s possible. Designers can tell you if it’s usable. But someone has to figure out if it’s worth building at all.
That’s the PM.
The Core Job: Reducing Uncertainty
Product management exists because building products is expensive and most products fail. Not because teams are incompetent. Because the future is unknowable, users lie (unintentionally), and markets shift.
The PM’s job is not to eliminate uncertainty. That’s impossible. The job is to reduce it systematically before the team invests months of engineering time.
Think about it this way: every product decision is a bet. The PM’s job is to make sure the team is making informed bets rather than blind ones.
The Four Types of Uncertainty
Every product decision sits at the intersection of four questions:
Value uncertainty: Will customers actually want this? Not “will they say they want it” but will they change their behavior to use it?
Usability uncertainty: Can customers figure out how to use it? A valuable product that’s confusing is still a failed product.
Feasibility uncertainty: Can we actually build it? With our team, our technology, our timeline?
Viability uncertainty: Should we build it? Does it fit our business model, our strategy, our resources?
A PM who ignores any one of these is gambling.
Google+ had world-class engineers (low feasibility uncertainty) but never answered the value question. They shipped features, not solutions.
Three Activities Every PM Does
Regardless of company size or product type, PM work breaks into three activities:
Discovery: Figuring out what to build. This is research, customer interviews, data analysis, prototype testing. The goal is reducing value and usability uncertainty before committing engineering resources.
Delivery: Actually getting it built and shipped. Working with engineering and design, writing specs, making trade-off decisions, removing blockers. This is where feasibility uncertainty gets resolved.
Optimization: Making it better after launch. Looking at metrics, running experiments, iterating based on real user behavior. This is where you learn if your bets paid off.
The ratio changes based on context. Early-stage startups are 80% discovery. Mature products might be 60% optimization. But every PM does all three.
The Slack Story: Discovery Done Right
In 2012, Stewart Butterfield’s company Tiny Speck was dying. They’d spent years building Glitch, an online game. It wasn’t working.
But something interesting was happening internally. The team had built a chat tool to coordinate across offices. People loved it. Not just used it. Loved it.
Butterfield noticed. The product people wanted wasn’t Glitch. It was how they talked to each other while building Glitch.
This is product management.
Not the decision to pivot. The noticing. The pattern recognition. The willingness to see that the valuable thing isn’t what you expected.
Slack launched in 2014. Salesforce acquired it for $27.7 billion in 2021.
The Google+ Story: Delivery Without Discovery
Google+ launched in 2011 with massive advantages. Google’s engineering talent. Distribution through Gmail, YouTube, Search. A $585 million marketing budget.
They shipped Circles (organize contacts), Hangouts (video chat), Streams (news feed). All technically excellent. All features that looked like Facebook features.
But no one at Google seemed to ask: What job do people need done that Facebook isn’t doing?
The answer, it turned out, was nothing. People weren’t frustrated with Facebook in a way that required a whole new social network. Google+ solved a problem Google had (competing with Facebook), not a problem users had.
Google+ shut down in 2019. Eight years and billions of dollars spent building a product no one needed.
The Invisible Decisions: Netflix’s “Are You Still Watching?”
You’ve seen this prompt. You’re three episodes into a show. Netflix asks if you’re still there.
This is a PM decision. Someone had to weigh:
User experience: Interrupting binge-watching is annoying.
Infrastructure costs: Streaming to sleeping viewers wastes bandwidth.
Engagement metrics: Does this prompt actually help or hurt retention?
Business model: What’s the cost-benefit of serving unconscious customers?
There’s no obviously right answer. A PM looked at the data, considered the tradeoffs, and made a call.
Every product you use is full of these invisible decisions. Someone chose the default settings. Someone decided which features made the cut. Someone picked the error messages you see when things break.
That someone is usually a PM.
How Companies Do It Differently
The PM role isn’t standardized. It adapts to context.
At Google: PMs are highly technical. They write detailed specs and work closely with engineers. The culture values analytical rigor and data-driven decisions.
At Amazon: PMs “work backwards” from the customer. They write the press release and FAQ before building anything. The culture values customer obsession and long-term thinking.
At startups: The PM might also be the founder, the customer support rep, and the person fixing the office Wi-Fi. Scope is unlimited, resources are scarce.
At enterprise companies: PMs spend more time on stakeholder management, sales enablement, and navigating organizational complexity. Technical decisions get delegated; political decisions don’t.
None of these approaches is “right.” They’re adaptations to different contexts.
When You Don’t Need a PM
Not every team needs a PM.
Early-stage startups often do better with founders filling the PM role. They have context and conviction that a hired PM would spend months acquiring.
Small teams with strong engineering leadership can self-organize around customer problems without dedicated product management.
Technical infrastructure teams sometimes need technical project managers, not product managers. The “customer” is internal, the problems are well-defined.
PM becomes necessary when:
The team is big enough that coordination requires a dedicated person
The problems are ambiguous enough that someone needs to focus full-time on understanding them
The stakeholder landscape is complex enough that someone needs to manage it
Adding a PM too early creates overhead. Adding one too late creates chaos.
Common Mistakes: What Bad PM Looks Like
Mistaking activity for progress: Full calendars and busy Slack channels don’t mean the product is getting better. Good PMs obsess over outcomes, not outputs.
Feature factory thinking: Treating product development like a conveyor belt. Specs go in, features come out. No learning, no iteration, no discovery.
Skipping discovery: Jumping straight to “what should we build?” without understanding the problem. This is how you build Google+.
Over-rotating on delivery: Becoming a project manager instead of a product manager. Tracking tasks instead of reducing uncertainty.
Ignoring constraints: Pretending feasibility and viability don’t matter. Dreaming up features the team can’t build or the business can’t support.
Here’s something worth noticing.
Pick a product you use daily. Instagram, Spotify, Uber, your banking app. Anything.
Now pick one feature and trace back the uncertainty decisions:
What value question did they have to answer? (”Will people actually share Stories?”)
What usability question? (”Can people figure out how to post?”)
What feasibility question? (”Can we build this at scale?”)
What viability question? (”Does this help us compete with Snapchat?”)
Now look for the tradeoffs. What did they sacrifice? What did they optimize for? Where do you see the invisible fingerprints of a PM decision?
You’ll start seeing these decisions everywhere. That’s when product management clicks.
Key Takeaways
PM is about reducing uncertainty, not eliminating it. You’re making informed bets, not guaranteeing outcomes.
Four uncertainties compete for attention: Value, Usability, Feasibility, Viability. Ignore one at your peril.
Three activities fill a PM’s time: Discovery (what to build), Delivery (getting it built), Optimization (making it better).
PMs have responsibility without authority. You can’t tell anyone what to do. You influence through clarity, context, and conviction.
The role adapts to context. Google PMs, Amazon PMs, and startup PMs do the same job differently.
Google+ had great engineers. Technical excellence isn’t enough. Reducing the right uncertainty matters.
This is the first article in a comprehensive Product Management Knowledge Base, designed to take you from foundational concepts to real-world product execution. Subscribe to follow the complete journey and build product thinking that goes beyond frameworks and interview prep.