FDEs and the KJ Method | Turning Field Fragments into Structure, and Where AI Stops

Hello, this is Ryuta Hamamoto from TIMEWELL.

This is the fourth article in our FDE practice series. The first three covered three skills: asking, watching, and being there. All three are skills for collecting fragments from the field. What you end up with is a stack of transcripts, five-column observation records, and three-layer notes. In a week, that is several hundred fragments.

The problem is that fragments in that form cannot be used for implementation. Which one do you build first? Which is specific to this company and which is a pattern other companies share? Staring at fragments does not answer that. You need a step that turns fragments into structure. For that step our engineers use the thinking behind the KJ method, which the anthropologist Jiro Kawakita created for field research. This article walks through the steps using field notes as material, draws the boundary between what AI does and what people keep, and explains how this differs from requirements consolidation in contract development. If you first want to check how far your own team can turn field fragments into structure, take the AI literacy check.

What the KJ method is: a way of letting structure rise from fragments, born in field research

Kawakita created the method to make sense of the enormous volume of fragments he collected on field expeditions in the Himalayas and Nepal, and it became widely known through his 1967 book on creative thinking, published as a Chuko Shinsho paperback.¹ The name comes from his initials. It is a registered trademark of Kawakita Research Institute, which provides formal training and seminars.² What this article describes is the practice our engineers use on site, learned from that way of thinking; it is not a substitute for the institute's training. Anyone who wants the essence of the method should go to the original book and the institute.

In my own words, the skeleton is four steps. Write each collected fragment on a card, one idea per card. Spread the cards out, gather those with similar content into small groups, and give each group a one-line name. Arrange the groups in space and draw the relationships between them with lines and arrows. Finally, write the diagram up as prose that can be communicated to others. In a late interview, Kawakita described the heart of the method as letting the fragments speak for themselves rather than sorting them into a framework you already hold.³

That is where it differs from other ways of organizing. Most organizing starts with a framework. You set up headings such as "issues," "requests," and "constraints" and put the fragments under them. It is fast, but fragments that fit no heading are discarded. The KJ way does not start with a framework. You look at the fragments, gather the ones that are close, and name them after they have gathered. So frameworks you did not anticipate appear. For an FDE, those unanticipated frameworks are where the value is. The anticipated ones could have been made in a meeting room.

The method was also taken up in quality management as the affinity diagram, one of the seven new QC tools. In English-speaking practice it is called affinity diagramming and is a standard way of turning interview fragments into structure in user research.⁴ The names differ, but the idea of letting structure rise from fragments is the same.

An FDE's Friday: four steps from a week of fragments to structure

Our engineers use this on Friday afternoons. It is the time when the fragments collected Monday through Thursday become a decision about what to build next week. Here are the steps, with the materials.

There are three materials: the verbatim interview transcripts from the first article, the five-column observation records from the second, and the three-layer ethnographic notes from the third. Together, a week yields a few hundred fragments.

Step one is making one-idea cards. From the transcripts, cut each statement into one card per idea. "The section manager approves" and "but when it's urgent the assistant manager stamps it" are two cards. From the observation records, lift each entry in the unease column onto a card: "explanation said section-manager approval, but the screen shows the assistant manager's name." From the notes, lift the words that followed "normally" and "here we." Add the source to each card in small letters: who, when, in what setting. You will need it later to check whether a group is a sales-only story or a company-wide one.

Step two is gathering similar cards. Spread them out and pull together the ones with similar content. The key is to gather by meaning, not by word. Gather every card containing the word "approval" and you mix stories about stamps with stories about screen actions. Conversely, "the assistant manager stamps it" and "the section manager doesn't look at details" share no words but are close in meaning. Only someone who was on site knows that closeness. Keep groups small, two to five cards, and split any that pass ten. Then give each group a one-line name. The name is not a summary; it is what the group is saying. "In practice, approval is two-stage: the assistant manager's judgment and the section manager's stamp."

Step three is the diagram. Place the groups on the table and connect them with lines: cause and effect, opposition, sequence. If a line can be drawn between "approval is two-stage" and "urgent cases travel on paper," that is a structure: paper survives because the on-screen approval flow does not handle urgency. The moment that structure becomes visible, next week's build is decided. Not fixing the approval screen, but building a route for urgent cases on the screen.

Step four is writing up. Turn the diagram into prose for the person on site and for our own team. We write two versions. One is for the person: a paragraph saying "next week we will build an on-screen approval route for urgent cases, because the current paper route assumes the assistant manager's judgment." The other is for us: the judgment "is the separate route for urgent cases a branch unique to this company, or a pattern others share?" That second version is the exit of the KJ method for an FDE.

Pattern or branch: returning group names to the product

Let me be clear about why an FDE uses this method. Not to tidy up fragments. Tidying is the means; the purpose is to sort group names into "a branch unique to this company" and "a pattern other companies share," and to return the patterns to the product.

The person who spent eight years as an FDE at Palantir wrote that the FDE's job was to solve the problem in front of them and that generalizing was the product team's job.⁵ We are a small company, so the same engineer does both. Then the question is where the generalization decision gets made. It cannot be made on raw fragments. Only once something has become a group name can you say "I have seen this at other companies." "Approval is two-stage" is a pattern we have seen at several companies, so on the product side we make the number of stages and the decision-maker at each stage configurable. "Urgent cases travel on paper" is also a pattern. "Tanaka in accounting holds that paper" is a branch. Branches are recorded and kept out of the product.

a16z's January 2026 essay lists, among its tests for the real FDE model, whether you can say no to customization.⁶ Saying no takes grounds, and the grounds are the group name. You can say "this is a branch unique to your company, so it won't go into the product; we'll absorb it through configuration instead" only because on Friday you made groups, named them, and sorted them into patterns and branches. Bring the fragments home unsorted and your only options are build everything or refuse everything.

And this happens weekly. Do it monthly and the groups grow too large to see the line between pattern and branch. Once a week, a few hundred fragments become a few dozen groups, and the group names become a few patterns and a few branches. That repetition is the substance of returning field learning to the product.

How it differs from requirements consolidation in contract development

Contract development also has a step for consolidating what was heard. You build a requirements list, prioritize, and price it. Judged by motion alone, both are organizing fragments. Here is the difference.

Aspect	Requirements consolidation (contract development)	FDE structuring
Framework	Built first (feature list, issue list)	Rises from the fragments
Unit	Requirement (unit of functionality)	Group name (unit of shop-floor reality)
Judgment	Priority and price	Pattern or branch
Exit	Requirements document, contract	Next week's build and patterns returned to the product
Frequency	Once, in the requirements phase	Every week

The biggest difference is whether the framework comes first. Requirements consolidation builds a feature list first and sorts interview fragments into it. Fragments that cannot be sorted fall out. "When it's urgent the assistant manager stamps it" fits nowhere on a feature list, so it never reaches the requirements document. And in production, urgent cases stall on the screen.

FDE structuring lets groups rise from the fragments without a framework, so "when it's urgent the assistant manager stamps it" becomes a group, gets a name, and becomes next week's build. The fragment that falls out in contract development becomes the first thing built in FDE. That reversal is the reason to use a method that lets structure rise from fragments.

The other difference is the exit. Requirements consolidation exits into a requirements document and a contract, where things are fixed. FDE structuring exits into next week's build and patterns for the product, updated every week. Some people find it unsettling that nothing is fixed, but shop-floor reality changes every week, and I think weekly updates track it more closely.

What AI does and what people keep

Of the four steps, we hand AI most of the first and the front half of the second.

For card-making, we have AI read the transcripts and observation records and cut them into one card per idea. Cutting a few hundred fragments by hand takes half a day; a machine takes minutes. Adding the source is also machine work if the transcript preserves speaker and time. But a person checks the granularity. AI tends to keep "the section manager approves, but when it's urgent the assistant manager stamps it" as one card. Whether to split it into two changes how the groups form later, so a person looks.

For the front half of gathering, the tentative arrangement, we let AI do it: produce a provisional layout by similarity of meaning, and people move things from there. Two things happen every time. AI gathers cards that share words and separates cards that share meaning but not words. "The assistant manager stamps it" and "the section manager doesn't look at details" end up far apart, and a person brings them together. And AI wants to name the groups, but its names are summaries: "statements concerning the approval process." That is not a name. Putting what a group is saying into one line stays a human job.

The diagram and the write-up are done by people. Whether a line can be drawn between two groups can only be judged by someone who knows whether that connection is real on the shop floor. Let AI draw the diagram and you get a clean picture whose lines are grounded in word similarity rather than in the field.

Kawakita said the heart of the method is letting the fragments speak.³ AI arranges fragments quickly, but it is not letting them speak. The ones who can are the people who were there when the fragments were collected. We keep this boundary less out of reverence for the method than because we have crossed it and built the wrong thing the following week.

What we do and where it stops

Let me be honest. This takes time. A whole Friday afternoon disappears. From an engineer's point of view, that is time that could be code. We keep doing it because when we skip the Friday groups and write code on Monday, we find out on Wednesday that half of what we wrote was a branch. Half a Friday protects a day and a half of the following week.

There are limits. The method cannot exceed the quality of the fragments collected. If the interviews were full of leading questions, the groups are groups of led answers. If observation lasted one day, the groups are one day's story. That is why the skills in the first three articles come first. Group names also depend on the height from which the namer looks. From the same fragments, naming at executive height gives "inefficiency in the business process"; naming at shop-floor height gives "the assistant manager stamps it." What an FDE builds next week is the latter, so names are given at shop-floor height. The executive-level wording is written separately at the write-up stage.

Finally, on the name. The KJ method is a registered trademark of Kawakita Research Institute, and we are not certified by it. What we do is card-based structuring learned from the thinking in Kawakita's book, and formal training is provided by the institute. Anyone who wants the essence of the method should go to the original book and that training. What we can write about is how we connected it to implementation on site.

Summary

Fragments collected on site cannot be used for implementation as they are. To turn them into structure, we use the thinking behind the KJ method that Kawakita created for field research: one-idea cards, gathering by closeness of meaning, a diagram of the relationships between groups, and a write-up for the person on site and for our own team. Because no framework is built first and structure rises from the fragments, frameworks nobody anticipated appear.

An FDE uses this to sort group names into branches unique to one company and patterns shared by others, and to return the patterns to the product. The fragment that falls out in contract development becomes the first thing an FDE builds. AI makes the cards and the tentative arrangement; people keep the naming and the diagram.

If you want to build an engineering team that can turn field fragments into structure, or are looking for a partner to turn your own shop-floor fragments into product, take a look at the WARP program or talk to us. The next article covers a newer way of collecting fragments: filming the shop floor and analyzing the video with AI.

Footnotes

1. Kawakita, J. Hassoho (Ways of Creative Thinking), revised edition, Chuko Shinsho (first edition 1967, revised 2017, in Japanese). Publisher page ↩

2. KJ Method, Kawakita Research Institute (in Japanese). The statement that the KJ method is the institute's registered trademark and the training information are from this site ↩

3. "The origin and core of the KJ method: an interview with Jiro Kawakita," Japanese Journal of Qualitative Psychology, No. 2 (2003, in Japanese). J-STAGE. The point about letting fragments speak is my summary of the interview ↩ ↩²

4. Affinity Diagramming for Collaboratively Sorting UX Findings and Design Ideas (Nielsen Norman Group) ↩

5. Reflections on Palantir (Nabeel S. Qureshi, October 15, 2024) ↩

6. The Palantirization of everything (Marc Andrusko, a16z, January 16, 2026) ↩