I sat down at 6 p.m. after a customer call I'd been excited about all day. I had two hours before I lost the thread. I needed to write up the call, draft a pitch, sketch the screens, and break the work into stories the team could pick up Monday. I knew how to do every step. I also knew I'd be lucky to get through two of the four.
That gap — between final customer validations and a working ticket the team can run with — is where most of a PM's week disappears. The judgment lives in two places: the original conversations/decisions/mock-ups, and the final prioritization decision. Everything in between is translation. I time-boxed two weeks to measure it: roughly 10–15 hours per week of pure translation work.
Well, that was before.
This article is a playbook for what I do now instead.
What this pipeline is not is "AI builds features from a customer call.".
A single call is N=1; a pain point one customer mentioned is a hypothesis, not a finding. If I let one conversation flow straight into a sized epic, I'd be doing worse PM work, not better.
Ultimately, the pipeline is a way to turn a pattern across multiple calls into a scoped, build-ready epic, without slowing down.
The pipeline below has data validation and experimentation baked in; those two elements are the reason the mechanical parts can move fast without lowering quality.
Here’s what you’ll need to make this happen:
Practices
Each stage below uses the same shape: what the stage does, what you need wired up, the prompt to paste, and the one thing that will bite you.
Turn a single call transcript into a hypothesis register — every claim tagged with a confidence label and a timestamp quote — so future-you can argue with evidence, not your memory.
A transcript (Zoom, Otter, or your recording tool's export).
Sample-size confidence inflation. Without the explicit single customer framing, the model will write findings, not hypotheses.
Take one hypothesis at a time and test it against real usage, not just the handful of calls it came from. Where that usage data lives depends on your stack, for me, it's SQL for the simple stuff and Python for anything that spans more than one database, but whatever your setup, the goal is the same: confirm the idea is worth building and the math behind it holds up. It's tempting to skip this step, since it's more work and a hypothesis can already feel obvious enough to build on. But this is where you find out if the pain point is real, or just specific to whoever mentioned it. If it holds up, it earns a pitch. If it doesn't, you've just saved yourself from building the wrong thing.
Read access to your warehouse, your reporting tool open in another tab, and the SQL dialect your tool uses (the cross-dialect SQL bug is the most common silent failure here — CURDATE() vs CURRENT_DATE, GROUP_CONCAT vs LISTAGG).
The version below is tuned to my setup. It uses MySQL through Mode, and Python for anything that spans more than one database. Yours will look different depending on your stack, so treat this as a worked example. A few things should carry over: test one hypothesis at a time, write a query that could prove it wrong, not just confirm it, and say upfront what result would falsify it.
Quick glossary for the prompt example below. A dialect is just which flavor of SQL your tool speaks. MySQL, Postgres, and BigQuery each phrase things slightly differently. A load-bearing assumption is a guess the LLM you're using has to make about your data, like which column connects two tables, that the whole answer depends on. If that guess is wrong, the LLM might still hand you an output, it's just the wrong one. So, the trick here in this prompt asks the model to label these assumptions directly in the code, so you know exactly which parts to check instead of guessing.
Cross-dialect SQL fragility. Prompt for the dialect upfront and treat the first result as "is this plausible?" not "is this true?"
This stage turns the synthesis and the data slice into a pitch document, ordered unknown-first so reviewers spend their attention on what's actually risky, not on what's already decided. That pitch gets written up and published to a specific page in Confluence, which means the model first needs to find the right space to publish into. That lookup comes back in batches, roughly the first 50 spaces at a time, so if you have more spaces than that, yours could land further down the list. When that happens, a second lookup call simply asks for the next batch until it finds the right one.
A Confluence MCP connector and a known parent page for pitches. Confluence organizes pages into spaces, and the API that looks them up paginates.
The connector paginates its results. Your space might not show up in the first 50, so build in a second lookup call. Otherwise the page won't land where you expect.
This stage picks up the pitch that just got approved in Stage 3 and turns it into something testable. Produce two artifacts in one pass: a tight design brief and an experiment plan with a pre-committed metric, threshold, and kill criteria. The pitch getting approved doesn't green-light the feature. It only green-lights running the experiment, nothing more.
The Figma MCP (figma.com/mcp) for reading existing components and a feature-flag tool (LaunchDarkly, ConfigCat, Statsig, etc.) for the experiment.
The MCP is great at reading existing components and producing component-by-component specs; it is not a finished-prototype maker. Treat its output as a brief, not a design.
Once the experiment gives you real confidence the idea works, for example, a higher chance free users convert to paid, create the epic and child stories in parallel. The guard rail — do one first, then fan out — is baked into the prompt.
A Jira MCP connector and your project key, team name, and assignee handle ready.
JQL date syntax is fragile across tenants. status changed to Done during (-7d, now()) doesn't work on every instance. If a query reads zero rows, retry with an alternate clause before believing the result.
The honest version of this article needs a failure, lol.
In an early version — before the Stage 2 data pass existed — a synthesis from a single call flowed straight into a pitch. We had a story sized and ready before I re-listened to the call and realized the customer had walked the "must-have" comment back two minutes later. I'd shipped a hypothesis into the pipeline as a finding because nothing was checking whether the hypothesis held.
Stage 2 exists because of that failure. Adding it cost about a day of prompt iteration and roughly two minutes per pitch at runtime. It is the single biggest quality improvement the pipeline has had.
Sending customer transcripts to an LLM has consequences.
Before any of this went live, I confirmed (1) the LLM provider's enterprise plan does not train on submitted data, and (2) the transcripts go through a PII redaction pass before they leave the recording tool.
Your compliance answer may differ.
If you can't square these two, the pipeline shouldn't run on real customer audio yet — it still runs on your own synthesis notes, which is most of the value.
N=1 anecdotes will quietly become roadmap weight if Stage 2 isn't wired in. The two minutes per pitch the data pass costs is the cheapest insurance in the workflow. Also, as PMs there’s recency bias we need to consider
End every multi-tool prompt with "flag any tool call that returned nothing useful." Otherwise you get clean-looking briefs built on missing data.
Six weeks later the team builds against the framing in the AC. Make the synthesis step preserve direct quotes with timestamps, and require the ticket step to use them verbatim.
When the model is about to make many similar API calls, prompt it to run one first, confirm the response shape, then fan out. One-line addition. Prevents twelve identical errors at once.
The point isn't that AI files tickets. The point is that the discovery-to-delivery loop is mostly translation work, and translation is now cheap.
What that buys isn't speed. It's focus.
When the mechanical layer collapses, the only thing left is the judgment work — sizing the problem, designing the experiment, deciding what's worth doing now versus later. That's the part of the job that's hard, and the part I want to spend my time on.
The 6 p.m. call I opened with doesn’t turn into a sprint epic that same night. Instead, it becomes a hypothesis register, a data slice the next morning, a pitch by the afternoon, a prototype test the following week, and an epic only if the test shows enough promise to justify building an MVP and putting it in front of real users. What's changed isn't the rigor. It's the time it takes to get the rigor done.
For PMs reading this, the question worth asking isn't "what should I automate?" It's:
Which translation tasks am I doing by hand because that's how I learned the job — and what would change about the time I spend on validation, sizing, and experiments if I stopped?
Mentorship program and in-person event experiences are at an extra cost.
Join for free!Join the TPMA Slack Community with 1000+ members
Free Virtual TPMA events for the entire TPMA Season
Become the first to know about in-person events and networking opportunities
I sat down at 6 p.m. after a customer call I'd been excited about all day. I had two hours before I lost the thread. I needed to write up the call, draft a pitch, sketch the screens, and break the work into stories the team could pick up Monday. I knew how to do every step. I also knew I'd be lucky to get through two of the four.
That gap — between final customer validations and a working ticket the team can run with — is where most of a PM's week disappears. The judgment lives in two places: the original conversations/decisions/mock-ups, and the final prioritization decision. Everything in between is translation. I time-boxed two weeks to measure it: roughly 10–15 hours per week of pure translation work.
Well, that was before.
This article is a playbook for what I do now instead.
What this pipeline is not is "AI builds features from a customer call.".
A single call is N=1; a pain point one customer mentioned is a hypothesis, not a finding. If I let one conversation flow straight into a sized epic, I'd be doing worse PM work, not better.
Ultimately, the pipeline is a way to turn a pattern across multiple calls into a scoped, build-ready epic, without slowing down.
The pipeline below has data validation and experimentation baked in; those two elements are the reason the mechanical parts can move fast without lowering quality.
Here’s what you’ll need to make this happen:
Practices
Each stage below uses the same shape: what the stage does, what you need wired up, the prompt to paste, and the one thing that will bite you.
Turn a single call transcript into a hypothesis register — every claim tagged with a confidence label and a timestamp quote — so future-you can argue with evidence, not your memory.
A transcript (Zoom, Otter, or your recording tool's export).
Sample-size confidence inflation. Without the explicit single customer framing, the model will write findings, not hypotheses.
Take one hypothesis at a time and test it against real usage, not just the handful of calls it came from. Where that usage data lives depends on your stack, for me, it's SQL for the simple stuff and Python for anything that spans more than one database, but whatever your setup, the goal is the same: confirm the idea is worth building and the math behind it holds up. It's tempting to skip this step, since it's more work and a hypothesis can already feel obvious enough to build on. But this is where you find out if the pain point is real, or just specific to whoever mentioned it. If it holds up, it earns a pitch. If it doesn't, you've just saved yourself from building the wrong thing.
Read access to your warehouse, your reporting tool open in another tab, and the SQL dialect your tool uses (the cross-dialect SQL bug is the most common silent failure here — CURDATE() vs CURRENT_DATE, GROUP_CONCAT vs LISTAGG).
The version below is tuned to my setup. It uses MySQL through Mode, and Python for anything that spans more than one database. Yours will look different depending on your stack, so treat this as a worked example. A few things should carry over: test one hypothesis at a time, write a query that could prove it wrong, not just confirm it, and say upfront what result would falsify it.
Quick glossary for the prompt example below. A dialect is just which flavor of SQL your tool speaks. MySQL, Postgres, and BigQuery each phrase things slightly differently. A load-bearing assumption is a guess the LLM you're using has to make about your data, like which column connects two tables, that the whole answer depends on. If that guess is wrong, the LLM might still hand you an output, it's just the wrong one. So, the trick here in this prompt asks the model to label these assumptions directly in the code, so you know exactly which parts to check instead of guessing.
Cross-dialect SQL fragility. Prompt for the dialect upfront and treat the first result as "is this plausible?" not "is this true?"
This stage turns the synthesis and the data slice into a pitch document, ordered unknown-first so reviewers spend their attention on what's actually risky, not on what's already decided. That pitch gets written up and published to a specific page in Confluence, which means the model first needs to find the right space to publish into. That lookup comes back in batches, roughly the first 50 spaces at a time, so if you have more spaces than that, yours could land further down the list. When that happens, a second lookup call simply asks for the next batch until it finds the right one.
A Confluence MCP connector and a known parent page for pitches. Confluence organizes pages into spaces, and the API that looks them up paginates.
The connector paginates its results. Your space might not show up in the first 50, so build in a second lookup call. Otherwise the page won't land where you expect.
This stage picks up the pitch that just got approved in Stage 3 and turns it into something testable. Produce two artifacts in one pass: a tight design brief and an experiment plan with a pre-committed metric, threshold, and kill criteria. The pitch getting approved doesn't green-light the feature. It only green-lights running the experiment, nothing more.
The Figma MCP (figma.com/mcp) for reading existing components and a feature-flag tool (LaunchDarkly, ConfigCat, Statsig, etc.) for the experiment.
The MCP is great at reading existing components and producing component-by-component specs; it is not a finished-prototype maker. Treat its output as a brief, not a design.
Once the experiment gives you real confidence the idea works, for example, a higher chance free users convert to paid, create the epic and child stories in parallel. The guard rail — do one first, then fan out — is baked into the prompt.
A Jira MCP connector and your project key, team name, and assignee handle ready.
JQL date syntax is fragile across tenants. status changed to Done during (-7d, now()) doesn't work on every instance. If a query reads zero rows, retry with an alternate clause before believing the result.
The honest version of this article needs a failure, lol.
In an early version — before the Stage 2 data pass existed — a synthesis from a single call flowed straight into a pitch. We had a story sized and ready before I re-listened to the call and realized the customer had walked the "must-have" comment back two minutes later. I'd shipped a hypothesis into the pipeline as a finding because nothing was checking whether the hypothesis held.
Stage 2 exists because of that failure. Adding it cost about a day of prompt iteration and roughly two minutes per pitch at runtime. It is the single biggest quality improvement the pipeline has had.
Sending customer transcripts to an LLM has consequences.
Before any of this went live, I confirmed (1) the LLM provider's enterprise plan does not train on submitted data, and (2) the transcripts go through a PII redaction pass before they leave the recording tool.
Your compliance answer may differ.
If you can't square these two, the pipeline shouldn't run on real customer audio yet — it still runs on your own synthesis notes, which is most of the value.
N=1 anecdotes will quietly become roadmap weight if Stage 2 isn't wired in. The two minutes per pitch the data pass costs is the cheapest insurance in the workflow. Also, as PMs there’s recency bias we need to consider
End every multi-tool prompt with "flag any tool call that returned nothing useful." Otherwise you get clean-looking briefs built on missing data.
Six weeks later the team builds against the framing in the AC. Make the synthesis step preserve direct quotes with timestamps, and require the ticket step to use them verbatim.
When the model is about to make many similar API calls, prompt it to run one first, confirm the response shape, then fan out. One-line addition. Prevents twelve identical errors at once.
The point isn't that AI files tickets. The point is that the discovery-to-delivery loop is mostly translation work, and translation is now cheap.
What that buys isn't speed. It's focus.
When the mechanical layer collapses, the only thing left is the judgment work — sizing the problem, designing the experiment, deciding what's worth doing now versus later. That's the part of the job that's hard, and the part I want to spend my time on.
The 6 p.m. call I opened with doesn’t turn into a sprint epic that same night. Instead, it becomes a hypothesis register, a data slice the next morning, a pitch by the afternoon, a prototype test the following week, and an epic only if the test shows enough promise to justify building an MVP and putting it in front of real users. What's changed isn't the rigor. It's the time it takes to get the rigor done.
For PMs reading this, the question worth asking isn't "what should I automate?" It's:
Which translation tasks am I doing by hand because that's how I learned the job — and what would change about the time I spend on validation, sizing, and experiments if I stopped?
Toronto Product Management Association (TPMA) is a community focused on development, growth and networking of Product professionals in the Greater Toronto Area.
