Persona Builder

Try it: /pm-skills:foundation-persona "Your context here"

This skill produces decision-usable personas from one canonical template pack.

When to Use

Before drafting PM or GTM artifacts that need a clear persona viewpoint
When teams disagree on priorities and need behavior-grounded tradeoff framing
When assumptions and confidence levels must be explicit for decision review
When tailoring downstream work (PRD, stories, launch, messaging, enablement) to a specific user or buyer profile

When NOT to Use

You need the job context rather than the person -> use define-jtbd-canvas; the canvas captures what customers hire products to do, the persona captures who they are
You are mapping internal stakeholders, not customers -> use discover-stakeholder-summary
You have raw interviews to synthesize first -> use discover-interview-synthesis; a persona built on unsynthesized notes inherits their noise
No evidence exists at all and a real decision rides on the persona: gather research first; the skill labels assumptions honestly but cannot substitute for evidence

How to Use

Invoke the skill by name (/pm-skills:foundation-persona on Claude Code, $foundation-persona on Codex):

/pm-skills:foundation-persona "Your context here"

Or reference the skill file directly: skills/foundation-persona/SKILL.md

Instructions

When asked to generate a persona, follow these steps:

Resolve mode and intent Determine whether the request is product or marketing (buyer alias allowed). If mode is omitted, ask for mode selection. If execution must continue without reply, default to product and state that fallback explicitly.
Collect context and evidence Use user-provided context first (goals, audience, domain, constraints, sources). If evidence is thin, continue generation but mark gaps and calibrate confidence.
Select exactly one template Use references/TEMPLATE.md and choose exactly one of:
- Product Persona Template
- Marketing Persona Template
Generate a complete artifact Fill the selected template end-to-end:
- header + one-sentence core-reality statement
- metadata table
- Persona Card
- sections 1 through 11
- Evidence & Confidence
Enforce mode boundaries
- Product mode: focus on workflow behavior, decision patterns, friction, quality bar, and product tradeoffs.
- Marketing mode: focus on buying triggers, evaluation criteria, committee dynamics, objections, messaging, and GTM implications.
Apply evidence and confidence policy
- Use High|Medium|Low confidence with rationale.
- Distinguish validated evidence from assumptions.
- State open questions and governance follow-up.
Finalize for direct use Remove template guidance blockquotes (> notes) from the final output. Ensure narrative entries are concrete and decision-changing, not placeholder bullets.

Supported Modes

product
marketing
buyer as input alias for marketing (output remains labeled Marketing)

Generated agent mode is out of scope for v2.5.0. If the user asks for agent, ask them to choose product or marketing.

Output Contract (v2.5.0)

Use one mode only (Product or Marketing) per output.
Keep section numbering and headings from the selected template.
Preserve the evidence table plus validated/assumed/open-questions/governance blocks.

Examples

See references/EXAMPLE.md for a completed sample output.

Output Template

Persona Output Templates (v2.5.0)

Use exactly one template per output:

Product Persona Template for foundation-persona product
Marketing Persona Template for foundation-persona marketing (and foundation-persona buyer alias)

Do not mix sections from both templates in one output.

Product Persona Template

[Persona Name] - [Archetype Label]

[One sentence that captures the persona’s core reality: what they do, what’s at stake, and what makes their situation distinct.]

Field	Value
Persona ID	[ PU-### ]
Type	[ Primary / Secondary / Supplemental / Negative ]
Product scope	[ What areas of the product this persona covers ]
Valid for	[ User type, company size, context where this persona applies ]
Not valid for	[ Adjacent user types this persona explicitly does not represent ]
Confidence	[ Validated / Directional / Proto - with brief evidence basis ]
Last validated	[ YYYY-MM-DD ]
Owner	[ Team or individual responsible for maintenance ]

Quick orientation. The Persona Card is the daily-use reference - extract it as a standalone one-pager. Sections 1-4 provide context and motivation. Sections 5-8 describe behavior and workflow. Sections 9-11 translate insight into product decisions. Evidence & Confidence calibrates trust.

Template note: Blockquote notes (>) are authoring guidance - remove them from the completed persona. Each bolded entry should be 2-4 sentences unless noted otherwise. Tables are reserved for reference data only.

Persona Card

The daily-use artifact for design reviews, sprint planning, and onboarding. Must fit on one page. Every element must pass the test: would removing this change a product decision? If not, cut it.

[Persona Name] - [Archetype Label] [2-3 sentences describing what this person does, who they serve, and why their relationship with the product domain matters.]

Key quote: “[De-identified verbatim quote from research that captures this persona’s worldview or core frustration.]”

Goals. [3-4 goals as a flowing sentence or short list. Outcomes, not features.]

Frustrations. [3-4 behavioral-level frustrations. Problems, not feature requests.]

Design rules - always. [3 rules the product must follow for this persona.]

Design rules - never. [3 things the product must avoid for this persona.]

1. Demographics & Identity

Attribute	Detail
Age	[ ]
Location	[ ]
Education	[ ]
Role	[ ]
Company size	[ ]
Team	[ Size and composition ]
Reports to	[ Direct manager -> skip level ]
Stakeholders	[ Who they deliver to or serve ]
Purchasing role	[ Decision-maker / Influencer / End user only ]
Accessibility	[ Assistive tech, vision/motor/cognitive considerations, situational constraints ]

[Career stage and trajectory.] [Where they are in their career, what they’re building toward, and how that shapes their relationship with tools in this domain.]

[Organizational leverage.] [Their influence relative to their seniority - who depends on their work, what breaks when they fail, what improves when they succeed.]

2. Technology & Environment Context

Tool	Role
[ Tool name ]	[ What it does in their workflow ]
[ Tool name ]	[ What it does in their workflow ]
[ Tool name ]	[ What it does in their workflow ]
[ Tool name ]	[ What it does in their workflow ]

[Digital fluency level.] [Their comfort with technology - not just “tech-savvy” or “non-technical” but what they can and can’t do, what concepts they understand, and where they hit walls.]

[Adoption and abandonment patterns.] [How they evaluate new tools, what makes them stay, and what makes them leave. Include specific thresholds if known from research.]

[Work environment.] [Physical setup, device usage, interruption patterns, and how their environment shapes their relationship with the product.]

3. Jobs to Be Done

Functional. [When (situation), they need to (action) so that (outcome). Focus on the progress they’re trying to make, not features they want.]

Emotional. [When (situation), they want to feel (emotional state) so that (consequence of that feeling). What does the experience need to deliver emotionally?]

Social. [How they want to be perceived by others as a result of doing this work well. What’s the social reward for success or the social cost of failure?]

Underlying. [The deeper job they don’t articulate - the structural tension or aspiration that shapes their relationship with every tool in this space. This is often the most strategically valuable insight in the persona.]

4. Goals & Motivations

Life goal provides aspirational context. End goals define what they want to accomplish through the product domain - name each descriptively. Experience goals define how the product should feel during use.

Life goal. [The aspiration that gives context to everything else. What are they building toward that the product either supports or ignores?]

[Descriptive end goal.] [What they want to accomplish. Include the product implication - what this goal demands of the product.]

[Descriptive end goal.] [Same structure.]

[Descriptive experience goal.] [How they want to feel during use. 1-2 sentences.]

[Descriptive experience goal.] [Same structure.]

5. Behavioral Patterns & Mental Models

[Core mental model.] [How they conceptualize their work in this domain. What metaphors do they use? What does their internal framing reveal about how the product should feel? 3-5 sentences - this is one of the most important entries in the persona.]

[Primary work pattern.] [The shape of their typical work - ratio of reactive to proactive, creating to modifying, solo to collaborative. What do they want that ratio to be vs. what it is?]

[Accuracy and quality approach.] [How they verify their work, what “good enough” means to them, and how that standard shifts by context.]

[Tolerance thresholds.] [Where they lose patience - with complexity, with configuration, with waiting, with ambiguity. Specific thresholds if known. 1-2 sentences.]

6. Decision-Making & Trust Patterns

[How trust is built and broken.] [The asymmetry of trust - how many positive experiences it takes to build vs. how quickly a single negative experience destroys it. Include specifics from research.]

[Adoption filter.] [The implicit questions they ask when evaluating a new tool or approach. Frame as a mental checklist they apply without articulating it.]

[Risk profile.] [Where they’re risk-averse and where they’re risk-tolerant. The boundary between exploration and commitment.]

[Feature discovery behavior.] [How they learn about new capabilities. Proactive? Accidental? Never? What this means for product investment in discoverability. 1-2 sentences.]

7. Workflow & Collaboration Context

[Work rhythm.] [The cadence of their work - anchored deadlines, fragmented time, deep focus blocks. How much uninterrupted time they typically have.]

[Collaboration model.] [Their role in the creator/consumer spectrum. Do they build, co-edit, review, consume? Who are their counterparts and what do those people do with their outputs?]

[Key collaboration friction.] [The specific way their collaboration model breaks down. What do their stakeholders or counterparts do that undermines the work?]

[Dependencies.] [What they depend on that they can’t control - upstream data, other teams’ processes, stakeholder availability. Where things break and who they blame.]

8. Current Alternatives & Workarounds

[Primary alternative.] [What they do today, with or without the product. The workflow they fall back to when the product fails them. Why that alternative persists despite its limitations.]

[Where the product enters.] [The specific role the product plays in their workflow today - and how fragile that position is.]

[The firing trigger.] [What specifically causes them to abandon the product and fall back to alternatives. The pattern, not just one anecdote.]

9. Pain Points & Unmet Needs

Frame each as a behavioral problem, not a feature request. Include why it persists and what it costs in time, credibility, or confidence. Include as many as research supports - typically 3-6.

[Pain point - descriptive label.] [What the pain is, why it persists, and what it costs.]

[Pain point - descriptive label.] [Same structure.]

10. Success Definition & Quality Bar

[Accuracy standard.] [What “correct” means to this persona. Zero tolerance? Directionally correct? Context-dependent?]

[Timeliness standard.] [What “on time” means. Their relationship with deadlines and the margin they expect.]

[Self-sufficiency standard.] [What a successful output looks like - does it need to stand alone, invite further exploration, generate action?]

[Quality bar by context.] [How the quality standard changes by situation. Describe 2-3 distinct contexts and what “good enough” means in each.]

11. Design Principles & Tradeoff Heuristics

When two good ideas compete, these rules - derived from the persona’s behavioral reality - resolve the tie. Include as many as the behavioral model supports - typically 4-7.

[X over Y.] [What to choose and what to deprioritize when they conflict. Why this persona’s reality demands this tradeoff.]

[X over Y.] [Same structure.]

Evidence & Confidence

Source	Type	Detail
[ ID ]	[ Interview / Survey / Analytics / Support / Session recording ]	[ Brief description, date, sample size ]
[ ID ]	[ ]	[ ]
[ ID ]	[ ]	[ ]

Validated. [Which sections are supported by converging evidence from multiple sources.]

Assumed. [Which sections rely on limited evidence or self-reported data. What would it take to validate them.]

Open questions. [The 2-3 most important things you still don’t know about this persona. Frame as specific, answerable research questions.]

Governance. [Review cadence, retirement criteria, and the next planned research action with a target date.]

Marketing Persona Template

[Persona Name] - [Archetype Label]

[One sentence that captures this buyer’s core decision reality: what triggers them to evaluate, what they’re trying to achieve, and what risk they’re managing.]

Field	Value
Persona ID	[ BM-### ]
Committee role	[ Champion / Economic Buyer / Technical Validator / End User / Influencer / Blocker ]
Decision context	[ What purchase decision this persona models ]
Valid for	[ Segment, company size, buying context where this persona applies ]
Not valid for	[ Adjacent buyer types this persona does not represent ]
Confidence	[ Validated / Working / Assumption - with brief evidence basis ]
Last validated	[ YYYY-MM-DD ]
Owner	[ Team or individual responsible for maintenance ]

Quick orientation. The Persona Card is the daily-use reference - extract it as a standalone one-pager. Sections 1-3 provide context and buying triggers. Sections 4-6 describe how they decide. Sections 7-8 map objections and alternatives. Sections 9-11 translate insight into GTM actions. Evidence & Confidence calibrates trust.

Template note: Blockquote notes (>) are authoring guidance - remove them from the completed persona. Each bolded entry should be 2-4 sentences unless noted otherwise. Tables are reserved for reference data only.

Persona Card

The daily-use artifact for campaign briefs, sales plays, pitch preparation, and messaging reviews. Must fit on one page. Every element must pass the test: would removing this change a messaging or sales decision? If not, cut it.

[Persona Name] - [Archetype Label] [2-3 sentences describing who this buyer is, what triggers their evaluation, and what’s at stake in their decision.]

Key quote: “[De-identified verbatim quote from a win/loss interview or sales call that captures how this buyer thinks about the purchase.]”

Buying trigger. [What event or pressure causes them to start evaluating solutions.]

Decision criteria. [The 3-4 things they evaluate most heavily, in priority order.]

Primary objection. [The most common reason they stall, defer, or say no.]

Messaging hook. [The single framing that most reliably moves this buyer forward.]

Competitive alternative. [What they’ll do instead if they don’t buy - including doing nothing.]

1. Demographics & Professional Context

Attribute	Detail
Title range	[ Typical titles this persona holds ]
Seniority	[ IC / Manager / Director / VP / C-suite ]
Department	[ ]
Company size	[ Revenue range and/or headcount ]
Industry	[ Specific verticals or horizontal ]
Reports to	[ ]
Budget authority	[ Owns budget / Influences budget / Requests budget ]
Purchasing role	[ Signs contracts / Recommends / Evaluates / Blocks ]

[Professional identity.] [How they see their role, what they’re measured on, and what professional pressure shapes their buying behavior.]

[Career context.] [Their career stage and how it affects risk tolerance in purchasing decisions. A first-time director buys differently than a tenured VP - that difference matters for sales positioning.]

2. Technology & Buying Environment

Attribute	Detail
Current solution	[ What they use today ]
Stack context	[ Key tools this purchase must integrate with ]
Technical fluency	[ How deeply they evaluate technical claims ]
Procurement process	[ Self-serve / Team evaluation / Formal RFP / Board approval ]
Typical deal cycle	[ Weeks / Months / Quarters ]

[Relationship with technology decisions.] [Whether they lead tech evaluations, defer to others, or play a specific role. How hands-on they are in evaluation vs. delegating.]

[Organizational buying culture.] [How their company makes purchasing decisions. Consensus-driven? Top-down? Committee? What the approval chain looks like.]

3. Buying Triggers & Catalyst Events

[Primary trigger.] [The specific event, pressure, or realization that moves this buyer from passive awareness to active evaluation. What changes in their world that makes the status quo unacceptable?]

[Secondary triggers.] [Other events that can initiate a buying cycle - leadership mandate, competitive pressure, team growth, failed tool, compliance deadline.]

[The “almost triggered” state.] [What keeps them aware of the problem but not yet actively evaluating. The gap between knowing and acting. This shapes nurture strategy.]

4. Jobs to Be Done (Buying Context)

Functional. [When (trigger event), they need to (find/evaluate/implement a solution) so that (business outcome). The progress they’re trying to make through the purchase itself, not just the product.]

Emotional. [How they want to feel about the decision - confident, safe, forward-thinking. What does a “good buying decision” feel like to them six months later?]

Social. [How they want to be perceived for making this decision. What does a successful purchase do for their internal reputation? What does a failed one cost?]

Underlying. [The deeper tension driving the purchase - often about professional identity, organizational politics, or career trajectory. The thing they won’t say in a sales call but that shapes everything.]

5. Decision Criteria & Evaluation Process

[How they evaluate - process.] [The steps they take from trigger to decision. Do they research independently first? Ask peers? Bring in a team? How do demos, trials, and references fit? 3-5 sentences describing the typical evaluation arc.]

[What they evaluate - criteria.] [The specific criteria they weigh, in rough priority order. Not a generic list - the actual factors this persona cares about and how they rank them.]

[How they compare - competitive frame.] [What they put side by side and how they structure the comparison. Spreadsheet? Gut feel? Delegate to a team member? What dimensions dominate?]

[What “good enough” looks like.] [Their threshold for making a decision vs. continuing to evaluate. What tips them from “still looking” to “let’s move forward”?]

6. Buying Committee & Influence Dynamics

[Their role on the committee.] [What they contribute to the buying process - discovery, evaluation, recommendation, approval, veto. How much weight their opinion carries.]

[Who they need to convince.] [The other stakeholders involved in the decision, what those people care about, and what this persona needs to provide to get buy-in.]

[Who can block them.] [The stakeholder most likely to slow down or kill the deal, what that person’s concerns are, and how this persona typically navigates the objection.]

[Internal champion behavior.] [If champion: how they sell internally, what materials they need, what arguments they make. If not champion: what role they play in supporting or undermining the champion.]

7. Objections, Risks & Barriers

Include as many named objections as research supports - typically 3-5.

[Objection - descriptive label.] [The objection, why it comes up, and what it reveals about the buyer’s underlying concern. What resolves it - not just the rebuttal, but what evidence or framing makes the concern go away.]

[Objection - descriptive label.] [Same structure.]

[The “do nothing” risk.] [Why this buyer might choose the status quo even after evaluating. What makes inaction feel safer than action? This is often the real competitor.]

[The “bad experience” ghost.] [Past purchasing experiences that shape their skepticism. What burned them before and what signals trigger that memory?]

8. Current Alternatives & Competitive Landscape

[Status quo.] [What they’re doing today and why it persists. What’s good enough about it and what’s starting to break.]

[Direct alternatives.] [The specific competitors they’re likely to evaluate. Not your full competitive set - the 2-3 options this persona actually puts on a shortlist and why.]

[Indirect alternatives.] [The non-obvious alternatives: internal tools, manual processes, hiring instead of buying, doing nothing. What makes these viable in the buyer’s mind?]

[Switching costs and lock-in.] [What makes leaving their current solution hard - data migration, retraining, integrations, political cost of admitting the last purchase was wrong.]

9. Messaging Architecture

[Primary message - the one that opens the door.] [The core framing that connects their trigger to your value in their language. Not a tagline - the message and why it works.]

[Supporting proof points.] [The 3-4 pieces of evidence that make the primary message credible - customer stories, data points, analyst validation, peer references - ranked by what this persona trusts most.]

[Language they use vs. language they distrust.] [The vocabulary this buyer uses to describe their problem and desired outcome. Equally important: words and phrases that trigger skepticism or feel like marketing speak. Include specific examples.]

[Content that moves them forward.] [The content types and formats this buyer consumes during evaluation - case studies, ROI calculators, peer conversations, technical docs. Where they look and what convinces.]

[Content that stalls them.] [What turns them off or slows the process - generic demos, gated content, aggressive follow-up, vague pricing. 1-2 sentences.]

10. Success Definition & Relationship Expectations

[What a successful purchase looks like.] [How this buyer defines a good decision - not just at purchase, but 3, 6, and 12 months later. What outcome makes them say “that was the right call”?]

[What a failed purchase looks like.] [The scenario they’re trying to avoid. What would make them regret the decision and what would the professional consequence be?]

[Relationship expectations.] [What they expect from the vendor relationship post-sale. High-touch? Self-serve? Strategic partnership? How much ongoing engagement they want and in what form.]

[Expansion and advocacy triggers.] [What would cause them to expand usage, renew enthusiastically, or refer peers. The path from buyer to champion to advocate.]

11. Sales & GTM Principles

These rules guide messaging, sales behavior, and campaign strategy for this persona. When two good approaches compete, these resolve the tie. Include as many as the buying model supports - typically 4-6.

[X over Y.] [What to prioritize in sales and messaging approach. Why this buyer’s reality demands this.]

[X over Y.] [Same structure.]

Evidence & Confidence

Source	Type	Detail
[ ID ]	[ Win interview / Loss interview / No-decision / CRM data / Call recording ]	[ Brief description, date, sample size ]
[ ID ]	[ ]	[ ]
[ ID ]	[ ]	[ ]

Validated. [Which sections are supported by converging evidence from multiple sources - ideally across won, lost, and no-decision outcomes.]

Assumed. [Which sections rely on limited evidence, internal assumptions, or sales intuition. What would it take to validate them.]

Open questions. [The 2-3 most important things you still don’t know about this buyer. Frame as specific, answerable research questions.]

Governance. [Review cadence, retirement criteria, and the next planned research action with a target date.]

Example Output

Rhea Patel - Keeper of the Approval Chain

Rhea owns the final approval gate in a regulated workflow, which means every shortcut taken upstream becomes her liability downstream, and she would rather absorb friction now than reconstruct a decision under audit six months later.

Field	Value
Persona ID	PU-004
Type	Primary
Product scope	Approval workflows, exception handling, evidence and audit surfaces
Valid for	Quality and compliance operations leads at 200-2000 person regulated companies, where approvals carry legal or patient-safety consequence
Not valid for	Individual reviewers who approve within their own scope, and consumer or low-stakes internal approvals with no audit obligation
Confidence	Directional. Five interviews plus support and audit-log review; behavioral model is consistent, quantitative baselines are missing
Last validated	2026-08-16
Owner	Product, Workflow and Compliance area

Quick orientation. The Persona Card is the daily-use reference. Sections 1-4 provide context and motivation. Sections 5-8 describe behavior and workflow. Sections 9-11 translate insight into product decisions. Evidence and Confidence calibrates trust.

Persona Card

Rhea Patel - Keeper of the Approval Chain Rhea runs clinical quality operations and holds the last signature before a submission package ships. She serves the reviewers upstream of her and the auditors downstream, and she is the person who gets asked, months later, why a decision was made. Her relationship with the product is defined by that asymmetry: everyone else is optimizing for today, and she is answering for it later.

Key quote [fictional, as is every quote and count in this example]: “I do not need it to be fast. I need to be able to stand behind it in a year when nobody remembers the context.”

Goals. Ship on time without carrying hidden assumptions past the gate. Make accountability legible so exceptions do not become orphans. Reconstruct any decision quickly when it is questioned. Spend her scarce attention on the few approvals that actually carry risk.

Frustrations. A green status that hides unresolved uncertainty. High-impact approvals recorded with no rationale. Exceptions granted under deadline with no owner or expiry. Evidence links that have gone stale since the approval. Being read as an obstacle by people who will not be in the room for the audit.

Design rules - always. Show why something passed, not just that it passed. Make ownership explicit at the moment an exception is created. Apply the same validation rules in the working flow and in the exported package.

Design rules - never. Never flatten low-risk and high-risk approvals into one undifferentiated flow. Never display an aggregate green state while a critical item is unresolved. Never let a deadline override remove the requirement to record a reason.

1. Demographics & Identity

Attribute	Detail
Age	41
Location	Boston, hybrid, three days on site
Education	BS Biology, later a regulatory affairs certification
Role	Director, Clinical Quality Operations
Company size	900 employees, mid-size regulated device manufacturer
Team	Six direct reports, mix of quality specialists and document controllers
Reports to	VP Regulatory Affairs, skip level to Chief Quality Officer
Stakeholders	Clinical operations, regulatory submissions, external auditors, occasionally legal
Purchasing role	Influencer. She does not sign, but a veto from her ends an evaluation
Accessibility	Works across two monitors with dense tables; increases browser zoom in late-day review sessions and loses layouts that assume a fixed viewport

Career stage and trajectory. Rhea moved from bench science into quality operations a decade ago and has built her reputation on submissions that survive inspection without findings. She is being positioned for a VP role, and the thing that would most damage that path is a preventable audit finding traced to a process she owned. That shapes every tool decision she makes: she is not evaluating for personal efficiency, she is evaluating for defensibility.

Organizational leverage. Her influence exceeds her title. Nothing ships without her gate, so when she declines to approve, timelines move and executives hear about it. That leverage is also a burden: teams route around her when they can, which means she often learns about a shortcut after it has already been taken.

2. Technology & Environment Context

Tool	Role
The approval workflow product	Where submissions are routed, reviewed, and gated
Regulated document management system	System of record for controlled documents; the destination her packages must satisfy
Slack	Where the real negotiation happens, and where approvals get informally pre-agreed before they appear in the tool
Spreadsheet exception tracker	Her personal shadow system for exceptions the product does not model well
Audit-log export	What she actually reaches for when a decision is questioned months later

Digital fluency level. Rhea is fluent in regulated systems and comfortable with structured data, filters, and exports. She is not a scripter and will not build an integration. She understands state machines and permission models conceptually because her job depends on them, so she asks precise questions about what a status actually means and is unsatisfied by vague answers.

Adoption and abandonment patterns. She evaluates a tool by trying to break its audit story: she will approve something, then immediately try to reconstruct why. If the reconstruction is hard, the tool is disqualified regardless of how good the daily workflow feels. She abandons quietly, by building a spreadsheet alongside the product rather than complaining, which means her dissatisfaction is invisible until the shadow system is entrenched.

Work environment. Dense information, high interruption, and long sessions clustered around submission deadlines. She reviews in focused blocks early morning and in fragmented pockets late in the day, and the late-day fragments are exactly when high-impact approvals arrive.

3. Jobs to Be Done

Functional. When a submission package reaches the final gate, she needs to determine whether every high-impact decision is supported and owned, so that she can approve without carrying unresolved risk into a regulated filing.

Emotional. When she signs, she wants to feel that she could defend the decision cold, without context, so that approving does not create a low-grade dread that surfaces every time an audit is scheduled.

Social. She wants to be seen as the person who makes shipping safe rather than the person who makes shipping slow. The social cost of being read as an obstacle is real, and it is why she looks for ways to say yes with conditions instead of no.

Underlying. The deeper job is converting distributed, informal judgment into something that survives the loss of context. Everyone else’s job ends at the decision; hers begins there. She is not managing a workflow, she is managing the future readability of decisions made by people who will have moved on.

4. Goals & Motivations

Life goal. To be the person whose systems hold up under scrutiny, and to reach a VP role on the strength of a record with no preventable findings.

Approve high-impact items with complete rationale. She wants every consequential approval to carry its reasoning at the moment it is made. This demands that the product distinguish high-impact from routine and require more at the higher tier, rather than treating a rationale field as universally optional.

Close every exception with a named owner. She wants exceptions to be temporary by construction. This demands that the product model owner, reason, expiry, and follow-up as required fields rather than free text, and that it surface exceptions approaching expiry.

Reconstruct any decision in under ten minutes. She wants to answer an auditor’s question without a forensic exercise. This demands durable evidence links and an export that carries the same context the working view had.

Feel proportionate rather than uniformly heavy. She wants the friction concentrated where risk is, so routine approvals move quickly.

Feel informed before she is asked. She wants to learn about a problem from the product, not from a stakeholder in a hallway.

Feel confident in the export. She wants what leaves the system to match what she saw when she approved it.

5. Behavioral Patterns & Mental Models

Core mental model. Rhea thinks in terms of a chain of custody for decisions, not a workflow. Each approval is a link, and the question she asks of any link is whether it will hold when pulled on later. She does not experience a status field as information; she experiences it as a claim someone made, and her instinct is to ask who made it and on what basis. This is why aggregate status indicators frustrate her disproportionately: a green badge is a summary of claims, and she needs the claims.

Primary work pattern. Roughly two thirds reactive, responding to items arriving at her gate, and one third proactive process work she rarely protects successfully. She wants that ratio closer to even, and the reactive share spikes hard in the week before a submission deadline.

Accuracy and quality approach. She verifies by sampling rather than exhaustively, choosing samples by risk rather than at random. Good enough means the decision is supported and the support is findable. Her standard does not relax under deadline, but her tolerance for how the support is captured does.

Tolerance thresholds. She loses patience with configuration that requires understanding the product’s internal model, and with any flow that makes her re-enter context the system already has. She will tolerate significant slowness in exchange for certainty, which is unusual and worth designing around.

6. Decision-Making & Trust Patterns

How trust is built and broken. Trust builds slowly through correct behavior in unremarkable cases and breaks in a single event: one contradictory approval, or one stale evidence link discovered during an audit, moves her permanently to verifying externally. She described a prior tool where one bad export ended her reliance on it entirely, after eighteen months of satisfactory use.

Adoption filter. Her implicit checklist runs roughly: can I reconstruct a decision made in this system a year from now, does it distinguish consequential from routine, does what I export match what I saw, and does it make ownership explicit or leave it implied. A tool that fails the first question is disqualified regardless of the rest.

Risk profile. Risk-tolerant about process change and risk-averse about evidence. She will pilot a new workflow willingly and will not accept a new system of record without a migration story for historical decisions.

Feature discovery behavior. Almost entirely accidental or peer-mediated. She does not read release notes and does not explore. Capability she is not told about directly is capability she does not have.

7. Workflow & Collaboration Context

Work rhythm. Anchored hard to submission deadlines, with the approval load arriving late and compressed. She has perhaps two protected hours early each day and fragmented attention afterward. The riskiest approvals disproportionately arrive during the fragmented window, which is a product problem disguised as a scheduling one.

Collaboration model. She is a reviewer and gatekeeper, rarely an author. Her counterparts are clinical and regulatory authors upstream, and auditors and regulators downstream who consume her output long after the fact. That downstream consumer never appears in the product, which is precisely why the product under-serves her.

Key collaboration friction. Approvals get informally negotiated in Slack and then recorded in the tool as a formality, so the recorded artifact captures the conclusion and loses the reasoning. She receives a decision with the argument stripped out and is expected to ratify it.

Dependencies. She depends on upstream authors to supply complete evidence, on reviewers to apply consistent standards, and on stakeholders to be available for clarification during compressed windows. When a submission slips, she is blamed for the gate rather than the inputs.

8. Current Alternatives & Workarounds

Primary alternative. A personal spreadsheet tracking exceptions, owners, and expiry dates, maintained in parallel with the product. It persists because it models the thing she actually manages, which is the lifecycle of an exception, whereas the product models the moment an exception was granted. It is fragile, unshared, and she knows it is a liability.

Where the product enters. It is the system of record for the approval event itself and is trusted for that narrow purpose. Its position is more fragile than usage metrics suggest, because the work she does around it is invisible to the product.

The firing trigger. Not one dramatic failure but a pattern: two or three occasions where the product’s record could not answer a question she was asked, each pushing more of the real work into the spreadsheet. The tool does not get abandoned, it gets hollowed out.

9. Pain Points & Unmet Needs

High-impact approvals recorded without rationale. The product accepts an approval on a consequential item with no reasoning captured, because the rationale field is optional everywhere. It persists because making it universally required would burden routine approvals, so it stays optional everywhere instead. The cost is paid months later in reconstruction time and, occasionally, in an audit finding.

Exceptions without owners or expiry. An exception can be granted under deadline pressure with nothing but a note. It persists because the deadline case is exactly when nobody wants another required field. The cost is a growing population of open exceptions nobody is accountable for, which is the single largest source of her shadow spreadsheet.

Aggregate status hides unresolved items. A package shows green while a critical item remains open, because the status rolls up completion rather than risk. It persists because the rollup was designed for progress reporting, not for gating. The cost is a false sense of readiness that reaches Slack before it reaches her.

Export loses the context of the working view. What she reviewed and what leaves the system are assembled by different logic, so the export can omit rationale or resolve a link differently. It persists because the two paths were built at different times. The cost is that her audit artifact is not the thing she approved.

Stale evidence links. A link that resolved at approval time points somewhere else, or nowhere, months later. It persists because links are stored as references without snapshots. The cost is direct: it is the failure mode most likely to produce an actual finding.

Contradictory approvals go undetected. Two reviewers can approve incompatible states of the same item without the system noticing. It persists because approvals are recorded per item rather than evaluated for coherence. The cost is discovered late, usually by her, usually at the gate.

10. Success Definition & Quality Bar

Accuracy standard. Zero tolerance on evidence and ownership, and pragmatic tolerance on presentation. A decision may be recorded tersely; it may not be recorded without a basis.

Timeliness standard. On time means the gate does not become the reason for a slip. She measures her own performance partly by how rarely she is the critical path, which is why she is more receptive to proportional friction than to uniform speed.

Self-sufficiency standard. A successful output stands alone. Someone with no context should be able to open the record and understand what was decided, by whom, on what basis, and what remains open.

Quality bar by context. In normal operation she expects full rationale on high-impact items and light-touch recording elsewhere. In deadline compression she will accept abbreviated rationale in exchange for explicit exception governance: owner, reason, expiry, and follow-up become non-negotiable precisely when everything else relaxes. In an incident or audit response the bar inverts entirely, and reconstruction speed dominates everything, including her willingness to tolerate an awkward interface.

11. Design Principles & Tradeoff Heuristics

Legibility over brevity. When a status could be shorter or more explicable, choose explicable. Her entire job is answering questions about decisions after the context is gone.

Proportional friction over uniform friction. When adding a required field, add it at the high-impact tier rather than everywhere. Uniform requirements get satisfied uniformly badly, which destroys the signal on the items that matter.

Explicit ownership over inferred ownership. When the system could infer an owner from context, require one instead. An inferred owner is not an owner when the exception is questioned.

Structured exceptions over free-text exceptions. When accommodating an edge case under deadline, model it with owner, reason, expiry, and follow-up rather than a comment field. The comment field is where her shadow spreadsheet comes from.

Parity over convenience. When the working view and the export could diverge for implementation convenience, keep them identical. A divergence here converts her audit artifact into a guess.

Risk rollup over completion rollup. When summarizing package state, summarize by unresolved risk rather than percentage complete. A green completion bar over an open critical item is worse than no summary at all.

Snapshot over reference. When linking evidence, capture what was seen at approval time rather than a pointer that resolves later. This is the difference between a record and a hope.

Evidence & Confidence

Source	Type	Detail

Source	Type	Detail
I1-I5	Interview	Five [fictional] quality and compliance operations leads at regulated manufacturers, 45-60 minutes each, 2026-06 to 2026-07
S1	Support	14 months of support tickets tagged approvals or exceptions, 312 [fictional] tickets reviewed and themed
A1	Analytics	Audit-log export analysis across 4 [fictional] customer tenants: rationale-field completion by impact tier
W1	Session recording	Three [fictional] recorded submission-gate sessions, observed rather than self-reported

Validated against the sources above, which are themselves [fictional]. The behavioral model in sections 5 and 6, the exception-lifecycle pain point, and the export-parity failure each name a study that supports them, which is what “validated” has to mean here: traceable to a source, not merely plausible. The shadow-spreadsheet workaround appeared unprompted in four of five [fictional] interviews. In your own persona this label is earned by real studies or it is not earned at all.

Assumed. The demographic detail in section 1 is composite rather than observed. The quality-bar shifts in section 10 come from interview self-report and have not been observed under real deadline compression, which is exactly the condition where self-report is least reliable. Validating that would require observing a live submission window rather than asking about one.

Open questions. What is the current re-open-after-approval rate by workflow stage, and does it concentrate in the late-day fragmented window as the behavioral model predicts? Which reviewer cohorts show the widest variance in rationale quality, and is variance driven by role or by time pressure? What are the recurring exception classes by frequency, and who actually owns them today?

Governance. Review every two quarters, or immediately after any audit finding touching the approval chain. Retire when the regulated-workflow segment falls below a quarter of new revenue, or when a successor persona based on observed rather than self-reported deadline behavior supersedes it. Next planned research: observe one live submission window, target 2026-10-31.

Real-World Examples

See this skill applied to three different product contexts:

Storevine (B2B): Storevine Campaigns marketing persona for self-serve SMB merchant acquisition and competitive positioning against Shopify plus Klaviyo

Prompt:

foundation-persona marketing brief

Quick marketing persona for Storevine Campaigns SMB acquisition.

Context:
- We're targeting Shopify + Klaviyo merchants who might consolidate
- Win-loss: 6/14 wins cited "too many tools"; 4/9 losses said "Klaviyo is good enough" [fictional]
- Need this for competitive landing page and acquisition email sequence
- Self-serve purchase, no committee, individual merchant decision

Prior work:
- Competitive analysis (Feb 2026): Shopify Email is template-first, Klaviyo is automation-first
- Interview synthesis: merchants describe "tool juggling tax" as real operational cost

Keep it brief, focused on acquisition messaging and objection handling.

Output:

Persona Dossier: Priya Sharma, The Merchant Who Pays the Tool-Juggling Tax (Marketing, Brief)

Brainshelf (Consumer): Brainshelf marketing persona for newsletter-creator acquisition and content-curation positioning

Prompt:

foundation-persona marketing brief

marketing persona for newsletter creator acquisition channel.

context: brainshelf users who share 3+ items/week have 3.4x retention
and 2.1 referral signups/quarter [fictional]. newsletter creators are
a natural fit because they already curate. want a persona for
acquisition messaging and potential "Curator" tier positioning.

competitors in this space: Readwise Reader, Raindrop, Pocket.
keep it brief but actionable for growth experiments.

Output:

Persona Dossier: Amara Osei, The Creator Who Curates Before She Writes (Marketing, Brief)

Workbench (Enterprise): Workbench Blueprints marketing persona for enterprise champion sales playbook and pilot-to-expansion messaging

Prompt:

foundation-persona marketing brief

Sandra V. to PM Skills agent:

> I need a brief marketing persona for the Workbench Blueprints enterprise
> sales playbook. This should represent the internal champion who drives
> the purchasing conversation.
>
> Context:
> - 3 pilot customers have requested formal proposals after Blueprint trials
> - Common stall point: champion can't answer IT security and legal questions
>   without vendor-supplied materials
> - Need: concise persona for messaging alignment, objection prep, and
>   pilot-to-expansion proof points
> - Sales cycle: 60-90 day evaluations with 3-5 stakeholder sign-offs
>
> Keep it brief but decision-usable for the sales team.

Output:

Persona Dossier: Sandra Vo, The Champion Who Cannot Arm Her Committee (Marketing, Brief)

Quality Checklist

Before finalizing, verify:

Exactly one mode is used and clearly labeled
buyer inputs are normalized to Marketing
Header, core-reality statement, metadata table, and Persona Card are present
All 1 through 11 sections from the selected template are present and complete
Includes/not-valid boundaries are explicit in the metadata and narrative
Evidence table is populated with concrete sources
Confidence is High, Medium, or Low with rationale
Validated, Assumed, Open questions, and Governance blocks are present
Template authoring notes (> guidance lines) are removed from the completed output