The product manager's job

Ask ten people what a product manager does and you'll get ten answers, most of them wrong. PMs are called "mini-CEOs," "the person who writes the specs," "the one in all the meetings." None of that captures it. The job has a definition, and understanding it is the difference between a PM who adds value and one who's just expensive coordination.

The actual job

A product manager is responsible for making sure the team builds the right thing — something valuable to customers and to the business — and they do it mostly through influence, not authority.

Two halves, both essential:

• "The right thing." Not building things faster (that's engineering's craft), not making them pretty (design's), but deciding what is worth building at all. A PM who ships the wrong thing efficiently has failed; a PM who ships the right thing has succeeded even if it was slow.
• "Through influence, not authority." This is the part that surprises people. A PM usually can't order anyone to do anything — engineers don't report to them, designers don't, executives certainly don't. They get the right thing built by building a shared understanding of what matters and why, so the team wants to build it. Persuasion, evidence, and trust are the PM's actual tools.

Not the CEO of anything

The "mini-CEO" myth does real damage, because it makes new PMs act like bosses — dictating, deciding unilaterally, overriding specialists. That fails fast, because they have none of a CEO's authority and all of a CEO's temptation to overreach. The engineers know more about what's buildable, the designers more about what's usable, the customers more about what's needed. A PM who dictates is throwing away the expertise around them.

The PM's real role is the opposite of a dictator: the person who gathers what the customers need, what the business needs, and what's technically possible, and synthesises them into a clear, shared decision about what to build — that the team then owns together.

The three lenses a PM balances

Every product decision sits at the intersection of three things, and the PM's job is to hold all three at once:

• Desirable — do customers actually want it? (The customer lens.)
• Viable — does it work for the business? (The business lens.)
• Feasible — can we actually build it, well, in reasonable time? (The technical lens.)

A great feature that's not feasible is a fantasy. A feasible, desirable feature that doesn't help the business is a charity. The PM lives where all three overlap, and most of the job is navigating the tension between them.

The worked example

A treats himself as the mini-CEO. He decides features alone, hands engineering detailed specs, and pushes his vision through by force of position. The engineers, whose feasibility concerns he overrode, build it reluctantly and slowly; it turns out customers didn't want it (he never checked); and the team resents being dictated to. He was "in charge" and delivered the wrong thing badly.

B sees her job as building shared understanding. She brings the customer evidence, works with engineering on what's feasible, aligns it to a business goal, and lets the team shape the how. The decision is clearly reasoned and collectively owned, so it's built well and fast — and it's the right thing, because desirability, viability, and feasibility were all checked. She had no more authority than A. She used influence instead.

The mistake

Thinking the job is to have great ideas and direct people to build them. The job is to make sure the team builds the right thing — discovered from customers and the business, validated as feasible — and to do it by earning agreement, not issuing orders. Great PMs are rarely the loudest voice; they're the clearest thinker and the most trusted synthesiser in the room.

---

Your turn

1. Write your product's current top priority. Then check it against the three lenses: desirable, viable, feasible. Does it pass all three?
2. For one recent decision, ask: did I dictate it, or did I build shared understanding? Notice which gets better results.
3. Identify the expertise around you (eng, design, customers) you've been overriding instead of gathering.

Key points

• A PM makes sure the team builds the RIGHT thing — through influence, not authority.
• The 'mini-CEO' myth causes overreach; the real role is synthesiser, not dictator.
• Every decision balances three lenses: desirable, viable, feasible.
• Great PMs are the clearest thinker and most trusted voice, not the loudest.