A system is just a bunch of small parts working in concert

Imagine your CEO walking up to you saying: “I need you to figure out where we were delivering value to customers in specific markets.” I have to assume some variation of this has happened to you, too.

I'd been reading Crossing the Chasm by Geoffrey Moore, and one idea stuck with me: A market is a group of customers who can reference each other. I know I should know this, and I’m embarrassed to admit this, but if you’re like me, it’s sometimes easy to forget these core principles. 

The pragmatic buyers, who make up most of any market, don’t know you. Rude. They want to buy from someone who already understands their industry and has helped companies like theirs solve similar problems. Basically, they buy from the market leader. Ok, I get it.

I'm only reading tea leaves here, but I think that going into 2027 more companies like yours will need a real vertical strategy. I figured out a way to find those use cases with Claude Code, and in this post I'll show you how you can do it too.

Here's what we're going to learn today

1. How to structure a week of customer evidence so an agent can spot patterns in it instead of just summarizing it.

2. The handful of conventions that decide whether your file is a database or a pile of assertions.

3. Why a controlled vocabulary matters more than the prompt, and the exact way its absence hides a real pattern in your data. I know this sounds a little confusing, but I promise it’ll make sense later!

4. How to write a gated prompt that stops to keep you in the loop, so you catch a wrong row before anything is built on it.

5. How to build an agent that can say no, challenge you, or remind you of your own rules, plus a judgment log that records every call you make as the human in the loop.

6. The question everybody skips: not what transfers into a new market, but what breaks.

Ok, so, what are horizontal and vertical use cases?

Horizontal use cases are the problems your company solves really well: the jobs to be done your product serves across many industries, presented in much the same way everywhere.

A vertical use case is different from taking a horizontal one and tweaking the language and examples for a market. A vertical use case is a pain felt only in one market, where you have evidence somewhere in your organization that you already help solve it.

Here's an example from the data in this post:

• The Science Based Targets initiative (SBTi) is how a company gets its carbon reduction targets approved by a third party. Helping companies report to SBTi is a horizontal use case for a carbon accounting company, because many industries need it. 

• But food companies have additional requirements that are specific to their industry, and if your product has specific capabilities for that, you have a vertical use case. 

That's what we're going after: the value you already deliver in one market that isn't in the list of use cases you take to market today.

Before an agent can find those, it needs your customer data gathered and structured. So this post has two parts: first a structured database, then the vertical use case writer that works with it. Hang with me.

You might be wondering how you’re going to build this if you don’t have access to a bunch of data. Don’t worry, I got you covered!

For this post I've prepared two things for you:

1. Rootline. A completely fake carbon accounting company I built using what I know about the industry. Every example below comes from it.

2. Four weeks of Rootline's customer data. 45 call transcripts (three of them internal pipeline reviews), 18 email threads, CRM exports, NPS, CSAT, Slack and testimonials, covering weeks 33 to 36 of 2026. I made this data messy to reflect the reality of your business.

You can grab all of it for free at https://github.com/vittycent/Structured-Database. If you can't use your own company's customer data, which is most people the first time, build this on Rootline instead. You'll need a Claude Pro subscription and we’ll use Claude Code for this exercise. 

Do this: download the Rootline data before you read on.

Let's set the stage here

Here's the whole system on a single 2x2 view. Every section after this zooms into one of these four boxes, so come back here if you need it.

The structured database is your hub. It hands the vertical use case writer exactly the right amount of context, which is how these models work best today. 

Instead of pasting in a year of raw transcripts and hoping for the best, the writer reads one organized file where every line points back to where it came from.

And because it's written for agents as well as for you, you can spin up another agent for whatever you're working on this month, like messaging or a go-to-market plan, connect it to the database, put it in the recycling bin for a while, and bring it back when you need it again.

Do this: redraw the first box with your own company's sources in it. That list is your scope for week one.

Two important tables hold this structured database together

One of the things I learned the hard way was not building a register of accounts from day one. I don’t want you to make this same mistake. If you don't tie every quote and insight to a specific customer account, you can't go back later and find the evidence behind a claim. 

Downstream, when other agents are working with the data, you end up with insights you can't defend or bring back into the organization. And that sucks for so many reasons I can’t even list them all here.

So the structured database rests on two tables, and everything else is derived from them.

• Account register. One row per account: vertical, ICP fit, and an independence group (more on that in the next section). Rows get corrected, never duplicated. Honestly, this is ordinary data hygiene and it's a bit boring, but it's what makes the numbers you eventually share defensible.

• Observation log. One row per thing a customer said, tied to an account. If a customer makes three separate points on one call, that's three rows. Rows get appended, never edited or deleted. This gives your agent a compass: when it finds a quote, it knows exactly which transcript, CRM record or NPS response to go back to.

Together they're the source of truth, the good book you’ll return to. Everything else in the file, like the pattern counts, the use case summaries and the signals and claims tables you'll see later, is built from these two. If one of those summaries ever disagrees with the log, the log wins. Every summary also carries a "recomputed as of" line saying which week it was last recalculated, so an agent can tell whether it's current.

A known limit: both tables get long fast. Rootline's observation log passed 300 rows quickly. For this example I kept everything in one file, but at work I'd move the register and the log into their own file and have the structured database point to it. I also built this locally on my machine, but this could be replicated with Notion, GitHub or wherever your team keeps things.

Here's what that looks like for one call.

Example 1: One call, seven rows

The source. Nordisk Emballage qualification call, 10 August 2026, 27 min 55 sec. Auto transcribed, not corrected.

[00:01:37] Erik Lindqvist: So your customer is asking you for product level data. Not a corporate number, specifically product level, per unit.

[00:01:44] Rune Dahlbäck: Three customers now. All food. And they all want something slightly different, which is the annoying part.

What came out of it. Seven rows in the account's first week: five from the call, one from the deal note the AE attached to it, one from a Slack thread about the deal.

What to notice. Every row carries a file path and a timestamp, so any claim built on it walks back to the second of the call it came from. (AFNS-3 and 4 in the use case column are Rootline's own use case IDs.) Five rows are the customer speaking. Two are relayed, because a deal note and a Slack message are your own people describing a customer, and you never quote those externally as customer words. O-0005 has no use case, which is correct and pretty common. And the row that matters most six weeks later is O-0007, a throwaway Slack line about a second non food deal.

Do this: create the two tables. Nothing else yet. You can add every other section later without rewriting these.

The conventions that carry the weight in the structured database

These rules sit at the top of the structured database, written in plain language, and every agent reads them before it touches the data. 

That way the instructions are built right into the file, and the agent doesn't have to work out how to read it. Remember who you're building it for: not only you, with all the context in your head, but other agents too.

A few of these are worth a closer look.

Count independence groups. An independence group is a set of accounts that can't be counted as separate voices. If five brands owned by the same food group all raise the same problem, that's one voice, not five. Two accounts belong in the same group when they share a parent, a consultancy or a buying consortium, or when the same person now works at both. A CRM export has no field for this, so a register built from one puts every account in its own group and inflates every count. You have to read the transcripts for it on purpose.

Don't leave blanks. Your CRM will have plenty of them. The problem is that a blank can mean three things: nobody asked, the customer didn't know, or the field doesn't apply. Don't leave one for the agent to wonder about, or it'll spend credits working out which. Write unknown or not applicable. You don't have to explain why it's missing. You just name it, and the agent moves on.

Give negatives a home. That's a counter evidence table: accounts that were asked and didn't have the problem. Without it, patterns can only ever grow, because nothing records the times a problem didn't show up. Here's Rootline's.

Example 2: Counter evidence

Notice the unassigned row. A negative that doesn't belong to a pattern yet still gets written down. You haven't thought of every pattern in your data yet, so this lets you group those later and reassign them once you've built out a pattern you like.

Do this: hold your existing customer research doc up against these eight. Most fail on source refs and on negatives.

Creating a dictionary of vocab unique to your business will save you a bunch of pain later

Let's pretend for a moment that your business uses language that's really confusing to outsiders, and the outsider is your agent. Every time it hits one of those terms in a transcript, it has to figure out what the heck it means. It might get there, but across this much data it's slow and easy to get wrong.

Take carbon accounting. "Auditor" can mean a financial auditor, an external assurance provider, or a customer's own sustainability consultant hired to challenge the numbers. That's what a controlled vocabulary fixes. 

It has two parts:

1. Some fields only accept values from a fixed list, like vertical, source kind, voice and buying stage, so the agent can't invent a new label every week. 

2. The file carries a glossary that says what each of your terms means in your context. That way the agent finds patterns on meaning, not on matching words.

Here's the thing I wish someone would have told me before I made this: Over three weeks, the agent writes "auditor challenge", "assurance pushback" and "audit failed our numbers" for the same thing. Each one looks like a separate item, none of them reaches the threshold for a pattern (for Rootline that's eight independent groups, more on that in the next section), and the file says the pattern doesn't exist. No error, no warning, no empty cell. It just quietly disappears.

So build in a merge rule. The agent can propose a new value or a merge, but it never coins one silently. You approve it and keep the old name as an alias, so rows written with the old term still count toward the merged one. Then you note it in the judgements log (more on that next).

Do this: list every term your company, your team and your customers use in different ways for the same thing. That's your glossary, and it only takes a couple of minutes. Then add a step to your weekly run that flags new terms to define or merge.

The weekly prompt, and the gates that make it verifiable

I want to be really clear: this prompt isn't something you queue up, walk away from to get coffee, and come back to finish. In many ways, that's the antithesis of working with AI. You work on it over an hour or two, depending on how much data your company produces. I do mine on a Monday morning in 15 to 20 minute chunks between meetings, and I'm done by lunch. It's work, like keeping any database current, and it's worth it because everything else I do that week runs on it.

The prompt runs in four gates. A gate is a checkpoint: the prompt stops, shows you its work, and waits for your go before it moves on.

1. Gate 1. Coverage and accounts. Every source reviewed gets listed, whether or not it produced anything. New accounts get ICP fit now, not later. Any account that might not be independent of another gets raised rather than guessed. Stop.

2. Gate 2. Observations. One row per thing a customer said, IDs allocated in sequence. Leaving a tag blank is correct and common. Stop, and report rows per source plus any source that produced none.

3. Gate 3. Recount, do not retype. Every register recomputed from the log, with the working shown for any status that moved. Stop.

4. Gate 4. Summaries. Every bullet ends with the observation IDs behind it. Anything unresolved goes to "open for the owner" with what it would change either way. Stop.

The stop after Gate 2 is the one that matters, because it's your last chance to fix a wrong row before every count and summary gets built on top of it. One prompt that goes from raw transcripts to a finished document produces something that looks right and can't be checked. And never let it resolve an ambiguity silently, because the most valuable output of a week is often the thing the data can't settle.

Keep a judgements log beside it, too: every call that changes what the data means, like a vocabulary merge or an account reclassified. Append only. It's how a future agent, and future you, can tell a deliberate decision apart from drift.

The test for a good week isn't how much got written. It's whether you can take any claim in a summary, follow it to a row, follow that row to a timestamp in a transcript, and find the customer actually saying it.

So what does the file actually find? Patterns. A pattern is a problem that keeps coming up across independent accounts over several weeks, and the pattern register tracks each one along with how much evidence stands behind it. Here's Rootline's after week 36.

Example 3: The pattern register

Every count derives from the observation log and can be recomputed from it.

P-01, what it is and what it would change: "The work lands on one person who has another job: quality, marketing, operations, a group manager with a queue. Hours a week, often outside working hours. If true, anything that assumes a project team, a kickoff or a weekly login is sold to someone who does not exist, and the competitor is whatever takes an afternoon."

P-12: "Lost and churned deals are recorded under price, or under nothing, because the picklist has no option for the real reason. If true, every report on why we lose is wrong in the same direction, and it is the report the board sees."

What to notice. Patterns are named in the customer's own words. A pattern only counts as confirmed with eight independent groups across three weeks, in two source kinds and two buying stages, because something said in eight discovery calls is really one situation observed eight times. And even confirmed stops at a judgement gate, where a human decides whether we'd actually change anything because of it. You can think about what this inclusion criteria could look like for your organization.

Do this: run the four gates on one week of your own sources. Keep the stops, even when it feels slow. And think about what would be the bar you’d set for calling something a pattern.

What one week adds, and where the unnamed use cases live

There are two versions of the Rootline file on purpose: one that stops at week 35, and one with week 36 loaded. Compare them and you can see what one week of a commercial team's work adds. This is an opportunity for you to check what it looks like but also run it yourself to see how it goes. A few of these are parts of the file I'll explain below: proof points are moments where a customer confirms you delivered something, and value claims are the things your company says about itself.

• 221 new observation rows from 20 sources

• A pattern reaching confirmed criteria and stopping at the judgement gate rather than promoting itself

• A pattern and a signal each opening at two new accounts

• Six new proof points

• One value claim moving to contradicted, because it finally got evidence and the evidence was against it

• A fifth row in "asked for, not served", which is where your next product conversation comes from

• Four questions left open for the owner, two of which change counts either way

Now for signals, which is where the second half of this post starts. 

A signal is something two or more independent accounts keep saying that has nowhere to go yet: it doesn't match any of your named use cases, and it hasn't hit the threshold for a pattern. It's not a theme yet, and it's not noisy either. Name it in the customer's words, never after one of your own modules, because that's how you stop being able to see it.

This is where the vertical use case writer goes looking. A signal is a clue that you might already be delivering value your use cases never named, so the writer can ask, "Is there anything in our CS transcripts showing we already deliver this?"

Example 4: Two signals

S-09 showed up in a single week, at two accounts, and it describes people doing unpaid manual work with the product in a way nobody at the company designed or sold. That's what an unnamed use case looks like before anyone names it.

The claims table works the other way around. It checks what you say about yourself against what customers say back. Every claim your company makes, on the website, in a deck or on a sales call, gets a row, and the proof points from the log get attached to it.

Example 5: A claim the evidence contradicts

Evidence status is computed, never typed:

What to notice. (The V numbers in "Backed by" are proof points.) Because the status is computed rather than typed, nobody can flatter a claim into being evidenced. Filter this table to unevidenced and you have a standing list of everything your company says about its own value that no customer has ever said back. And C-07 is on the website as a customer quote, when it started as an SDR's paraphrase.

Do this: after your first week, filter your claims table to unevidenced and read it. It's the fastest win in this whole method.

The vertical use case writer: three inputs, and an agent that can say no

The structured database is set up. Now the vertical use case writer can answer one question: "Am I looking at a way this company provides value to the customer that's unique to this particular vertical?" To answer it, the agent needs to know your existing use cases (including the horizontal ones from the beginning of this post), which vertical you're looking at, and whether you have any customers in it. That's three inputs.

The structured database. Read only for this agent, always. It can never be better than what it reads.

1. A served use case file. The use cases you already name, written as general patterns, including how each one shows up in transcripts and emails, and what each one is not. This lets the agent rule out everything you already cover and spend its effort on what you don't.

2. A research file on the target market. Outside sources only, each one named and dated. Whoever writes it, you or a research agent, shouldn't look at your customer data while doing it, so the research can't be bent toward what you already sell. Matching the two is the agent's job. The file ends with its limits: what it looked for and what it didn't. Add some insights on how I’ve built this with Gemini. Also, opportunity to use Grok which is good on X if your users are using that, and Perplexity if it’s important for the data to be really recent.

Like the weekly prompt, the writer works in gates, but these are its own three, with a review from you between each one: candidates, then positioning, then messaging. Before any of them, it runs what I call Gate 0, three questions that let it say no.

Have I seen this vertical before? If yes, it adds to the earlier run instead of rediscovering the same use cases and presenting them as new.

• What does the research allow? It reads the limits first, because a missing topic only means something if somebody went looking. If the research never searched for a topic, finding nothing about it doesn't mean the market doesn't care.

• Is there enough evidence? It matches the industry to real accounts, counts independent groups and states the number. Below a floor, meaning a minimum number of groups you set, it reports the gap instead of filling it.

One trap almost everyone hits: Rootline's vertical field had three values, and dairy, seafood and bakery lived only in free text. So tell the agent how to match an industry name to accounts, and have it write that list into its output, or the account set quietly changes between runs.

For Rootline, I pointed it at functional food and drinks, the products that promise to help you sleep better or stay alert, which are getting really popular in Sweden. Here's the first page of what came back.

Example 6: An agent reporting a gap instead of filling it

Lead with the gap. "The database holds no evidence about functional food customers. Every candidate in this file is a need proven in other food segments and carried across. Read every position below as what we would test, not what we know."

What the limits allowed. "Sustainability was sized small on purpose. Only EUDR and passing mentions were kept, and nothing further was searched. Silence on carbon demand in functional food is therefore not evidence of low salience. Nobody looked."

Search result. 0 hits for whey, kvarg, skyr, energy drink, caffeine, GLP, fibre, gut, reformulation, novel food, health claim, sports.

What to notice. This is the first page of the output, and before it says anything else, it says the run found nothing in the target market. An agent that leads with its own gap is one you can trust with the rest.

Do this: write your served use case file first, with a "not this" for every entry. It takes an afternoon, and it's the input that does the most work.

What transfers, what's native, and what breaks

At its first gate, candidates, the writer asks three questions about every possible use case, and each answer gets a grade.

• What transfers? (Grade A) A need proven in your structured database that meets a market condition confirmed in the research. It needs both halves.

• What's native to the market? (Grade B) A challenge the research names that you could plausibly serve. By definition, there's no customer evidence behind it.

• What breaks? (Grade C) A proven need that won't hold up in the new market.

Almost everybody skips the third question, and I think it's where this exercise most often goes wrong. An agent that only finds matches says yes to everything, and you can't tell it apart from one that works.

The writer also grades transfer and servability separately. Transfer is how well a need you've proven carries over into the new market. Servability is whether your product can actually serve it there. A need can transfer perfectly and still be one your product can't serve. Rootline's A-3 transfers strongly, because functional food brands buy the way Rootline's existing customers do. But the claims under attack in functional food are health claims under Regulation 1924/2006, the EU rules on nutrition and health claims, and a carbon accounting product can't back those up. One combined score would bury that.

And park the breaks, don't delete them. A break is just something that isn't true yet. Markets move, and when you point the agent at this vertical again, a parked break keeps the reason it was rejected. It's the same idea as counter evidence in the database.

Example 7: Transfer and servability, graded apart

Example 8: The parked Grade C list

What to notice. C-3 is one of the best evidenced patterns in the whole database, at 13 independent groups, and it still doesn't transfer. Carrying it across would have produced confident, well cited, wrong positioning. Every parked break also names what would move it, so the next run checks instead of re-arguing.

Do this: on your first run, read the Grade C list before the Grade A list.

Positioning that is defensible, and what you actually walk away with

I'm a big fan of April Dunford, so at its second gate, positioning, this agent writes each position the way she would. Her components, in order, plus three additions that do a lot of the work:

1. Competitive alternatives. What they do today without you, including nothing.

2. Unique attributes. Each tied to an observation, with the known weakness stated right there. A positioning doc that hides its weaknesses only survives until the first demo.

3. Value and proof. Including which market the proof came from.

4. Target market characteristics. How to spot someone who cares, ending with a negative signal: who looks similar but doesn't have the problem.

5. Market category. What kind of thing you tell the buyer this is. It's the highest leverage choice, because it decides who you get compared with and often whose budget pays for you.

6. Relevant trend. One line is enough.

And every entry closes with what would falsify this, which keeps the document honest as it ages.

Then there was the finding that was worth more than any use case in the run. A 67 source research file on functional food and drinks contained the words carbon, emissions, footprint, climate and scope 3 exactly zero times, for a company that sells carbon accounting. And right away, the limit: the research never searched for those terms, so low interest is a hypothesis, not a conclusion. Absence only counts as evidence when somebody looked.

So be honest about what the output is. With no customers in the market, it's a discovery agenda, not a messaging brief. Grade A means a proven need meeting a confirmed market condition with zero customer evidence there: a strong hypothesis, and a great reason to go out and ask. Say so on the first page. It's also not about pumping these out really quickly. You work through each position with the agent and check the sources yourself before anything goes external.

Example 9: One position, end to end

A-1, a forced change of origin. Grade A. Transfer medium, servability high. Hypothesis grade. No functional food customer evidence.

In one line. When a buyer has to replace a protein source and more than one alternative sits at a similar price, carbon can decide which alternative wins. It will not decide whether to switch.

Market category. "A sourcing comparison used inside the tender, on the procurement budget, not a carbon accounting tool." This moves the comparison set away from Verdanta and Klimatly to a spreadsheet price comparison, and moves the budget away from a sustainability function the research cannot show exists. Evidence for the move: S-06, "New lines never come off again", five groups.

Weakness, stated in the document. Rootline does not sell a procurement only offer.

Negative signal. "Whey based brands look like the same buyer and are not: locked into forward contracts with no choice of supplier."

What would falsify this. "The alternatives to Chinese pea protein turn out far apart on price, so carbon never breaks a tie. Or switch decisions for 2027 are locked before anyone asks about carbon. Or the factor library cannot separate protein isolates by origin."

What to notice. (Verdanta and Klimatly are Rootline's made-up competitors.) The category choice is the whole move. It takes a carbon product and puts it on the procurement budget, because the evidence says there's no sustainability budget line to buy from. And the entry names its own weakness and its own falsifier, so the next person to read it knows exactly where to push.

Do this: add a negative signal and a falsifier to a positioning doc you already have. It takes fifteen minutes, and it'll change a conversation.

What I learned the hard way

• Run it by hand before you write the skill. Doing it manually first changed the design five times, including adding Gate 0 entirely. If I'd written the skill first, I wouldn't have seen any of those.

• My tidy three step plan didn't survive. I planned extract, then cluster, then draft. What works is one gated weekly prompt, because clustering is just a recount from the rows.

• Validation has to be blind, and mine is still on my list. I hid some vertical use cases in the Rootline data on purpose, so I could check whether the agent finds them. That check has to be run by an agent that has never seen the answer key, because any agent that knows where I planted the Easter eggs will find them and report success. I'd read the key, so that run still needs doing.

• The writer's third gate, messaging, hasn't run on anything yet. The functional food run is paused partway through positioning, so the messaging step is a design, not a result. I'd rather tell you that than pretend it's finished.

Summary

If you take one step after reading this, don't build the agent yet. Take one week of whatever carries a customer's voice at your company and write the observation log. Source ref on every row, their words in quotes, one idea per row. That one week will tell you whether the rest is worth it.

For most people, the blocker isn't the AI. It's getting the transcripts. The ask works when it's small and specific: one vertical, one quarter, read only, and something your sales or CS lead gets back, like a themed brief on what their accounts actually complain about. Scrubbing the data is yours to own: taking out names and anything sensitive before it goes anywhere near an AI tool is your job, not theirs. And those hidden use cases are often already known somewhere. Maybe your SDRs know about them, and it just hasn't gotten to the marketing team yet.

If access is going to take a month, https://github.com/vittycent/Structured-Database has four weeks of Rootline's data waiting. Build it on that in the meantime, and let me know how it goes.