/product-analysis

Evidence-Based Persona Construction Framework

The Problem

Personas often become fictional ideals rather than market realities.

The Empathy Leap: Teams "put themselves in the user's shoes" without evidence, producing personas that feel true to the team but don't exist in the market.

The Demographic Trap: Personas built around age, income, and job title—easy to research, useless for prediction. "35-45 year old marketing managers" tells you nothing about what they'll buy.

The User-Buyer Conflation: Personas for users without connection to purchasing authority. Building for people who can't buy means building for people who can't become customers.

The Persona Museum: Personas created once and treated as permanent artifacts, even as markets evolve and evidence contradicts them.

The consequences:

1. Products built for imaginary segments that don't exist in sufficient numbers
2. Marketing that resonates with personas but not actual prospects
3. Features prioritized for users who don't control purchasing decisions
4. Strategies based on assumptions rather than market reality

The only valid persona is one grounded in evidence—observable behaviors, documented needs, verified purchasing patterns.

Core Principles

1. Evidence Before Empathy

Observable behaviors, stated problems, and documented frustrations precede imaginative empathy exercises. The persona emerges from data, not design.

Evidence hierarchy:

1. Observed behavior (what they actually do)
2. Stated problems (what they say is broken)
3. Stated preferences (what they say they want)
4. Demographic patterns (who they are)

Empathy is valuable for understanding why behaviors occur—but only after you've established what behaviors occur.

2. Purchasing Authority is Primary

A persona without connection to budget and buying power is a user sketch, not a business-relevant segment.

Always trace to: Who pays?

For B2B: Decision-maker, Influencer, Budget-holder, and User are often different people. Personas must account for the full buying unit.

For B2C: Even individual consumers have budget constraints and decision authority patterns.

3. Behaviors Over Demographics

What people do matters more than who they are.

Behavioral signatures beat demographics:

• "Checks price three times before buying" > "35-45, suburban, two kids"
• "Evaluates 5+ options before deciding" > "Director-level, $150k salary"
• "Abandons cart when shipping appears" > "Urban millennial, college-educated"

Demographics may correlate with behaviors but don't cause them. Build personas around behaviors.

4. Personas are Hypotheses

Each persona is a testable claim about a market segment. They evolve as evidence confirms or refutes them.

Treat personas like scientific hypotheses:

• State the claim clearly
• Identify what evidence would confirm or refute
• Update confidence as evidence accumulates
• Retire personas when evidence contradicts

5. Overlap is Information

When personas blend, that reveals market structure. Edge cases and hybrid personas expose real complexity—don't force artificial separation.

Overlap patterns:

• High overlap = possibly one persona, not two
• Partial overlap = segment within segment
• Edge cases = potential emerging segment

Key Vocabulary

Diagnostic States

State PC0: No Evidence Base

Symptoms:

• Personas described as "we think" or "probably"
• No actual user quotes or data supporting claims
• Personas created in brainstorming sessions without research
• Can't point to specific real people who match persona
• Confidence language absent ("these users definitely...")

Key Questions:

• What evidence sources have you consulted?
• Can you quote a real person expressing this need?
• Can you name 5 real people who fit this persona?
• What would change your mind about this persona?

Interventions:

• Conduct evidence census: list all available evidence sources
• Review mining: extract behavioral patterns from competitor reviews
• Forum archaeology: find where users discuss problems in this category
• Interview existing customers (if available)

Risk: Building for personas that don't exist. All strategic decisions built on sand.

State PC1: Demographic-Only Personas

Symptoms:

• Personas defined primarily by age, income, location, job title
• No behavioral patterns documented
• "35-45 year old marketing managers" without what they do
• Can't predict how persona would evaluate your product
• Demographic research substituted for behavioral research

Key Questions:

• What does this persona actually DO when faced with the problem?
• What behaviors distinguish them from others with same demographics?
• If you removed all demographics, could you still identify them by behavior?
• How would they evaluate your product? What steps would they take?

Interventions:

• Behavioral signature extraction: list observable actions, not traits
• Decision journey mapping: how do they evaluate and choose?
• Problem behavior inventory: what do they do when the problem occurs?
• Replace every demographic statement with a behavioral statement

Risk: Marketing to people who look right but don't have the problem you solve.

State PC2: User Personas Without Purchase Authority

Symptoms:

• Personas describe users but not buyers
• No connection to budget or purchasing power
• Can't answer "who pays for this?"
• Enterprise personas don't map to organizational structure
• "Influence without authority" not accounted for

Key Questions:

• Who makes the purchasing decision for this persona?
• Who influences the purchasing decision?
• Who controls the budget?
• Who actually uses the product daily?
• Is the user the buyer? If not, how do they connect?

Interventions:

• Purchase authority mapping: decision-maker, influencer, budget-holder, user
• Buying unit analysis: who's in the room when decisions are made?
• Segment by purchasing authority, not just usage patterns
• For B2B: map personas to org chart roles, not just job functions

Risk: Building for users who love the product but can't buy it.

State PC3: Static Personas Without Evidence Grounding

Symptoms:

• Personas haven't changed since initial creation
• No mechanism for updating with new evidence
• Contradictory evidence ignored or rationalized
• "That's not our target user" dismissal without investigation
• Creation date unknown; no version history

Key Questions:

• What evidence would change this persona?
• What contradictory evidence have you encountered?
• When was this persona last reviewed?
• What's different about the market since creation?

Interventions:

• Evidence annotation: link every persona claim to specific sources
• Contradiction log: track evidence that doesn't fit
• Confidence leveling: assign P1/P2/P3/P4 to each persona
• Scheduled persona review: quarterly minimum

Risk: Strategy based on outdated understanding of market.

State PC4: Overlap Confusion

Symptoms:

• Users seem to fit multiple personas
• Edge cases don't belong anywhere
• Personas are mutually exclusive by fiat, not evidence
• Real users don't match any persona cleanly
• Frequent debates about which persona a user belongs to

Key Questions:

• Where do your personas overlap?
• What distinguishes the overlapping segments?
• Are "edge cases" actually a distinct segment?
• Are some personas actually one segment described two ways?

Interventions:

• Venn mapping: visualize persona overlaps explicitly
• Edge case documentation: catalog who doesn't fit and why
• Hybrid persona consideration: is the overlap itself a segment?
• Boundary clarification: what behaviors distinguish adjacent personas?

Risk: Missing segments that don't fit the predetermined framework.

State PC5: Validated Persona Set

Symptoms:

• Each persona grounded in specific, cited evidence
• Purchase authority documented and mapped
• Behavioral signatures are clear and distinguishing
• Confidence levels assigned and reviewed
• Update mechanism in place and used

Indicators:

• Can quote specific evidence for each persona claim
• Know exactly who pays vs. who uses for each persona
• Can predict how each persona would evaluate product
• Contradictions documented and addressed
• Version history shows evolution

Next Step: Use personas in Feature-Persona-Use Case Mapping Framework

Process

Phase 1: Evidence Census

Input: Product category definition, competitor list Output: Evidence source inventory with coverage assessment

Steps:

1. Inventory all evidence sources:

2. Assess coverage:

   • Which user types appear frequently in evidence?
   • Which problems are mentioned most often?
   • What vocabulary do users actually use?
   • Where are evidence gaps?

3. Document limitations:

   • Survivorship bias (only users who stayed/reviewed)
   • Selection bias (who writes reviews?)
   • Recency bias (recent changes may not be reflected)

Output template: See Evidence Census Template

Phase 2: Behavioral Pattern Extraction

Input: Evidence census, sample of evidence sources Output: Behavioral signature candidates with frequency data

Steps:

1. Code evidence for behavioral patterns:

   • What do users actually DO (not who they ARE)?
   • What triggers action? What situation prompts hiring a solution?
   • What prevents action? What makes them not buy or churn?
   • How do they evaluate options? What matters to them?

2. Cluster behaviors:

   • Which behaviors appear together frequently?
   • Which behaviors are mutually exclusive?
   • Which behaviors cross demographic lines?

3. Quantify where possible:

   • How often does each pattern appear?
   • In which sources is it strongest?
   • How confident are we?

Behavioral signature format:

## Behavioral Signature: [Name]

**Core behavior**: [What they do]
**Trigger**: [What prompts this behavior]
**Evidence count**: [N instances across sources]
**Example quotes**:
- "[Quote]" - [Source]
- "[Quote]" - [Source]

Phase 3: Purchase Authority Mapping

Input: Behavioral patterns, evidence of purchase decisions Output: Purchase authority map per behavioral segment

Steps:

1. For each behavioral segment, identify:

2. Map authority relationships:

   • Is the user the buyer? (B2C often yes, B2B often no)
   • Who initiates the search for solutions?
   • What's the approval process?
   • How long is the decision cycle?

3. Segment by purchasing context:

   • Same behavior, different purchase authority = different segment
   • Individual contributor vs. manager = different buying process

Output template: See Persona Card Template (Purchase Authority section)

Phase 4: Persona Synthesis

Input: Behavioral signatures, purchase authority maps, evidence citations Output: Persona cards with confidence levels

Steps:

1. Combine patterns into proto-personas:

   • Group related behavioral signatures
   • Add purchase authority context
   • Assign preliminary confidence level

2. Validate completeness:

   • Does persona answer: What do they do? Why? What do they need? Who pays?
   • Are behavioral signatures specific enough to distinguish?
   • Is purchase authority clear?

3. Document evidence anchors:

   • Link every claim to specific evidence
   • Note where evidence is thin

4. Identify overlaps and edges:

   • Where do personas blur together?
   • What cases don't fit?

Output template: See Persona Card Template

Phase 5: Validation and Iteration

Input: Proto-personas, additional evidence Output: Validated persona set with confidence levels

Steps:

1. Test personas against new evidence:

   • Does new evidence confirm or contradict?
   • Do real users match predicted behaviors?

2. Interview validation (if possible):

   • Present persona to users: "Does this describe you?"
   • Test behavioral predictions: "How would you evaluate...?"

3. Contradiction resolution:

   • When evidence contradicts, which is stronger?
   • Update or split persona as needed

4. Confidence level updates:

   • P1 → P2: First confirming evidence
   • P2 → P3: Multiple sources confirm
   • P3 → P4: Quantified and predictive

Confidence Level Definitions:

Anti-Patterns

1. The Empathy Leap

Pattern: Skipping evidence to "put yourself in the user's shoes" based on imagination.

Signs:

• Persona workshops without prior research
• "We think users feel..." without quotes
• Detailed emotional journeys with no cited sources
• Team consensus treated as validation

Why it fails: Your shoes aren't their shoes. Empathy without evidence produces personas that feel true to the team but don't exist in the market. Teams tend to imagine users who are just like them.

The test: Can you cite specific evidence for every persona claim?

Fix: Every persona claim needs an evidence anchor. "Users feel frustrated" becomes "In 47 reviews, users explicitly mentioned frustration with [specific issue]."

2. The Demographic Trap

Pattern: Building personas primarily around demographics because they're easy to research.

Signs:

• Personas lead with age, income, job title
• Behaviors missing or generic
• Could describe these demographics for any product
• No prediction of how persona would evaluate your specific product

Why it fails: Demographics don't predict behavior. Two 35-year-old marketing managers may have opposite needs, while a 25-year-old and 55-year-old may behave identically.

The test: If you removed all demographics, could you still distinguish this persona by behavior?

Fix: Lead with behavioral signatures. Demographics can be secondary context, never primary definition.

3. The User-Buyer Conflation

Pattern: Assuming the user is the buyer, or ignoring purchase authority entirely.

Signs:

• B2B personas without org chart context
• Can't answer "who pays?"
• Features designed for users who can't purchase
• No influencer/decision-maker distinction

Why it fails: Building for users who can't buy means building for people who can't become customers. Especially fatal in B2B where user and buyer are often different.

The test: For each persona, can you name who makes the purchasing decision?

Fix: Purchase authority map is required, not optional. Every persona needs: who decides, who pays, who uses.

4. The Persona Museum

Pattern: Creating personas once and treating them as fixed artifacts.

Signs:

• Personas created years ago, never updated
• "That's not our target user" dismissals
• No mechanism for incorporating new evidence
• Contradictory evidence ignored

Why it fails: Markets evolve. New evidence emerges. Personas that don't update become increasingly fictional.

The test: When were these personas last reviewed? What evidence would change them?

Fix: Assign confidence levels. Track contradictions. Schedule reviews. Personas are living hypotheses, not museum pieces.

5. The Edge Case Dismissal

Pattern: Ignoring users who don't fit neatly into personas with "that's not our target."

Signs:

• "Edge cases" excluded without investigation
• Users who don't fit blamed for not fitting
• Rigid persona boundaries by fiat
• Possible segments dismissed as noise

Why it fails: Edge cases reveal market structure. Today's edge case may be tomorrow's core segment. Dismissal prevents learning.

The test: How many real users don't fit any persona? What do they have in common?

Fix: Document edge cases explicitly. Analyze why they don't fit. Look for patterns among the misfits.

Boundaries

Assumes

Not For

Degrades When

Complementary To

Worked Example: Developer Tools

Phase 1: Evidence Census

Category: Developer productivity tools (IDEs, code editors, dev environments)

Evidence sources identified:

Evidence gaps: Junior developers underrepresented; enterprise constraints understated.

Phase 2: Behavioral Pattern Extraction

Behavioral Signature 1: The Keyboard Optimizer

Core behavior: Obsessively customizes keybindings, creates macros, tracks keystrokes Trigger: Any friction in common workflow Evidence count: 150+ Reddit threads on keybinding customization Example quotes:

• "I remapped every key to avoid reaching for the mouse" - r/vim
• "Spent 3 hours optimizing my config to save 10 seconds daily" - HN

Behavioral Signature 2: The Just-Works User

Core behavior: Accepts defaults, avoids configuration, switches tools when current one breaks Trigger: Tool stops working; coworker recommends alternative Evidence count: Common pattern in G2 reviews ("easy setup" praise) Example quotes:

• "I don't have time to learn another config format" - Reddit
• "Switched to X because it worked out of the box" - G2 review

Behavioral Signature 3: The Team Standardizer

Core behavior: Evaluates tools for team adoption, prioritizes consistency over individual preference Trigger: New team member onboarding friction; inconsistent environments causing bugs Evidence count: Enterprise review pattern on G2 Example quotes:

• "We needed everyone on the same environment" - G2 review
• "Individual tool choice was causing integration issues" - HN

Phase 3: Purchase Authority Mapping

Phase 4: Persona Synthesis

Persona: The Craft Developer (maps to Keyboard Optimizer)

Confidence Level: P3 (Validated)

Behavioral Signature:

• Customizes every tool extensively before productive use
• Values efficiency measured in keystrokes/seconds
• Active in online communities sharing configs
• Tries new tools frequently, switches if compelling
• Individual purchasing (personal license)

Pain Density:

Purchase Authority: Self. Buys personal licenses, influences team adoption through evangelism.

Evidence Anchors:

• "My .vimrc is 500 lines and I know every one" - r/vim
• "I evaluate tools by extensibility first, features second" - HN

Persona: The Productive Pragmatist (maps to Just-Works User)

Confidence Level: P3 (Validated)

Behavioral Signature:

• Accepts defaults, minimal customization
• Values "just working" over optimization
• Switches tools when friction exceeds threshold
• Influenced by peer recommendations
• Cares about time-to-productivity, not long-term efficiency

Pain Density:

Purchase Authority: Self for free tools; manager approval for paid.

Evidence Anchors:

• "I just want to write code, not configure tools" - Reddit
• "Switched because it worked on first try" - G2

Persona: The Platform Coordinator (maps to Team Standardizer)

Confidence Level: P2 (Emerging)

Behavioral Signature:

• Evaluates for team adoption, not personal preference
• Prioritizes consistency, onboarding, compliance
• Long evaluation cycles, committee decisions
• Manages tool transitions across team
• Cares about support, documentation, enterprise features

Pain Density:

Purchase Authority: Engineering manager/VP. Budget from engineering or IT.

Evidence Anchors:

• "We standardized on X to reduce environment issues" - G2
• "SSO and audit logs were requirements" - G2 enterprise review

Success Indicators

Leading Indicators

Lagging Indicators

Evolution

Review Triggers

• Time: Quarterly minimum
• Market shift: Competitor pivot, new entrant, technology change
• Evidence contradiction: Multiple sources contradict persona
• Conversion anomaly: Unexpected segment behavior
• Product launch: New features may attract different personas

Changelog