Chapter 5 Tools, but not about tools
Everyone has the tools now.
In 2015, “being technical” as a PM meant you could write SQL, read a Jira ticket, build a wireframe in Balsamiq. Those were scarce skills. They signaled something.
In 2026, a new grad with a browser can generate a PRD, prototype three variants, run a cohort analysis, and draft the launch email before noon (ProductBoard 2024). The skills aren’t scarce. The judgment about what to do with the output is.
So this chapter is not about which tool to use. It’s about what the job looks like when the tools stop being the point — and what failure modes appear when PMs don’t notice that the tools changed faster than their habits did.
5.1 1. The artifact trap
The trap is measuring your day by output. Docs written. Decks completed. Dashboards built. Tickets closed.
AI made artifacts infinite. You can generate twenty PRDs by 10am. None of them matter if you picked the wrong problem. The trap is feeling productive because output is high, while impact stays flat.
Startup: The trap here is velocity. You can ship a new landing page, a new onboarding flow, a new pricing experiment every week. You will. Your users will be confused, your data will be too thin to read, and your team will burn out sprinting at targets that keep moving. The PM’s job at this stage is saying “stop” more than “go” — protecting the focus that learning requires.
Scale-up: The trap is process. A spec for every ticket. A review for every spec. A deck for every review. AI makes the artifacts easy to generate, which means more of them get generated, which means more reviews are needed, which means the team is producing documentation about documentation. Your job: ask what you can delete. Not defer — delete. “What do we stop doing to create capacity for this?” is a PM question AI will never ask.
Mega-corp: The trap is documentation theater. The twelve-page memo with appendices. The pre-read that people read on the way to the meeting. Executives will skim and ask one question you didn’t answer. AI can generate the twelve pages in twenty minutes. That does not make twelve pages the right answer. The PM who can write the one-page version — and defend why the other eleven pages don’t matter — is the one executives trust to make decisions.
Test: Open your document folder. Count how many docs produced in the last quarter were read by more than three people. Count how many changed a decision. If the second number is much smaller than the first, you’re in the artifact trap.
5.2 2. Prototyping: Speed as a forcing function, not a substitute for clarity
Before: Prototyping was expensive. So you debated first, then mocked in high fidelity, because you could only afford one pass. The constraint was useful — it forced clarity before execution.
After: Prototyping is cheap. One hour in v0 or Replit or Claude gets you something testable. The risk is using that speed to defer clarity rather than achieve it. You prototype five things and learn nothing because you never defined what “this works” means before you started.
The discipline: write the success criteria before you prompt. “If three of ten users complete this flow without asking for help, we keep going.” If you don’t write that, you’ll iterate forever on things that feel promising but never cross a threshold.
Startup: You don’t have a designer. You have the tools and a browser. You can get to testable in an afternoon. Use it to kill bad ideas fast — not to polish them into things that look like products before you’ve proven they solve anything. The prototype that goes to users on day three beats the polished demo that never leaves the internal review.
Scale-up: You have design, you have research, you have a process that exists for good reasons. AI makes that process look slow. A PM with Claude can produce a testable prototype while the design brief is still being written. Use that speed to filter: run the rough test to kill the ideas that aren’t worth Design’s time, then bring the survivors to the team for craft. You’re not replacing design — you’re pre-filtering for them. That’s a legitimate use of speed.
Mega-corp: You have a design system, accessibility requirements, brand guidelines, and a legal review process. You cannot “just ship a test.” But everyone else in the building can prototype on your surface — marketing, growth, other PMs, third-party partners. Your job is knowing which experiments are running without you, which ones matter, and which ones violate a constraint that the person who built the prototype didn’t know to check.
Test: How long does it take your team to go from an idea to something a real user has touched? If the answer is more than two weeks at a startup, something is wrong. If the answer is less than a week at a mega-corp without a review process, something is also wrong.
5.3 3. Self-service data: Speed without the review is a liability
This is distinct from Chapter 4, where the focus was the relationship with your data team. This is about you, alone, with a query tool, at midnight, trying to understand a number that moved.
AI-powered SQL tools changed what PMs can do with data. They also changed what PMs can confidently get wrong.
The risk isn’t that AI gives you wrong numbers. It’s that it gives you wrong numbers confidently, with clean formatting, in a chart that looks like it came from your data team. The LLM doesn’t know that event_timestamp is UTC while your user interface displays Pacific. It doesn’t know the table you’re querying was deprecated in Q4 and the new one has a different schema. It doesn’t know about the sampling decision your data team made that excluded a specific cohort from the default dataset.
The discipline: Treat self-service data as exploration, not as evidence. Use it to generate hypotheses, to understand direction, to figure out what question you actually want to ask. Don’t use it as the source you cite in the exec review without someone who knows the schema confirming the join was right.
Startup: Learn the schema. Physically. Sit with the engineer who built it and have them walk you through the tables. The model will confidently query the wrong thing if you don’t catch it. Being the PM who knows what the data actually means — not just what it says — is a compounding advantage.
Scale-up: The data team is backlogged. You’re going to self-serve. That’s fine. Build the habit of tagging them before you act on something, not after. “Here’s what I found, here’s what I’m planning to do with it, let me know if the query is wrong” is one message. It saves you from presenting a broken number in the quarterly business review.
Mega-corp: You have experimentation infrastructure. Use it. The rigor exists for a reason — the sample size requirements, the holdout period, the guardrail metrics. When PMs run “quick tests” outside the infrastructure, they produce results they cannot trust and cannot defend. The infrastructure is slow on purpose.
Test: What’s the last number you presented that turned out to be wrong? If the answer is “never,” you’re not moving fast enough. If the answer is “most of them,” you’re moving recklessly. The PM who can tell you both the answer and the confidence interval on the answer is the one who doesn’t lose trust in reviews.
5.4 4. Writing: AI writes the draft. You write the subtext.
Before: A clean, concise, well-structured PRD signaled PM ability. Writing was the craft, visible and testable.
After: AI writes clean, concise, well-structured PRDs. What it does not write is the thing that makes a document useful rather than just presentable: the unstated constraint, the political context, the thing everyone knows but no one wants to be the first to write.
AI writes the first draft. You write the second draft — the one where you add the paragraph that explains why Sales is going to push back on this, the footnote that acknowledges the competing initiative from the other team, the framing that makes the tradeoff visible rather than buried in an appendix.
Startup: The doc is a Notion page nobody will read if it’s more than one screen. AI will generate a beautiful six-section PRD. Delete four sections. Then delete the section headers. Then read it out loud. If you can explain it that way, ship the doc.
Scale-up: The doc needs to survive a reviewer who has twelve of them in their queue and will spend four minutes on yours. AI will make yours look identical to the other eleven. What makes yours legible is the thing only you know: what failed in the previous attempt, what the data says that isn’t in the standard dashboard, what the customer said that changed the problem statement.
Mega-corp: The doc enters a process. It will be reviewed by legal, policy, comms, and executives who have context you don’t have about concerns you didn’t anticipate. The PM who writes for the reviewer — not just for the process — gets through faster. “I flagged the privacy implication of section 3 with legal and here’s their input” is the sentence that saves you two weeks.
Test: Give your last PRD to an engineer and a lawyer. If they each ask the same question — one you didn’t answer — you wrote for the model, not your audience.
5.5 5. What remains when all the tools are free
Three things:
Problem selection. AI will optimize whatever you give it. If you give it the wrong problem, it will optimize the wrong problem with impressive speed and confidence. Picking which problems are worth solving — not just which solutions are worth building — is still entirely yours.
Narrative. Why now, why us, why this is the thing to do when everything is hard and the metric is flat. Teams don’t follow charts. They follow the story they can retell. AI gives you words. Conviction is yours.
Accountability. The model cannot get fired. You can. That asymmetry is why the job exists and why it pays what it pays.
5.6 Try this
Exercise: Take your current project. Do this with AI assistance:
- Generate the PRD.
- Generate a testable prototype.
- Generate a dashboard showing three metrics that would indicate success.
Now do this without AI:
- Write the two-sentence version you’d tell your CEO in an elevator. No jargon.
- List the three most likely reasons this fails.
- Name the person who will be most frustrated if it succeeds — and why.
If the second set was harder than the first, that’s the work. Everything AI generates is scaffolding. The second set is the building.
Chapter 6 stops describing the job and asks you to test whether you like it. Not conceptually. Actually.