Notes, affinity mapping and working as a team

Sofia told the developers to add “pause delivery” because customers want it. Max, the tech lead, asked a fair question: who exactly said that, and what did they say? She had nothing to show him. Her notes from twelve conversations lived mostly in her head, plus a few lines in her phone.

That's a learning bottleneck: everything the company knows about customers sits in one person. Then “the customers said so” turns into an order nobody can check, and the team has two options, obey or ignore. Both are bad. Even when that person is right, nobody can see why, so the next disagreement starts from zero.

It can come from the other side too: a team that refuses to hear about customers at all. “You focus on the product, I'll handle the customers” and “I have no time for interviews, I have code to write” build the same wall from opposite ends.

The cure has three parts:

• prep conversations together;
• take notes with real quotes;
• review them together, and share quotes right after each talk.

The cure for a bottleneck starts before any conversation, with conversation prep. It's short: about thirty minutes, not a strategy week. In it the team:

• agrees on its 3 big questions, what it most needs to learn from this kind of person;
• writes down best guesses about the customer, so surprises are visible later;
• decides what commitment to ask for at the end, such as a trial order or an introduction.

Bring both product and business people. Otherwise nobody asks what the missing side needs to know: engineers forget about budgets, sales forgets about how the thing will actually be used.

Do desk research first. Anything you can find online, like the public prices of the main brands or a clinic's size and opening hours, you look up before the meeting. Asking it face to face wastes the customer's patience and your best minutes. Face time is for what only the customer knows: their past, their decisions, their problems.

The core question of prep is simple: what do we want to learn from these people? If you can't answer it, skip the conversation until you can.

Who should go to a customer conversation? People who make product decisions need to hear customers themselves, at least sometimes: bad news passed on by someone else is too easy to dismiss. The sales reps of Megan, CatChow's head of sales, talk to clinics anyway and can help set meetings up, but they shouldn't be the only ones who listen.

The ideal team is two people. One talks; the other takes notes and notices when the first starts pitching or misses a signal. Three or four people facing one customer feels like an interrogation, and the answers turn formal. To give everyone first-hand contact, rotate who goes instead of sending everyone at once.

The note-taker's seat is also the best invitation for a sceptic. Max thinks interviews are a waste of time, and his doubt is fair if past conversations were full of compliments. Don't argue with him. Ask for ten minutes to help pick the questions, especially the ones that matter to engineering, then let him take notes on Thursday. Once a conversation saves the team a week of building the wrong thing, you won't need to invite him twice.

Notes are easier to sort later when each line starts with a mark. These note-taking symbols are one simple set; invent your own if you like, as long as the whole team uses the same ones:

• ! pain or problem
• ~ workaround, a homemade fix
• # obstacle, something that blocks change
• ₴ money or budget
• @ a named person or company
• ? a feature request to dig into, not a spec
• >> next step
• + or − strong emotion

Write one fact per line, with the customer's exact words in quotes whenever you can. A verbatim quote does double duty: it's evidence for a sceptical teammate and ready-made copy for a landing page.

Why mark emotion separately? Because “it's a problem” said calmly and said with anger are two different findings, and a pain with − next to it weighs more. Top each page with who, where and when, plus who took the notes, so anyone can find the conversation again months later.

A note is only useful if someone who wasn't there can trust it. After Olivia's call, Sofia wrote just: “Olivia likes the idea, buying food is annoying, wants discounts.” Meanwhile Olivia had described running out on a Sunday again, driving to three shops, paying almost double for small bags at the third, and a phone reminder every three weeks that she still forgets.

The note kept one opinion and two interpretations, and lost everything that made the pain real. Watch for three traps:

• opinions: “likes the idea”, which nobody even said;
• your interpretations: “buying food is annoying”, a summary that hides the facts;
• guessed solutions: “wants discounts”, read into a story about price.

Instead, write what happened: the customer's verbatim quote in quotation marks, concrete past facts (where, when, how much), and a symbol at the start of the line. The three shops and the double price stay word for word. The reminder that fails gets ~: it's her workaround, and it isn't working. That tells the team far more than “annoying”.

The fastest cure for a learning bottleneck is a habit: right after each conversation, post what you heard where the whole team can see it. Not your conclusion, but the evidence behind it.

Compare two updates after the same calls. “Customers want a pause button, please add it” leaves the team with two options, obey or ignore, and no way to check. “Two of three owners described food piling up while they were away; one said ‘The box sat outside the door for a week’” lets everyone see what you saw, and argue with it if they read it differently.

A good update has:

• who: which customer, from which segment;
• what happened, as a verbatim quote or a concrete fact;
• where the full notes are, so anyone can dig deeper;
• optionally, your interpretation, clearly labelled as yours.

Post it the same day, while the details are fresh. The point isn't to report your activity. It's to let someone like Max, who wasn't on the call, reach his own conclusion from the same facts. Then a decision comes from a pattern the team can see, not from whoever spoke loudest.

Notes nobody looks at are useless. So after conversations comes conversation review: a quick debrief the same day, and a longer look at all notes once a week. Update your beliefs and your three big questions, and discuss the craft too: which questions worked, where you slipped into pitching, which signal you missed.

Then comes synthesis: putting notes from many conversations side by side and looking for patterns. Pull out every ! line and ? request, group similar ones, and count how many people said the same thing.

A pattern is a group, not a card. When most people in a batch describe the same pain, several of them with strong emotion, that's evidence worth digging into: what did they do next, and what did it cost? A single feature request isn't wrong, it's just alone; a couple more conversations will show whether it grows. Building everything because “it all came from customers” spreads the team thin, and chasing the most original idea confuses novelty with evidence.

With a focused segment, six conversations are often enough to see a pattern. A decision comes from that pattern, not from the one customer who spoke loudest.

Affinity mapping is a simple way to synthesise many conversations at once. It needs nothing more than a wall and a pack of sticky notes, or a shared online board:

1. Put each observation or quote on its own card: one ! line or ? request per card.
2. Lay out all the cards from every conversation side by side.
3. Move similar cards into groups.
4. Name each group and count how many people are in it.
5. Treat the biggest groups with the strongest emotion as your patterns, and pick the next question to dig into.

For six owners of diet cats, the wall might show one big group, “food runs out at a weekend”, with cards from five of the six people (83%), three of them marked −, and a lone card asking for cat photos in the app. The lone card isn't wrong, it's just alone. Two more interviews will show whether it grows into a group or stays a one-off.

Decisions come from groups. The group names, with their counts and best quotes, go into a shared table the whole team can see.

Talking to customers is a tool, not a ritual. Megan's team did ten calls in a week and logged them all in the CRM, which sounds like a great result until you ask what the team learned. Most calls ended with “great, send us the info”.

Signs a team is just going through the motions:

• reps talked more than the customer, or presented the idea;
• the calls collected compliments like “sounds great”;
• there were no next steps, and calls ended with “send us the info”;
• there are no notes, or notes nobody reviewed;
• a surprising answer changed nothing in the plan;
• no question felt scary, and nobody knew what they wanted to learn.

Real learning looks different. Calls end with concrete next steps that have dates, such as a trial order next month. Quotes are shared with the team the same day. And when something surprising comes up, the plan shifts to account for it, or at least the next three big questions do.

Count what you learned and what people committed to, not how many calls happened.