samarv/customer-empathy-study-groups

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.