Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.usecustory.com/llms.txt

Use this file to discover all available pages before exploring further.

Persona details in Custory are designed to improve product decisions. They are not meant to become long narrative profiles that nobody reopens. The best persona is the one your team actually uses when reviewing a journey, framing an opportunity, or deciding whether a solution helps the right customer.

​
What persona editing is for

Use persona details to answer:
  • Who is this journey really for?
  • What is this person trying to get done?
  • What frustrates or blocks them?
  • How do they make decisions?
  • What tools, constraints, and behaviors shape the experience?

​
Persona fields in Custory

Custory supports detailed persona editing across four practical categories:
  • Identity
  • Role and context
  • Goals and pains
  • Tech profile

​
Identity

​
Name

Use a clear, memorable label that the team will actually say out loud in meetings. Examples:
  • First-time workspace admin
  • Founder evaluating ROI
  • Ops manager onboarding the team

​
Bio

Use the bio for a concise summary of who this person is and why they matter. Good bio example: Runs setup for a small B2B team, wants fast initial value, and becomes the internal champion if onboarding feels controlled and predictable.

​
Role and context

​
Role

This is the person’s job, function, or operating position. Examples:
  • Product manager
  • Founder
  • Team admin
  • Support lead

​
Role in journey

Custory supports:
  • End user
  • Team admin
  • Manager
  • Buyer
  • Approver
  • Champion
Use this when the person’s role in the buying or usage motion matters more than their job title.

​
Primary job-to-be-done

Use this for the core progress the persona is trying to make. Good example: Get the team set up quickly enough that people see value before rollout momentum drops.

​
Buying influence

Custory supports:
  • Not involved
  • Recommends
  • Evaluates
  • Approves
  • Owns budget
This is especially useful for founder-led B2B teams where the user, admin, and buyer are often different people.

​
Budget / income

Use this when price sensitivity, purchasing power, or team budget context influences the journey meaningfully.

​
Location

Use location only when it changes the experience, workflow, or buying context. Do not add geography just to make the persona feel fuller.

​
Goals and pains

​
Goals

Add the outcomes the persona wants. Examples:
  • Launch the workspace without engineering help
  • Show early value to the rest of the team
  • Avoid choosing a tool that creates support overhead

​
Frustrations

Add the recurring blockers, anxieties, or failure modes. Examples:
  • Too many setup choices too early
  • Unclear ownership after signup
  • Hard to explain the tool internally

​
Motivations

Add the deeper reasons they care. Examples:
  • Wants to look competent as the internal owner
  • Needs fast wins to justify rollout
  • Prefers tools that reduce future coordination cost

​
Tech profile

​
Tech savviness

Custory supports:
  • Low
  • Medium
  • High
Use this to interpret friction correctly. A confusing setup for a highly technical persona means something different than the same friction for a non-technical admin.

​
Devices

Add the devices or environments that matter in practice.

​
Tools and apps

List the systems this persona already lives in. This helps teams reason about integration expectations, workflow fit, and adoption patterns.

​
Field visibility

Custory lets you enable or disable persona fields. Use that to keep the persona focused:
  • Keep only the fields that sharpen decisions
  • Hide the fields your team is not using yet
  • Expand detail only when the workflow actually needs it
This is important for smaller teams. Too much persona structure too early can turn a useful operating tool into admin overhead.

​
Editing advice for founder-led teams

​
Write for decisions, not for storytelling

Each field should help answer a product, adoption, support, or prioritization question.

​
Prefer specificity over polish

It is better to write one sharp frustration than five generic bullets.

​
Refine over time

Personas do not need to be perfect on day one. Custory is built for living profiles that get sharper as your team learns more.

​
Common mistakes

​
Writing personas like a brand deck

If the persona sounds polished but does not change product decisions, it is too abstract.

​
Duplicating minor variations

Create a separate persona only when the role, workflow, or decision logic is meaningfully different.

​
Treating empty fields as failure

If a field does not help your current workflow, leave it off. A lean, useful persona is better than a complete but stale one.