---
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

1.  **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.
2.  **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.