AI made first drafts cheap. It did not make being wrong cheap, and checking work you did not write is a skill you have practised for years.
Most product teams now have a new kind of colleague. It writes the summary, builds the table and drafts the plan in seconds. Its work arrives looking finished: clean formatting, a confident tone, numbers to one decimal place.
Its mistakes arrive the same way. A wrong figure in an AI draft does not look wrong. It looks exactly like a right one.
The habit that works is simple. Before a number goes anywhere that matters, a second check looks at it, and that check has not seen how the first answer was produced. In my own work, every number an agent hands me goes to a second agent that gets the sources and the claims, but never sees how the first one reached them.
If you work in QA or test automation, you will recognise this at once. It is your job.
The oldest idea in testing
Testing exists as its own role because the person who built something is badly placed to judge it. Not because builders are careless, but because they already know what they meant. They read the intent, not the output.
So you were put on the other side of that line. You were handed the requirement and the build, and asked a different question: does this do what it says, and how would it fail? You learned to distrust the happy path. You learned that “it works on my machine” is a claim, not evidence.
That separation, between the one who makes and the one who checks, is exactly what AI-assisted product work now depends on. The first draft is cheap. The value has moved to the independent check.
What actually transfers
This is not encouragement. It is a translation. Three habits you already practise matter most when an AI writes the first draft.
You check against the source, not the summary. When a defect report says a field rejects valid input, you do not trust the report. You try the input. A product manager reviewing AI output needs the same reflex: open the file the number came from, not the paragraph that describes it.
You decide what “right” looks like before you run the test. An expected result written after the actual result is not a test. It is a story. The same holds for experiments, launch criteria and every AI-generated analysis: the useful debate happens before the data, not after.
You ask questions that force a verdict. “Can you take a look?” gets a polite summary. “Mark each claim true, false or unverifiable, and quote the line that decides it” gets an answer. You have been writing acceptance criteria like that for years.
Why this still reads as “just QA”
Here is the problem. On a resume, all three habits get described as testing: “Executed test cases.” “Logged defects.” “Performed regression.” A product hiring manager is likely to read that as execution.
The work underneath is judgment, so describe the judgment:
- “Executed test cases” becomes “decided what would count as correct before a release, and tested the release against it.”
- “Logged defects” becomes “found where the product would fail users, and ranked the failures by their impact on users.”
- “Performed regression” becomes “protected existing customers while the product changed.”
- “Automated the regression suite” becomes “made it safe for the team to ship more often.”
None of these overstate the work. They name the part of it that product roles screen for. You are not underqualified. You are underdescribed.
The part you control
There is a version of this moment that feels like a threat. AI tools now draft test cases, plans and specs. It is easy to look at that and decide the ground is shrinking.
The Handbook of Epictetus opens by separating what is up to us from what is not. The tools are not up to you. Which tasks get automated is not up to you. What is up to you is where you put your judgment, and how clearly you can say what it is worth.
You cannot control that the work is changing. You can control the judgment you bring to what comes next.
When every first draft is free, the scarce skill is knowing which ones are wrong. You have been practising that skill your whole career. The move into product is not a leap away from it. It is a promotion of it.
One thing to try this week
Take one thing an AI tool produced for your team, whether a summary, a test plan or a status report, and check it the way you would check a build. Note what you would have missed if you had trusted it. That note is the start of your product story.
If this is the kind of thinking you want more of, the newsletter goes out once a month: one field note.