Sharper decisions, not more documents
Product management has a peculiar relationship with writing. You produce a great deal of it: briefs, specs, updates, one-pagers, release notes, answers to the same question in four different channels. Very little of that writing is the job. The job is deciding what the team should do next, and being right often enough that people keep trusting you to decide.
That distinction matters here, because a language model is extraordinarily good at the first thing and has no access at all to the second. Used without thought, it makes you faster at producing documents and no better at making decisions. Used well, it takes the documents off your plate and gives you back time, plus a tireless critic for the decisions themselves.
This lesson is the map. The rest of the course follows it.
How it fails at product work specifically
You probably know the basics already: a language model predicts plausible text from patterns in what it has read, and it knows nothing about your situation beyond what you put in front of it. If that is new, the opening lesson of AI for UX and Product Design explains the mechanism well. What matters for product managers is how that mechanism shows up in your work, because it fails in three recognisable ways.
It invents evidence. Ask it to summarise customer feedback and it can produce a theme, a count or a customer quote that is not in your material. The invented quote will be well phrased and on topic, which is exactly why nobody questions it on the slide.
It agrees with you. These systems are tuned to be agreeable. Tell it which option you prefer and it will find reasons you are right. Tell it the opposite and it will find reasons for that too. For someone whose job is making calls under uncertainty, an enthusiastic yes from a machine is worse than no input at all.
It produces confident, generic strategy. Ask what your product should prioritise and you will get a sensible answer that would fit almost any product in your category. It sounds like strategy. It is the average of every strategy document it has read, with none of your market, your customers, your numbers or your history in it.
In plain English
- Hallucination:
- A fluent, confident claim that is not true. In product work it usually looks like a customer quote, a number or a competitor fact that nobody can source.
- Sycophancy:
- The tendency to agree with whatever position the person asking seems to hold. It makes leading questions worthless.
- Context:
- Everything you have given the model in this conversation. Your market, data and history do not exist for it unless you paste them in.
- Generic output:
- An answer that is reasonable for any company in your category and therefore tells you nothing about yours.
The honest map
Here is product work, stage by stage, with a blunt assessment of where the tool earns its place.
| Stage | Task | How much it helps |
|---|---|---|
| Discovery | Synthesising tickets, feedback and interview notes | A lot, with checking |
| Discovery | Talking to customers | Not at all |
| Discovery | Market and competitor desk research | A little, and verify every fact |
| Definition | Drafting specs, requirements and acceptance criteria | A lot |
| Definition | Listing edge cases and open questions | A lot |
| Definition | Deciding the problem worth solving | Not at all |
| Delivery | Release notes, changelogs, internal documentation | A lot |
| Delivery | Knowing whether the thing works for customers | Not at all |
| Decisions | Arguing against your priorities | A lot, if you do not lead it |
| Decisions | Making the call | Not at all |
| Stakeholders | Drafting updates and rehearsing objections | A lot |
| Stakeholders | Delivering bad news | Not at all |
Notice the pattern. The "a lot" rows are all about producing or restructuring text you can then check against something real. The "not at all" rows are all about contact with reality: customers, results, judgement and accountability. That pattern is the most useful thing in this lesson, because it tells you what to do with a task this course never mentions.
The most dangerous row is "a little" on market research. Competitor pricing, feature lists and market sizes come back sounding authoritative and are frequently out of date or invented outright. Anything factual about the outside world has to be sourced from somewhere other than the model before it goes near a roadmap.
Checkpoint
AI helps most where product work means producing or restructuring text you can check, and not at all where it means customers, judgement or accountability.
Who should skip this course
Skip it, with no hard feelings, if one of these describes you.
You have never used an AI assistant. This course is intermediate. It assumes you can hold a working conversation with one. Start with Prompt Engineering and come back.
Your organisation does not allow customer data in external tools. Much of the value in lessons two and three depends on pasting feedback, tickets or internal documents. If your policy forbids that, the responsible answer is to stop, not to find a workaround.
Your problem is alignment, not throughput. If the roadmap changes every fortnight because leadership cannot agree, faster specs will not help. A better written document does not settle a disagreement between two directors.
You want it to set your strategy. It will not. It has never met your customers, read your data or sat in your planning meetings, and what it gives you instead is the industry average dressed as advice.
The mindset that works: a fast, well-read colleague on their first day. Useful for drafts, lists and hard questions. Not someone whose opinion about your market you would repeat in front of the leadership team.
Checkpoint
The three product failures to watch for are invented evidence, agreement with whatever you seem to believe, and strategy so generic it fits any company.
๐ Quiz
Question 1 of 4You ask a model what your product should prioritise next quarter and get a sensible, well-structured answer. What is the fairest reading?