A self-incriminating field guide for new and aspiring product managers, written between meetings I did not need to be in.

If you are new to product management, congratulations: you have been handed a job title that everyone — including you, including your mom, including the recruiter who placed you — completely misunderstands. The first 90 days will be a quiet, humiliating tour through every fantasy you had about the role.

Here are seven of mine. May yours be shorter and cheaper.

1. "I am the decider."

My fantasy: I would sit at the head of the table in a soft-shoulder blazer, listen to my engineers and designers debate, and then point at one of them like a Roman emperor in a hoodie. We ship Option B. Lunch is on me.

Reality: I do not decide whether the cache invalidates on logout. I do not decide what shade of grey the empty state is. I do not decide which framework gets used. I do not decide how the API is shaped. The engineer decides the engineer things. The designer decides the designer things. I am responsible for whether the customer wants the thing at all, and whether the business can actually sell, support, and not get sued for it.

If you walk into a team meeting day one and try to "decide," the engineers will smile politely and then quietly route around you for the rest of the quarter. You will find out at the retro.

The real job: Be the person who knows the customer, the data, the market, and the business well enough to shape the thing — not order it.

2. "I am the protector of the team."

My fantasy: Stakeholders are wolves. I am a Roman shield. The engineers are the artisans, and I stand between them and the howling sales VP, taking arrows so they may craft.

Reality: When you "protect" the team by saying no to every request, two things happen. One, the requesters go around you, because adults do that. Two, you lose the most valuable thing a new PM can have, which is people in other parts of the company who will actually pick up your call.

The sales VP is not a wolf. The sales VP has a quota and is the reason your salary cleared on the 15th.

The real job: Engage with the requests. Most of them won't survive contact with the actual problem and the actual data, but you have to show that, not just deflect it. "Protector" is how junior PMs end up isolated and slowly de-staffed.

3. "I am the why-guy."

My fantasy: I would stride into standup, gesture at a Miro board, and explain the why with such conviction that the engineers would weep and recommit to the mission.

Reality: "The why" usually fits in two sentences. Customers churn at month three because onboarding is incoherent. If we cut it from 11 steps to 4, we expect retention up 6 points. Done. That took eight seconds. If your entire job is saying that out loud once a quarter, you are not a product manager — you are a slightly expensive parrot.

The real job: Yes, articulate the problem and the metric. But that's the warm-up, not the workout. The work starts after.

4. "I write a great PRD, therefore I have done product management."

My fantasy: A 14-page PRD with a Table of Contents, a Background section, a Glossary, three Appendices, and a Slack thread of compliments from the design lead.

Reality: A long PRD written before you've put a prototype in front of a real human being is a confident document about a thing that does not work yet. I have personally written PRDs for features that, when prototyped, customers visibly recoiled from. The PRD did not save the feature. The PRD just made the funeral better-documented.

The real job: Prototype first, learn what actually solves the problem, then write the spec — and let the prototype itself carry most of the weight. The PRD covers the edge cases the prototype can't show: scale, compliance, weird states, the eight things legal cares about. It is a supplement, not a séance.

For new PMs: If your team's process is "PM writes a doc → engineers build it → ship it → hope," that's not product management, that's a relay race with a guaranteed dropped baton. Real discovery means putting something fake in front of someone real before anyone writes production code.

5. "My job is to confirm the problem is real."

My fantasy: I'd interview ten customers, return triumphantly with a slide that said YES, THE PROBLEM IS REAL, and everyone would clap.

Reality: Your leadership already knew the problem was real. That's why it's on the roadmap. If you spend three weeks "validating" something every adult in the building already accepts, you will be (correctly) perceived as someone who needs three weeks to find the bathroom.

The real job: Assume the problem is real and go find a solution that actually moves the metric. The hard part is almost never "is churn bad?" The hard part is "what do we build that makes churn less bad in a way the customer notices and prefers over what they have now?"

6. "AI is going to do my job."

My fantasy / nightmare, depending on the day: A model writes the spec, generates the prototype, runs the user test, summarizes the findings, and emails it to the engineers, while I stare at a window.

Reality: AI is genuinely fantastic at the delivery side — code generation, boilerplate, scaffolding, glue. That's the easy half of the job, and it's getting easier every quarter. The hard half — figuring out which solution will actually move a real human being to switch from what they're doing today — is now more valuable, not less, because everyone else's delivery just got faster too.

What AI will do for new PMs, if you let it:

• Spin up a clickable prototype in an afternoon instead of a sprint.
• Roleplay a skeptical customer or a hostile stakeholder so you can rehearse the conversation before you have it for real. (Yes, this is a very subtle plug for the PM Depot simulator. We have eight personas and one of them will absolutely ruin your sprint planning.)
• Pressure-test your assumptions before you commit to a doc.
• Help you build the taste — what good looks like — that takes most PMs five years to develop by osmosis.

It does not replace judgment. It accelerates the people who have it and exposes the people who don't.

7. "If I just ship more, faster, the metrics will move."

My fantasy: Output is outcome. Velocity is virtue. If we just shipped twice as much, retention would double. Probably.

Reality: Customers can tell when they're being used as a test track. Every change costs them attention, retraining, and a small amount of trust. Ship enough half-baked stuff at your loyal users and they will start to feel like the lab rats they technically are. Then they leave, and your "velocity" metric will be the only one trending up at the all-hands.

The real job: Test on the small group of people who opted in to being tested on. Protect everyone else from the chaos. Ship to the masses only when you have actual evidence the thing works.

So what is the job, in one sentence a hiring manager won't roll their eyes at?

You're an individual contributor on a small team of builders, and your specific contribution is making sure whatever the team builds is something customers will actually use and the business can actually sustain. Everything else — the docs, the meetings, the OKRs, the strategy slides — is in service of that, or it's noise.

The first 90 days are mostly about realizing how much of the noise you used to think was the job.

Sharpen your judgment without burning real customers: PM Depot runs an AI simulator where new PMs can absolutely faceplant in private — discovery calls, sprint planning, customer interviews, hostile stakeholder ambushes — against personas that don't care about your feelings and won't tell HR. Also: a toolkit, frameworks, and a coach named Hal who will ask you the one question you were hoping nobody would.

Practice the meeting before the meeting practices you.