One argument, five lessons
Strip away the prompts and this course has made one argument.
A language model produces plausible text. That makes it excellent at product work with a recognisable shape: grouping feedback, structuring a spec, listing edge cases, arguing the other side, rewriting an update for a different audience. It makes it unreliable wherever the work depends on truth, on your specific market, or on judgement, because plausible and true come out of the same process looking identical.
Every habit followed from that. Label feedback so every theme traces to real items. Make the model mark what it assumed in a spec. Hide your preference before asking for criticism. Draft updates from facts and deliver bad news yourself. None of those habits depends on a particular tool, which is why they should outlast whichever one you use this year.
Capstone: one real decision, end to end
Reading about this is not the same as doing it. Pick a real, modest decision you face in the next few weeks: a feature to scope, a request to accept or decline, a small ranking of options. Then work through it with the habits from each lesson. Use only material your organisation allows you to paste, and remove customer details you do not need.
Step one: evidence. Gather the feedback relevant to the decision, give each item an ID, and run a traceable synthesis. Check every quote and recount the theme that matters most. Write down how many claims you had to remove.
Step two: definition. Draft a short spec from your own problem statement and evidence, with requirements marked FROM BRIEF or ASSUMED. Turn the ASSUMED list and the open questions into an agenda for your next conversation with engineering and design.
Step three: pressure test. Describe your options evenly, ask for the case for and against each, and the "what would have to be true" list. Steelman the option you are leaning against. Note any belief you discover that nobody has tested.
Step four: communication. Draft the update for two different audiences from your facts. If the decision disappoints someone, rehearse the conversation, then write the message yourself.
Step five: reflect. Where did the tool save you real time? Where did it produce something you would have been embarrassed to repeat? Which step would you skip next time, and which would you never skip?
Keep the prompts and outputs from this exercise in one document. When someone later asks how you reached the decision, you will have an answer that is a record rather than a memory.
Checkpoint
Run one real decision through traceable synthesis, a marked-up spec, an even-handed pressure test and your own communication, then note where the tool helped and where it misled.
Your checklist
Before anything AI-assisted leaves your hands, run through this.
| Check | Question to ask yourself |
|---|---|
| Evidence | Does every theme, quote and count point to items I have opened myself? |
| Counter-evidence | Did I ask for the customers who disagree, and read what came back? |
| Assumptions | Is every requirement I did not decide either confirmed or listed as open? |
| Invented numbers | Did any metric, score or market figure come from the model rather than a source? |
| Leading questions | Did I reveal my preference before asking for criticism? |
| Grounding | Do I know which parts of the critique rest on facts about my market it does not have? |
| Tone | Did the update keep the bad news and the ask visible? |
| Ownership | Is the decision mine, and would I defend it without mentioning the tool? |
| Data | Did I paste only what my organisation approves, with customer details removed? |
Watch for a slow change over months. If every spec starts as a generated draft, you can gradually lose the habit of thinking a problem through from a blank page. Keep writing the problem statement yourself, always, on the work that matters most.
A realistic week
None of this is a transformation. You still talk to customers yourself. You paste a batch of labelled tickets on Monday and spend twenty minutes checking the themes. You draft the spec for Wednesday's refinement with the assumptions marked, and the meeting runs faster because the arguments are already listed. Before Thursday's planning you ask for the case against your ranking and prepare for the two objections that landed. On Friday the update goes to three audiences in three versions, and you write the one difficult paragraph yourself.
That is a few hours back and one more round of scrutiny than you would otherwise have had time for. It is worth having. Anyone promising more is selling something.
Where to go next
AI for UX and Product Design if you work closely with designers or do some design yourself. It goes deeper on interview synthesis, flows, interface copy and design critique.
AI for Leaders and Executives if you are moving into a role where you set direction for teams, or need to talk about AI investment and risk with the people who fund your product.
Context Engineering if your longer sessions start drifting, or you want to understand why a synthesis gradually begins quoting its own summary instead of your data.
Free AI courses with certificates if you want recognised credentials to sit alongside what you have practised here.
You have earned the Roadmap Ready badge. It does not mean your roadmap is right. It means you now know which parts of it a machine helped with, and which parts are yours to defend.
Checkpoint
The realistic gain is a few hours a week and an extra round of scrutiny, provided the evidence is checked, the assumptions are visible and the decision stays yours.
๐ Quiz
Question 1 of 4What single idea underlies every habit in this course?