Simulated user feedback for product managers

User research is scarce, so it goes to the big bets, and the small calls get made on instinct: which of two onboarding steps to cut, what to call a feature, whether a setting needs explaining. Each is cheap to get wrong once and expensive to get wrong a hundred times. A fast simulated read gives those calls some outside input.

• Feature questions: what simulated users would use first, and why.
• Onboarding: where simulated newcomers stall on the live product.
• Release copy: whether the announcement makes sense to people who were not in your planning meetings.
• Research prep: sharper questions for your next real study.

Prioritization. "Which of these three would you use first, and why?", with each option described in a sentence. The answers come back with reasons, split by role, age, gender and country.

Naming. Offer two or three names for a feature and ask what each person expects it to do. When a name makes people expect something else, you have found a support ticket before anyone files it.

Switching. "What would make you switch from what you use today?" The answers are a draft list of objections for your launch page and your sales team.

Then follow up with the whole group, or interview one person. Both are free within a fair daily limit.

AI focus group

For onboarding changes, let simulated newcomers try it. Start from your public sign-up page with a task such as 'Create an account and finish setting it up'. Each one signs up with an inbox of their own and works through your first screens in a real browser for up to 40 steps, and the report shows where each one stalled and why.

After a change, run it again on the same people with the same task and see who gets further. There is no side-by-side comparison for flows yet, so read the two reports together.

Onboarding flow testing

Paste the release note, the changelog entry or the in-app announcement as copy, and describe your users. Simulated readers say whether they understood what changed and whether they would try it. The common failure is copy written for the team that built the feature.

Error messages, empty states and tooltips can be tested the same way, one at a time.

It does not know your existing users. Simulated people bring no history with your product, and even twins built from your customer list are simulations. What your users actually do lives in product analytics, support tickets and interviews, and those win when they disagree.

It cannot measure adoption or retention, reach screens that need an existing account, or stand in for users with specialist expertise. Use it to choose what to study, then study it with real users.

Before a research session, run the draft screens or the question past simulated users, fix the obvious problems, and use their objections to write sharper interview questions.

Before a release, test the onboarding change as a flow and the announcement as copy. After it ships, watch real behavior in your analytics.