Why I built Nala

By Alex Crowley, founder of Nala

I’ve spent my career as a product manager at startups and scale-ups. The job, as I understand it, is to know your customers well enough to build the right things, and to say no to the rest.

Most weeks the second half is the harder half. Someone pitches a feature, often a founder, and often it has little to do with what customers have told us. Saying no to the person who signs off the roadmap takes more than a hunch. It takes evidence they can check for themselves.

That evidence was always in the interviews. Getting it out of them, and in front of the people deciding, is where it kept going wrong.

Turning interviews into evidence

Ten hour-long interviews come to well over a hundred pages of transcript. Sorting them by hand into behaviours, pains and motivations takes days, 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.

Nala starts from the words, not a summary. Every passage is judged on the same questions, every theme is counted in people rather than mentions, and every count opens to the words behind it.

Getting the team to act on it

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 into a Notion page nobody opened twice. In the meeting it came down to who argued best, not what customers said.

So Nala doesn’t stop at a list of themes. It ends in a case: a short doc with the question you’re deciding, your call, and the evidence for and against it. A claim in a case looks like this.

Anyone reading the case can open the quotes under any line and comment where they disagree. Nala flags any line with no source, or one that says more than the study does.

What I believe about evidence

Count people, not mentions. One loud customer is still one customer, so every number says how many people, out of how many.

Every claim opens to its words. If a reader can’t check it, it’s an opinion.

Show the case against. The evidence that cuts against you belongs in the case. It’s what makes the rest believable, and sometimes the honest answer is not to build.

Product principles

Evidence alone doesn’t move a team. People have to want to open it. So these are the rules I hold Nala to.

Clean. Nothing on the screen that isn’t telling you something. Your customers’ words carry the page, and the interface steps back.

Familiar. It should feel like the tools you already use: a doc that writes like a doc, where typing # drops in a theme with its count. Nothing to learn before you start.

A joy to work with. Quick enough that you explore rather than wait, and calm enough to spend an afternoon in.

And it should let you do three things well.

• Explore your data quickly. Every theme, person and quote is a click from the next, so a question takes you straight to who answered it.
• Check the evidence. Open any count to the quotes behind it before you repeat it in a meeting.
• Write a case your team wants to read. Good-looking enough to share as it is, convincing enough for a sceptic, and open for your team to comment on and argue in.

Where Nala doesn’t hold

A note about evidence should show its own limits, so here are Nala’s.

• It reads interviews and nothing else. Reviews, tickets and surveys are left out on purpose, so it stays simple.
• It doesn’t make the decision. The call in a case is always the author’s, with their name on it.
• A count says who raised a point, not how common it is. Ten interviews are ten people, not a market.
• A model writes the theme names and summaries. It does that last, from each theme’s own quotes, and never decides what counts.

If you run interviews and still lose the argument, I built this for you.

Alex