Netflix Product Manager Interview Preparation Guide - Junior Level

Framework:

1. Scope & assumptions
2. Year-0 costs (12 months)
3. Year-1 benefits (productivity, churn, hiring savings)
4. Net present value & break-even
5. Sensitivity

Scope & assumptions:

• Program: 12-month internal PM apprenticeship; cohort = 8 apprentices
• Mentors: 8 senior PMs (1:1 mentor), each mentors 1 apprentice with ~10% time allocation
• Company size: 200 PMs current; avg PM fully loaded comp = $140k/yr
• Apprentices comp: $65k/yr (entry-level), ramp to 100% productivity by month 9
• Discount rate ignored for 12-month horizon; use straightforward cash flow

Costs (12 months):

• Apprentice salaries: 8 * $65,000 = $520,000
• Benefits & overhead (25%): 0.25 * 520,000 = $130,000
• Mentor time cost (10% of mentor salary): mentors paid $170k fully-loaded; cost = 8 * 0.10 * 170,000 = $136,000 (opportunity cost)
• Training content, workshops, tools: $40,000
• Admin & recruiting internal cost: $24,000
  Total costs = $520k + $130k + $136k + $40k + $24k = $850,000

Projected Benefits (12 months):
A) Productivity contribution (value delivered by apprentices vs cost):

• Assume an average PM at full productivity delivers $300k of business value/year (proxy: revenue impact + efficiency)
• Apprentices ramp: months 1–3: 20% productivity; 4–6: 40%; 7–9: 70%; 10–12: 100%
• Average productivity per apprentice over year = (30.2 + 30.4 + 30.7 + 31.0)/12 = (0.6+1.2+2.1+3.0)/12 = 6.9/12 = 57.5% => value per apprentice ≈ 0.575 * $300k = $172,500
• Total apprentice-derived value = 8 * $172,500 = $1,380,000

B) Mentor productivity drag (10% time): mentors lose 0.10 * $300k value = $30k value each => 8 * $30k = $240,000 lost value (already approximated in mentor cost above but separate as value impact)

C) Churn reduction & hiring savings:

• Baseline PM annual churn = 10% of 200 = 20 PMs; cost to hire & ramp replacement ~ $80k each
• Program reduces churn by 1 percentage point (conservative) = 2 fewer departures => savings = 2 * $80k = $160,000
• Long-term pipeline value: internal promotion reduces external hiring premium; conservatively attribute extra $60k saved per year across future hires = $60,000 (year 1 partial)

Net benefit year 1:

• Gross apprentice value: $1,380,000
• Minus mentor drag: -$240,000
• Plus churn/hiring savings: +$220,000
  Net benefit = 1,380,000 - 240,000 + 220,000 = $1,360,000

Net ROI and break-even:

• Total program cost = $850,000
• Net benefit - cost = $1,360,000 - $850,000 = $510,000 net gain in year 1
• Break-even: costs recovered when apprentice value + savings >= costs + mentor drag. Solve: By month ~6–7 (since ramp average crosses cost). Rough estimate: break-even ~ 6.5 months.

Sensitivity (key levers):

• If apprentices ramp slower (50% avg vs 57.5%): benefits drop ~12% => net flips to ~ $380k still positive.
• If mentor time required is 20% => mentor drag doubles to $480k and cost rises; ROI tightens; break-even ~10–12 months.
• If churn reduction = 0 => lose $160k, ROI still positive but smaller.

Recommendation:

• Pilot with 8 apprentices, track monthly KPIs: apprentice impact (project delivery), mentor time logged, retention at 12 months, hiring cost saved. Reassess mentor time and consider group mentoring to reduce mentor burden if needed.

High-level business case for EV charging network partnership:
Costs:

• CapEx/OpEx contributions to charger deployment (per-station subsidy), integration engineering, driver education and incentives; estimate $Xm over 3 years depending on geography.
  Benefits:
• Faster EV adoption by drivers → lower fuel costs, fewer maintenance claims, improved CO2 metrics, improved brand positioning.
• Potential revenue from charging fees share and higher trip margins for EV drivers.
  Driver incentives:
• Free/discounted charging credits for first 12 months, reduced lease rates for EVs, guaranteed earnings protection while transitioning.
  ROI timeline:
• Year 0–1: pilot deployment in 3 markets, adoption ramp; Year 2: scale to 10–20 markets; break-even expected Year 3–4 depending on subsidy levels and driver uptake.
  Potential regulatory hurdles:
• Local permitting for chargers, utility interconnection rules, potential incentives/subsidy eligibility variations. Mitigations: partner with local utilities, apply for grants, stagger rollouts.
  Recommendation: run a tightly scoped 12-month pilot with clear cost-per-adopted-driver targets and pre-specified go/no-go criteria.

Direct answer
Standardizing postmortem practice across many independent teams means providing a lightweight, consistently-structured template, clear rules for when it's required and how it's enforced, and enough automation and shared tooling that quality doesn't depend entirely on any one team's discipline, while still leaving room for teams to adapt details to their own context.

Structured elaboration

• Template fields, kept minimal and consistent. Severity, timeline, impact, root cause, contributing factors, action items with owners and dates, and a short executive-readable summary. Keep it short by design; a template with thirty required fields will get filled in perfunctorily rather than thoughtfully.
• Lifecycle, not just a document. Define the steps from incident closure to a completed, reviewed postmortem to verified action items: for example, draft within 3 business days, review by a peer or facilitator within a week, and action items tracked to closure through the org's standard ticketing integration.
• Enforcement that's incentive-based, not just punitive. Track and publish (internally) which teams are consistently completing postmortems and closing action items on time, make that visible to leadership, and treat missing postmortems for qualifying incidents as a real gap to address rather than optional homework, while avoiding heavy-handed mandates that just produce perfunctory, low-quality compliance.
• Shared tooling, one integration point. A postmortem is only as good as whether it's actually findable and the action items are actually tracked; integrate with the org's existing ticketing and dashboard tools once, centrally, rather than each team building or half-building its own tracking.
• Resolve unclear ownership explicitly. When a shared, critical system spans multiple teams and it's unclear who owns postmortem follow-through, this ambiguity itself slows down incident resolution and remediation; the governance model needs an explicit rule (for example, the team that owns the paging rotation for that system owns convening the postmortem, with contributing teams required to participate) rather than leaving it to be sorted out ad hoc every time.

Worked example
A 200-team organization standardizes on a single lightweight template (six required fields, one optional appendix for deep technical detail), requires a postmortem for any incident above a defined severity within 3 business days, and integrates action-item tracking directly into the same ticketing system every team already uses, with automatic escalation for anything overdue by more than two weeks. A monthly org-wide dashboard shows postmortem completion rate and action-item closure rate by team, visible to engineering leadership, which creates gentle peer-comparison pressure without any team being individually called out punitively. For a shared payments-adjacent system with unclear ownership across three teams, the org defines an explicit rule: whichever team owns the primary on-call rotation for that system is responsible for convening and completing the postmortem, with the other two teams required to attend and co-own any resulting action items in their area.

Trade-offs and pitfalls
The most common failure is over-standardizing: a heavy, rigid template designed for the org's most complex incidents gets applied to every minor one too, producing fatigue and perfunctory compliance. The second is under-enforcing: publishing a template with no lifecycle, tracking, or ownership rule, which produces wildly inconsistent quality across teams and leaves shared-ownership incidents falling through the cracks.

Direct answer

For a designer, problem definition and framing means establishing, before any screens get sketched, exactly who is affected, what is currently happening, what "better" would look like, and how you'll know when you've gotten there. The goal is to make the team's shared understanding of the problem explicit and checkable, rather than letting each person carry a different unstated assumption into the design review.

Structured elaboration

The discipline produces a small set of concrete artifacts, not just a mental model: a written problem statement (who, current state, desired state, timeframe, metric), a short list of prioritized hypotheses about what's driving the gap, the success metrics that will confirm a fix worked, and acceptance criteria, meaning the specific pass or fail checks a proposed change must clear before it ships. These are lightweight, often a paragraph and a bulleted list, but writing them down (rather than keeping them as shared assumptions) is what lets a team catch disagreement before it costs a sprint of design work.

Postponing solutions until after this framing matters because the first plausible-looking fix is rarely the best one, and it is much cheaper to be wrong about a sentence on a page than about a shipped redesign. A designer who frames first is also better positioned to push back when a stakeholder arrives with a solution already attached ("just add a carousel"): the framing step gives you the vocabulary to ask what problem that carousel is meant to solve, rather than either building it uncritically or rejecting it without a reason the stakeholder will accept.

Worked example

A well-formed problem statement in this discipline: "New users who complete account setup in under 2 minutes retain at 3x the rate of users who take longer than 5 minutes; setup currently takes a median of 6 minutes. We want median setup time under 3 minutes within one quarter, measured as time from account-creation-start to setup-complete event." This names the user, the current and desired states, a timeframe, and a metric, without saying anything yet about what the setup flow should look like.

A concrete instance of this same discipline: "Checkout abandons at 38%, well above the 22% baseline for comparable flows; the evidence is a session-replay review, the impact is estimated by multiplying the affected monthly session volume by the abandonment-rate gap and the average order value (a concrete formula, not a bare figure), and the constraint is a two-sprint budget" names the situation, evidence, impact, and constraints in one breath, the same components this broader framing discipline exists to produce.

Trade-offs and pitfalls

The risk of over-investing in this step is real: an experienced designer can spend so long framing that discovery itself becomes the bottleneck, especially on a low-stakes change where a quick prototype would answer the question faster than more analysis. The right calibration is proportional to reversibility and cost: frame carefully before a redesign that will take a quarter to build and is hard to undo; frame lightly, in a sentence, before a change you could ship and revert in a day.

Direct answer

In a regulated industry the story changes in three ways before you ever open a slide deck: what you're allowed to show gets filtered by regulation first, every number needs a documented trail back to its source, and the audience usually includes someone whose job is to say no. The craft is presenting a defensible, compliant insight that is still genuinely persuasive, not a watered-down one.

Structured elaboration

1. Filter the insight through the regulatory constraint before you design the story.
Start by asking what you are legally or contractually allowed to surface, not what would make the best slide. In healthcare this typically means de-identification requirements in the style of HIPAA (the Health Insurance Portability and Accountability Act, the US healthcare privacy law) (removing or generalizing direct identifiers, applying k-anonymity style aggregation so no small cell size can be re-identified); in finance it often means restrictions on disclosing individual customer positions, fair-lending constraints on which variables can drive a decision, and model-risk-management documentation requirements. The constraint is not a formatting afterthought, it determines which findings you can even lead with. A finding that is only compelling at the individual-customer level may need to be re-cut at a cohort or segment level to be shshowable at all.

2. Choose an anonymization or aggregation method proportionate to the risk, and say so explicitly.
Common options, roughly in order of how much detail they preserve: generalization/binning (age becomes a 10-year band), suppression of small cells (any group below a stated threshold, for example n<10, is not reported individually), k-anonymity (restructuring the data so every individual is indistinguishable from at least k-1 others) or differential privacy (adding carefully calibrated statistical noise so no single record can be reverse-engineered from the released numbers) for released datasets, and full aggregation to segment or cohort level for anything leaving the compliance boundary. State which one you used and why in the deck itself, not just in a footnote; a compliance-literate audience will ask, and pre-empting the question builds trust.

3. Build the documentation trail the regulator or auditor would expect.
At minimum: a data lineage note (where the data came from, what was excluded and why), the exact aggregation/anonymization method applied, the population definition, and any known limitations or exclusions. In a bank this is close to what model-risk-management documentation already requires; in healthcare it is close to what a compliance or privacy officer would ask for before approving external use of a dataset. Producing this alongside the insight, not after someone asks for it, is what separates a defensible story from an accidental disclosure.

4. Present the compliance-versus-insight trade-off to the executive directly, instead of hiding it.
An executive who wants the fuller, more granular picture needs to understand that the constraint is not analyst caution, it is a hard requirement with real penalties for the organization. Frame it as: here is the insight we can show at the compliant aggregation level, here is what more granular view would add, and here is why we cannot show that view without additional legal/privacy sign-off (and what that sign-off would require, e.g., a data use agreement, approval from an institutional review board (the ethics body that approves research involving people's data), legal review). This turns a limitation into a scoped, honest recommendation rather than a vague 'we can't share that.'

Worked example

A healthcare analytics team wants to show a hospital system that a proposed care-pathway change reduces 30-day readmissions. The raw finding is a 2.1 percentage point reduction (from a baseline of 15.0% to 12.9%) in a cohort of 640 patients. Because the cohort includes some very small subgroups (for example, a specific rare-diagnosis subgroup of 6 patients), the team cannot report readmission rates by that subgroup without violating a small-cell suppression rule (commonly a minimum reportable cell size, e.g. n>=11, used across many healthcare reporting standards). The story that ships: the top-line reduction at the full-cohort level (which is well above the suppression threshold and safe to report), a note that subgroup-level results are directionally consistent but suppressed below n=11 per data governance policy, and an explicit statement that a follow-up analysis with a larger sample is planned before subgroup-level claims can be made. The executive sees the real result, understands exactly why the subgroup cut is withheld, and knows what it would take to get it.

Trade-offs and pitfalls

• The biggest pitfall is aggregating so heavily to stay 'safe' that the insight becomes too vague to act on; the discipline is finding the least aggregated view that is still compliant, not the most conservative one available.
• A second common mistake is treating the regulatory constraint as something to mention once in an appendix; a compliance-savvy stakeholder will judge you on whether the constraint shaped the analysis from the start, not whether you disclosed it at the end.
• Do not let 'the regulation requires it' become an excuse for skipping normal storytelling discipline (headline, evidence, recommendation); the compliant version of the insight still needs to lead with the so-what, it just has a narrower evidentiary base.
• When in doubt about whether a cut of the data is disclosable, the right escalation path is your privacy/compliance/legal function, not an individual judgment call, and that escalation itself is worth naming as part of your process when a stakeholder pushes for more granularity.

Direct answer

At two days of silence with a deadline approaching, keep working the problem in parallel on two tracks: escalate progressively (wider audience, shorter response window) instead of waiting indefinitely or jumping straight to someone's manager, and start a temporary workaround so your own deadline isn't hostage to someone else's response time.

Structured elaboration

1. Reconfirm the ask was clear before escalating. Silence sometimes means the original message was ambiguous or buried, not that it's being ignored. A quick, sharper re-send (what's needed, by when, what breaks if it slips) is worth trying before widening the audience.
2. Widen the channel and audience, not just the volume. Loop in a teammate of the owner's, or their tech lead, with a concise summary: what's blocked, since when, and what you need. This isn't going over anyone's head yet, it's making sure the request isn't sitting unseen in one inbox.
3. Escalate to management if there's still no response, framed around unblocking the work, not blaming the person: bring your own manager or a shared point of contact (like a PM) into a short, direct conversation rather than an open-ended thread.
4. Start a workaround in parallel, not sequentially after escalation: a mock, a stub, or a scoped assumption that lets you keep making progress while the real dependency gets resolved, clearly labeled as temporary so it doesn't quietly become permanent.
5. Close the loop afterward. Once unblocked, note what caused the delay (no on-call coverage, unclear ownership, a channel nobody monitors) so the same two-day silence doesn't repeat next time.

Worked example

Say another team owns a data pipeline, and a schema change they need to ship is blocking your dashboard launch, due in three days. You messaged the pipeline owner two days ago and got no reply.

1. Reconfirm: you send a sharper follow-up in the same thread: "Following up: I need the orders table schema change merged by Thursday EOD to hit our dashboard launch Friday. Anything blocking you on it, or should I loop in someone else?"
2. Widen: a few hours pass with no reply, so you message the pipeline team's tech lead directly (not a reply-all): "I've been blocked on the orders schema change since Monday and our Friday launch depends on it. Can you help me find the right person, or unblock it yourself?"
3. Escalate: by end of day, still nothing, so you bring it to your manager or a shared PM in a short conversation, not a long thread: "I've tried the owner directly and through their lead over two days with no response, and Friday's launch depends on this. Can you help get it unblocked?"
4. Workaround, run in parallel from day one: while those messages are going out, you build your dashboard against a stubbed version of the new schema (a local view with the expected new columns backfilled from sample data), clearly commented as temporary, so the launch timeline doesn't wait on the real merge landing.
5. Close the loop: once the schema change lands, you raise in the team retro that the pipeline team had no on-call coverage for urgent schema requests, and propose a shared "blocked on us" channel so a two-day silence doesn't happen again.

(The same five-step shape applies outside engineering: a designer blocked on a brand asset from marketing, or a QA engineer blocked on a test environment from infra, would reconfirm, widen, escalate, work around, and close the loop the same way.)

Trade-offs & pitfalls

• Pitfall: escalating too fast, before trying a second direct attempt, which can read as skipping over someone unnecessarily.
• Pitfall: waiting too long out of politeness, which puts your own deadline at risk and, in review, looks like you didn't flag a risk early enough.
• Pitfall: treating escalation and workaround as either/or. Doing them in parallel protects the deadline regardless of how fast the escalation resolves.
• Senior differentiator: framing every step (the re-send, the widened ask, the escalation) around getting unblocked, not around who's at fault, so the relationship with the owning team survives the deadline pressure.

Vision summary:
As PM I’d frame Airbnb’s data engineering vision as “centralized, self-serve data platform with baked-in governance”: a single logical platform where teams can discover, consume, and publish data products easily, while automated controls enforce quality, lineage, access, and compliance.

How it shapes product strategy and roadmap:

• Strategy prioritizes developer productivity and discoverability (catalog, SDKs, templates) plus platform-level guardrails (schema registry, automated testing, policy-as-code).
• Roadmap splits into enablement (self-serve UX, onboarding flows, templates), reliability (pipeline observability, SLA monitoring), and governance (access controls, lineage UI, data quality alerts).
• KPIs: time-to-insight, # of self-serve data products, incident rate, percent datasets with verified lineage.

Trade-offs (developer velocity vs quality/lineage):

• Tension: stricter gates (pre-prod validations, enforced schemas) slow new development but reduce rework and incidents. Looser rules speed prototyping but increase downstream debugging and compliance risk.
• PM approach: tiered UX — “sandbox” fast lane for experiments, and “production” path with automated checks for promoted datasets; invest in fast feedback loops (local validators, quick linting) to minimize friction.

Product decisions easier vs harder:

• Easier: reuse of common joins, cross-team analytics, audits, GDPR/CCPA compliance, and onboarding new teams (catalog + templates).
• Harder: extremely rapid, one-off experiments that require novel schemas; migration of legacy pipelines that bypass platform; negotiating SLAs for near-real-time use cases where governance checks add latency.

Example decisions:

• Implement schema evolution rules: choose incremental validation + automated migrations (balances velocity/quality).
• Build lineage-first catalog: prioritizes metadata capture in pipeline SDKs to make governance low-friction.

Principle:
Design for safe defaults and low-friction escalation: make the governed path the easiest path for production use, while preserving experimental agility.

Situation & goal: Migrate user profiles from legacy on‑prem store to cloud user store with minimal risk while validating correctness, performance, and business continuity. Pilot should prove technical migration, business rules, and monitoring before full cutover.

Pilot size & sampling strategy

• Size: 2,000–10,000 users (or 1–5% of total users), whichever yields statistically meaningful behavior.
• Sampling: stratified random sample across key dimensions: account age (new/old), activity tier (active/idle), geography/region, plan type (free/paid/enterprise), edge cases (multi‑email, social logins). Add a small manual cohort of high‑risk enterprise accounts for targeted testing.

Validation checks

• Schema mapping: field-by-field mapping document; automated schema validation to detect type mismatches, missing required fields, malformed values.
• Completeness: row counts, per‑field null rate comparison, checksum/hash comparisons of immutable segments.
• Referential integrity: verify foreign keys (e.g., user → subscriptions/orders) resolve in target; run end‑to‑end flows dependent on linked entities.
• Business rules: verify derived attributes (status, entitlements, feature flags) match expected logic.
• Functional smoke tests: login, password reset, permissions, personalization surfaces.

Monitoring metrics & thresholds

• Data correctness error rate: <0.1% mismatches allowed for pilot; critical fields (email, auth id) 0% tolerance.
• Latency: read/write latency within 2x of current P95; target: P95 < 200ms for reads.
• Failure rates: API error rate <0.5%.
• Rollforward failures (migration jobs failing): <0.2% per batch.
• User impact: support tickets attributable to pilot < 0.05% of pilot users per week.

Validation process & cadence

• Run automated validation after each batch, nightly reports, and real‑time dashboards for critical metrics.
• Manual QA and stakeholder review after first 1,000 users and at pilot midpoint.

Rollback criteria

• Immediate rollback triggers:
  • Critical field corruption (e.g., auth id mismatches) detected >0 users.
  • Login failures impacting >0.1% of pilot users or any enterprise SLA breach.
  • Repeated job failures causing >0.5% data loss risk.
• Conditional pause & investigation:
  • Error rate exceeds thresholds for two consecutive batches.
  • Latency degradation >2x baseline at P95 for >30 minutes.
• Rollback mechanism: freeze writes to target, route reads back to legacy, reverse sync using latest snapshot + tombstone handling, run verification before resuming.

Acceptance thresholds for full rollout

• Data correctness error rate ≤0.05% overall; critical fields 0% tolerance.
• Performance: P95 read latency within 1.5x baseline; write durability confirmed.
• Operational: migration job success rate ≥99.9%, monitoring and alerts in place, runbook validated, support team trained.
• Business: zero SLA violations for enterprise accounts during final pilot window and support tickets within baseline.

Risks & mitigations

• Risk: hidden referential breaks — mitigate with dependency graph checks and end‑to‑end functional tests.
• Risk: rollback complexity — rehearse rollback in staging; keep clear runbook and automated scripts.

Next steps (PM actions)

• Approve sampling plan and thresholds with engineering, security, customer success.
• Schedule pilot windows and communications plan for affected users.
• Define KPIs for Go/No‑Go decision and sign‑off stakeholders (Eng, Sec, Legal, Support, Sales).

Sprint velocity measures the amount of work a team completes in a sprint, usually expressed as story points (or completed backlog items) per sprint — it’s a historical average used for forecasting capacity. A sprint burndown chart shows remaining work (hours, points, or tasks) across sprint days; it visualizes progress toward the sprint goal and exposes scope creep or blocked work.

Common misuses of velocity when comparing teams:

• Treating velocity as an objective productivity metric — comparing teams penalizes different estimation scales and contexts.
• Ranking or rewarding teams based on velocity, which encourages gaming estimates or cutting quality.
• Using raw velocity to reallocate work across teams without accounting for skillset, domain, or definition-of-done differences.
• Expecting velocity parity across teams of different sizes, tech stacks, or complexity.

If I saw unstable velocity across sprints, I would:

1. Diagnose root causes quickly — review sprint retros, burndown anomalies, scope changes, blocker frequency, team capacity (vacations/sick leave), and changes to estimation or DoD. Example: frequent mid-sprint scope adds explain spikes.
2. Stabilize process and scope — enforce a clearer definition-of-ready/definition-of-done, limit mid-sprint scope changes, and improve backlog refinement so stories are sized consistently before sprint start.
3. Improve predictability and communication — adjust planning with shorter confidence windows (use rolling averages), surface capacity constraints to stakeholders, and run focused retros to create action items (e.g., reduce task switching, pair on risky stories) and track their impact over subsequent sprints.

Direct answer

An empathy map is a lightweight visual tool teams use to synthesize what a user says, thinks, does, and feels, in order to build shared understanding and surface design or product opportunities together, rather than relying on any one person's interpretation of the research.

Pre-work (sent 48 hours before)

Share a short persona or a recent customer vignette along with 2 to 3 real user quotes or metrics. Ask each participant to review it and bring one customer anecdote or data point of their own. Prepare a shared whiteboard with a 2x2 empathy-map template and a written agenda.

60-minute workshop plan

• 0 to 5 min, kickoff: state the purpose, the expected outputs (top 3 insights, 3 possible experiments), roles, and the timebox.
• 5 to 20 min, individual silent brainstorm: each person adds 3 to 5 sticky notes per quadrant using the shared persona or a real customer quote.
• 20 to 40 min, share and cluster: each participant reads 1 to 2 highlights per quadrant while the facilitator groups similar notes into clusters and a scribe labels each cluster with its supporting evidence.
• 40 to 50 min, insight generation: small mixed groups (designer, engineer, customer success) each pick one cluster and answer what problem it indicates, how it affects the business or user outcome, and what hypothesis or experiment follows. For example, if the customer-success representative brings in three separate tickets about a payment failing with no explanation, that cluster becomes the group's pick, and the hypothesis becomes that a vague failure message, not the underlying fraud rule, is driving repeat checkout abandonment.
• 50 to 60 min, decide next steps: each group presents one insight and one next action (prototype, analytics check, or user interview), and the product manager captures priorities, owners, and a timeline.

Roles during the session

• Facilitator (product manager): keeps time, keeps scope, synthesizes.
• Designer: surfaces empathy patterns, proposes UX experiments.
• Engineer: calls out technical constraints and feasibility.
• Customer success: brings the customer's voice, flags severity and urgency.
• Scribe: documents clusters, evidence, and action items.

For a two-sided or marketplace product, add a merchant-facing product manager or a growth representative so the map captures both sides of the transaction, not only the buyer's experience.

Sample prompts for each quadrant

• Says: "What exact phrases or quotes have customers used?" For example, "It takes too long to set up."
• Thinks: "What might they be worried about or assuming but not saying?" For example, "Is this secure? Will this break my workflow?"
• Does: "What observable actions do they take?" For example, retries setup, contacts support, abandons the flow.
• Feels: "What emotions underlie the behavior?" For example, frustrated, anxious, relieved.

Converting results into product insights

Synthesize the clusters into 3 prioritized problems, each backed by evidence (quotes, frequency, and severity as flagged by customer success). For each, write a clear hypothesis: "If we do X, then metric Y will improve by roughly Z." Map each hypothesis to a concrete next step, a quick prototype test, an analytics event change, or a targeted interview. Log outcomes against the roadmap or backlog, tag tickets with the empathy cluster they came from, assign an owner, and set a measurable target. Share a one-page summary with stakeholders and run at least one validation step within two weeks.

Trade-offs and pitfalls

A 60-minute session generates directional hypotheses, not proof; treat every "insight" from the workshop as a candidate for validation, not a finished decision.