---
name: gemba-interview-protocol
description: "A question bank for interviewing someone while watching them do real work — built around what's observed in the moment, not recalled afterward, with reminders for staying out of the way of the work itself. Use when: You can actually observe the work happening — sitting with a support agent, watching a customer use the product live, following a process end to end. You want to catch workarounds and small frictions so routine the person doing them wouldn't think to mention them unprompted. Not for: You can't actually observe the work — that's a general discovery interview, working from recall instead of observation. The conversation is about a decision that's already been made, not an ongoing workflow — that's the win-loss interview guide. Your presence would meaningfully change how the work gets done and there's no way to account for that — note the gap directly if it happens rather than pretending it didn't."
---
<!-- Auto-generated from content/templates.ts by scripts/generate-skills.ts -- do not edit this file directly. Edit the kata's guide content and regenerate. -->

# Gemba interview protocol

A question bank for interviewing someone while watching them do real work — built around what's observed in the moment, not recalled afterward, with reminders for staying out of the way of the work itself.

Family: Voice of the customer · Format: .xlsx · Domain: core

## What it is

A gemba interview happens where the work actually happens, watching it as it's done rather than asking someone to describe it from memory afterward. This protocol drafts questions built to reference what you're seeing in real time — 'I noticed you just...' — plus reminders specific to observing without disrupting the work you came to see.

## When to use it

Use it when:

- You can actually observe the work happening — sitting with a support agent, watching a customer use the product live, following a process end to end.
- You want to catch workarounds and small frictions so routine the person doing them wouldn't think to mention them unprompted.
- You want evidence grounded in what actually happened, not a recalled and possibly polished account of it.

Not when:

- You can't actually observe the work — that's a general discovery interview, working from recall instead of observation.
- The conversation is about a decision that's already been made, not an ongoing workflow — that's the win-loss interview guide.
- Your presence would meaningfully change how the work gets done and there's no way to account for that — note the gap directly if it happens rather than pretending it didn't.

## How to fill it in

- **researchGoal** — What do you want to see, specifically? 'How support agents actually triage tickets' drafts a sharper protocol than 'understand support.'
- **topics** — Drafted from your research goal — includes a 'setting the scene' opener and prompts built to reference what you observe live, not just planned questions.
- **reminders** — Drafted for gemba-specific technique — watching before asking, naming what you saw neutrally rather than what you inferred.
- **narrative** — Drafted from the research goal — how to observe without disrupting the work, and what to listen for.

## What good looks like

The example below is a gemba session watching a support agent triage a normal shift of tickets: questions built around real-time observation, a prompt for checking whether behavior changed because of the observer's presence, and reminders specific to watching work without interrupting it.

Full worked example, on-screen and as a downloadable .xlsx: https://www.katafacts.com/katas/gemba-interview-protocol

## Common mistakes

- **Interrupting an action in progress to ask about it.** — You lose the moment and the natural flow of the work — wait for a natural pause, or ask about it immediately after rather than mid-action.
- **Not asking whether behavior is different because you're watching.** — People often work differently when observed — asking directly turns that gap into a finding instead of a blind spot in what you recorded.
- **Describing what you inferred instead of what you actually saw.** — "I noticed you were struggling" is your interpretation stated as fact — "I noticed you paused there" is neutral and lets them characterize it themselves.

## What it connects to

Downstream:

- **Voice of the customer (VOC) evidence log** (`voc-evidence-log`) — Gemba observations are exactly the kind of raw material the evidence log tallies — log them as entries, source type 'gemba.'
- **Work-in-progress (WIP) aging report** (`wip-aging-report`) — A workaround observed in a gemba session is often the human explanation behind a stalled-item pattern the WIP aging report would otherwise only see as a number.

## Where AI helps

Judgement — stays with you:

- Deciding when to interrupt versus wait for a natural pause
- Judging whether an observed workaround is a real finding or a one-off

Analysis — AI helps:

- Drafting real-time-observation questions from a stated research goal
- Drafting gemba-specific technique reminders

Drudgery — automated:

- Counting topics and questions
- Exporting to xlsx in the house format

---

Gemba interview protocol is licensed [CC BY 4.0](https://creativecommons.org/licenses/by/4.0/). Attribution: Katafacts (katafacts.com).

## Using this skill

Apply this method as part of whatever broader task, instructions, or deliverable you're already working on -- it's a method to use, not a standalone conversation to start. There is no generation tool for this catalogue yet, so draft the artifact's actual content yourself, following the fields above, the same way a person filling this out by hand would. The canonical guide page and a downloadable worked example (.xlsx) are at https://www.katafacts.com/katas/gemba-interview-protocol.
