Intellectual Frontiers Rolebooks

The Product Manager’s New Job Is Acceptance

Adversarial Testing from ICP to Adoption

When software is cheap to build, the product manager’s job is proving that the intended customer will find it, use it, and keep it.

AI has made software cheaper to build. It has not made customer attention, trust, workflow change, or proof of value any cheaper. A product can be technically correct, pass a scripted acceptance test, look great in the demo, and still fail because the intended customer never understood the promise, never finished setup, or used it only because someone required it.

Forthcoming. The book is in review; its companion and tools are open now.

Your software can pass QA and UAT and still fail the people it was built for.

This Rolebook is for senior product managers and product leaders whose job is changing. It introduces Acceptance Engineering, a practical discipline for testing the whole path from the ICP and the market promise through evaluation, onboarding, real use, demonstrated value, and continued adoption. It shows where QA and UAT stop, why the buyer and the user are often different people, and how to design tests that can fail, record every rescue, and keep the evidence.

It is short on purpose, it respects the people who do QA, UX research, sales, and customer success, and it says what evidence would show that its own argument is wrong.

Never UAT a product without UATing the promise that caused the user to try it.

What you will be able to do

• Tell what QA, UAT, usability testing, and acceptance testing can and cannot show
• Define an ICP tightly enough to test
• Map who buys, who uses, and who can force adoption
• Test the promise that earned the customer’s attention along with the product
• Design an adversarial test and log every rescue
• Challenge your own metrics and keep evidence that does not go stale
• Use AI to design and challenge tests without letting it stand in for the customer
• Decide what evidence would make you narrow, change, or stop

The premise

A release passes QA and a scripted acceptance test, and the demo looks great. Then real customers arrive. Setup takes days, the person who does the work never saw the promise, and success has to rescue every account. Nothing was broken. The feature worked and the promise did not hold.