Mostly harmless, conspicuously useful

The Hitchhiker's Guide to Becoming a Product Manager

A product manager decides what should be built, for whom, and in what order, which is a perfectly reasonable job description until you notice that the engineering team reads the roadmap for dates, the executive team reads it for ambition, and neither party is reading the same document. You learn to translate "we should do something about the dashboard" into problems worth solving, evidence worth gathering, bets worth sequencing, and a backlog that disappoints someone deliberately rather than accidentally. Product management is not the art of saying yes; it is the art of saying yes to one thing and thereby saying no to forty others, all of whom have opinions and three of whom have budget. The customer asks for a feature, the user needs a different feature, and the metric that went up may have gone up for reasons that are good, bad, or unrelated, which the dashboard will not volunteer. This guide travels from interviewing one confused user to setting product strategy for a portfolio, with practical stops at discovery, requirements, prioritization, metrics, roadmapping, and the recurring discovery that a shipped feature is a hypothesis that has finally been allowed to meet its evidence. The grand objective is a product that serves users and funds the company; the daily evidence is usually a decision that someone disagrees with, a metric that requires context, and a roadmap that survives the week in a shape its author still recognises.

Things to recognise

• A feature request describes a solution the customer already imagined; the underlying problem is usually larger, smaller, or adjacent, and building the request verbatim is the fastest way to ship the wrong thing on time.
• Backlog items carry hidden cost: each one must be estimated, refined, tested, documented, supported, and eventually retired, so a backlog that grows without pruning becomes a museum of intentions no one visits.
• Confirm the problem, the affected user, and the evidence before writing a story, because a correct story for the wrong problem is still impressively wasteful and surprisingly persistent.

Take the useful exit

Level 1 · Novice

Listen to the user before building the monument they did not request

You observe discovery interviews, support tickets, and requirement drafts without committing scope, learning how a sentence beginning "we should just" can end in a quarter of work.

You begin with read-only artifacts: discovery interview notes, support tickets, sales call summaries, competitor screenshots, a backlog someone else maintains, and a metrics dashboard expressing recent opinions about recent behaviour. Product discovery is the work of identifying and validating problems worth solving through user evidence, while requirements definition translates a validated problem into specs, user stories, and acceptance criteria that engineering can build and a tester can cross-examine. You review these with designers, engineers, support staff, and an experienced product manager so that everyone can trace how a vague complaint becomes a written story before anyone writes a line of code whose acceptance criteria is still "you know what I mean."

Suppose a sales rep reports that "customers want a bulk export." In a discovery review, you read the interview notes and find three customers mentioned export, two of them in the same week, one of them while describing a completely different problem. You draft a problem statement, list the jobs the export would satisfy, and note that none of the three asked for the same fields. One brisk problem statement is an anecdote with good posture, not a roadmap; but it prevents the team from commissioning an enterprise export engine for a job that one customer performs twice a year with a perfectly good spreadsheet.

Words from the spaceship manual, translated

Product discovery: The work of identifying and validating problems worth solving through interviews, observation, and evidence, before deciding what to build. It is the practice of finding out what is true, which is faster and cheaper than building something and then finding out.
Problem statement: A concise description of who has what problem, under what conditions, and why it matters. It describes the situation, not the solution, and a problem statement that mentions a button is a solution in a costume.
User story: A short statement of a user need in the form "as a [who], I want [what], so that [why]," expanded with acceptance criteria. It is a promise to have a conversation, not a substitute for having one.
Acceptance criteria: The conditions a story must satisfy to be considered done, written before the work begins. They are how the team agrees what "finished" means in a language more enforceable than a shared nod.