Generate Software User Personas
Three persona cards — primary, secondary, and negative — with the attributes that change your build: technical proficiency, jobs-to-be-done, and evaluation behavior.
Free, no setup, 2-3 minutes.
How It Works
Describe What You're Building
Tell the agent the product and who you think uses it. If you've already run earlier discovery steps, it picks up from there.
Define the Primary Persona
Technical proficiency, daily trigger, current tools, device, JTBDs, and how they evaluate whether to adopt. The agent pushes back on anything that reads like a stock photo.
Stop at Three — Primary, Secondary, Negative
Three personas. Not seven. I've watched founders fragment scope across five "primary-ish" users and ship for none of them. The agent enforces the cap and demands an explicit negative.
Translate Personas Into Build Decisions
Platform priority, onboarding depth, feature scope, integration priority, churn signals to design against. The output is meant to change what you build next week, not sit in a deck.
Where User Personas Sits in Discovery
Step 3 of 8 in discovery. It runs after Competitive Analysis sharpens the segment, and feeds Market & Distribution with a concrete user to price and reach.
Use this when: You're about to scope features and realize you haven't decided who you're actually building for.
Who it's for: Founders and PMs scoping a software product who keep defaulting to demographics instead of behavior.
Jobs-to-Be-Done Over Demographics
Every other AI persona generator I've used hands back "mid-30s manager" and stops there. Age range and job title don't change a single line of code. A JTBD statement — "when I get a client inquiry, I want to check availability instantly, so I can respond before they book someone else" — does. Each persona ships with 2-3 of those.
Technical Proficiency Drives the Build
Whether your primary user is no-code, basic, power user, or developer changes onboarding depth, error handling, and how many actions fit on a screen. The agent treats it as a required field and pushes back when you skip it. Same for device preference, current stack, evaluation behaviour, and churn signals — every attribute connects to a build decision.
A Negative Persona Is Mandatory
I won't let the agent finish this step without one. "We don't want to exclude anyone" is the red flag — it's how products grow SSO, audit logs, and admin dashboards before they have ten users. Naming who you're explicitly not for is the cheapest scope control you'll do all week.
Frequently Asked Questions
A user persona is a one-page sketch of the person who actually opens your product — their job-to-be-done, technical proficiency, current tools, evaluation behavior, and the signals that would push them to churn. The point isn't a face on a slide; it's a set of constraints that change what you build. In B2B this is closely related to the ideal customer profile (ICP) — the company-level shape of who buys — but the user persona zooms in on the individual whose workflow your product changes. This tool is a free user persona generator that produces three of them — primary, secondary, and one explicit negative — in 3 minutes, no signup or template download.
A buyer persona is a sketch of the person who signs off on the purchase — their priorities, budget authority, evaluation criteria, and the questions they'll ask before approving spend. In B2C the buyer and the user are usually the same person, so a single persona covers both. In B2B they diverge — the user might be a customer success manager, the buyer is the VP of Operations, and the customer persona that closes a deal looks nothing like the one that uses the product daily. This tool focuses on the user persona side; the buyer side gets pressure-tested in Competitive Analysis, where pricing, procurement, and the do-nothing baseline meet the buyer's actual decision frame.
Three. Primary, secondary, and one explicit negative. The agent won't generate more — I've seen too many founders fragment scope across five "primary-ish" personas and ship for none of them. If your product genuinely serves more than two distinct user types, that's a positioning question worth surfacing in Lean Canvas first.
Because without one, every feature request sounds reasonable. "We're not building for enterprise IT teams" eliminates SSO, audit logs, and role-based access from scope — weeks of work, gone. The agent will push back if you resist naming one. The same scope-control logic at feature level lives in Feature Priorities.
How the user decides to adopt — free trial, peer recommendation, RFP, vendor list — and what would make them quit in week one. Both shape the build. Evaluation behavior drives onboarding and pricing surface; churn signals (one bad import, a missing integration, a 30-second wait) drive what retention scope has to cover. The agent asks for both.
They're hypotheses, not facts. The agent flags assumption-only personas and tells you to validate with 3-5 user interviews. A hypothesis that changes what you build next week still beats no user model at all. The market context behind the personas lives in Market & Distribution.
Where To Next
Next discovery step:Market & Distribution
Principles behind it:Saying No, Context Over Purity
When you're ready to build:MVP in 6 WeeksPoC in 2 Weeks
Built & Maintained by Varstatt
Varstatt is a one-person product studio run by Jurij Tokarski, product engineer since 2011. These tools are free and open — no signup, no catch.