The cheapest user research happens before you build anything
We have made a free AI agent skill that runs a focus group on your PRD — while it's still just a document.
In Customer Success, we spend a lot of time cleaning up after decisions that were made too early. A feature ships, the tickets roll in, and it turns out the thing nobody questioned in the spec is exactly the thing real users can't get past. By then it's expensive: engineering time spent, expectations set, a roadmap to unpick.
The frustrating part is that the feedback was always available. It just arrived after the build, when it costs the most to act on.
Testing the spec, not the software
A Product Requirements Document is a set of assumptions wearing a confident font. It's written from one person's head, in their context, with their level of patience and their fast, reliable internet connection. Real users don't share that context. They arrive on cheap phones, on bad connections, with screen readers, with no time and less goodwill.
Most validation methods can't run until something exists to click. But the assumptions are all there in the PRD, ready to be challenged — if you have a way to pressure-test a document the way you'd normally pressure-test a build.
So I built one. It's a Claude skill called FocusGroup_PRD, and it's free and open source.
How it works
You give it a PRD. It then does four things:
Imagines the product as if it had already shipped exactly as specified — the screens, the core loop, the first ninety seconds after sign-up.
Runs 20 fixed user personas through it, deliberately varied across income, tech-literacy, accessibility needs and device context. The screen-reader user, the rural low-bandwidth user, the sceptical late adopter, the time-starved single parent — each produces an honest log of where they got stuck, what delighted them, and whether they'd come back.
Convenes a panel of 5 product managers — a traditionalist, a disruptor, a design-led PM, a growth-metrics PM and a technical one. They read the findings, critique each other, and genuinely disagree before converging.
Hands you back a prioritised set of revisions, a redlined PRD, and the raw logs — with the decisions it couldn't make flagged for you.
Why the disagreement matters
The point isn't a tidy consensus. A focus group where everyone's delighted has failed, and a PM panel that agrees on everything isn't telling you anything. The skill is built to preserve the tension — to surface the 3-2 split rather than smooth it over — because that's where the real product decisions live. You stay the tie-breaker. It just makes sure you're breaking the right ties, early, when changing your mind is still free.
It runs on plain Claude.ai or in agent setups like Cowork, and the personas are fixed and inspectable, so runs are reproducible and you can see exactly who's in the room.
It's MIT-licensed and on GitHub. Star it, fork it, point it at your own spec and tell me what it gets wrong:
