Behavioral Analytics Reference

Metrics frameworks

AARRR (Pirate Metrics)

A funnel-shaped framework for tracking the full customer lifecycle:

Stage	Question	Example metrics
Acquisition	How do users find us?	Signups by channel, landing page conversion
Activation	Do they have a good first experience?	Completed onboarding, first key action
Retention	Do they come back?	DAU/MAU, Day 7/30 retention, cohort curves
Revenue	Do they pay?	Conversion to paid, ARPU, expansion revenue
Referral	Do they tell others?	Invite rate, viral coefficient, NPS

Use AARRR to identify which stage has the biggest drop-off. Fix that stage first.

North Star Metric

A single metric that best captures the core value your product delivers to customers.

Criteria for a good North Star:

1. Reflects customer value - Not revenue or vanity (page views)
2. Leading indicator - Predicts future business outcomes
3. Actionable - Teams can influence it through product changes
4. Measurable - Can be tracked reliably with existing instrumentation

Examples:

• Slack: messages sent per organization per week
• Airbnb: nights booked
• Spotify: time spent listening
• Notion: active team blocks created

Input metrics

Break the North Star into 3-5 input metrics that drive it:

North Star: Weekly active projects (for a project management tool)

Input metrics:
  1. New projects created per week (creation)
  2. Collaborators added per project (collaboration)
  3. Tasks completed per project per week (engagement depth)
  4. Return rate of project owners within 7 days (retention)

Each input metric should be owned by a specific team and have a target.

Activation analysis

Defining the activation event

The activation event is the action that signals a user has experienced the core value of your product. It is the strongest early predictor of long-term retention.

Finding it:

1. List all actions a user can take in the first 7 days
2. For each action, calculate Day 30 retention rate for users who did vs. did not perform it
3. The action with the highest retention lift is your activation event
4. Validate: does it make intuitive sense? Does it reflect real value delivery?

Activation funnel

Map every step from signup to activation event. Measure drop-off at each step:

Step 1: Sign up                    100%
Step 2: Verify email                85%  (-15%)
Step 3: Complete profile setup      62%  (-23%)  <-- biggest drop-off
Step 4: Create first [object]       48%  (-14%)
Step 5: Invite a teammate           31%  (-17%)
Step 6: Complete first workflow     24%  (-7%)   = activation

Fix the step with the biggest absolute drop-off first (Step 3 in this example).

Time-to-activate

Track the median time from signup to activation. Shorter is better. Benchmark against your own historical data. If time-to-activate is increasing, onboarding is getting worse even if total activation rate holds steady.

Retention analysis

Retention curve types

N-day retention - What % of users who signed up on Day 0 are active on Day N?

• Day 1 retention: immediate engagement signal
• Day 7 retention: habit formation signal
• Day 30 retention: product-market fit signal

Unbounded retention (rolling) - What % of users who signed up on Day 0 were active at any point during the Day N-to-Day N+7 window? More forgiving than N-day; better for products with irregular usage patterns.

Bracket retention - What % of users are active in Week 1, Week 2, Week 3, etc.? Groups time into buckets. Good for weekly-use products.

Reading retention curves

A healthy retention curve flattens over time (asymptote). An unhealthy curve continues to decline toward zero.

Healthy:    100% -> 40% -> 28% -> 22% -> 20% -> 19% -> 19%  (flattens at ~19%)
Unhealthy:  100% -> 30% -> 15% -> 8%  -> 4%  -> 2%  -> 1%   (never flattens)
Improving:  Newer cohorts flatten at a higher % than older cohorts

If the curve never flattens, you have a retention problem that no amount of acquisition can fix. Focus on product-market fit before scaling acquisition.

Cohort analysis

Always analyze retention by cohort (the week or month users signed up). This reveals whether the product is getting better or worse over time.

Structure a cohort table:

              Week 0   Week 1   Week 2   Week 3   Week 4
Jan cohort     100%     35%      22%      18%      16%
Feb cohort     100%     38%      25%      20%      --
Mar cohort     100%     42%      28%      --       --
Apr cohort     100%     45%      --       --       --

Read diagonals for "what happened this week across all cohorts?" (useful for detecting the impact of a release or outage). Read rows for "how does this cohort age?" (useful for comparing cohort quality over time).

Funnel analysis

Designing a funnel

1. Define the goal - What is the desired end action? (e.g., completed purchase, activated account, submitted form)
2. Map the steps - List every required step in order from entry to goal
3. Set the conversion window - How long does a user have to complete the funnel? (e.g., within one session, within 7 days)
4. Choose strict vs. loose - Strict: steps must happen in exact order. Loose: steps can happen in any order. Strict is more accurate for linear flows.

Funnel metrics

Metric	Definition	Why it matters
Step conversion rate	% who complete step N given they completed step N-1	Identifies the weakest step
Overall conversion rate	% who complete the final step given they entered step 1	Top-line funnel health
Drop-off rate	1 - step conversion rate	Where users abandon
Time between steps	Median time from step N to step N+1	Identifies friction or confusion
Funnel velocity	Median time from entry to completion	Overall flow efficiency

Diagnosing drop-off

When a step has high drop-off:

1. Segment - Is drop-off universal or concentrated in a specific segment?
2. Session replay - Watch recordings of users who dropped off at that step
3. Exit survey - Trigger a one-question survey when users abandon
4. Hypothesis - Form 2-3 hypotheses for why users drop off
5. Qualitative validation - Run 3-5 interviews with users who dropped off
6. Experiment - A/B test the top hypothesis

Feature adoption analysis

Measuring adoption

Metric	Formula	Use
Adoption rate	Users who used feature / Total active users	Overall penetration
Adoption breadth	Features used per user per period	Engagement depth
Time to first use	Median days from signup to first feature use	Discovery speed
Sticky feature ratio	Users who use feature in 2+ of last 4 weeks / Users who ever used it	Habit strength

Feature-retention correlation

For each feature, calculate:

1. Day 30 retention for users who adopted the feature
2. Day 30 retention for users who did not adopt the feature
3. Retention lift = (1) - (2)

Rank features by retention lift. The features with the highest lift are your product's core value drivers - protect them and promote adoption.

Caution: Correlation is not causation. Power users adopt more features AND retain better, but forcing feature adoption may not cause retention. Validate with qualitative research before building "feature nudge" campaigns.

Tool-agnostic implementation

Event taxonomy

Define a consistent naming convention for all tracked events:

Format: [Object]_[Action]

Examples:
  project_created
  project_viewed
  task_completed
  invite_sent
  report_exported
  subscription_upgraded

Rules:

• Use snake_case consistently
• Object first, then action (past tense)
• Include properties as structured key-value pairs, not in the event name
• Document every event in a tracking plan spreadsheet before implementation

Essential event properties

Every event should carry:

• user_id - Unique identifier for the user
• timestamp - ISO 8601 format
• session_id - Groups events within a session
• platform - web, ios, android, api
• plan_tier - For segmented analysis

Feature-specific events add:

• object_id - The entity being acted on
• source - Where the user came from (navigation path, notification, search)
• duration_ms - For time-based interactions

Data quality checklist

• All critical funnel events are instrumented and firing
• Event properties match the tracking plan schema
• No duplicate events (check for double-firing on page load)
• User identity is resolved across devices (if applicable)
• Historical data backfill covers at least 90 days before analysis
• Bot / test traffic is filtered from production data

Interview Protocol Reference

Interview types

Type	Duration	Best for	Sample size
Semi-structured	45-60 min	Exploratory research, understanding workflows	8-12 participants
Structured	30 min	Consistent data across many participants	15-20 participants
Contextual inquiry	60-90 min	Observing real behavior in natural environment	5-8 participants
Diary study + debrief	1-2 weeks + 30 min	Longitudinal behavior, habits, pain points	10-15 participants

Semi-structured is the default choice for most product research. Use structured only when you need quantifiable comparisons across a larger sample.

Recruiting

Screener design

A screener filters applicants to ensure you interview the right people. Structure:

1. Disqualifying questions first - Eliminate non-targets early to respect their time
2. Behavioral questions over self-reported - "How many times did you [action] last month?" is better than "Are you a frequent user?"
3. Include a trick question - Add one question where only one answer is correct to catch professional survey-takers
4. Quota tracking - Define how many of each segment you need before recruiting starts

Screener template

1. What is your role? [Single-select: target roles + "Other"]
   -> Disqualify: "Other"

2. How often do you use [product/category] in a typical week?
   [Never / 1-2 times / 3-5 times / Daily / Multiple times daily]
   -> Disqualify: "Never" (unless studying non-adopters)

3. Which of these tools do you currently use? [Multi-select]
   -> Include 2-3 fake tool names to catch inattentive respondents

4. When was the last time you [key behavior]?
   [This week / This month / 1-3 months ago / Longer / Never]
   -> Target based on research question

5. Would you be available for a 45-minute video interview in the next 2 weeks?
   Compensation: [amount]
   [Yes / No]

Sample size guidance

Pattern saturation typically occurs at 8-12 interviews for a homogeneous population. If interviewing across 3 distinct segments, aim for 5-6 per segment (15-18 total). Diminishing returns start after 12 interviews per segment.

Consent and ethics

Every interview requires informed consent covering:

1. Purpose - What the research is about (high level, not hypotheses)
2. Recording - Will you record audio/video? Can they decline recording?
3. Confidentiality - How data will be stored, who will access it, how long retained
4. Voluntary - They can stop at any time without consequence
5. Compensation - Amount, form, and when they will receive it

Consent script template

Before we begin, I want to share a few things:

- This interview is about understanding how you [topic]. There are no right or
  wrong answers - I'm here to learn from your experience.
- With your permission, I'd like to record this session. The recording will only
  be used by our research team and will not be shared externally. You can ask me
  to stop recording at any time.
- Your participation is completely voluntary. You can skip any question or end
  the interview at any time.
- You'll receive [compensation] within [timeframe] after our conversation.

Do you have any questions before we start? Do I have your permission to record?

Interview guide structure

Block 1: Introduction (5 minutes)

• Deliver consent script (above)
• Set expectations: "This will take about 45 minutes. I'll ask about your experience with [topic]. I'm interested in your honest perspective."
• Build rapport: "Before we dive in, can you tell me a bit about your role and what a typical day looks like?"

Block 2: Context (10 minutes)

Goal: Understand the participant's environment before diving into specifics.

Starter questions:

• "Walk me through how you currently handle [workflow]."
• "What tools or processes do you rely on for [activity]?"
• "How has your approach to [topic] changed over the past year?"

Block 3: Core exploration (25 minutes)

Goal: Deep-dive into the research questions. Use open-ended questions and follow-up probes.

Question patterns:

• Behavioral recall: "Tell me about the last time you [action]. Walk me through what happened step by step."
• Pain point discovery: "What's the most frustrating part of [workflow]? What makes it frustrating?"
• Workaround detection: "Is there anything you've built or hacked together because existing tools don't do what you need?"
• Priority mapping: "If you could change one thing about [product/process], what would it be and why?"
• Unmet needs: "What would your ideal [solution] look like? What would it let you do that you can't do today?"

Block 4: Reactions (10 minutes)

Goal: Get feedback on specific concepts, prototypes, or ideas. Optional - skip if the research is purely exploratory.

Rules:

• Show, don't describe - use mockups, prototypes, or competitor screenshots
• Ask for initial reaction before explaining anything
• "What do you think this does?" tests comprehension
• "Would you use this? When?" tests intent (but take answers with skepticism - stated intent does not equal future behavior)

Block 5: Wrap-up (5 minutes)

• "Is there anything I didn't ask about that you think is important?"
• "Is there anyone else you'd recommend I speak with about this?"
• Thank them and explain next steps: "We'll be synthesizing feedback from several interviews over the next few weeks. I may follow up with a brief clarification."
• Confirm compensation delivery

Interviewer technique guide

The five rules

1. Listen more than you talk - Target an 80/20 split (participant/interviewer). If you're talking more than 20%, you're over-steering.
2. Embrace silence - After a participant answers, count to 5 silently. They will often elaborate, correct themselves, or surface deeper thoughts.
3. Follow the energy - When a participant shows emotion (frustration, excitement, confusion), follow that thread. "You seem frustrated by that - tell me more."
4. Never suggest answers - "So you found it difficult?" is leading. Instead: "How did you find that experience?"
5. Mirror and probe - Repeat their last few words as a question to get them to elaborate. Participant: "It was really confusing." You: "Confusing?"

Probing techniques

Technique	When to use	Example
Silence (5 sec)	After any answer	(just wait)
Echo	When you want elaboration	"You mentioned it was 'clunky'..."
"Tell me more"	When the surface answer is too thin	"Can you tell me more about that?"
"Walk me through"	For process/workflow understanding	"Walk me through exactly what you did"
"Why" ladder	To get to root cause (ask why 3-5 times)	"Why was that important?" -> "Why?" -> "Why?"
Contrast	To surface unspoken preferences	"How does that compare to [alternative]?"
Hypothetical	To test priorities	"If that didn't exist, what would you do instead?"

Thematic analysis framework

After interviews are complete, analyze transcripts using this process:

Step 1: First-pass coding

Read each transcript and highlight notable quotes. Tag each with a descriptive code - a short phrase capturing the idea. Examples:

• "workaround-spreadsheet" - participant built a spreadsheet to compensate
• "trust-issue-data" - participant doesn't trust the data they see
• "time-pressure-reporting" - reporting takes too long under deadline pressure

Step 2: Code consolidation

After coding all transcripts, list all codes and merge synonyms. Aim for 30-50 unique codes across all interviews.

Step 3: Affinity clustering

Group related codes into 5-8 themes. Name each theme with an actionable phrase:

• "Users don't trust dashboard data because refresh timing is unclear"
• "Manual workarounds fill gaps in export functionality"
• "Onboarding fails to address the first critical workflow"

Step 4: Pattern quantification

For each theme, count:

• Frequency - How many participants mentioned it? (e.g., 7 of 10)
• Intensity - How strongly did they feel? (mild annoyance vs. blocking pain)
• Spontaneity - Did they bring it up unprompted, or only when asked directly?

Step 5: Insight generation

Transform themes into insight statements:

Format: "[X out of Y] participants [observation] because [reason], which means [implication for product decisions]."

Example: "8 of 10 participants built manual spreadsheet workarounds for reporting because the export feature doesn't support custom date ranges, which means adding flexible date filtering would eliminate the #1 workaround and reduce time-to-report by an estimated 30 minutes per week."

Step 6: Prioritization matrix

Plot insights on a 2x2 matrix:

• X-axis: Business impact (low to high)
• Y-axis: Frequency / severity (low to high)

Top-right quadrant = act on immediately. Bottom-left = deprioritize or monitor.

NPS Analysis Reference

Scoring methodology

The question

"On a scale of 0-10, how likely are you to recommend [product/company] to a friend or colleague?"

Segmentation

Score	Category	Meaning
9-10	Promoter	Loyal enthusiasts who will refer and repurchase
7-8	Passive	Satisfied but unenthusiastic; vulnerable to competitors
0-6	Detractor	Unhappy customers who can damage brand through negative word-of-mouth

Calculation

NPS = (% Promoters) - (% Detractors)

Range: -100 (all Detractors) to +100 (all Promoters). Passives affect the denominator but not the numerator - they dilute both sides proportionally.

Example

200 responses: 100 Promoters (50%), 60 Passives (30%), 40 Detractors (20%) NPS = 50% - 20% = +30

The follow-up question

The number alone is nearly useless. The follow-up open-ended question is where insight lives:

"What is the primary reason for your score?"

This verbatim response is the most valuable data point in the entire NPS program. Always require it. Never make it optional.

Verbatim coding scheme

Code each open-ended response into categories. Build a codebook specific to your product, but start with these universal categories:

Positive codes (common among Promoters)

Code	Description	Example verbatim
P-EASY	Ease of use / simplicity	"It just works, no training needed"
P-FAST	Speed / performance	"Reports generate in seconds"
P-SUPPORT	Support quality	"Support team resolved my issue same day"
P-VALUE	Value for money	"Best ROI of any tool we use"
P-FEATURE	Specific feature praise	"The dashboard is exactly what I need"
P-RELIABLE	Reliability / uptime	"Never had downtime in 2 years"

Negative codes (common among Detractors)

Code	Description	Example verbatim
D-UX	Confusing interface / bad UX	"Can never find what I'm looking for"
D-BUG	Bugs / errors	"Keeps crashing when I export"
D-MISSING	Missing feature	"No API access, have to do everything manually"
D-PRICE	Too expensive	"Price went up 40% with no new features"
D-SUPPORT	Poor support	"Waited 5 days for a response"
D-PERF	Slow performance	"Loading times are unacceptable"
D-ONBOARD	Hard to get started	"Took our team 3 months to fully adopt"

Passive codes

Passives often cite mild versions of Detractor complaints or conditional praise:

• "It's fine but..." (code as the "but" - that is the real signal)
• "Good for basic use, but we'll outgrow it" (D-MISSING or D-SCALE)

Segmented analysis

Never report a single NPS number. Always segment:

Essential segments

Segment	Why it matters
Customer tenure (0-3mo, 3-12mo, 12mo+)	New users often score higher (honeymoon) or lower (onboarding pain)
Plan tier (free, pro, enterprise)	Enterprise customers may have different expectations
Use case / job title	Product may serve one persona well and another poorly
Geography / region	Cultural response biases differ significantly
Account size (# seats)	Large accounts have different dynamics than individuals

Cohort trending

Track NPS monthly or quarterly by cohort. The most useful view is a line chart:

• X-axis: time (monthly or quarterly)
• Y-axis: NPS score
• Lines: one per segment (e.g., tenure cohort, plan tier)

Look for:

• Declining trends - Even if absolute NPS is positive, a decline signals emerging problems
• Segment divergence - If enterprise NPS rises while SMB drops, investigate
• Event correlation - Did NPS change after a pricing change, major release, or outage?

Industry benchmarks

Industry	Median NPS	"Good" threshold	"Excellent" threshold
SaaS / B2B Software	+30 to +40	+40	+60
E-commerce	+40 to +50	+50	+70
Financial services	+20 to +30	+35	+55
Healthcare	+20 to +30	+35	+55
Consumer technology	+40 to +50	+55	+70
Telecom / ISP	-5 to +10	+15	+30

Benchmarks are directional only. Compare against your own trend first, industry benchmarks second, and competitor benchmarks third (if available).

Closed-loop follow-up process

NPS without follow-up is a vanity metric. Implement a closed-loop program:

Detractor follow-up (within 48 hours)

1. Alert - Route Detractor responses to the account owner or CS team immediately
2. Acknowledge - Send a personalized response within 24 hours: "Thank you for your feedback. I'd like to understand your experience better. Would you be open to a 15-minute call this week?"
3. Listen - On the call, use interview techniques (see interviews.md). Do not defend or sell. The goal is to understand.
4. Resolve - If there is a fixable issue, fix it and follow up. If it is a product gap, document it and share the timeline honestly.
5. Track - Log the follow-up outcome. Measure: what % of contacted Detractors become Passives or Promoters in the next survey?

Passive follow-up (within 1 week)

Passives are the most actionable segment - they are close to being Promoters but something is holding them back.

1. Identify the blocker - Code their verbatim to find the specific barrier
2. Targeted outreach - Share feature announcements, training resources, or account reviews that address their stated blocker
3. Re-survey - Include Passives in a follow-up micro-survey 30-60 days later to measure movement

Promoter follow-up (within 1 week)

1. Thank them - A genuine thank-you goes a long way
2. Activate - Ask for a review, testimonial, case study, or referral. Promoters who are asked are 4x more likely to refer than those who are not.
3. Learn - Ask Promoters what they value most to reinforce those product areas

Statistical considerations

Minimum sample size

For NPS to be directionally useful, collect at least 50 responses per segment. For statistically significant comparisons between segments, aim for 200+ per segment.

Margin of error

NPS has a wider margin of error than most people assume:

Sample size	Margin of error (95% CI)
50	+/- 14 points
100	+/- 10 points
200	+/- 7 points
500	+/- 4.5 points
1,000	+/- 3 points

A 5-point NPS change on 100 responses is within the margin of error - do not report it as a meaningful shift. Focus on trends across multiple periods.

Response rate targets

Channel	Typical rate	Good rate
In-app survey	15-25%	30%+
Email survey	5-15%	20%+
Post-interaction	20-40%	40%+

Low response rates introduce non-response bias. If rate is below 10%, treat results as directional only and supplement with qualitative methods.

Persona Building Reference

Persona template

Use this template for each persona. Every field must be grounded in observed data - never fill a field from assumption alone.

# Persona: [Realistic Name]

## Role & context
- **Job title**: [Actual title from research]
- **Company size**: [Range observed in research sample]
- **Industry**: [If relevant to behavior differences]
- **Technical skill**: [Low / Medium / High - based on observed tool usage]

## Goals
1. [Primary goal - what they are trying to achieve with the product]
2. [Secondary goal]
3. [Tertiary goal, if applicable]

## Pain points
1. [Primary frustration - the thing that causes the most friction]
2. [Secondary pain point]
3. [Tertiary pain point]

## Behavioral patterns
- **Usage frequency**: [Daily / Weekly / Monthly - from analytics data]
- **Primary workflow**: [The main thing they do in the product]
- **Feature affinity**: [Which features they use most and least]
- **Channel preference**: [How they prefer to interact - self-serve, support, community]

## JTBD statement
"When [situation they find themselves in], I want to [motivation / action],
so I can [desired outcome]."

## Key quote
> "[Verbatim quote from an interview that captures this persona's mindset]"
> - [Participant ID, role, tenure]

## Data sources
- Interviews: [N] participants matching this profile
- Survey responses: [N] respondents in this segment
- Analytics segment: [Description of behavioral cohort]

Persona development process

Step 1: Gather raw data

Combine data from multiple sources. Never build personas from a single method.

Source	What it provides	Minimum for personas
Interviews	Goals, pain points, workflows, quotes	8-12 interviews
Survey data	Scale of patterns, demographics, preferences	100+ responses
Behavioral analytics	Usage frequency, feature adoption, retention	30+ days of data
Support tickets	Common issues, frustration intensity	3+ months of tickets
Sales/CS notes	Purchase motivations, objections, churn reasons	10+ account notes

Step 2: Affinity mapping

1. Extract data points - Pull individual observations from each source onto sticky notes (physical or digital). One observation per note.

   • "Uses the product daily but only for reporting" (analytics)
   • "Frustrated by lack of API access" (interview)
   • "Selected 'ease of use' as top priority" (survey)

2. Cluster silently - Group related notes without labels first. Let the clusters emerge from the data rather than forcing them into pre-existing categories.

3. Name the clusters - Once groups stabilize, give each a descriptive name:

   • "Power users who want automation and API access"
   • "Occasional users who need quick answers from dashboards"
   • "Admins who configure for others but rarely use the product directly"

4. Identify axes - Find the 2-3 dimensions that most strongly differentiate the clusters. Common differentiating axes:

   • Technical skill level (low to high)
   • Usage frequency (occasional to daily)
   • Use case complexity (simple to advanced)
   • Team size (individual to large team)
   • Decision-making role (user vs. buyer vs. influencer)

Step 3: Define persona boundaries

Plot clusters on a 2D grid using your top 2 differentiating axes. Each occupied quadrant (or distinct cluster) becomes a candidate persona.

Rules:

• 3-5 personas maximum - More than 5 means you haven't found the real differentiators. Merge until you have distinct, memorable archetypes.
• Each persona must be different in behavior, not just demographics - "Young marketer" vs. "Senior marketer" is not a valid distinction unless their product behavior actually differs.
• Include at least one underserved persona - The user your product currently fails. This prevents your persona set from being a mirror of your best customers.

Step 4: Draft and review

Write each persona using the template above. Then review:

Peer review checklist:

• Can a product manager read this persona and make a different decision than they would without it?
• Does every attribute trace back to observed data (interview quote, survey stat, analytics metric)?
• Are the personas distinct enough that a feature request would clearly matter more to one persona than another?
• Does the JTBD statement feel specific, not generic?
• Are pain points stated as problems, not feature requests?

Step 5: Validate

Holdout validation - If you have enough data, build personas from 70% of your research and test them against the remaining 30%. Can you classify the holdout participants into the right persona?

Stakeholder validation - Share personas with customer-facing teams (sales, CS, support). Ask: "Do you recognize these people? Who is missing?" Front-line teams interact with customers daily and catch blind spots.

Behavioral validation - Map personas to analytics segments. Do users in each analytics segment actually behave the way the persona predicts? If Persona A "uses the product daily for reporting," verify that the corresponding analytics segment shows daily login + report views.

Keeping personas alive

Personas rot if they are not maintained. Treat them as living documents:

Quarterly review

1. Check analytics segments - have the behavioral patterns shifted?
2. Review recent interview and survey data - any new pain points or goals?
3. Talk to 2-3 CS reps - "Is this persona still accurate? What has changed?"
4. Update the persona document with changes and a changelog entry

Persona adoption tactics

• Name them in meetings - "How does [Persona Name] feel about this?" is more concrete than "How do our users feel about this?"
• Hang them on walls - Physical or virtual posters in team spaces
• Include in PRDs - Every product requirement should name which persona it serves
• Use in prioritization - When debating features, ask which persona benefits and how many of that persona exist in your user base

Worked example

Below is a condensed example for a B2B project management tool.

Persona: Priya the Project Lead

Role & context

• Job title: Senior Project Manager
• Company size: 50-200 employees
• Technical skill: Medium

Goals

1. Keep cross-functional projects on track without micromanaging
2. Generate status reports for leadership with minimal manual effort
3. Standardize workflows across her 3 direct-report PMs

Pain points

1. Spends 2+ hours/week compiling status updates from multiple sources
2. Cannot enforce consistent task structure across teams
3. Notifications are overwhelming - no way to filter by priority

Behavioral patterns

• Usage: daily, 4-5 sessions, avg 12 min per session
• Primary workflow: check dashboard -> review overdue tasks -> update status
• Feature affinity: high use of dashboards and reports; low use of time tracking
• Channel: prefers self-serve; rarely contacts support

JTBD statement "When I'm preparing for Monday leadership sync, I want to pull a consolidated status across all active projects, so I can brief executives in 5 minutes without chasing updates from 6 different team leads."

Key quote

"I just need one place where I can see red/yellow/green for every project without asking anyone. That's literally all I want."

• P07, Senior PM, 14-month customer

Data sources

• Interviews: 4 of 10 participants matched this profile
• Survey: 38% of respondents selected "status reporting" as top use case
• Analytics: Cohort with daily login + 3+ dashboard views/week (22% of MAU)

Survey Design Reference

Question type catalog

Closed-ended questions

Single-select (radio) - Use when answers are mutually exclusive.

• "What is your primary role?" (PM, Engineer, Designer, Other)
• Best for: demographics, categorical data, filtering

Multi-select (checkbox) - Use when respondents may choose multiple options.

• "Which of these features do you use regularly?" (select all that apply)
• Best for: feature usage, channel discovery, pain point identification
• Always include "Other (please specify)" and "None of the above"

Likert scale (5-point) - Use for attitude and agreement measurement.

• "How satisfied are you with [feature]?" (Very dissatisfied to Very satisfied)
• Standard anchors: Strongly disagree / Disagree / Neutral / Agree / Strongly agree
• Always use odd numbers (5 or 7) to allow a neutral midpoint
• Label every point, not just the endpoints

Rating scale (1-10 or 1-5) - Use for intensity or likelihood.

• "How likely are you to recommend us?" (0-10, NPS format)
• "How important is [capability] to your workflow?" (1-5)
• Label endpoints clearly ("Not at all likely" to "Extremely likely")

Ranking - Use sparingly; cognitively expensive for respondents.

• "Rank these 5 features by importance to your daily work"
• Limit to 5-7 items maximum
• Consider MaxDiff (best-worst scaling) for longer lists

Open-ended questions

Short text - Use for brief qualitative input.

• "What is the single biggest thing we could improve?"
• Limit to 2-3 per survey; response quality drops after that

Long text - Use for detailed feedback on specific experiences.

• "Describe a recent situation where [product] did not meet your needs."
• Place after a related closed-ended question for context priming

Scale design rules

1. Consistency - Use the same scale direction throughout (always low-to-high or always high-to-low, never mix)
2. Balanced - Equal number of positive and negative options with a neutral center
3. Labeled - Label every scale point, not just endpoints; this reduces interpretation variance by 15-20%
4. No more than 7 points - 5-point scales are sufficient for most purposes; 7-point scales add marginal precision but increase cognitive load
5. Avoid "N/A" as a scale point - Use a separate "Not applicable" option outside the scale if needed

Question writing checklist

• One concept per question (no double-barreled: "How satisfied are you with speed and reliability?" is two questions)
• No leading language ("Don't you agree..." or "How much do you love...")
• No loaded terms ("Do you waste time on..." implies the answer)
• No absolutes ("Do you always..." or "Do you never...")
• No jargon unless your audience definitely knows the terms
• Response options are exhaustive and mutually exclusive
• Question order moves from general to specific (funnel structure)
• Sensitive questions are placed late in the survey, after rapport is built

Sampling strategy

Sample size guidelines

Precision needed	Confidence level	Population size	Minimum sample
Directional insights	80%	Any	50-100
Reliable segments	90%	<10,000	200-300
Statistical significance	95%	>10,000	380-400
Sub-group analysis	95%	>10,000	100 per sub-group

For most product research surveys, 200-400 responses provide actionable data. Below 50, switch to interviews instead.

Recruitment channels

Channel	Best for	Watch out for
In-app intercept	Active users, feature feedback	Interruption fatigue; excludes churned users
Email to customer list	Broad reach, segmentable	Low response rates (5-15%); email fatigue
Post-interaction (support, purchase)	Experience-specific feedback	Recency bias; captures extreme experiences
Panel / third-party	Non-customers, market research	Quality varies; screen carefully
Community / social	Engaged users, qualitative richness	Self-selection bias; skews toward power users

Reducing non-response bias

1. Keep surveys under 7 minutes (12-15 questions)
2. Send reminders at 3 days and 7 days (two reminders max)
3. Offer an incentive proportional to effort (gift card, product credit)
4. Time sends for Tuesday-Thursday, 10am-2pm local time
5. Personalize the invitation (name, specific product context)
6. Compare early vs. late respondent demographics to check for bias

Distribution best practices

Pre-launch checklist:

• Pilot with 5-10 internal respondents; fix confusing questions
• Test on mobile devices (40-60% of respondents will be on mobile)
• Set a close date and communicate it in the invitation
• Define analysis plan before sending (what will you cross-tab? what segments?)

During collection:

• Monitor completion rate daily; if below 80%, identify where people drop off
• Check for straight-lining (same answer for every Likert question) and flag suspicious responses
• Do not change questions mid-collection; if you must, start a new wave

After collection:

• Clean data: remove responses under 2 minutes (speed-runners) and straight-liners
• Weight responses if sample demographics skew from known population
• Analyze open-ended responses with thematic coding (see SKILL.md synthesis section)
• Report margin of error alongside all percentage findings