Pretend you are the power user so soft UX claims and buried workflow breaks fail before the people who live in the product every day hit them.
Optimistic changelogs optimize for the team that wants to ship. The power-user seat does the opposite. It asks which keyboard path broke, which export or API edge case is least tested, which migration step is unpaid labor, and which change would make a heavy user leave.
This is one of the core moves before a redesign, pricing pack change, or feature sunset: after you describe the upside, seat a careful heavy user and make them try to reject the change. The output you want is not a cheerleading rewrite. It is a short list of material workflow objections, the exhibits each needs, and the edits that would survive them.
How to cast the seat
Name a real mandate: protect daily throughput, keep advanced workflows intact, or underwrite a migration without silent data loss. Give constraints: must-keep shortcuts, export formats, and integrations you will not break without a bridge. Without constraints the seat becomes cartoonish. With constraints it produces questions you might actually hear.
Write the seat into the prompt as a named role with a mandate. Example: "Power user: list the top reasons to reject this change, the workflow with the weakest migration path, the data risk that worries you most, and the ten diligence questions you would send after the demo. Stay inside a realistic mandate and avoid illegal tactics."
What to demand from the pass
- Top reasons to delay or narrow this change.
- The assumption that looks strongest and is least tested with heavy users.
- The workflow, API, or export break that would worry you most.
- What would make you accept the change instead.
- The ten hardest questions you would send in writing after the walkthrough.
Run that brief in Pingpong against the real changelog, migration notes, and support history. Follow with a home-team response pass so you leave with edits and test packs, not only fear. When the decision is a sunset or redesign, run this seat after support and customer attacks so it can use earlier objections as ammunition.
When the change leans on a single happy-path demo, force the seat to price edge-case risk in writing. Ask what happens if bulk actions fail, if keyboard users lose speed, or if an integration silently drops fields. Edge cases that only appear in an appendix still count.
Pair with pretend you are the angry customer, pretend you are the first customer, before you kill the feature, stress-test a product sunset, war-game a packaging change, and the war-game decisions hub. See how to run a Pingpong.