Nala

My job as a product manager is to know customers well enough to build the right things, and to say no to the rest. The second half is the harder half.

Ideas arrive from everywhere, and many have little to do with what customers have told us. Deciding together what not to build takes more than a hunch. It takes evidence everyone can open and check, and that evidence was always in the interviews.

Ten hour-long interviews come to well over a hundred pages of transcript, and by the tenth I was skimming. So I pasted them into a chatbot, like most of us do. It gave me confident paragraphs. I couldn’t tell who had said any of it, or how many people had, and neither could anyone I showed it to.

Even good findings lost their evidence on the way to the decision.

They went into a slide deck, where a quote became a bullet point, or a Notion page nobody opened twice. The meeting ran on whoever sounded surest, not on what customers said.

Teams already have a fast answer: paste the interviews into ChatGPT, build the deck in Gamma. It’s quick and it looks good, but nothing in it can be checked, and a sceptical engineer knows it. Research repositories like Dovetail solve a different problem: they’re built for research teams. A 20-person start-up doesn’t need an archive. It needs the team to agree on one decision this week.

Small product teams with customer words and a decision to agree on.

The sharpest case is the product manager at a company of 10 to 50 people. They’re expected to set direction, but they only get the authority to do it when they tie it to a goal the founders already own, and prove it well enough that engineers and founders act. I’ve been that PM.

The person they most need to bring along is usually a founder who isn’t from product, and who will give the case three minutes.

It isn’t for insights teams whose deliverable is the study itself, for brand tracking, or for monitoring tickets at scale. Nala reads interviews and nothing else.

Models make small judgments a person could check. Code does the counting.

Nala follows the phases of thematic analysis (Braun and Clarke, 2006): code every passage, search for themes, then review each one against the transcripts. It never asks a model what the data says. It asks thousands of small, typed questions, stores every answer, and counts them in the database. A language model does one job, last: it names and summarises each theme, citing its quotes.

Classical ML and NLP · Jev, a model that answers fixed questions instead of writing · an LLM only to name and summarise

The analysis is how you get there. The case is the product.

A case is a short doc in three parts: what we heard, what we decided, and what we’ll do. It writes like any doc. Type # for a theme or @ for a person and they arrive with their counts. The call is always the author’s, with their name on it.

Nala checks it as you write: a line with no source, a shaky theme, a claim that says more than the interviews do. Then it goes where decisions really get made: a read-only link, a presentation or a PDF. The team comments until it agrees, and the outcome is recorded.