👤 persona-extract¶

Persona extraction engine -- takes decision-log output and signal scan data, then produces deep persona research with real stories, decision points, Four Forces analysis, and offer mapping. Uses web search to find real evidence. Use when converting validated market signals into evidence-based buyer personas grounded in real stories.

License: MIT | Security: CLEAN

Install¶

brunnr install persona-extract

Tags: Hunter Pipeline

Security Scan¶

CLEAN — 0 findings

This skill passed all 7+1 threat class checks with no findings.

File Info¶

Property	Value
Path	`skills/persona-extract/SKILL.md`
Size	17.4 KB
SHA-256	`0270c51dd45f5fca2c54c99d7ffc5c354da13d24b887dab639fd8d3aa64f89ac`
README	`skills/persona-extract/README.md`

Skill Prompt¶

Persona Extract¶

Transform decision-log output and signal scan data into deep, evidence-based buyer personas using the Signal-to-Story Pipeline. Produces structured JSON and human-readable markdown with real pain stories, success stories, decision point maps, Four Forces analysis, and next-step hints for offer-scope.

Step 0: Load Conventions¶

Before doing ANYTHING, read the shared conventions file:

Read ${SKILLS_DIR}/_conventions.md

This file defines: canonical vault path, folder-to-type mapping, frontmatter contract, valid statuses, tag hierarchy, cross-reference syntax, and the PipelineEnvelope schema. All output from this skill MUST conform to those conventions. If there is a conflict between this SKILL.md and _conventions.md, the conventions file wins.

Pipeline Position¶

signal-scan -> decision-log -> **persona-extract** -> offer-scope -> hunter-log

This skill consumes the output of decision-log (and references signal-scan data), and feeds into offer-scope for product scoping.

When to Use¶

Converting validated market signals into buyer personas
Building evidence-based archetypes from real community stories
Mapping decision points where a product could intervene
Understanding who is in a market, what they want, and how they buy
Preparing persona data for offer-scope to generate a build spec

Trigger Phrases¶

"Extract personas for [opportunity]"
"Who is the buyer for [domain/opportunity]?"
"Run persona extraction on this decision"
"Build personas from this signal scan"
"/persona-extract [decision-log output]"

Prerequisites¶

Before starting, the following must be available:

Decision-log output -- A completed decision-log result with domain, opportunity title, and supporting signal data
Signal data -- Pain signals, spend signals, and behavior signals from the upstream signal scan
Ship candidates -- Candidate products identified by the signal scan or decision log

If any of these are missing, prompt the user to run the upstream skill first or provide the data manually.

Input¶

The skill expects the following input structure (typically assembled from upstream skill outputs):

interface PersonaExtractInput {
  decision: DecisionLogOutput         // or relevant subset
  domain: string
  opportunity_title: string
  pain_signals: PainSignal[]
  spend_signals: SpendSignal[]
  behavior_signals: BehaviorSignal[]
  ship_candidates: ShipCandidate[]
}

Workflow¶

Decision-Log Output + Signal Data (from upstream skills)
    |
Phase 1: Opportunity Definition (frame the research)
    |
Phase 2: Evidence Collection (web search -- real data REQUIRED)
    |
Phase 3: Pain Story Collection (verbatim quotes, real attributions)
    |
Phase 4: Success Story Collection (what winners did differently)
    |
Phase 5: Decision Point Mapping (forks in the road)
    |
Phase 6: Four Forces Analysis (Moesta's push/pull/anxiety/habit)
    |
Phase 7: Persona Clustering (3-4 evidence-based archetypes)
    |
Phase 8: Offer Mapping (decision points -> product interventions)
    |
Phase 9: Next-Step Hint Generation (prepare input for offer-scope)
    |
Output: JSON + Markdown -> vault

Phase 1: Opportunity Definition¶

Start with the decision-log output. Extract and confirm:

Domain: The space being explored (e.g., "DevOps education")
Opportunity: The specific opportunity title from the decision log
Hypothesis: Who might care about this and why (drawn from signal data)
Research targets: Which communities, subreddits, forums, and platforms to search

Present a research plan to the user before proceeding. This prevents wasted search effort on the wrong communities.

Phase 2: Evidence Collection¶

This phase requires extensive web search. No hallucinated evidence. No personas from memory.

Search systematically across the following sources for the domain and opportunity:

Source	What to Collect	Why
Reddit (relevant subreddits)	Pain language, "I wish..." posts, rants, workarounds, recommendations	Raw emotional evidence, real language
Hacker News	Technical frustrations, tool complaints, career anxiety threads	Senior/experienced perspective
DEV.to / Hashnode	Blog posts about struggles, "what I learned" retrospectives	Narrative-rich stories
Stack Overflow / forums	Repeated questions, workarounds, duct-tape solutions	Behavior signals
Twitter/X	Viral threads, complaints, hot takes, engagement patterns	Real-time sentiment
Discord / Slack communities	Direct requests, topic resonance, engagement patterns	Community-specific pain
Review sites (G2, Capterra)	2-3 star reviews especially -- where the nuance lives	Switching intent, feature gaps
Amazon reviews	Reviews of competing books/courses in the space	Learning journey pain

Collection Rules¶

Search for pain language: "I wish...", "I'm so frustrated...", "Why can't someone just...", "I spent X hours trying to..."
Search for emotional content: anger, desperation, relief, triumph
Search for specific failures: "I broke production because...", "I failed the interview when..."
Every piece of evidence must be a real quote from a real post -- include username/attribution when available
Collect at least 15-20 raw stories across sources before proceeding to clustering
Note the platform, date/recency, and engagement metrics (upvotes, replies) when possible
Do NOT summarize. Copy verbatim. Their language IS your data.

Phase 3: Pain Story Collection¶

From the raw evidence, extract structured pain stories. Each story captures one person's struggle.

Per pain story, capture:

Field	Description	Rule
situation	What was happening when the pain occurred	Specific context, not abstract
pain	What hurt -- the actual problem experienced	In their words
current_workaround	What they do instead of a real solution	Reveals product opportunity
emotional_state	How they feel about it	Use their emotional language
evidence	The REAL quote with attribution	Must be an actual quote from an actual post

Pain Story Rules¶

Minimum 3 pain stories per persona (9+ total across all personas)
Every story must have a real quote in the evidence field
Attribution format: "quote text" -- u/username on r/subreddit (N upvotes) or "quote text" -- @handle on Twitter or "quote text" -- [platform] user
If you cannot find real evidence for a pain story, do not fabricate one. Note the gap and search more.

Phase 4: Success Story Collection¶

Not everyone is stuck. Find the people who made it through and study what they did differently.

Per success story, capture:

Field	Description	Rule
situation	Where they started -- what struggle they faced	Must match a pain story pattern
what_they_did	The specific actions that led to the breakthrough	Actions, not mindset shifts
outcome	What changed as a result	Concrete, measurable when possible
evidence	The REAL quote with attribution	Must be an actual quote

Success Story Rules¶

Minimum 2 success stories per persona
Look for: "What finally clicked for me was...", "The thing that changed everything was...", "After I stopped X and started Y..."
Success stories reveal the product intervention point -- the thing that could help stuck people take the success path

Phase 5: Decision Point Mapping¶

Every journey from struggle to success has forks in the road. Map the critical decision points where some people succeed and others stay stuck.

Per decision point, capture:

Field	Description
trigger	What starts the search -- the event that moves someone from passive to active
stuck_behavior	What the people who remain stuck do at this fork
success_behavior	What the people who break through do at this fork
product_intervention	What product could help the stuck person take the success path

Decision Point Rules¶

Each persona should have at least 2 decision points
Triggers must be specific events, not vague states ("failed a production deploy" not "feels frustrated")
Product interventions must be specific enough for offer-scope to act on (format, content type, delivery mechanism)

Phase 6: Four Forces Analysis¶

Apply Bob Moesta's Four Forces model across all collected evidence. This is a global analysis across all personas, not per-persona.

Force	Question	Source
Push	What is wrong with the current situation?	Pain stories, workarounds, emotional language
Pull	What attracts them to a solution?	Success stories, aspirational language, desired outcomes
Anxiety	What scares them about buying/switching?	Objections, hesitations, past failures, trust concerns
Habit	What keeps them doing nothing?	Default behaviors, free alternatives, inertia patterns

Four Forces Rules¶

Every force must have at least 3 entries
Each entry should trace back to specific evidence from the collection phase
For a switch to happen: Push + Pull must exceed Anxiety + Habit
The analysis should reveal what to amplify (push, pull) and what to reduce (anxiety, habit) in the eventual offer

Phase 7: Persona Clustering¶

Group the collected stories into 3-4 distinct persona archetypes. These are behavioral archetypes, NOT demographic groups.

Per persona, define:

Field	Description
persona_name	Descriptive name encoding the emotional state or behavior pattern
archetype	Short label -- e.g., "The Reluctant Senior", "The Copypaste Engineer", "The Midnight Firefighter"
demographics.job_titles	Common job titles for this archetype
demographics.experience_range	Years of experience range
demographics.salary_range	Approximate salary range (for WTP anchoring)
demographics.company_size	Typical company size
emotional_state	The dominant emotional experience of this archetype
pain_stories[]	3+ pain stories with real evidence (from Phase 3)
success_stories[]	2+ success stories with real evidence (from Phase 4)
decision_points[]	2+ decision points with interventions (from Phase 5)
buying_triggers[]	Specific events that would cause them to search and purchase
objections[]	What would make them hesitate, with evidence-based counters
willingness_to_pay	Price range, evidence (anchored to SPEND data), and anchor products
channels[]	Where they spend time, their behavior on each platform, estimated reach

Clustering Rules¶

Minimum 3 personas, maximum 4
Personas must be distinct -- if two personas have the same pain stories and decision points, merge them
Every persona must have at least 3 pain stories with real evidence
Archetype names should be memorable and encode the behavioral pattern
Demographics serve WTP anchoring and channel targeting -- they are NOT the primary clustering dimension

Phase 8: Offer Mapping¶

For each persona's decision points, map potential product interventions.

Per intervention, consider:

Format: Must match the persona's consumption context (2 AM incident = checklist, not course)
Language: Use the persona's exact pain language from collected evidence
Price anchor: Derived from SPEND data and the persona's willingness-to-pay
Channel: Where the persona would discover this product

This phase produces the raw material that offer-scope will refine into a full build spec.

Phase 9: Next-Step Hint Generation¶

Generate a structured hint for the downstream offer-scope skill. This selects the highest-value path from the persona data.

The hint must include:

Field	Description
top_persona	The persona with the strongest pain + highest WTP -- the best first target
top_decision_point	The single decision point with the highest composite of pain intensity, urgency, and WTP
willingness_to_pay	The WTP data for the top persona, anchored to SPEND evidence
best_channel	The channel where the top persona is most reachable and most receptive

Output¶

The extraction produces two files:

Vault Output¶

Save to: Admin/Product-Discovery/Personas/{domain-slug}-{YYYY-MM-DD}.md

Vault path: ${VAULT}/Admin/Product-Discovery/Personas/

1. JSON: `persona-extract-[domain-slug]-[date].json`¶

Structured data following the schema in references/output-schema.json. Must validate against that schema.

2. Markdown Summary¶

Human-readable report with the following sections:

---
type: persona
date: YYYY-MM-DD
status: complete
tags:
  - hunter/persona
  - hunter/domain/{domain-slug}
  - hunter/opportunity/{opportunity-slug}
decision_ref: "{decision-slug}"
signal_scan_ref: "{signal-scan-slug}"
---

### Persona Extract: [Opportunity]

**Date**: [date]
**Domain**: [domain]
**Opportunity**: [opportunity]

#### Meta Insight

[The overarching persona insight -- what connects all these people]

#### Persona Summary

| Persona | Archetype | Emotional State | Top Pain | WTP |
|---------|-----------|-----------------|----------|-----|
| [name] | [archetype] | [state] | [pain] | [range] |
| ... | ... | ... | ... | ... |

#### Personas

##### 1. [Persona Name] -- "[Archetype]"

**Demographics**: [job titles] | [experience] | [salary] | [company size]
**Emotional State**: [description]

###### Pain Stories

**Story 1**: [situation]
- **Pain**: [pain]
- **Workaround**: [current workaround]
- **Emotional State**: [how they feel]
- **Evidence**: "[real quote]" -- [attribution]

[... repeat for each story]

###### Success Stories

**Story 1**: [situation]
- **What they did**: [actions]
- **Outcome**: [result]
- **Evidence**: "[real quote]" -- [attribution]

###### Decision Points

| Trigger | Stuck Behavior | Success Behavior | Product Intervention |
|---------|---------------|-----------------|---------------------|
| [trigger] | [stuck] | [success] | [intervention] |

###### Buying Triggers

| Trigger | Urgency | Channel |
|---------|---------|---------|
| [trigger] | [level] | [channel] |

###### Objections

| Objection | Counter |
|-----------|---------|
| [objection] | [counter] |

###### Willingness to Pay

**Range**: [range]
**Evidence**: [evidence]
**Anchor Products**: [list]

###### Channels

| Platform | Behavior | Estimated Reach |
|----------|----------|----------------|
| [platform] | [behavior] | [reach] |

##### 2. [Next persona...]

#### Four Forces Analysis

##### Push (What is wrong now)
- [push factor 1]
- [push factor 2]
- [push factor 3]

##### Pull (What attracts them to a solution)
- [pull factor 1]
- [pull factor 2]
- [pull factor 3]

##### Anxiety (What scares them about buying)
- [anxiety factor 1]
- [anxiety factor 2]
- [anxiety factor 3]

##### Habit (What keeps them doing nothing)
- [habit factor 1]
- [habit factor 2]
- [habit factor 3]

#### Next Step: offer-scope

**Top Persona**: [name]
**Top Decision Point**: [trigger + intervention]
**Willingness to Pay**: [range + evidence]
**Best Channel**: [platform + behavior]

#### References

- **Decision Log**: [[Admin/Product-Discovery/Decisions/{decision-slug}]]
- **Signal Scan**: [[Admin/Product-Discovery/Signal-Scans/{signal-scan-slug}]]

Resources¶

references/¶

output-schema.json -- JSON Schema for the structured persona extraction output. Load when producing the JSON file to validate against.

README.md¶

Full methodology reference: The Signal-to-Story Pipeline, Four Forces model, Sales Safari, JTBD, 5 Rings of Buying Insight, buyer psychology glossary, case studies. Load when you need deeper context on frameworks or terminology.

Quality Checklist¶

Run this checklist before delivering the extraction:

[ ] All personas have real evidence -- every pain/success story includes an actual quote with attribution
[ ] No hypothetical personas -- all archetypes are derived from observed stories, not imagination
[ ] Web search was used in Phases 2-4 -- this skill cannot work from memory alone
[ ] Minimum 3 personas, each with minimum 3 pain stories with evidence
[ ] Four Forces analysis covers all 4 quadrants with at least 3 entries each
[ ] Decision points map to specific product interventions (format + content type + delivery)
[ ] Buying triggers include the channel where the persona would be when triggered
[ ] Objections have evidence-based counters, not generic dismissals
[ ] Willingness to pay is anchored to SPEND data from the signal scan, not guesses
[ ] Channels include specific platforms with behavior descriptions and reach estimates
[ ] Next-step hint is populated with the highest-value persona, decision point, WTP, and channel
[ ] JSON output validates against references/output-schema.json
[ ] Markdown output includes correct frontmatter (type, date, status, tags, refs)
[ ] Markdown is saved to vault at Admin/Product-Discovery/Personas/
[ ] All upstream references (decision_ref, signal_scan_ref) are linked
[ ] Pipeline kanban updated: move card to "Persona Researched" column (see _conventions.md Pipeline Kanban Contract)

README¶

Persona Extract¶

A Ground-Up Masterclass in Customer Persona Research, Buyer Psychology, and Jobs to Be Done¶

Written for the engineer who can build anything but has never studied who buys things and why.

Table of Contents¶

The Discipline: What Is Persona Research?
The Canon: Thinkers, Texts, and Frameworks That Matter
Frameworks: The Major Models You Need to Internalize
The Lingo: A Conversational Glossary of Buyer Psychology
The Process: How Persona Extraction Actually Works
The Four Forces in Practice
Common Mistakes
Case Studies
The Methodology: The Signal-to-Story Pipeline

The Discipline¶

What IS Persona Research?¶

Persona research is the disciplined practice of understanding the real human beings who might pay you money. Not "users" in the abstract. Not a demographic bucket. Actual people, with anxieties and aspirations, stuck in situations they want to escape, spending real hours searching for solutions, weighing their options, and — if you earn it — pulling out a credit card.

Most engineers skip this step entirely. They build for themselves, or they build to spec, or they build what seems technically interesting. And then they launch to silence. The product works. Nobody cares. This is the most common failure mode in software, and it is almost entirely a failure of understanding people, not a failure of engineering.

Persona research is related to, but distinct from, several adjacent disciplines:

Market segmentation divides a total addressable market into groups based on shared characteristics — geography, company size, industry, behavior. It answers "who is out there?" at a macro level. Persona research goes deeper: it answers "what is this specific person thinking, feeling, and doing at the moment they start looking for a solution?"

Customer profiling (sometimes called Ideal Customer Profile or ICP, especially in B2B) describes the firmographic and demographic traits of your best-fit buyer — revenue range, team size, tech stack, job title. It is the spreadsheet version of your customer. Persona research adds the narrative: the story of their struggle, their emotional state, their decision-making process.

Jobs to Be Done (JTBD) is a theory of customer motivation. It asks not "who is the customer?" but "what job is the customer hiring this product to do?" It is the single most important framework in persona research, and we will spend significant time on it below.

User research / UX research studies how people interact with a product after they have it. Persona research studies how people arrive at the decision to acquire the product in the first place. UX research asks "can they use it?" Persona research asks "will they buy it, and why?"

Buyer psychology is the study of how people make purchasing decisions — the cognitive biases, emotional triggers, social influences, and decision heuristics that govern whether someone converts from "interested" to "paid." Persona research draws heavily from buyer psychology to model not just who the buyer is, but how they decide.

Demand-side sales (a term from Bob Moesta) flips the traditional sales model. Instead of pushing a product onto a buyer, you study the demand that already exists — the struggle the buyer is already experiencing — and position your product as the thing they were already looking for. Persona research is the foundation of demand-side sales: you cannot sell to demand you do not understand.

Why Engineers Skip This (And Why It Kills Their Products)¶

Engineers are trained to solve well-defined problems. Persona research feels squishy, subjective, and unverifiable. There is no compiler. There is no test suite. You cannot assert that your persona is correct.

But here is the thing: every product decision you make — what to build, what to name it, how to price it, where to announce it, what words to put on the landing page — is implicitly a bet on who your buyer is and what they care about. If you skip persona research, you are still making those bets. You are just making them with zero data, based on your own projections onto a market you have not studied.

The products that succeed are not always the best-engineered. They are the ones that meet a real person at a real moment of struggle with a real solution that the person can find, understand, trust, and afford. Persona research is the discipline of knowing all of that before you write a line of code.

The Canon¶

The Thinkers You Must Know¶

Alan Cooper — The Inmates Are Running the Asylum (1999). Cooper is the father of software personas. He was a programmer who realized that developers build software for themselves, creating interfaces that make sense to engineers and baffle everyone else. His key insight: create fictional but research-grounded characters (personas) and design for them instead of for "the user" in the abstract. Cooper's framework forces you to make specific decisions — "Would Janet do this? Would Janet understand this?" — instead of hiding behind vague generalizations. His contribution is foundational: before Cooper, software teams talked about "the user" as if there were only one.

Clayton Christensen — Competing Against Luck (2016). Christensen is the originator of Jobs to Be Done theory (building on Theodore Levitt's famous quip about quarter-inch drills and quarter-inch holes). His key insight: customers do not buy products. They "hire" products to make progress in specific circumstances. The unit of analysis is not the customer or the product — it is the job. Christensen's framework reorients everything: you stop asking "what features do our customers want?" and start asking "what progress are they trying to make, and what is getting in the way?" This is the most important shift in thinking this document will teach you.

Bob Moesta — Demand-Side Sales 101 (2020). Moesta worked with Christensen and operationalized JTBD into a practical sales and research methodology. His key insight: every purchase is a "switch" — someone fires an old solution and hires a new one. The switch is governed by Four Forces (push, pull, anxiety, habit). Moesta's framework, the Switch interview, is a forensic reconstruction of a past purchase decision, and it is the gold standard for understanding why people buy. His contribution is making JTBD actionable — not just a theory but a repeatable interview and analysis method.

Adele Revella — Buyer Personas (2015). Revella created the 5 Rings of Buying Insight, a structured framework for capturing everything that matters about how a buyer decides. Her key insight: most "personas" are useless because they describe demographics instead of decisions. A real buyer persona captures the priority initiative (what triggered the search), success factors (what the buyer wants to achieve), perceived barriers (what might stop them), the buyer's journey (how they evaluate), and decision criteria (what factors they weigh). Her contribution is rigor: a repeatable process for building personas that actually inform marketing and product decisions.

Eugene Schwartz — Breakthrough Advertising (1966). Schwartz was a direct-response copywriter who identified the five levels of customer awareness. His key insight: you cannot sell the same way to someone who does not know they have a problem as you sell to someone actively comparison-shopping. The five levels — Unaware, Problem-Aware, Solution-Aware, Product-Aware, Most Aware — determine everything about how you communicate. His contribution to persona research is the recognition that the same person can be a different "persona" depending on where they are in their awareness journey. A person who does not yet realize they have a problem requires education. A person comparing two products requires differentiation.

Robert Cialdini — Influence: The Psychology of Persuasion (1984). Cialdini identified six (later seven) principles of persuasion: reciprocity, commitment/consistency, social proof, authority, liking, scarcity, and unity. His key insight for persona research: buying decisions are not purely rational. They are heavily influenced by psychological shortcuts. Understanding which principles matter most to your specific persona — does this buyer respond more to social proof or to authority? — lets you craft messaging and positioning that aligns with how they actually decide. His contribution is a taxonomy of persuasion mechanisms that apply across every buying context.

Daniel Kahneman — Thinking, Fast and Slow (2011). Kahneman (with Amos Tversky) developed the dual-process theory of cognition: System 1 (fast, intuitive, emotional) and System 2 (slow, deliberate, rational). His key insight for buyer psychology: most purchasing decisions are made by System 1 and then rationalized by System 2. People buy on feeling and justify with logic. This means your persona research must capture not just what the buyer thinks but what the buyer feels. It also means your messaging must appeal to System 1 first (emotion, story, identity) and give System 2 something to work with second (features, specs, ROI calculations).

Amos Tversky — Tversky co-developed prospect theory with Kahneman: the discovery that losses loom larger than gains. People are not rational utility maximizers. They are loss-averse, reference-dependent decision-makers. His key insight for persona research: the fear of losing what you have (time, money, status, comfort) is a more powerful motivator than the promise of gaining something new. This is why "switching costs" matter so much, why the status quo is so sticky, and why your persona's anxiety about change is as important to understand as their desire for improvement.

Byron Sharp — How Brands Grow (2010). Sharp challenges traditional segmentation with evidence that most brand growth comes from acquiring light buyers, not from deepening loyalty among heavy buyers. His key insight: brand differentiation is often less important than brand salience (mental and physical availability). While Sharp's work is most applicable to large consumer brands, the implication for persona research is important: do not over-segment. Sometimes the biggest growth comes from making your product easier to find and easier to try, not from hyper-targeting a narrow niche.

April Dunford — Obviously Awesome (2019). Dunford is the leading practitioner of product positioning. Her key insight: positioning is not messaging — it is the context you set for your product so that its value is obvious. Positioning determines who your competitive alternatives are, what your unique attributes are, and which customers care most. For persona research, Dunford's contribution is the recognition that your persona and your positioning are interdependent. You cannot position a product without knowing who it is for, and you cannot fully define a persona without knowing what you are positioning against.

Ryan Levesque — Ask (2015). Levesque developed the ASK Method, a systematic approach to surveying your market to discover segments you did not know existed. His key insight: the right questions, asked the right way, reveal buckets of people with distinct needs — and the most valuable question is often "What is your single biggest challenge with [X]?" His framework includes the Deep Dive Survey, the Micro-Commitment Bucket Survey, and the "Do You Hate Me?" survey. For persona research, Levesque's contribution is a structured way to let the market tell you who the personas are, rather than inventing them from assumptions.

Amy Hoy — Sales Safari methodology. Hoy developed Sales Safari as a research methodology for bootstrapped founders who cannot afford focus groups or large-scale surveys. Her key insight: you learn more about your customers by observing them in their natural habitat (forums, Reddit, review sites, social media, Q&A sites) than by asking them directly. People lie in surveys (often unintentionally). But when they write a frustrated Reddit post at midnight, they are telling the raw truth. Sales Safari teaches you to systematically mine these natural conversations for pain language, emotional triggers, workarounds, and buying signals. Her contribution is making persona research accessible, evidence-based, and grounded in real behavior rather than hypothetical responses.

Frameworks¶

Jobs to Be Done (JTBD) — The Core Framework¶

JTBD starts with a counterintuitive premise: people do not buy products. They hire them.

The most famous example is Clayton Christensen's milkshake study. A fast-food chain wanted to sell more milkshakes. They surveyed customers about what would make a better milkshake — thicker? more chocolate? cheaper? The answers led nowhere. Then Christensen's team observed: nearly half of all milkshakes were sold before 8:00 AM, to commuters, who bought them alone, who took them to their cars. The "job" was not "enjoy a dessert." The job was "make my boring 45-minute commute less boring, keep me full until lunch, and give me something to do with my free hand." The milkshake was competing not against other milkshakes — it was competing against bagels, bananas, and boredom. Once the team understood the job, they could improve the product for the job: make it thicker (lasts longer), add chunks of fruit (moments of surprise), provide a thinner straw (extends the experience).

This is the foundational lesson: you do not compete against similar products. You compete against everything else the customer could hire to get the same job done.

Theodore Levitt said it first: "People don't want a quarter-inch drill. They want a quarter-inch hole." But JTBD goes further: they do not want the hole either. They want the shelf that goes in the hole. They want the books organized on the shelf. They want the feeling of having their life together. The job cascades upward from functional to emotional to social.

JTBD distinguishes three types of jobs:

Functional jobs: the practical task. "I need to deploy this application to production."
Emotional jobs: how the person wants to feel. "I want to feel confident that it won't break at 3 AM."
Social jobs: how the person wants to be perceived. "I want my team to see me as someone who ships reliable software."

All three matter. Most engineers instinctively focus on the functional job and ignore the emotional and social ones. This is a critical blind spot. People routinely pay more for solutions that address the emotional and social jobs, even when a cheaper solution handles the functional job adequately.

The Four Forces Model (Bob Moesta)¶

Every switch — every moment someone changes from one solution to another — is governed by four forces:

Push of the current situation: What is wrong right now? What pain, frustration, or limitation is the person experiencing with their current approach? This is the fuel. Without push, there is no motivation to change. Examples: "My deploy process is a mess of shell scripts I'm afraid to touch." "I've been studying for six months and still can't build a real project." "We lost a customer because of downtime."
Pull of the new solution: What is attractive about the alternative? What does the new thing promise? This is the magnet. Pull is aspiration, possibility, the imagined better future. Examples: "This tool promises zero-downtime deploys." "This course says I'll build a real project in 30 days." "Their landing page shows dashboards that look exactly like what I need."
Anxiety of the new solution: What scares the buyer about switching? This is the brake. Anxiety kills more deals than competitors do. Examples: "What if this tool is too complex for my team?" "What if the course is just another tutorial that doesn't stick?" "What if I pay and it doesn't work for my use case?" "Can I get a refund?"
Habit of the present: What keeps the buyer doing what they are currently doing, even though it is not great? This is inertia. Habits are powerful because they require zero cognitive effort. Examples: "I already know my janky shell scripts." "Free YouTube tutorials are good enough, probably." "Switching tools means retraining the whole team."

For a switch to happen, Push + Pull must exceed Anxiety + Habit. Your job as a product builder is to amplify push and pull while reducing anxiety and habit. This is not manipulation — it is alignment. You are helping someone who is already struggling to find the solution they are already looking for.

The Switch Interview¶

Moesta's Switch interview is a forensic reconstruction of a past purchase. You interview someone who recently bought something (your product or a competitor's) and walk backward through their timeline:

First thought: When did you first realize something needed to change? What happened?
Passive looking: When did you start casually noticing alternatives? What caught your eye?
Active looking: When did it become a project? What did you search for? Where did you look? Who did you talk to?
Deciding: What were your finalists? How did you choose? What almost stopped you?
Consuming: What happened after you bought? Was it what you expected?
Satisfied/Dissatisfied: Where are you now? Would you buy again?

The power of this interview is that it captures the real decision process — not a hypothetical one. You are asking people to remember what they actually did, not to predict what they would do. Memory is imperfect, but it is vastly more reliable than hypothetical intention.

Buyer Personas: Adele Revella's 5 Rings of Buying Insight¶

Revella's framework gives you five categories of insight to capture for every persona:

Priority Initiative — What triggered the search? Not "they need better DevOps" but "their CEO publicly committed to 99.99% uptime after a P1 incident, and now their job depends on delivering." The priority initiative is the specific event or situation that moved this person from passive to active.
Success Factors — What does the buyer want to achieve? Not features ("I want auto-scaling") but outcomes ("I want to sleep through the night without PagerDuty waking me up"). Success factors are the buyer's definition of winning.
Perceived Barriers — What could prevent them from buying? "My boss won't approve the budget." "I'm not sure this works with our legacy stack." "The last three tools we tried failed." Barriers are real or imagined obstacles, and both kinds matter equally because both kinds stop the sale.
Buyer's Journey — How do they evaluate and decide? Do they read blog posts? Watch demos? Ask on Twitter? Check G2 reviews? Talk to their network? The buyer's journey tells you where to show up and what format your content should take.
Decision Criteria — What factors do they weigh? Price? Ease of implementation? Vendor reputation? Community size? Integration with existing tools? Decision criteria tell you what to emphasize (and what to de-emphasize) in your positioning.

Levels of Awareness (Eugene Schwartz)¶

Schwartz identified five levels of customer awareness, and each level requires a fundamentally different approach:

Unaware: The person does not know they have a problem. They are not searching. They are not frustrated. They are blissfully ignorant — or the pain is so normalized they do not recognize it as pain. You cannot sell to this person directly. You must first educate them that a problem exists.
Problem-Aware: The person knows something is wrong but does not know solutions exist. "My deploys keep breaking but I thought that was just how it works." At this level, you lead with empathy for the problem. You name their pain in their language.
Solution-Aware: The person knows that solutions exist but has not found yours yet. "I know there are CI/CD tools but I haven't evaluated any." At this level, you lead with your approach — why your type of solution is the right one.
Product-Aware: The person knows about your specific product but has not bought yet. "I've seen your landing page but I'm not sure it's for me." At this level, you lead with differentiation, proof, and objection-handling.
Most Aware: The person knows your product, trusts it, and is ready to buy. They just need a reason to act now. At this level, you lead with an offer — a deal, a deadline, a bonus.

Why this matters for persona research: the same person can sit at different awareness levels depending on timing. Your persona model must account for where on this spectrum the person is, because it determines every word of your messaging.

Sales Safari (Amy Hoy)¶

Sales Safari is observational research for bootstrappers. The methodology:

Go where your potential customers already congregate. Reddit, Hacker News, Stack Overflow, niche forums, Facebook groups, Twitter threads, Amazon reviews of competing books/courses, app store reviews of competing tools, Quora answers, Discord servers, Slack communities.
Read. Do not post. Do not survey. Read. You are an anthropologist studying a tribe. Your job is to observe, not to interact.
Collect verbatim quotes. Copy-paste the exact words people use. Not your summary — their actual language. You are building a library of pain in the customer's own voice.
Look for patterns. What complaints come up over and over? What workarounds do people build? What do they spend money on (or refuse to spend money on)? What emotional language do they use? Where is the intensity highest?
Build personas from evidence, not imagination. Every claim in your persona should be traceable to a real quote from a real person in a real context. "I think our customers probably feel X" is fiction. "Here are 47 Reddit comments from people saying X in their own words" is evidence.

The cardinal rule of Sales Safari: Do not ask people what they want. Watch what they do. People are unreliable narrators of their own future behavior. They will tell you they would pay for something and then not pay. They will tell you they do not need something and then buy it. But their actual behavior — what they search for, complain about, spend time on, spend money on, build workarounds for — that tells you the truth.

The Lingo¶

A conversational glossary for the engineer entering this world.

ICP (Ideal Customer Profile): The firmographic and demographic description of your best-fit customer. In B2B, this is company size, industry, revenue, tech stack. In B2C, it might be income level, life stage, or job role. The ICP answers "what kind of company/person is this?" The persona answers "what is this person going through?"

Buyer persona vs. user persona: The buyer is the person who pays. The user is the person who uses. They are often different people. In B2B, the VP signs the contract but the engineer uses the tool. In B2C with family purchases, the parent pays but the child uses. Your messaging must speak to the buyer (who cares about ROI, risk, and justification) while your product must serve the user (who cares about usability, speed, and daily experience).

B2B vs. B2C buyer psychology: B2B purchases involve multiple stakeholders, longer timelines, higher stakes, and formal justification processes. The buyer must defend the purchase to others. B2C purchases are often faster, more emotional, and driven by individual desire. But do not be fooled: B2B buyers are still human. They still have emotions, fears, and ambitions. The difference is that B2B buyers must rationalize their emotional decision to a committee.

Decision-making unit (DMU): In B2B, rarely does one person make a purchase decision alone. The DMU includes the champion (the person who wants it and pushes for it internally), the economic buyer (the person who controls the budget), the technical buyer (the person who evaluates whether it actually works), and often influencers and end users. Understanding the DMU tells you who to persuade and about what.

Champion vs. economic buyer vs. technical buyer: The champion loves your product and will fight for it internally. Your job is to arm the champion with ammunition (case studies, ROI data, comparison sheets) to win the internal battle. The economic buyer cares about cost, risk, and return. The technical buyer cares about integration, security, and implementation effort.

Pain point vs. aspiration: Negative motivation ("I need to stop losing data") vs. positive motivation ("I want to build a world-class data platform"). Both are real. Pain is usually a stronger short-term motivator. Aspiration is usually a stronger long-term motivator. The best products address both.

"Vitamin vs. painkiller": A vitamin is nice to have. A painkiller is must-have. Investors and buyers both prefer painkillers. If your product is a vitamin, you have to work much harder to sell it. The question to ask: "If this product disappeared tomorrow, would the customer be in pain, or would they just be mildly inconvenienced?"

"Hair on fire" problem: The problem is so urgent, so painful, so immediate that the customer will buy almost anything that credibly solves it. They are not comparison-shopping. They are not reading reviews. They are desperate. Finding a hair-on-fire problem is the best possible starting point for a product.

Willingness to pay (WTP): How much someone would actually pay for your solution. You cannot reliably gauge this by asking "Would you pay $X?" (people say yes to be polite). Better methods: look at what they currently pay for alternatives, look at the value of the problem being solved (how much time/money they lose), and test with real pricing on real offers.

Price sensitivity / price elasticity: How much does demand change when price changes? Some buyers are extremely price-sensitive (students, bootstrapped founders). Others barely notice (enterprise with approved budgets). Your persona must capture this.

Switching cost: Everything the buyer must invest to change from their current solution to yours. Not just money — time, learning, migration effort, team retraining, social capital spent convincing colleagues. High switching costs create inertia even when your product is clearly better.

Status quo bias: People prefer the current state of affairs, even when an objectively better option exists. Changing feels risky. Staying feels safe. This is irrational but universal. Your persona research must account for the gravity of the status quo.

Loss aversion: Losing $20 hurts roughly twice as much as gaining $20 feels good (Kahneman & Tversky). This means framing matters enormously. "Stop losing 10 hours a week to manual deploys" is more motivating than "Save 10 hours a week with automated deploys." Same product, same benefit, different psychological impact.

Social proof: People buy what other people buy. Testimonials, case studies, customer counts, logos, reviews — all forms of social proof. The more uncertain the buyer, the more they rely on social proof.

Authority bias: People trust and buy from perceived experts. Certifications, publications, speaking engagements, credentials — all signal authority. In your persona research, note whether your buyer is more influenced by social proof ("10,000 companies use this") or by authority ("recommended by Kelsey Hightower").

Anchoring: The first number a buyer sees sets their expectation. If they see a competitor at $99/month first, your $49/month looks like a deal. If they see a free alternative first, your $49/month looks expensive. Anchoring is why pricing pages show the enterprise plan first.

Decoy effect: Adding a third option can make one of the other two look more attractive. A $10 basic plan and a $50 pro plan see low pro adoption. Add a $45 "standard" plan with fewer features than pro, and suddenly pro looks like a bargain. This is not deception — it is giving buyers a frame of reference for value.

Buyer's remorse: The regret that follows a purchase, especially a significant one. It is caused by post-decision anxiety: "Did I make the right choice?" Onboarding, quick wins, confirmation emails, and community access all reduce remorse. Your persona research should identify what would trigger remorse for each persona so you can prevent it.

"The struggle" (Moesta): The specific moment when someone becomes dissatisfied enough with their current situation to start looking for alternatives. This is the origin of every purchase. Understanding the struggle is understanding the genesis of demand.

"Firing moment": When someone actively abandons their current solution. "I uninstalled the app." "I cancelled the subscription." "I stopped using spreadsheets." This moment reveals what the old solution failed at — which tells you what the new solution must succeed at.

"Hiring criteria": What the new solution must do to get the job. These are not features — they are outcomes. "It must get me to production in under an hour." "It must not require my team to learn a new language."

Consideration set: The short list of options a buyer actively evaluates. Usually 2-4 products. Understanding what else is in your buyer's consideration set tells you who you are really competing against (it is often not who you think).

"Table stakes" vs. differentiators: Table stakes are what every product in the category must have. Differentiators are what make you stand out. In your persona's mind, table stakes are pass/fail (you either have them or you are eliminated). Differentiators are the tiebreakers.

Emotional vs. rational buying: Here is the inconvenient truth for engineers: almost every purchase decision is emotional first and rationalized second. People buy because they feel something — fear, desire, frustration, hope, belonging — and then they construct a logical justification. "I bought it because the ROI is 3x" is the rationalization. "I bought it because I was terrified of getting fired after the last outage" is the truth. Your persona must capture both the real emotional driver and the rational justification the buyer will use to defend the purchase to themselves and others.

The Process¶

How Persona Extraction Actually Works¶

This skill implements a specific process that synthesizes Sales Safari, JTBD, and the 5 Rings into a repeatable workflow.

Step 1: Define the Opportunity¶

Start with signal scan output. You have quantitative data: search volume, community size, spending patterns, competition density. The signal scan tells you there is demand. Persona extraction tells you who is demanding, why, and how they buy.

Ask: What signal are we exploring? What market or problem space? What is the initial hypothesis about who cares about this and why?

Step 2: Go Where They Are¶

Identify the watering holes. Where do the people with this problem spend time online?

Reddit: Subreddits related to the problem space. Sort by Top (All Time) and then by New to see both the biggest pain points and the emerging ones.
Forums and communities: Niche forums, Discord servers, Slack groups, Facebook groups. These are where the most committed and frustrated people congregate.
Review sites: G2, Capterra, Product Hunt, app store reviews — look at 2-star and 3-star reviews especially. 1-star reviews are rage. 5-star reviews are delight. 2-3 stars are where the nuance lives.
Q&A sites: Stack Overflow, Quora. Look at what people ask, how they ask it, and what answers get upvoted.
Social media: Twitter/X threads, LinkedIn posts. Search for the problem keywords and see who is complaining, celebrating, or asking questions.
Amazon reviews: For books and courses in the space. What did people love? What did they wish was covered? What did they find useless?

Do NOT start with surveys. Surveys ask people to articulate things they may not consciously understand about their own behavior. Start with observation. Surveys come later, once you know enough to ask good questions.

Step 3: Collect Pain Stories¶

Copy verbatim quotes. Real language. Real emotion. You are building an evidence base.

Look for: - "I wish..." statements: "I wish someone would just explain Kubernetes without assuming I know networking." Direct expressions of unmet need. - "I'm so frustrated..." statements: "I'm so frustrated that every tutorial assumes you're on a Mac." Emotional intensity signals important pain. - "Why can't someone just..." statements: "Why can't someone just make a CI/CD tool that doesn't require a PhD in YAML?" The clearest possible product opportunity. - Workarounds and duct-tape solutions: "I wrote a 500-line bash script to do what should be a one-click operation." Where people build workarounds, there is a product opportunity. - Excessive time spent: "I spent three weeks trying to get Terraform working with our setup." Time is the most expensive resource. Where people burn time, they will pay money. - Emotional intensity: Crying, anger, desperation, relief, triumph. The strength of the emotion correlates with willingness to pay. Nobody pays to solve a mild inconvenience. People pay to escape suffering.

Step 4: Collect Success Stories¶

Not everyone is stuck. Some people made it through. Find them and study what they did.

Look for: - "What finally clicked for me was..." — The insight or moment that unlocked progress. - Specific actions, not mindset shifts: "I stopped reading documentation and started breaking things in a sandbox" is actionable. "I just needed to believe in myself" is not. - The tools, resources, and people that helped: What did the successful people use? Who did they learn from? What was the bridge between stuck and unstuck?

Step 5: Identify Decision Points¶

Every journey from struggle to success has forks in the road. At each fork, some people go one way (and succeed) and others go another way (and stay stuck).

Map these decision points: - The triggering event: What started the search? A failed deploy? A performance review? A tweet that went viral? A competitor shipping faster? - The stuck behavior: What do the people who remain stuck do? Watch another tutorial? Read another blog post? Procrastinate? Blame the tooling? - The success behavior: What do the people who break through do? Build a project? Join a community? Hire a coach? Buy a course? - The product intervention: At this specific fork, what product could help the stuck person take the success path? What format, what content, what price point, what delivery mechanism?

Step 6: Cluster into Archetypes¶

Group the stories you have collected into 3-4 distinct personas. Not demographic groups — behavioral archetypes.

Each persona gets: - A name: Something memorable. "Overwhelmed Omar" or "Aspiring Alice" — names that encode the emotional state. - A situation: What is happening in their life/career right now? What pressures are they under? - An emotional state: What do they feel? Frustrated? Anxious? Ambitious? Desperate? - A job-to-be-done: What progress are they trying to make? Stated in their language, not yours. - Buying triggers: What specific events would cause them to search for and purchase a solution? - Objections: What would make them hesitate or say no? - Willingness to pay: Based on what they currently spend, what the problem costs them, and what alternatives exist. - Channels: Where do they spend time? Where would they encounter your product?

Step 7: Map Decision Points to Offers¶

For each fork in the road you identified, design a product intervention:

What format? The format must match the buyer's context. Someone panicking at 2 AM during an outage needs a concise reference guide, not a 40-hour video course. Someone commuting needs audio. Someone on their lunch break needs a 15-minute video.
What language? Use their exact words. Not "infrastructure as code best practices" but "how to stop being terrified of your Terraform files." The language from your pain stories IS your marketing copy.
What price? Anchor to what they already pay. If they subscribe to three $29/month SaaS tools, a $49 one-time purchase is easy. If they have never paid for learning content, even $9 feels expensive. Price is relative to the buyer's existing spending patterns.

The Four Forces in Practice¶

Let us make the Four Forces model concrete with an example from the developer education space.

Push (What is wrong now)¶

Tutorial hell: consuming content endlessly without building anything real
Imposter syndrome: feeling like a fraud who will be exposed at the next standup
Fear of being fired: the market is tight and skills gaps feel dangerous
Wasted time: "I've been studying for a year and I still can't build a production app"
Public failure: a deploy went wrong, a PR got torn apart, a demo crashed in front of stakeholders

Pull (What is attractive about the new solution)¶

"Finally understand production systems" — not just toy examples
Career advancement: promotions, raises, better job offers
Confidence: walking into a meeting and knowing you can deliver
Autonomy: not needing to ask senior engineers for help on basic things
Peer respect: being the person others come to for answers

Anxiety (What scares them about switching)¶

"Will this actually be different from the last five courses I bought?"
"Is this person actually qualified, or just a good marketer?"
"What if I'm too far behind for this to help?"
"Can I get a refund if it doesn't work?"
"What will my partner say if I spend $200 on another course?"
"What if I still can't build anything after finishing?"

Habit (What keeps them doing what they do)¶

"I'll just watch another YouTube video" — free content as a default
"I need to learn more before I can start building" — preparation as procrastination
"The documentation should be enough if I just read it more carefully"
"My company should be training me, I shouldn't have to pay for this myself"
Comfort of consumption vs. discomfort of creation

Using the Four Forces to Craft Offers¶

To make a switch happen, you must:

Amplify Push: Name the pain. "You've been in tutorial hell for months. You can build a to-do app but not a production system. That gap is not going to close by watching more videos." Make the buyer feel seen. Make the status quo feel intolerable.
Amplify Pull: Paint the after. "In 30 days, you'll have deployed a real application with CI/CD, monitoring, and auto-scaling. You'll understand every piece because you built it yourself." Make the destination vivid and specific.
Reduce Anxiety: Offer guarantees. Show social proof. Demonstrate credibility. "30-day money-back guarantee, no questions asked." "Here's what 500 engineers said after completing this." "Here's my background and why I'm qualified to teach this." Address every objection before it becomes a reason to close the tab.
Reduce Habit: Make the first step trivially easy. "Start with this free 15-minute module and see if it clicks." Lower the activation energy. If the current habit is "watch free YouTube," give them something free that is dramatically better than YouTube, so the habit of consuming free content actually leads them to you.

Common Mistakes¶

Building personas from imagination instead of evidence. The most common mistake. You sit in a room, brainstorm who your customer "probably" is, and write a fictional biography. This persona reflects your assumptions, not reality. Every claim in a persona must trace back to evidence: a quote, a behavior, a data point.

Treating demographics as personas. "Our persona is a 28-year-old male software engineer in San Francisco making $150K." This tells you nothing about motivation, decision-making, or willingness to pay. A 28-year-old in SF and a 45-year-old in Omaha can have the exact same job-to-be-done. Demographics are lazy proxies for motivation.

Interviewing only happy customers (survivorship bias). Your happiest customers will tell you why your product is great. They will not tell you why most people do not buy, or why some people buy and then churn. Talk to people who considered buying and did not. Talk to people who cancelled. Talk to people who chose a competitor. That is where the real insights live.

Asking "Would you buy X?" (hypothetical vs. actual behavior). People are terrible at predicting their own future behavior. They will say "yes, I'd pay $50 for that" and then never buy it. Instead, study past behavior: "Tell me about the last time you bought something to solve this problem. What was it? How much did you pay? What made you decide?"

Building for too broad an audience. "Our target market is developers." That is not a persona — that is a census category. Narrow down. Which developers? In what situation? Experiencing what specific struggle? The narrower your persona, the sharper your product, messaging, and positioning. You can broaden later. You cannot sharpen later.

Ignoring the emotional and social jobs. An engineer building a DevOps course might think the job is "learn Kubernetes." But the emotional job might be "stop feeling like a fraud" and the social job might be "earn respect from senior engineers." If you address only the functional job, you are competing on features. If you address the emotional and social jobs, you are competing on transformation — and people pay more for transformation.

Not updating personas as the market changes. Personas are not permanent. Markets evolve. New competitors emerge. Customer needs shift. The persona you built 18 months ago may no longer reflect reality. Revisit and refresh your personas regularly, especially when you see changes in buying patterns, churn reasons, or competitive landscape.

Case Studies¶

The Milkshake Study (Bob Moesta / Clayton Christensen)¶

A fast-food chain hired Christensen's team to help sell more milkshakes. Traditional market research (surveys, focus groups) asked customers what would improve the milkshake. They got useless answers: "Make it chocolatier," "Make it cheaper." The team shifted to observation. They stood in the restaurant and watched. They discovered that 40% of milkshakes were bought before 8 AM by solo commuters who took them to their cars and drove away. Through Switch interviews, they learned the milkshake was "hired" for the job of making a long, boring commute interesting and keeping the buyer full until lunch. The milkshake was competing against bagels (too crumbly), bananas (gone in two bites), and donuts (sugar crash by 10 AM). Armed with this insight, the chain made the milkshake thicker (lasts longer), added fruit chunks (moments of textural surprise), and moved the dispenser in front of the counter (faster for commuters in a hurry). Sales increased. The lesson: understand the job, not the product category.

Sales Safari and Freckle Time Tracking (Amy Hoy)¶

Amy Hoy developed Sales Safari by practicing it herself. She spent months reading forums, blogs, and comments where freelancers and small agency owners talked about their work. She discovered a recurring pain: time tracking was universally hated. Not because the tools were bad (there were dozens) but because the tools were designed for managers who wanted to monitor employees, not for freelancers who wanted to invoice clients and understand their own profitability. The emotional job was not "track time" — it was "feel in control of my business." The anxiety was not about the tool — it was about confronting how much time was being wasted. Hoy built Freckle (later Noko) specifically for this persona: a freelancer or small team lead who needed time tracking to be painless, guilt-free, and oriented toward billing. She used the exact language she had collected from her research in her marketing. The product grew to significant revenue without venture funding. The lesson: observe before you build, and use their words, not yours.

Basecamp and the Struggling Small Business¶

Basecamp (originally 37signals) built their project management tool for a specific persona: the owner or manager of a small business or small team who was drowning in email, spreadsheets, and missed deadlines. Not enterprise. Not startups chasing hypergrowth. Small, stable, profitable businesses run by people who wanted simplicity, not power. Jason Fried and David Heinemeier Hansson explicitly rejected feature complexity, integration ecosystems, and enterprise sales. They priced simply, communicated simply, and built simply — because their persona valued simplicity above all else. Every feature request that would complicate the product was evaluated against the question: "Would this make our persona's life simpler or more complicated?" Basecamp reached hundreds of millions in revenue serving this persona while competitors chased the enterprise market. The lesson: a deeply understood persona creates product discipline.

Notion and the Productivity Enthusiast¶

Notion grew by understanding a persona that no one else was specifically serving: the productivity enthusiast. This is a person who genuinely enjoys organizing information, building systems, and optimizing workflows. They are not looking for "just a notes app" — they want a canvas for building their personal operating system. The emotional job: feel like a systems thinker. The social job: share impressive setups with peers (the rise of "Notion templates" as a secondary economy). Notion leaned into this persona with a flexible, block-based architecture that rewarded tinkering and customization. Their community strategy — template sharing, YouTube creators showing their setups, Twitter threads about workflows — was perfectly calibrated for a persona that derives satisfaction from building and showing systems. The lesson: understand not just what the persona needs but what the persona enjoys, and design for the joy.

The Methodology¶

The Signal-to-Story Pipeline¶

This persona-extract skill implements a named methodology: The Signal-to-Story Pipeline. It is a synthesis of the best frameworks in the field, adapted for async and observational research (because most of us cannot conduct 50 live interviews before building something).

What It Is¶

The Signal-to-Story Pipeline transforms quantitative market signals (search volume, spend data, community size, competition density) into narrative-rich buyer personas grounded in evidence.

Input¶

Signal scan data. Numbers that indicate demand exists: people are searching, spending, complaining, building workarounds. The signal scan answers: "Is there a market here?" The Signal-to-Story Pipeline answers: "Who is in that market, what do they want, and how will they buy?"

Method¶

The method fuses three traditions:

Sales Safari (Amy Hoy) for evidence collection. Go where the customers are. Read, do not ask. Collect verbatim quotes. Mine for pain language, emotional triggers, workarounds, and spending patterns. This gives you the raw material — the stories.
Switch Analysis (Bob Moesta) for decision modeling. Apply the Four Forces framework to every story you collect. What pushed them? What pulled them? What made them anxious? What held them back? Map the timeline from first thought through deciding through consuming. This gives you the decision architecture.
5 Rings of Buying Insight (Adele Revella) for structured capture. For each emerging persona, fill in: Priority Initiative, Success Factors, Perceived Barriers, Buyer's Journey, and Decision Criteria. This gives you the actionable intelligence.

Layered on top: Schwartz's Awareness Levels to segment each persona by where they are in their journey from unaware to ready-to-buy, so your messaging meets them where they are.

Output¶

For each persona archetype, the Signal-to-Story Pipeline produces:

Identity: Name, situation, emotional state, core job-to-be-done
Four Forces analysis: Push, pull, anxiety, habit — with verbatim evidence for each
5 Rings profile: Priority initiative, success factors, perceived barriers, buyer's journey, decision criteria
Awareness level: Where they sit on the Schwartz scale
Decision point map: The forks in their journey, what the stuck behavior is, what the success behavior is, and where a product can intervene
Offer hooks: Format, language, price anchors, objection pre-emption, and channel strategy — all derived from evidence, not assumption

Credit¶

The Signal-to-Story Pipeline stands on the work of: - Bob Moesta: Four Forces model, Switch interview, demand-side sales theory - Amy Hoy: Sales Safari observational research methodology - Adele Revella: 5 Rings of Buying Insight - Eugene Schwartz: Levels of Awareness - Clayton Christensen: Jobs to Be Done theory - Daniel Kahneman & Amos Tversky: Prospect theory, loss aversion, System 1/System 2

It is not a replacement for any of these frameworks. It is a pipeline that sequences them: signals in, stories out, structured for action.

Summary¶

Persona research is not a soft skill. It is an engineering discipline applied to human behavior. You are reverse-engineering a decision process — one that is messier than code, more irrational than algorithms, and more consequential than architecture.

The engineer who learns to think this way — to see the struggling human behind every search query, every forum post, every abandoned cart — gains an unfair advantage. Not because they build better software (they might) but because they build the right software, for the right person, at the right time, with the right words.

The Signal-to-Story Pipeline gives you a repeatable process for doing this. Start with signals. Go to where the humans are. Listen to their stories. Model their decisions. Cluster them into archetypes. Map their decision points to offers.

Then build.

👤 persona-extract¶

Install¶

Security Scan¶

File Info¶

Skill Prompt¶

Persona Extract¶

Step 0: Load Conventions¶

Pipeline Position¶

When to Use¶

Trigger Phrases¶

Prerequisites¶

Input¶

Workflow¶

Phase 1: Opportunity Definition¶

Phase 2: Evidence Collection¶

Collection Rules¶

Phase 3: Pain Story Collection¶

Pain Story Rules¶

Phase 4: Success Story Collection¶

Success Story Rules¶

Phase 5: Decision Point Mapping¶

Decision Point Rules¶

Phase 6: Four Forces Analysis¶

Four Forces Rules¶

Phase 7: Persona Clustering¶

Clustering Rules¶

Phase 8: Offer Mapping¶

Phase 9: Next-Step Hint Generation¶

Output¶

Vault Output¶

1. JSON: persona-extract-[domain-slug]-[date].json¶

2. Markdown Summary¶

Resources¶

references/¶

README.md¶

Quality Checklist¶

README¶

Persona Extract¶

A Ground-Up Masterclass in Customer Persona Research, Buyer Psychology, and Jobs to Be Done¶

Table of Contents¶

The Discipline¶

What IS Persona Research?¶

Why Engineers Skip This (And Why It Kills Their Products)¶

The Canon¶

The Thinkers You Must Know¶

Frameworks¶

Jobs to Be Done (JTBD) — The Core Framework¶

The Four Forces Model (Bob Moesta)¶

The Switch Interview¶

Buyer Personas: Adele Revella's 5 Rings of Buying Insight¶

Levels of Awareness (Eugene Schwartz)¶

Sales Safari (Amy Hoy)¶

The Lingo¶

The Process¶

How Persona Extraction Actually Works¶

Step 1: Define the Opportunity¶

Step 2: Go Where They Are¶

Step 3: Collect Pain Stories¶

Step 4: Collect Success Stories¶

Step 5: Identify Decision Points¶

Step 6: Cluster into Archetypes¶

Step 7: Map Decision Points to Offers¶

The Four Forces in Practice¶

Push (What is wrong now)¶

Pull (What is attractive about the new solution)¶

Anxiety (What scares them about switching)¶

Habit (What keeps them doing what they do)¶

Using the Four Forces to Craft Offers¶

Common Mistakes¶

Case Studies¶

The Milkshake Study (Bob Moesta / Clayton Christensen)¶

Sales Safari and Freckle Time Tracking (Amy Hoy)¶

Basecamp and the Struggling Small Business¶

Notion and the Productivity Enthusiast¶

The Methodology¶

The Signal-to-Story Pipeline¶

What It Is¶

Input¶

Method¶

Output¶

1. JSON: `persona-extract-[domain-slug]-[date].json`¶