How should product managers use AI when building products?

Use AI for the work, but keep the decision about what to build with people. Before AI drafts a PRD, roadmap or prototype, answer three questions: what must be true for this to work, what evidence would prove us wrong, and what is the cheapest test we can run first.

What check did AI remove from product development?

AI removed the pause between an idea and the work. That delay used to be where someone asked "should we build this?" AI works inside whatever assumptions you give it, so unless someone asks the question deliberately, nobody does.

Is it a problem to write a PRD with AI?

No, as long as the thinking comes first. A PRD drafted in ten minutes can still describe the wrong feature. Ask what problem the feature fixes before the PRD exists, and the AI draft will be pointed at the right thing.

How do you know if AI is improving your product team's work?

Don't rely on usage dashboards, which only show that people use the tools. Put work from before AI next to work from after it. If you can't point to what improved, the usage numbers don't mean much.

Should every new feature include AI?

No. Ask users which job they are stuck on before adding AI. Sometimes the job needs AI, and sometimes it doesn't, and the user's problem should decide that, not the trend.

How do you stop AI from producing too many ideas to act on?

Ask AI for ideas, then cut the list to one. If you can't explain why each of the others lost, keep cutting. More ideas only help if the team says yes to fewer of them.

How to Actually Build With AI: 12 Checks Product Managers Run Before the Build

1

The full infographic, as a PDF

The exact one from the post, sized to print or keep within reach.

2

A copy in your inbox

The download link lands in your email too, so it's there when you need it. No follow-up campaign.

3

The Product System, weekly

My note on leading product in the AI era. One idea a week that compounds. Unsubscribe anytime.

AI removed the check your team didn't know it needed.

That check was one question: should we build this?

There used to be a pause between an idea and the work. It was annoying. Drafting a PRD or building a prototype took real time. But that delay was where someone stopped and asked whether the thing was worth doing at all.

AI doesn't ask it. Give it an idea and it works inside your assumptions, fast and well. It can write a brilliant PRD for the wrong feature.

Here are 12 things worth checking before AI does the work, grouped into four stages. Each one swaps something AI makes easy for something that decides whether the work is worth it. Here is how to put the check back before you build.

Point the speed at the right bet

The first check swaps speed for the next bet. Faster output only helps if it is pointed at the right thing. Before any draft, finish this line: "We build this next because..." If you can't, stop.

The second swaps meeting notes for who does what. AI notes from every meeting are easy to collect and easy to ignore. End each meeting by reading out the decisions and their owners. If a decision has nobody owning it, name an owner there and then, even if that owner is you.

The third swaps a borrowed setup for your own rules. Copying someone else's AI workflow gives you their habits, not your company's. Write down three rules your team always follows. Put them in your AI setup first, so everything it produces starts from how you actually work.

Choose the problem, then let the team choose the solution

The fourth check swaps more ideas for fewer yeses. Fifty ideas in a minute is not a strategy. Ask AI for ideas, then cut the list to one. If you can't say why the others lost, keep cutting. Saying no to good ideas is the work.

The fifth swaps a fast PRD for the real why. A PRD drafted in ten minutes can still be about the wrong problem. Ask what problem the feature fixes before the PRD exists. Asking why someone wants the feature is cheaper than any draft.

The sixth swaps a tight spec for the team's call. More detail in every user story leaves the team less room to think. Cut the "how" from your next story and keep the goal. If the team asks how, ask what they'd try first.

Let evidence, not polish, change the plan

The seventh check swaps call recaps for plan changes. A summary of every customer call is only useful if it changes something. After each customer call, write down one thing you learned. Change the plan only when several calls point the same way, not after one loud conversation.

The eighth swaps polish for named disagreements. A polished roadmap can hide the places people don't agree. Before the roadmap goes out, list where people disagree. If you can't find a single disagreement, ask each person what they'd cut. The answers will show you where the real disagreements are.

The ninth swaps a quick demo for the riskiest bet. A prototype by lunchtime is impressive and proves very little. Name the guess that kills the idea if it's wrong. Test that guess before anyone builds the demo.

Check that AI is earning its place

The tenth check swaps a one-off for something kept alive. An AI workflow that works once is a demo. Check the AI setups you rely on every week. I went tool to tool until I was a copy-paste monkey. Then I spent about a year on one setup that keeps improving. The value is in keeping it working.

The eleventh swaps usage for quality. AI usage dashboards tell you people are using the tools, not that the work improved. Put work from before AI next to work from after. If you can't point to what improved, ignore the usage chart.

The twelfth swaps AI by default for AI by need. Adding AI to every feature is easy now. Ask users which job they're stuck on before adding AI. Sometimes the answer is that the job doesn't need it.

The check behind all 12

Read the list again and every item is the same check in a different place. Before AI drafts the PRD, roadmap or prototype, make it answer three questions:

What must be true for this to work?

What evidence would prove us wrong?

What's the cheapest test we can run first?

Those three questions are the pause, written down. They take minutes. They decide whether the hours AI saves you go into something worth keeping.

This is a sibling of an earlier list about building products in general, /vault/how-to-actually-build-a-product, which covers the same idea from the feature side: decide before you build.

Put the pause back. Then you decide.

The AI PM scorecard shows where you actually rank: martongaspar.com/scorecard

What would you add to the list?

Questions people ask

How should product managers use AI when building products?: Use AI for the work, but keep the decision about what to build with people. Before AI drafts a PRD, roadmap or prototype, answer three questions: what must be true for this to work, what evidence would prove us wrong, and what is the cheapest test we can run first.
What check did AI remove from product development?: AI removed the pause between an idea and the work. That delay used to be where someone asked "should we build this?" AI works inside whatever assumptions you give it, so unless someone asks the question deliberately, nobody does.
Is it a problem to write a PRD with AI?: No, as long as the thinking comes first. A PRD drafted in ten minutes can still describe the wrong feature. Ask what problem the feature fixes before the PRD exists, and the AI draft will be pointed at the right thing.
How do you know if AI is improving your product team's work?: Don't rely on usage dashboards, which only show that people use the tools. Put work from before AI next to work from after it. If you can't point to what improved, the usage numbers don't mean much.
Should every new feature include AI?: No. Ask users which job they are stuck on before adding AI. Sometimes the job needs AI, and sometimes it doesn't, and the user's problem should decide that, not the trend.
How do you stop AI from producing too many ideas to act on?: Ask AI for ideas, then cut the list to one. If you can't explain why each of the others lost, keep cutting. More ideas only help if the team says yes to fewer of them.