Chapter 4 The peers & power map
You don’t ship alone. You ship through people.
AI didn’t change that. It changed who has leverage, where — and it changed faster than the org charts did. Most teams are still running 2019 collaboration patterns on 2026 technology. That gap is where the friction lives.
Understanding your peers is not soft skills. It is a strategic map of where decisions get made, where they get blocked, and where your value either compounds or disappears.
4.1 1. Engineering: From spec-taker to co-decider
Before: You wrote the spec. Engineers asked questions. You answered. They built. Your value came from being the person who resolved ambiguity before it reached them.
After: Engineers paste your PRD into Cursor and have a working prototype before the meeting ends (ProductBoard 2024). The spec isn’t the plan. It’s the opening position in a negotiation you now share.
The question shifted from “Can we build it?” to “Should we?” Engineers have always had an opinion on “should we.” They now have the tools to demonstrate it. The PM who treats engineers as executors is losing ground to the PM who treats them as co-deciders with a different angle on the same problem.
Startup (fewer than 50): There is no “Engineering.” There’s a CTO and two others, and everyone is a PM in some corner of the product. Your value is not writing the spec. It’s being the person who kills 80% of what gets prototyped before it becomes technical debt. If you fall in love with every demo, you become QA with a nicer laptop.
Scale-up (50–500): You have real engineering managers, real roadmaps, real tension between platform work and feature work. AI makes it possible to build the wrong thing five times faster. Your defense is the pre-mortem: “If this works exactly as designed, what breaks? What slows down? Who has to support it for two years?” You’re not writing specs to start work. You’re writing them to stop bad work.
Mega-corp (5,000+): Engineering is a city. Infra, platform, ML, integrity — all separate orgs, all with different incentive structures. You do not convince “Engineering.” You convince four Staff engineers, two Directors, and a TPM who each have veto power and each measure success differently. Your edge is context they don’t have: what the CEO said in the all-hands, what the legal review found, what the data from the last three experiments actually means when you read it carefully. The model doesn’t know any of that. You do.
Test: If an engineer shipped your feature without you, would users notice the absence of your involvement? If no, you weren’t doing PM work. You were project management.
4.3 3. Data: From gatekeeper to co-interpreter
Before: You waited two sprints for a dashboard. The scarcity made you thoughtful. You asked fewer, better questions.
After: You ask the model, you get the chart in three minutes, and you have ten times as many questions by noon. The abundance is making everyone sloppy.
The relationship with the data team shifted. They used to be a bottleneck you worked around. Now they’re a check on the analysis you’ve already run. That’s a harder relationship to manage, because it requires you to be right often enough to justify moving fast and humble enough to get reviewed before you take action.
Startup: There is no “Data.” There’s a Postgres database and a founder who knows SQL and a dozen tables named with timestamps that you cannot decode. Anyone can query now. Half the queries are wrong because the schema is lying. Your job is knowing which table is lying and why — that is judgment. It has no shortcut.
Scale-up: You hired a data team. They have a backlog three weeks long. You’ve learned to self-serve with LLM-to-SQL. Now your analysis is fast but unreviewed, and the data team is frustrated because they keep cleaning up after you. The right arrangement: use AI to explore, bring data into anything you’re going to act on. Not because you can’t trust yourself. Because “I ran this by data” is a defensible position when the CEO asks why the metric moved.
Mega-corp: Data is a priesthood with metrics, logging, experimentation policy, and a privacy review process that you cannot shortcut. Your job is not to go around them. It’s to bring them in early enough that the instrumentation you need is baked into the build, not bolted on after launch when you’re trying to measure what happened.
Test: When the data and your gut disagree, how do you decide? If you say “data every time,” you’re a spreadsheet. If you say “gut every time,” you’re fired. PMs answer “it depends” and then explain what it depends on. The quality of that explanation is the actual test.
4.4 4. GTM: From feature-thrower to story-partner
Before: You threw features over the wall. GTM figured out how to sell them. You blamed each other when they didn’t sell.
After: Sales reps, marketers, and CS leads have AI generating their own one-pagers, email sequences, and objection responses. If your story is weak, they’ll rewrite it — and what they rewrite it into might not be what you intended to promise. If your story is strong, they’ll amplify it at a scale you can’t match yourself.
The leverage point moved from “write the enablement doc” to “own the narrative before it gets rewritten.”
Startup: GTM is the founder and one AE and you, on a call with a prospect who is telling you in real time that the product doesn’t do what you thought they needed. That is the apprenticeship. It is painful. It works.
Scale-up: GTM is real now. They have quota. They have a customer on the phone right now asking about the feature you deprioritized last quarter. Your job: give them a story that survives first contact with a real buyer. Not a story that sounds good in a planning review. A story a sales rep can retell in thirty seconds without embarrassing themselves or the company.
Mega-corp: GTM is a continent. Sales, CS, partner, policy, comms, legal, regional. You will not meet all of them. They will all encounter your work. Your job at this scale is owning the promise the company can keep — because when GTM over-promises and the product under-delivers, the postmortem comes back to you, not to them.
Test: Can a sales rep explain your product in thirty seconds using only words you gave them? If not, you haven’t done the GTM work. “Read the PRD” is not a handoff strategy.
4.5 5. The new org: AI PMs and what that title actually means
Startup: You are the AI PM. There’s no one else. Congratulations. Also, condolences. You will be asked to decide things no one has decided before in a product that didn’t exist two years ago. That’s either exciting or terrifying. Knowing which one tells you a lot.
Scale-up: You now have a “PM, AI” and a “Growth PM” and a “Platform PM” and a “Core PM” and a “ML PM,” and the boundaries between them are actively contested. The question is always who owns the outcome — not who owns the model. If you don’t own the outcome, you don’t own the model, regardless of what the org chart says.
Mega-corp: There are twelve “AI PMs.” Three are doing genuinely new work. The rest rebranded six months ago when it became clear that “AI PM” was a better title than “PM, Recommendations.” Your job is knowing which is which before you stake your roadmap on their API — because their API will change, their team will reorg, and if you didn’t validate the dependency you’ll be explaining the miss to your VP in Q3.
4.6 The AI shift in three lines
Everyone on your team got a junior PM in their IDE.
Your job is not to compete with it. Your job is to be the senior PM across a team where everyone is moving faster, generating more options, and making more decisions without you.
That requires three things AI genuinely cannot provide:
Context — what happened last quarter, what the CEO promised Wall Street, what broke at 2am and why. The model doesn’t know. You do.
Conflict — saying no with reasons that survive Slack, executive review, and the hallway conversation. “The model suggested it” dies in the hallway.
Conviction — picking the narrative the team will repeat when the metric dips, when the press is bad, when the feature ships with bugs. Teams don’t follow the best-written PRD. They follow the story they can retell at 11pm.
4.7 Try this
Exercise: Map the last cross-functional conflict you were involved in. Who had to agree for it to move? Who could have vetoed it? Who did you forget to talk to until too late?
Now do it three times:
- If you were at a ten-person startup. Who disappears from the map? What gets easier?
- If you were at a 300-person scale-up. Who gets added? Where does friction appear?
- If you were at Meta. What functions exist that don’t exist at the other two? What reviews have no equivalent?
If your answer was “nothing changes,” you haven’t worked in all three. If your answer was “everything changes” — good. Now: do you like that work? The job is the map.
Chapter 5 covers what the craft looks like when everyone has the same tools — and why that doesn’t make the PM role obsolete. It makes it more accountable.