| name | customer-empathy-study-groups |
| description | A roleplay-based framework to identify product friction and bridge the gap between internal knowledge and the actual customer experience. Use this when a product feels "Frankenstein-ed," when launching a complex 0-to-1 feature, or when support tickets indicate users are getting stuck in "obvious" places. |
Customer Empathy Study Groups
A Study Group is a structured, cross-functional roleplay session designed to reveal the "entropy" and friction that accumulate in a product. Instead of reviewing a demo or looking at a friction log, the team "embodies" the customer to experience the product’s failures firsthand.
Core Rules
- You do not work at this company: You must abandon all internal knowledge of where buttons are, why certain docs are linked, or how the backend functions.
- We are not here to solve problems: The session is for practicing empathy and experiencing friction. Do not suggest fixes, file bugs, or critique design during the roleplay. Record the pain; solve it later.
The Workflow
1. Assemble the Group
Gather 4 to 8 people from across the company (e.g., Support, Engineering, Sales, and Product). Diversity is critical; avoid having only the team that built the feature in the room.
2. Set the Persona and Outcome
Define a specific, motivating goal for a fictional company.
- Company Name: Give it a cutesy, arbitrary name (e.g., "Dolphin Aquarium Industries") to lower defensiveness.
- The Persona: Assign roles within the group (e.g., "Jenny is the CEO," "Tim is the Designer").
- The Goal: Define a specific outcome (e.g., "We need to sell tickets for the farmer's market using an in-person reader by 4:00 PM today").
3. Appoint a Maestro
Designate a facilitator to act as the "Character Enforcer." The Maestro’s job is to interrupt the moment someone uses internal knowledge.
- The Trigger: If a participant says, "I know the doc link is broken, so I'll just search for the internal wiki," the Maestro pauses the session.
- The Correction: "As a reminder, you don't work here. You've never heard of that wiki. Start the sentence again as a CEO who is confused."
4. Execute Painfully Slowly
Navigate the product end-to-end. Do not rush.
- Start at the beginning: Start with a Google search or the first page load, not a deep-linked dashboard.
- Voice your thoughts: Participants should narrate their confusion. "I’m looking for a 'Get Started' button but all I see is 'Documentation.' I guess I have to read the docs?"
- Embody the stress: Feel the "business emotional" impact of the product’s failures.
5. Transition to Action
Once the roleplay is over, funnel the "business emotional" discoveries into existing formal processes:
- Tag Craft Bugs: Label identified issues with a specific "Craft" or "Friction" tag.
- Set Acknowledgement SLAs: Ensure the responsible team acknowledges (not necessarily fixes) the identified friction points within a set timeframe (e.g., 7 days).
Examples
Example 1: Incorporating a Company
- Context: The team wants to test the "Atlas" incorporation flow.
- The Roleplay: The group pretends to be two co-founders in different countries trying to split equity.
- The Friction: They realize they don't know each other's physical home addresses, and the product blocks them from moving forward without that data.
- The Insight: The "Internal Knowledge" would have been to just put a placeholder. The "Customer Empathy" is the realization that this stops the momentum of starting a business.
Example 2: Setting up In-Person Payments
- Context: Testing a new hardware reader.
- The Roleplay: A non-technical business owner trying to connect a reader to a tablet at a crowded market.
- The Friction: The Bluetooth pairing requires a firmware update that takes 10 minutes.
- The Insight: The team "feels" the stress of a line of customers waiting while a progress bar crawls across the screen.
Common Pitfalls
- Breaking Character: Participants often use "PM-speak" to justify a bad UI. The Maestro must be ruthless in stopping this immediately.
- Focusing on Solutions: If the group starts whiteboarding a fix mid-session, the empathy is lost. Stay in the "pain" until the session ends.
- High-Fidelity bias: Using Figma mocks instead of the live product. Use the actual software the customer uses, including broken links and slow load times.
- Defensiveness: If the team that built the product feels attacked, the session fails. Remind everyone that the group is a "fictional company" and the goal is observation, not performance review.
