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.
1---2name: customer-empathy-study-groups3description: 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.4---5
6# Customer Empathy Study Groups
7
8A 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.
9
10## Core Rules
11
121. **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.
132. **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.
14
15## The Workflow
16
17### 1. Assemble the Group
18Gather 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.
19
20### 2. Set the Persona and Outcome
21Define a specific, motivating goal for a fictional company.
22* **Company Name:** Give it a cutesy, arbitrary name (e.g., "Dolphin Aquarium Industries") to lower defensiveness.
23* **The Persona:** Assign roles within the group (e.g., "Jenny is the CEO," "Tim is the Designer").
24* **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").
25
26### 3. Appoint a Maestro
27Designate a facilitator to act as the "Character Enforcer." The Maestro’s job is to interrupt the moment someone uses internal knowledge.
28* **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.
29* **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."
30
31### 4. Execute Painfully Slowly
32Navigate the product end-to-end. Do not rush.
33* **Start at the beginning:** Start with a Google search or the first page load, not a deep-linked dashboard.
34* **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?"
35* **Embody the stress:** Feel the "business emotional" impact of the product’s failures.
36
37### 5. Transition to Action
38Once the roleplay is over, funnel the "business emotional" discoveries into existing formal processes:
39* **Tag Craft Bugs:** Label identified issues with a specific "Craft" or "Friction" tag.
40* **Set Acknowledgement SLAs:** Ensure the responsible team acknowledges (not necessarily fixes) the identified friction points within a set timeframe (e.g., 7 days).
41
42## Examples
43
44**Example 1: Incorporating a Company**
45* **Context:** The team wants to test the "Atlas" incorporation flow.
46* **The Roleplay:** The group pretends to be two co-founders in different countries trying to split equity.
47* **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.
48* **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.
49
50**Example 2: Setting up In-Person Payments**
51* **Context:** Testing a new hardware reader.
52* **The Roleplay:** A non-technical business owner trying to connect a reader to a tablet at a crowded market.
53* **The Friction:** The Bluetooth pairing requires a firmware update that takes 10 minutes.
54* **The Insight:** The team "feels" the stress of a line of customers waiting while a progress bar crawls across the screen.
55
56## Common Pitfalls
57
58* **Breaking Character:** Participants often use "PM-speak" to justify a bad UI. The Maestro must be ruthless in stopping this immediately.
59* **Focusing on Solutions:** If the group starts whiteboarding a fix mid-session, the empathy is lost. Stay in the "pain" until the session ends.
60* **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.
61* **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.
majiayu000