Skip to content
Founder Communications

How to capture stories as your team scales

Solo founders see every story. Past 5 to 10 people, roles silo and stories stop surfacing naturally. Three systems that fix it: data anyone can query, cross-team transcript mining, regular founder cadence.

By Justin DeMarchiFebruary 10, 20266 min read
In this article· 7 sections
How to capture stories as your team scales

A solo founder sees every story. They take the customer call, ship the feature, hire the contractor, write the post. Nothing surfaces because nothing is buried. The pulse is intact.

A two-person team is the same. Three, mostly the same. Past 5 to 10 people, roles silo. Sales talks to the real customer. Engineers ship the feature. Support sees the usage pattern. The marketing team writes the content. Each one knows their corner. Nobody owns "what is the company's story this week."

Stories do not stop happening as you scale. They stop reaching the people who write about them.

The fix is not to ask the founder harder. It is to build the systems that make stories visible across the company. Three of them compound.

What goes wrong with story extraction by default?

The default state in a 20-person B2B company looks like this. Sales takes 60 calls a month and logs notes to the CRM. Product ships features and writes them up in a release log. Customer support handles tickets and closes them. Marketing writes the content. Each system runs.

None of those systems pass material to the marketing team. CRM notes are CRM-shaped, not story-shaped. The release log is feature-shaped. Support tickets close. The marketing team is left with whatever they happened to overhear in Slack and a vague sense that interesting stuff is happening somewhere they cannot see. The founder used to be the connector when there were five people. Past 15, the founder is in board prep, fundraising, customer onboarding for the largest accounts. The connector role does not get reassigned. It just stops happening.

How do you build a queryable internal data layer?

The first system fixes a specific failure: the marketing team has to file a ticket every time they need a number for a piece of content.

Build the internal data layer so non-engineers can query it directly. Connect Claude or a similar AI assistant to your data warehouse or your production database, read-only and scoped. The marketing team should be able to ask, in plain English, "what is our median time-to-value for paid users in Q2," and get the answer without pulling an engineer off the roadmap.

The pattern that fails: writing the article first, then hunting for four data points to support it. Those points end up shoehorned. The piece reads as forced.

The pattern that works: identify the metrics that matter early. The two or three numbers that, if they shift, change how the company tells its story. Build the system to monitor them. Keep them visible across the team. Reference them in content as they shift. The content reads as grounded because it is.

How do you mine cross-team transcripts for stories?

The second system targets the most underused source of stories in a B2B company: sales call transcripts.

Sales talks to real customers about real pain points every day. Most teams transcribe calls for the CRM and never analyze them for patterns. The transcripts sit in a database and get used only for individual deal-tracking.

Run a month of those transcripts through Claude or a similar model with prompts about:

  • Recurring objections that signal a positioning gap
  • The exact phrases customers use to describe the problem, which usually do not match the marketing team's language
  • The moments deals turned, good or bad
  • What customers ask that the team has no good answer to

The output is two things at once. Content material, because verbatim customer language is the highest-conversion asset on a landing page or in a post. And product insight, because the same patterns that make for good content also surface what to build.

This applies beyond sales. Customer success calls, onboarding sessions, exit interviews, support tickets at volume. Anywhere customers are talking, there is content material the marketing team is not seeing.

What does a regular founder cadence look like?

The third system addresses what the founder was doing when there were five people: connecting the dots, telling the team what they were noticing.

Sit down with the founder every one or two weeks for 30 to 45 minutes. Not only when a white paper is due. The cadence is the point.

Capture what changed in the last week or two, what is bothering them, what a customer said that stuck. The interview playbook covers the in-the-room craft.

The compounding effect is real. By month three, the content team has multiple hours of footage and transcripts to draw from. By month six, the content team is no longer asking the founder for stories.

Compare to the reactive version: the marketing team finally needs a white paper, schedules a single 90-minute interview with the founder, the founder shows up unprepared, and the team gets one good story out of it. The cadenced version has produced 30 to 40 hours of recordings by then.

How do you track customer baselines and outcomes?

The fourth system targets a specific gap: most B2B companies talk about customer outcomes in the abstract because they never captured the baseline that would make outcomes provable.

A baseline is a measurement at customer onboarding. Where they are at the day they sign. What success means for them specifically. What they are trying to fix. The metrics that matter to their business, not yours.

Capture it deliberately at the start. Then check progress at natural milestones: 30 days, 60 days, 90 days, end of year. The format does not matter. A short async survey, a 15-minute call with the customer success lead, a structured note in the CRM. What matters is that it gets captured at known points and stored where it can be referenced.

The output is a library of customer-journey stories with real before-and-after numbers. Not "we helped them grow," but "they signed at $X MRR with Y% activation rate, and at 90 days they were at 2X MRR with Y plus 15 points." That specificity is what makes case studies, sales decks, landing page proof, and content travel. Without baseline capture, those numbers do not exist, which is why most B2B case studies read like marketing instead of evidence.

This is also the system that catches insights the customer does not articulate themselves. Six months in, customer success can see that customers who started with X behavior end up with Y outcome. That pattern is content material, product insight, and a sales argument all at once.

The setup cost is real. Somebody has to design the baseline, train customer success to capture it consistently, build the place where the data lives. But the payoff compounds. After a year, the company has structured before-and-after data on every customer, which is the highest-conversion content asset a B2B company can build.

Why does systematic capture beat reactive extraction?

Reactive extraction (we need a story for this article) produces forced, generic content. The team works backward from a brief and the output reads like backfill.

Systematic capture (we have data, customer voice, and the founder's thinking on a regular cadence) produces a content bank. Each piece of content is a draw from the bank, not a fresh hunt. The bank is the compounding asset.

The shift is from "interview before publishing" to "have already interviewed for the last six months." Same hours of founder time. Different yield.

A coda

Stories do not disappear as you scale. They stop reaching the people who write about them.

Every B2B company past 10 to 15 people accumulates more story material than the marketing team can capture without a system. The default response is to ask the founder harder. The actual move is to build the capture infrastructure: data anyone can query, transcripts mined for patterns, a regular cadence that catches the founder's thinking before it disappears into the next priority.

For the in-the-room craft of a single interview session, see interviewing a founder. For the wider arc this sits inside, the founder storytelling guide covers extraction, shaping, and deployment end to end.

Frequently asked

Common questions.

  • Why do stories stop surfacing as a company scales?

    Roles silo. Sales talks to customers but logs only to the CRM. Engineers ship features that solve specific user problems but never tell those problems as stories. Customer support sees actual usage patterns the marketing team never hears about. Past 5 to 10 people, the content team becomes the only group thinking about story capture, and they cannot be everywhere.

  • What is the most underused source of stories inside a B2B company?

    Sales call transcripts. Most teams transcribe calls for the CRM and never analyze them for patterns. Run a month of transcripts through Claude or a similar model with a prompt about objections, customer language, and the moments deals turned. The output is both content material and product insight.

  • What kind of data system should a content team have access to?

    Anything that lets non-engineers query the data without filing a ticket. Connect Claude or a similar AI to your data warehouse or production database (read-only, scoped). Marketing should be able to ask 'what is our median time-to-value for paid users in Q2' and get the answer without pulling the dev team off the roadmap.

  • How often should a content team interview the founder?

    Every one or two weeks for 30 to 45 minutes. Not only when a white paper is due. The cadence captures what changed, what is bothering them, what a customer said. By month three the content team has multiple hours of material to draw from instead of starting from scratch on every piece.

  • What is the wrong way to use data in founder content?

    Writing the article first and then hunting for four data points to support it. The data ends up shoehorned. The reverse is the move: identify the metrics that matter early, build the system to monitor them, keep them visible across the team. Reference them in content as they shift.

Justin DeMarchi
Written by

Justin DeMarchi

B2B content engineer and founder of DUO. Eight-plus years running marketing and content systems for brands in tech, SaaS, and AI.

More in Founder Communications