We built one good PRD from one customer call. Here's everything it actually took.

Most product teams have, by now, tried the same experiment. Grab a pile of call transcripts, support tickets, or survey exports. Paste them into Claude or ChatGPT alongside a prompt someone copied off LinkedIn. Hit go. Hope something useful comes out the other end.

Sometimes it half-works. Often it doesn't. Either way, the team does it again next week, with a slightly different prompt, on a slightly different pile of noise, and quietly hopes the outputs will be consistent enough to compare. They jump straight from capture to create and skip the step that actually matters.

We recently ran a live masterclass where we did this properly: took a single real customer transcript, and in front of an audience, with no shortcuts, built it up, piece by piece, into a structured product requirements document grounded entirely in what the customer actually said. No magic prompt. No secret model. Just the techniques that any product team can use today, applied with real discipline.

It took thirty minutes of focused expert effort to turn one conversation into one good document on one topic.

That's the headline worth sitting with. Not because the techniques don't work, they work brilliantly, and we're going to walk through every one of them below, because every product leader should understand them. But because what that thirty minutes really revealed is the size of the job behind the job. If this is what it costs to do it well once, what does it cost to do it well always, across every call, every ticket, every topic, every week, for a team that has better things to do than babysit a prompt?

Let's break down what it actually takes.

The trap: jumping straight from capture to create

Here's the pattern we see in nearly every team that's "dabbling" with AI for customer research: they capture noisy, messy inputs, call recordings, support threads, sales notes, survey verbatims, all in different shapes and formats and try to smash them directly into a prompt that's meant to produce a finished output. A summary. A list of feature requests. A roadmap brief.

It's an understandable instinct. The model is right there. The transcript is right there. Why not just ask it for what you want?

The answer is that you end up with outputs you can't trust, can't compare, and can't repeat. One week's "top customer pain points" looks nothing like last week's, not because the customers changed their minds, but because the prompt did. There's no consistency, because there's no structure underneath - just raw noise, in, and a plausible-sounding paragraph, out.

What's missing is the step in the middle.

Capture, codify, create - the step everyone skips

The teams who get real, lasting value from AI-driven research don't go straight from raw input to polished output. They insert a deliberate middle stage: codify. Before you ask a model to summarise, recommend, or draft anything, you first turn your noisy inputs into clean, structured, comparable signal, and you store that signal somewhere durable, whether that's a spreadsheet, a database, or a proper insight repository.

This single shift changes everything downstream. Once your customer conversations exist as compressed, structured statements rather than sprawling transcripts, you can aggregate them, filter them, search them, and build on them, regardless of whether they originally came from a sales call, a support ticket, an email, or a Slack thread. The format becomes the great leveller. Source stops mattering. Signal is all that's left.

It's a simple idea. It's also the part of the process that has to happen every single time, for every single input, with enough consistency that the signal you extract in January still means the same thing and lines up cleanly, with the signal you extract in September. That's not a prompting trick. That's an operating discipline.

Turning a transcript into "voice of the customer" - the real craft of signal extraction

This is where the masterclass got hands-on, and where the real expertise lives. We took a genuine call transcript, speaker-attributed, timestamped, the works - and iteratively built a prompt to turn it into clean, structured "voice of the customer" statements.

The first attempt, as always, was rough: a wall of text, a summary table nobody asked for, the same idea expressed three different ways, padded out with a prefix and a suffix that made it useless for pasting into anything resembling a database. So we refined it. Again. And again.

We used Markdown emphasis to draw the model's attention to the concept that mattered ("workflow", in this case LLMs read emphasis the way people do). We added explicit rules: no prefix, no suffix, one concept per statement, only output items backed by a clear customer need or ask. We forced consistency by requiring every statement to follow an action-oriented "I want to [do X], so that [Y]" structure, the exact format any product manager would recognise from a well-run discovery process. And, critically, we gave the output somewhere to put context: a CSV format with headers for participant name, timestamp, statement, and context, so that nothing - including who said it and when - got lost along the way.

What came out the other end was a clean, structured table of real customer language: comparable, filterable, attributable, and ready to sit in a spreadsheet next to hundreds of others just like it.

What it took to get there was somewhere north of eight distinct rounds of refinement, each one correcting a problem the last one had introduced, because that's how prompting actually works. Tighten one rule, and you may quietly contradict another (we found this out the hard way: ask a model to "follow this exact sentence format" and "include context with each statement," and it will simply drop the context, because you never told it where to put it). Good prompt design isn't a single clever instruction. It's a long, careful negotiation with a system that takes everything you've ever told it literally, and forgets nothing.

And here's the thing worth noticing, that entire negotiation has to happen again for the next topic. And the one after that. Across every new data source, every format quirk, every shift in the underlying model. One excellent prompt, tuned for one topic, on one transcript, is a prototype, not a process. Giving the model eyes and ears: tool calling and zero-shot prompting.

The next technique solves a smaller, more specific friction point, and it's a genuinely useful one to know about. Modern LLMs can be connected to external tools through the Model Context Protocol (MCP): things like web search, CRM lookups, or document retrieval, which the model can activate on its own, mid-conversation, based on the guidance you give it.

In the masterclass, we gave the model access to a web search tool and asked it, in a single "zero-shot" instruction, with no examples provided, to read the homepage at a given URL and write a concise paragraph describing the business. No copy-pasting. No manual research. The model recognised the link, understood it could use the search tool to resolve it, fetched the content, and produced a usable paragraph of business context, unprompted by any further instruction from us.

It's a small thing. It's also a glimpse of where the puck is heading: less manual context-gathering, more models that go and get what they need. But notice the scale of what was actually automated here, one homepage, fetched once, for one paragraph of context. A real research operation doesn't run on one paragraph about one company. It runs on context about thousands of accounts, contacts, conversations, and competitors, refreshed continuously, not assembled one tool-call at a time by someone who happens to remember to ask.

Letting the model write its own brief: meta-prompting

If the first technique was about disciplining the model's output, this one is about disciplining its understanding, and it's arguably the cleverest trick in the whole session.

Rather than writing a persona prompt ourselves and hoping it landed well, we asked the model to help us build one. We told it, plainly, what we were trying to do, "help me create a role prompt for a language model that will act as a product researcher for a B2B SaaS company" and let it run a two-stage process: first, a consultation, in which it asked us clarifying questions about our research goals, our target customers, and the kind of analysis we wanted; second, generation, in which it used our answers to produce a detailed, reusable persona.

This is meta-prompting: using the model to design the instructions that will later guide the model. It's a technique that rewards transparency, the more context you give it about what you're trying to achieve, the sharper the brief it builds for itself. And it produces something genuinely valuable: a persona and a business description that, once built, measurably improve the quality, relevance, and specificity of everything that follows.

Which raises the obvious next question. That persona, that business context, they're now genuinely useful assets. So where do they live? Who keeps them current as the business evolves? And how do you make sure that everyone on a ten-person product team is using the same version of them, rather than each person's personal copy slowly drifting out of sync with reality?

From hundreds of insights to one document

This is where everything we'd built came together and where the masterclass produced its aha moment.

We took the codified, structured "voice of the customer" signal, hundreds and hundreds of individual statements on a single topic, exported from Four/Four and fed it into a single, carefully constructed prompt. Alongside it, we provided the business description we'd generated through tool calling, the persona we'd built through meta-prompting, and a structured PRD template written in Markdown, headers and all, ready to be filled in like a form.

The result: a draft product requirements document, grounded in real customer language, shaped by genuine business context, written in the voice of a product researcher who actually understood the brief, all from inputs that, individually, were just noisy conversations a few minutes earlier. It's a genuinely impressive output. It's also worth being honest about what produced it, hundreds of insights, manually exported, manually pasted, manually reassembled, by someone who had already spent the previous twenty-five minutes hand-building the very prompt that made sense of them. to produce one document, on one topic, once.

What this exercise actually proved

Here's the honest reflection, the one most "AI productivity" content skips entirely, everything you've just read is real, valuable, and worth knowing. Document processing, tool calling, meta-prompting, persona design, structured assembly, these are not gimmicks. They are the genuine building blocks of high-quality, AI-assisted customer research, and any product leader who understands them will get more out of Claude, ChatGPT, or any other model than someone who doesn't.

But notice what it took to get one good output. A skilled practitioner. Thirty focused minutes. Eight-plus rounds of prompt refinement. A web search bolted on by hand. A persona built through a guided back-and-forth. A spreadsheet export, copied and pasted, of insights that already existed in structured form somewhere else.

Now multiply that by every topic your team cares about. Every account you want to understand. Every quarter you need fresh evidence for the roadmap. Every new hire who needs to be brought up to speed on how "we" do this, so the outputs stay consistent across the team rather than drifting apart, prompt by prompt, person by person.

That's not a prompting problem anymore. That's an operating model.

Capture, codify, create - run as a system, not a side project

The framework underneath everything we demonstrated is simple to describe: capture your customer conversations from every channel, codify them into structured, comparable signal, and create outputs - PRDs, personas, journey maps, roadmap briefs - with the confidence that comes from evidence rather than anecdote.

Doing this once, by hand, for one topic, is a genuinely valuable exercise and we'd encourage every product leader to try it, because it builds real intuition for how these models think and where they need guiding. Doing it continuously, consistently, and at the scale a real B2B SaaS business operates at across tens of thousands of conversations, dozens of topics, and every team that needs to act on what customers are saying, is a different undertaking entirely. It's the reason we built Four/Four: to run capture, codify, and create as a continuous system, so your team spends its thirty minutes on the decisions that come after the evidence, not on assembling the evidence itself.

If you'd like to see what that looks like when it's running quietly in the background of your business, on every call, every ticket, every topic, all the time - we'd be glad to show you.