Product Manager

Teams used to build products with nobody in particular deciding what to build. Sales passed along whatever a customer asked for, engineering built it, and anything urgent got settled by whoever ran the company. With ten people and two or three requests a week, that works.

It stopped working as requests piled up. With twenty requests on the list and room for three this month, no one in the room had the job of choosing the three. Engineering, with no basis for choosing, built whatever was asked loudest, and when the result went unused the blame spread out somewhere between sales and engineering. Six months of that produces a product with thirty features and five that anyone opens. Nobody made a bad call along the way, which is the point — there was no call to make.

A product manager (PM) exists to fill that empty seat. Decisions collect with one person, and the same person has to explain afterwards whether the decision was right. What shapes the role is that the seat came with responsibility rather than authority. A PM usually has no say in hiring or performance reviews, so the way to move anything is to build the case and win the team over.

A day is made of three things: checking numbers, sitting in working sessions, and writing decisions down. The order varies by team; the work looks about like this.

1. Morning starts with yesterday's numbers — how much the newest feature is being used, how many new signups reach the point where the product first does something for them. A number that was 12 percent yesterday and is 4 percent today rewrites the day's plan, usually before anyone has opened a calendar.
2. Late morning goes to whatever is being built now. Reviewing design work and settling the conditions it left open, answering the edge cases engineers ask about. "What should this show when the payment fails?" arrives several times a day, and an unanswered one of those stalls a whole ticket.
3. Afternoon goes to putting decisions in writing. The document covering what is being built, why, and what counts as finished is a product requirements document (PRD), and each requirement inside it gets cut into one-sentence units written from the user's side, called user stories. The product backlog, where candidates wait, gets reordered in the same stretch.
4. Users and salespeople get met with in the gaps. Checking whether something is worth building before building it is product discovery, and these conversations are its raw material.
5. Weekly, prioritization and the product roadmap come back around. With forty candidates and room for six this quarter, explaining the thirty-four that got deferred takes longer than explaining the six that didn't.

Nothing in that day produces code or screens, so the output is hard to see. Plenty of days end with three decisions and nothing else, and whether those decisions were good shows up in the numbers weeks later. That lag is most of what makes the job hard to evaluate from outside, including for the person doing it.

The daily pairing is with a designer and with engineers. With a product designer a PM works out how the problem gets solved; with engineers, how much of it fits in this round. Many companies treat those three as the standard unit of a product team, and the pairing holds even when the team has no formal name for it.

When a question needs numbers, it goes to a product analyst — the role that reads product data into something a decision can rest on. Splitting the person who forms the hypothesis from the person who tests it cuts down on finding only the result you wanted. On smaller teams the same person does both, and the safeguard has to come from writing the expected number down before looking.

Requests arrive through sales and customer success. Why a deal was lost, why an account left: those land there first. Turning what got built into language a market understands belongs to a product marketing manager, and the two of them negotiate launch timing and message. The reporting line usually runs up to the chief product officer (CPO), who owns the product organization.

None of those relationships comes with authority, and that's the condition the job runs under. Neither the designer nor the engineers report to the PM, which leaves evidence and agreement as the only instruments available.

"The PM needs to call this before the next step can move."

Design and engineering are both stopped, waiting on a decision.

"Mia, send the PRD first and we'll break it into tickets."

The requirement has to be written down before it can be split into units of work.

"That request didn't make the roadmap this quarter. The reasoning is written up."

An answer that hands over the deferral and its reasoning together.

At Pagedeck a request to put expiry dates on shared document links came in eleven times across three quarters. Sofia collected the list, and Mia brought it to the prioritization meeting with the contract size of each requesting account and whether that account had since churned attached.

What got settled there wasn't build or don't build but order. Expiry dates went into the quarter and access logs went to the next one, because Theo said the two together ran four weeks while expiry alone ran one. Mia wrote up the reasoning for the deferred half and shared it with sales, so the same eleven accounts could be answered with something other than silence.

The most common mistake is reading "mini CEO" as a description of authority. A PM sets the direction of a product, so the comparison feels natural. But unlike a chief executive, a PM cannot hire, evaluate or direct anyone. Miss that difference, start delivering decisions as instructions, and the team complies on the surface while quietly stopping the flow of bad news. The person who loses the most from that is the one making the decisions, since the warnings that stop arriving were the ones worth hearing.

The other one is narrowing the job to writing specs. The visible output is documents, so it reads that way. Documents are how a decision travels; what the role answers for is the result that decision produced once it reaches users. A beautifully written spec that yields a feature nobody uses leaves the responsibility here, not with whoever received the document.