Personas, Journey Mapping, and User Empathy Questions

Framework: rapid, hypothesis-driven lean research focused on riskiest assumptions (supply-demand fit, willingness to transact, and onboarding friction).

Week 0–2 plan (budget $10k):

• Goals: produce 2–3 validated personas per side; decide launch-primary persona; surface top 3 jobs-to-be-done and critical barriers.
• Spend:
  • $4k: 40 qualitative interviews (20 craftsmen, 20 hobbyists) via $50 incentives.
  • $1.5k: 500-response targeted survey (mix of open + choice-based questions) to quantify segments.
  • $2k: guerrilla usability/context visits to 6 local workshops/meetups (observational + prototype walkthroughs).
  • $1k: landing page + small paid social test ($500 each side) to measure intent.
  • $1.5k: analysis, recruiting, and contingency.

Execution:

• Recruit via local maker groups, Etsy-like sellers, Facebook hobby groups, Craigslist. Screen for recency of selling/buying, project frequency, price sensitivity.
• Interview script: motivations, workflow, pain points, willingness to pay/fee sensitivity, trust signals, preferred discovery channels. Use 5-point commitment questions to gauge action intent.
• Survey to validate prevalence of behaviors and to cluster (e.g., weekend hobbyist vs. project-based buyer; full-time artisan vs. occasional seller).
• Synthesize into personas: demographics, tech comfort, primary job-to-be-done, success metrics, objections, preferred acquisition channel, $ willingness.

Prioritization rule:

• Optimize for the side whose scarcity most blocks transactions and where acquisition/onboarding is lowest-cost with highest lifetime value. Likely prioritize craftsmen (supply) if the marketplace is new: without items, buyers churn. Decision based on interview + landing test: if >30% craftsmen indicate willingness to list within 2 weeks with concierge onboarding, prioritize them.

Two quick MVP validation experiments:

1. Concierge supply-test (soft launch for sellers)

   • Recruit 10 local craftsmen; offer free concierge listing (we take photos, write descriptions, set pricing) and commit to promoting their items to a curated buyer pool.
   • Metrics: listings created, time-to-first-listing, conversion to sale, seller retention after 2 weeks, NPS. Validates supply onboarding friction and seller value perception.

2. Demand smoke-test via landing pages + paid ads

   • Build two targeted landing pages (one for hobbyists looking for custom items; one for hobbyists wanting classes/DIY kits). Run $500 ad tests per segment targeting local geo/interest audiences.
   • Offer a time-limited waitlist with a $10 refundable deposit for priority access or a booking CTA for a mock product.
   • Metrics: click-through, conversion to deposit/booking, cost-per-intent, qualitative questions on willingness to pay. Validates real intent and pricing.

Outcome & next steps:

• Use persona scoring: prevalence (survey %), activation likelihood (experiment conversion), and LTV (lifetime value, the total revenue expected from a customer over their relationship with the product) proxy (willingness to pay). Choose primary persona with highest combined score.
• Feed learnings into MVP roadmap: prioritized onboarding flows, trust features (reviews/guarantees), and top acquisition channels for launch week.

A concise B2B persona schema, with evidence per field

• Name and role: title, seniority, and decision-making power. Evidence: CRM job titles, account segmentation, customer interviews.
• Primary goals and success metrics: what this person is trying to achieve. Evidence: product analytics tying feature usage to outcomes, sales discovery notes, interviews.
• Key tasks and workflow: core tasks, tools used, handoffs to other roles. Evidence: contextual interviews, session recordings, product telemetry (funnels).
• Pain points and blockers: specific frustrations and constraints. Evidence: support tickets, NPS (net promoter score) verbatim comments, usability-test transcripts.
• Buying and evaluation criteria: what features, security posture, and return on investment they need to see. Evidence: win/loss interviews, procurement documents, requests for proposal (RFPs, formal documents a buyer sends asking vendors to bid).
• Technical context and data maturity: stack, integrations, and data literacy. Evidence: onboarding surveys, integration logs, customer-success calls.
• Organizational constraints and stakeholders: budget cycles, compliance requirements, and the decision chain. Evidence: account plans, contract terms, stakeholder interview maps.

A single page for two audiences
Order the fields so the top third, name and role, goals, pain points, serves a PM skimming for context in a meeting, and the middle and bottom, tasks and workflow, technical context, org constraints, serves a designer working through flows in detail. Both audiences read the same page; neither needs a separate version, because the depth increases as you move down rather than requiring a second document.

Why these sources
Interviews and contextual research capture motivation and workflow; analytics and CRM data validate frequency and scale; support and sales conversations surface high-signal pain points and buying reasons. Combining qualitative and quantitative evidence is what makes each field defensible rather than assumed.

Keeping personas up to date
Instrument the canonical signals behind each field (product events, account attributes) and run a quarterly automated check that flags drift, for example a shift in role distribution or a usage pattern that no longer matches the stated goals. Maintain the page in the design-system repo with a visible change log, sync with customer success and sales monthly, and run a lightweight re-validation, 5 to 8 interviews plus an analytics snapshot, after any major product release. Treat every field as a hypothesis with a stated confidence level, and prioritize re-research wherever confidence is low or the underlying metric has moved.

Direct answer

With only six quotes, the fastest way to make sense of them is to sort each one into what the user literally said (Says), the belief or worry probably sitting behind it (Thinks), the behavior it implies (Does), and the emotion driving that behavior (Feels), then look for the behavior clusters that repeat across the six statements rather than treating each quote as its own separate insight.

Empathy map

SAYS

• "I don't trust new apps with my banking."
• "If I can't find it in 3 clicks, I close the app."
• "I want an advisor to confirm my choices."
• "I compare rates before committing."
• "I get frustrated by long forms."
• "I like getting email summaries."

THINKS

• Is this app secure and reputable enough to trust with my money?
• This needs to be fast and obvious, or I am gone.
• I want an expert to tell me I am making the right call.
• I should check I am not leaving a better rate on the table.
• Forms are a tax on my time; I will cut corners or quit.
• I want a record I can refer back to later.

DOES

• Abandons the app when navigation feels unclear or slow.
• Compares competitors and rates outside the app before committing.
• Seeks a human, by chat or call, to confirm important decisions.
• Rushes through or minimizes long forms.
• Relies on email summaries instead of re-opening the app.

FEELS

• Cautious and a little suspicious about financial risk.
• Impatient with friction.
• Reassured once an expert has weighed in.
• Confident once the numbers are laid out side by side.
• Frustrated by bureaucracy, calmed by a concise follow-up.

Two actionable persona insights

Insight 1, "Cautious Comparator": the says-and-does pattern (distrust of new apps, comparing rates externally) points to a need for visible trust signals and transparent comparison rather than persuasion. Product move: add a side-by-side rate comparison inside the app instead of forcing the user to leave and check elsewhere, plus visible credibility markers near money-related actions. Watch how often users complete a comparison inside the app instead of tabbing away to a competitor's site as a leading indicator.

Insight 2, "Efficiency-Seeking Decision-Comforter": the 3-click and long-form frustrations, combined with wanting an advisor and liking email summaries, point to a user who wants speed for routine steps and human reassurance for the one step that matters most. Product move: shorten the primary path to the 3-click bar the user stated outright, add a one-tap path to a human or guided confirmation at the single highest-stakes step, and keep the existing email-summary habit rather than trying to pull them back into the app for it.

Trade-offs and pitfalls

Everything in Thinks and Feels here is inferred, not stated, so treat it as a hypothesis to validate with a slightly larger sample or a targeted survey question before betting a redesign on it. Six quotes from an unknown number of distinct users is enough to sketch a direction, not enough to be confident about magnitude.

With five users I'm not trying to prove the persona statistically. I'm checking whether the same 2-3 core claims keep showing up across independent people and independent methods, remote interviews, a short diary study, and whatever analytics already exist, and I stop iterating once that convergence is clear or once one more user stops teaching me anything new.

Methods for 5 users: 3 short, 30-45 minute remote interviews to check stated motivations and decision criteria directly; all 5 users in a short 3-day micro diary study, one quick daily prompt asking what they tried and what got in the way, to see real behavior in context rather than a recalled summary; and a check against any existing analytics for users matching the persona's profile, to see whether their behavior lines up with the sample.

What counts as validating evidence: convergence across independent sources on the same claim. If the same core pain point or goal shows up in the interviews and the diary entries and matches the analytics pattern, that's real signal, not just one person's story repeated back.

Documenting confidence: score each of the persona's 2-3 key claims on a simple 0-3 scale, 0 contradicted, 1 weak or ambiguous, 2 some support, 3 strong support across multiple sources, and record which specific quotes, diary entries, or metrics back each score, so anyone reviewing later can see the evidence, not just the number.

When to stop iterating: stop when at least 3 of the 5 users independently support the persona's core claims, 60%, with no direct contradiction from another source, or when an additional user or two adds no new theme, since that flat line in new information is itself a stopping signal. Keep going, with another small batch of 5, only if a core business decision hinges on this persona and confidence is still weak.

Worked example: suppose 3 of 5 interviewees describe the same specific frustration, a confusing settings menu, 60%. The diary study from all 5 shows 4 of them actually opening that settings menu at least once during the 3 days, and 2 of those 4 leave a diary note describing confusion there, consistent with, not contradicting, the interview finding. That's convergence across two independent methods on the same claim, enough to call this persona trait validated and move on, rather than running a sixth interview hoping for more certainty.

Trade-offs & pitfalls: five users can validate that a pattern exists; it can't tell you how common that pattern is across your whole base, so don't let a small-sample validation get reported upward as a prevalence number. Diary studies are easy to under-recruit for because 3 days feels short, but participants often drop off by day 2, so over-recruit slightly or check in daily to keep the sample intact. And stopping just because you're out of time, rather than because the evidence actually converged, is a different decision; be honest with stakeholders about which one happened.

With ten pain points and only three sprints of capacity, I'd score each pain point against a small set of explicit criteria in a short workshop, rank them, then lock in the next three sprints' worth of work with owners and rationale written down so the decision survives someone asking "why did we pick this" three months later.

Criteria (score 1-5 each)

• User impact: how many users hit it and how badly (frequency times severity)
• Effort: rough size in points or days (a lower effort score means higher cost)
• Business value: revenue, retention, or support-cost impact
• Risk: legal, accessibility, or brand risk if left unaddressed
• Strategic fit: does it support a stated objective this quarter

Weight the criteria once, up front, so scoring doesn't turn political later: for example Impact 35%, Effort 25%, Business value 20%, Risk 10%, Strategic fit 10%.

Workshop (60-75 minutes)

• 0-10 min: recap the ten pain points and the criteria and weights, set before the room, not decided live
• 10-25 min: silent individual scoring, each participant scores all ten pain points against all five criteria on their own
• 25-45 min: discuss only the outliers, items where two or more people's scores disagree by 2+ points; leave everything else alone
• 45-60 min: compute the weighted total, rank, and see how many items fit three sprints of capacity
• 60-75 min: assign an owner and a one-line acceptance criterion to each selected item

Fast-path alternative (quick consensus): when there's no time for individual scoring, run a 20-30 minute version instead. Read each pain point aloud, take a quick thumbs-up/down/sideways vote on "is this top-3-sprint-worthy," discuss only the split votes, and rank the rest by a show of hands. It trades rigor for speed and works when the room already broadly agrees on priorities; it is not a substitute for the full scoring pass when priorities are contested or a budget needs to be justified upward.

Who attends: a design or research lead as facilitator, the PM who owns the roadmap, an engineering lead who can call effort, one support or customer-facing rep who has heard these complaints directly, and, if risk criteria matter, someone from legal or accessibility.

Capturing decisions: a single shared doc or board records, for each selected pain point, the weighted score, notes on any disagreement, the assigned owner, the sprint it lands in, and the metric that will tell you it's fixed. Someone who wasn't in the room should be able to read that doc and understand why each of the ten items ended up in or out.

Worked example: using the weights above (Impact .35, Effort .25, Business .20, Risk .10, Strategic fit .10) on three of the ten pain points:

• "Checkout button hidden on mobile": Impact 5, Effort 4, Business 4, Risk 2, Strategic fit 3. Score = 5(.35) + 4(.25) + 4(.20) + 2(.10) + 3(.10) = 1.75 + 1.00 + 0.80 + 0.20 + 0.30 = 4.05
• "Confusing error message on password reset": Impact 3, Effort 5, Business 2, Risk 3, Strategic fit 2. Score = 1.05 + 1.25 + 0.40 + 0.30 + 0.20 = 3.20
• "No bulk export for enterprise admins": Impact 4, Effort 1, Business 5, Risk 1, Strategic fit 5. Score = 1.40 + 0.25 + 1.00 + 0.10 + 0.50 = 3.25

Even though the export item scores highest on business value and strategic fit, its low effort score (it's expensive to build) pulls its total below the checkout fix once effort is weighted in. The checkout fix ships first; the export feature may still be worth doing, just not in the next three sprints.

Trade-offs & pitfalls

• A weighted score can hide a genuine values disagreement (is user impact really worth more than business value here) behind a false sense of precision from two decimal places; use the number to structure the conversation, not end it.
• If the same few people always set the weights, the criteria will quietly encode their department's priorities. Revisit weights periodically with a wider group.
• Ten items is a lot for one workshop; if scoring drags past the timebox, that's a signal you need the fast-path version, not more time.
• Effort estimates from a workshop are directional, not a commitment. Confirm sprint fit with engineering during actual sprint planning before publishing which items are "in."