General PM

What a Product Manager Actually Does

A PM is responsible for the outcome of a product, not any single deliverable. In practice that means constantly moving between understanding user problems, deciding what to build, and making sure it actually ships and works. There is no fixed job description that holds across companies — the shape of the role changes with company stage, but the core job, deciding what matters and why, does not.

The Product Life Cycle

Every product moves through recognizable stages: discovery, before you know if the problem is real; build, once you have enough conviction to commit engineering time; launch, when real users first touch it; and growth or decline, once the market gives its verdict. Knowing which stage you are in changes what "good work" looks like — the discipline discovery rewards (staying open, testing cheaply) actively hurts you once you are in growth mode, where focus and execution speed matter more.

Core PM Vocabulary

Terms like North Star Metric, MVP, roadmap, backlog, and PRD get used loosely and inconsistently across companies. A North Star Metric is the single measure that best represents the value your product delivers. An MVP is the smallest version of a product that lets you test a real assumption, not a smaller version of your final vision. Getting these definitions straight early saves you from talking past engineers and designers who use the same words differently.

Types of PM Roles

Not all PM roles are the same job. A Growth PM is judged on acquisition and retention numbers. A Platform PM builds for other engineering teams as their customer. A Technical PM needs enough engineering fluency to make architecture tradeoffs credibly. An AI PM increasingly needs to understand model behavior and evaluation, not just user behavior. Knowing which flavor of PM you are, or want to become, changes what skills are actually worth investing in first.

Problem Framing

Most failed products did not fail because of bad execution — they failed because the team was solving a problem nobody urgently had. Problem framing means writing down, in plain language, who has the problem, when it shows up, and what they currently do about it (including doing nothing). If you cannot state the problem without mentioning your own solution, you have not actually framed it yet.

User Research Methods

Interviews, surveys, and usage data each answer different questions. Interviews are best for understanding why, in someone's own words, but are easy to lead with a bad question. Surveys scale but only tell you what people think they'll do, not what they actually do. Usage data tells you what people actually did, but never why. Good discovery combines at least two of these rather than trusting one in isolation.

Jobs to Be Done

People don't buy products, they hire them to make progress on something. The Jobs to Be Done lens asks what "job" a user was trying to get done when they reached for your product, or a competitor's, or a completely different category of solution entirely. This reframing is useful because it surfaces real substitutes you'd otherwise miss — a spreadsheet can be the actual competitor to your analytics tool, not another analytics tool.

Validating Demand Before You Build

Validation means finding the cheapest possible test that could prove you wrong. That might be a landing page measuring signup intent, a manual "concierge" version of the feature done by hand before it's automated, or simply asking a handful of target users to pay before anything exists. The goal is never to prove yourself right — it's to find out fast, and cheaply, if you're wrong.

Product Vision

A vision describes the world your product wants to exist in a few years out, independent of any specific feature. It should be specific enough to rule things out — a vision vague enough to justify any roadmap decision is not actually doing its job. The test of a good vision is whether it helps you say no to a reasonable-sounding feature request because it doesn't serve where you're trying to go.

Strategy Frameworks

Frameworks like Playing to Win (where to play, how to win) or the Product-Market Fit pyramid exist to force explicit tradeoffs rather than let strategy stay implicit. None of them are magic — their value is in the discipline of writing the answer down and testing whether your team actually agrees on it, which is often where strategy quietly falls apart.

Positioning

Positioning is the specific claim you make about who your product is for and what it does better than the alternative, stated plainly enough that a stranger understands it in one sentence. Weak positioning tries to be for everyone; strong positioning accepts that being clearly right for a narrow group beats being vaguely relevant to a broad one.

Prioritization Frameworks

RICE, ICE, and similar scoring frameworks exist to make competing priorities comparable on the same axis instead of an argument about whose feature "feels" more important. They work best as a forcing function for the conversation, not as a spreadsheet formula you trust blindly — the real value is in debating the inputs, not the final score.

Roadmapping

A roadmap that lists features and dates is a promise, not a strategy artifact — and it will be wrong the moment reality diverges from the plan, which is always. A roadmap organized around outcomes and themes instead of specific features gives you room to change the "how" without breaking the commitment you actually made to stakeholders.

Working With Engineering and Design

The PM's job in this relationship is to arrive with a clear problem and constraints, not a pre-decided solution — otherwise you're not collaborating with engineering and design, you're dictating to them and losing their best thinking. The best PM/eng/design relationships treat tradeoffs as a shared decision, made with full information on both sides, not a negotiation across a wall.

Agile and Sprint Practices

Agile ceremonies (standups, sprint planning, retros) exist to surface problems early, not to perform process for its own sake. A team doing Scrum by the book but never actually adjusting based on what a retro surfaces is going through the motions. The actual point is a tight feedback loop between planning and reality.

Shipping and Iteration

Shipping is not the finish line — it's the point where you finally get real signal instead of a guess. Treat the first release of anything as a hypothesis test, with a plan for what you'll look at afterward to decide whether to invest further, iterate, or kill it. Products that never get iterated on after launch usually weren't being watched closely enough to know they needed it.

Defining Success Metrics

A good metric is specific enough that two people looking at the same dashboard would agree on whether it moved. Vague goals like "improve engagement" hide the fact that nobody has actually decided what engagement means numerically, which makes it impossible to know if you succeeded.

North Star Metric

Your North Star Metric should represent the value your product delivers to users, not a vanity number that goes up regardless of whether people are genuinely benefiting. A good test: if this number goes up but users are unhappier, you picked the wrong metric.

Experimentation and A/B Testing

A/B testing only produces trustworthy answers with enough sample size and a genuinely random split — running a test on too little traffic and reading the early results as a verdict is one of the most common ways teams fool themselves with "data."

Data-Informed Decision Making

Data should inform judgment, not replace it — numbers tell you what happened, not always why, and not what to do next. The strongest PMs use data to challenge their own assumptions first, before using it to challenge anyone else's.

Launch Planning

A launch is not a single day, it's the coordination of positioning, channels, and internal readiness all landing at the same moment. Planning backwards from launch day, rather than treating it as whatever's left over once building is done, is what separates a real go-to-market motion from an afterthought announcement.

Acquisition

Acquisition channels differ enormously in cost, speed, and durability — paid ads buy speed but stop the moment budget stops, while something like an agent network or word of mouth is slower to build but compounds. The right channel depends entirely on your specific market's trust dynamics, not a generic "best practice."

Activation and Retention

Activation is the first moment a user experiences the real value of your product, and it's usually much narrower and more specific than "signed up." Retention is what happens after — and it lives or dies on whether the product becomes a genuine habit, not just a one-time useful tool.

Monetization Basics

Pricing and packaging decisions should follow from how value is actually delivered and perceived, not be bolted on after the product is built. The units you charge for should track the units of value a customer experiences — charging per seat when value scales with usage, for example, misaligns the two.

AI-Assisted Development for PMs

AI-assisted development changes the PM's job by collapsing the distance between a spec and a working prototype — a PM who can prompt a real, functioning first draft can validate ideas faster than one who can only write a document about them. That doesn't replace engineering, but it does change how early in the process a PM can get real signal.

AI Product Management Fundamentals

Managing an AI-powered product means managing for probabilistic, not deterministic, behavior — a feature can work correctly 95% of the time and still be a bad product if the 5% failure mode is the wrong one. Evaluation, not just a demo, is how you know if an AI feature is actually ready.

Working With AI Tools as a PM

The AI tools worth adopting as a PM are the ones that shorten the distance between an idea and a testable version of it — for research synthesis, for drafting specs, for prototyping. The risk is trusting AI output uncritically on anything user-facing without your own judgment sitting on top of it.

Influencing Without Authority

Most of a PM's influence comes from being trusted to have done the homework, not from a title. Bringing evidence, having genuinely considered the counterargument, and being willing to be proven wrong builds the kind of credibility that gets your call respected the next time, even without formal authority over the people you're asking to move.

Communicating Up and Across

Executives need the headline and the decision being asked of them; your team needs the detail and the reasoning behind it. Sending the same message to both audiences usually under-serves one of them — knowing which altitude to communicate at is its own skill, separate from the underlying judgment.

Managing Through Ambiguity

Product work rarely comes with a clear right answer, and waiting for certainty before deciding usually just means someone else decides for you, later, with less context. The skill is making a reasoned call with incomplete information and being transparent about what you don't yet know, rather than projecting false confidence.

Building a Portfolio

A PM portfolio is strongest when it shows real reasoning, not a polished summary of an outcome — what the problem actually was, what you considered and rejected, and why. A single case study walked through in depth beats five bullet points of impact metrics with no story behind them.

Interviewing as a PM

PM interviews test whether your thinking is structured under pressure, not whether you land on the "correct" answer to a hypothetical. Practicing out loud, with a real framework you can fall back on when you're stuck, matters more than memorizing sample answers to common questions.

Operating as a PM Day to Day

Most of the real job is unglamorous: writing things down clearly enough that decisions don't need to be re-litigated, following up on the details nobody else is tracking, and noticing early when a project is quietly drifting off course. The daily discipline is what the frameworks are actually in service of.