Use when doing UXR synthesis or interpreting interviews, support threads, telemetry, issue reports, or other research signal about people who adopt, deploy, operate, or build apps on top of freq-cloud.
Scope warning. This skill describes users of freq-cloud — people who deploy, operate, or build apps on top of the platform. It does not describe contributors to freq-cloud. Do not conflate adopters with people building or operating the freq project: different goals, constraints, and decision criteria. Keep those populations separated in any synthesis pass that loads this skill.
When you have research signal — interview snippets, support tickets, deploy telemetry, issue comments, feedback threads — apply the persona set as a stable lens rather than re-deriving "who is this for" each pass:
recognition_cues: it most directly matches. Most evidence should land cleanly on exactly one persona; signal that fits two equally well usually means the cue language needs sharpening or the persona set needs a refresh.jobs_to_be_done:, , , , and — not against a generic "user." A complaint about pricing means very different things from Maya than from Henrik, and the synthesis should reflect that.pains:adoption_yes_if:rejection_no_if:anti_goals:Each persona is its own JSON document conforming to the TinyPerson Persona Schema. Load the file you need from the personas/ subdirectory; do not duplicate or paraphrase its contents elsewhere.
| File | Persona | One-line hook |
|---|---|---|
personas/indie-saas-founder.json | Maya Okafor | Bootstrapped solo SaaS founder on a single VPS; cost predictability and lock-in drive every decision. |
personas/internal-platform-engineer.json | Henrik Lindqvist | Staff platform engineer at a mid-size org; wants a thin compute substrate above Kubernetes for the long tail of small services. |
personas/sovereignty-operator.json | Aiko Tanaka | Compliance lead at a regulated Japanese insurer; air-gapped, post-quantum, audit-evidence driven. |
personas/multi-tenant-agency-dev.json | Diego Martín | Two-person agency hosting ~35 client sites on one shared cluster; per-client blast radius is the dominant concern. |
personas/small-ha-cluster-operator.json | Priya Iyer | Founding backend engineer running 3 VMs across 2 regions without Kubernetes; mesh + leader election + low op overhead. |
The personas are deliberately distinguishable on operational scale (single VPS → small fleet of regional sites), decision driver (cost, operator burden, regulation, multi-tenancy, distributed primitives), and buyer (self vs internal stakeholders vs compliance vs clients). A given piece of research signal should land cleanly on one persona most of the time; if it does not, see step 3 above.
other_facts prefixesEach JSON file follows the TinyPerson Persona Schema and uses dedicated schema fields wherever possible. To keep other_facts machine-parseable across personas, every persona file MUST include the following exact prefixes (one or more strings per prefix):
current_stack: — what they use today and whyjobs_to_be_done: — top jobs freq-cloud could plausibly help them accomplishpains: — current frustrations that create switching energyadoption_yes_if: — capabilities or signals that make freq-cloud a credible yesrejection_no_if: — capabilities or gaps that make freq-cloud a noanti_goals: — what they explicitly do not care aboutrecognition_cues: — phrases, requests, objections, or behaviours that let you mechanically tag evidence to this personaWhen tagging or weighting evidence, parse other_facts for these prefixes — they are the load-bearing fields for synthesis. Synthesis output should attribute each finding back to specific personas (e.g., "Persona X is the dominant signal source this cycle; Persona Y appeared in zero evidence and may be a blind spot") rather than collapsing everything into a generic user voice.
docs/personas.md. The JSON files in personas/ are the single source of truth; do not duplicate persona content elsewhere in the repo.