Cohere should have been one of the defining companies of the LLM era.

Founded in 2019 by Aidan Gomez, one of the co-authors of Attention Is All You Need, Cohere had the experts, the timing, the enterprise focus, and the transformer lineage itself. Anthropic came later, in 2021, founded by former OpenAI people with a safety obsession that sounded, at the time, like it should slow them down.

By 2026, the gap was absurd. Cohere was in the low hundreds of millions of ARR. Anthropic had raised at a $380B post-money valuation and was reported at tens of billions in annualized revenue.

This piece is about why.

Not because Cohere is bad. Cohere is an extraordinary company. That’s the point. The interesting comparison is not great versus stupid. It is GREAT versus merely GOOD. In this market, merely GOOD is still a fast scaler. The Coheres, the Harveys, the Mistrals. None of them are Anthropic.

I wanted to understand the difference properly. So I treated the question like a research project.

Tackling the “how to build great AI products” question as a real research project

This is not a newsletter article about AI. Not really.

I could’ve generated one of those in fifteen minutes. So could you. So could anyone with a Claude tab open and a vague opinion. Which is roughly why I’ve stopped reading most newsletters this year. Too much opinion, not enough research.

So I did the opposite.

I write this newsletter every single week, two hundred straight weeks of it. I took the time I usually spend on eight editions and dumped it all into one question. 100+ hours. Hundreds of thousands of words of research. Four books, none of which I’d recommend to anyone I like.

And an actual research methodology loosely cribbed from Jim Collins’s Built to Last: 23 pairs of companies in roughly comparable starting positions, drawn from a population of 86 algorithm/ML/AI scalers I could verify across thirty years. Two companies per pair, one GREAT and one merely GOOD. The methodology section explains how it actually worked.

One example of the kind of thing that comes out of digging into actual companies instead of writing AI takes:

DoubleClick was, in my view, the closest thing the pre-2000 internet had to a proto-AI company. The architecture that defined web monetization for the next thirty years. Where did the idea come from? Two guys in a room asking “what do people do to make money?” Someone said “banners on websites, I guess.” That’s the origin. A banal brainstorm. You will not find that story in any AI book published this year. There are about a hundred details like it in the 15 thousand words ahead.

My research question: what separates GREAT AI products from merely GOOD ones?

The pattern was easier to name than I expected, and much harder to live with.

The GREATs kept making decisions that looked locally absurd: too narrow, too messy, too expensive, too slow to monetize, too hard to explain in a board deck. The GOODs chose the cleaner explanation almost every time.

The GREATs had a stomach for locally absurd decisions. The GOODs didn’t.

But “locally absurd” is not a personality trait. It is what a good decision looks like when the room is optimizing for the wrong layer.

The move looked wrong at the product layer and right at the data layer. Wrong at the current revenue layer and right at the future loop layer. Wrong inside the regime and right after the regime changed.

The six weird looking moves

1. Make the product uglier so it can label itself.

A clean product asks for feedback later. A labeling machine turns the next click, edit, accept, reject, upscale, or signature into training data.

2. Stop polishing the thing that is already good.

GREATs rotate at 8/10. GOODs keep improving the node current revenue still rewards, because it feels rational right until it slows them down.

3. Leave the product surface and follow the buyer’s money.

The locally sane move is to make writing better, search better, transcription better. The compounding move is to ask where the buyer’s economic value moves next.

4. Fund bets that look stupid as products but rational as signal.

Loss-making phones, negative gross margins, delayed launches, weird wrappers. The product math says no. The signal math says maybe.

5. Overbuild the boring data machine before anyone believes it matters.

“Data-centric AI”: Rubrics, expert labelers, failure lists, weekly cadence. It looks like operational overkill until the competitor with “cleaner SaaS” cannot learn fast enough.

6. Remove the “kitchen”, even when the kitchen is where today’s revenue lives.

Redirects, sales processes, no-training clauses, partner surfaces, privacy boundaries. They all look commercially reasonable. They all put distance between the model and the money.

The Anthropics of this study weren’t smarter, better-funded, or first. Half the time they were last. The Coheres were thoughtful, articulate, and right about everything inside the regime they were operating in. That was the problem.

The Anthropics simply grow much faster, from PMF (measured as $1M ARR) to my scale threshold status (measured as $100M ARR).

One last warning, because the rest of the piece earns it: most of what I expected to find on the way to that answer was wrong. Here’s a preview of 6 beliefs I held that the research busted wide open:

Six things I no longer believe

1. AI-native speed comes from the LLM APIs. Wrap and ship. Reality: Both sides of every matched pair have access to the same APIs. Some train their own models, some wrap, and the wrap-or-train decision turns out to be uncorrelated with greatness. APIs explain why this era is fast. They do not explain why some companies in this era are four times faster than the others.

2. OpenAI will take it all. Reality: Take-it-all stories have been told about every dominant company in every era of this research, and they have been wrong every single time. Search didn’t collapse to one winner. Recommendation didn’t. Computer vision didn’t. Translation didn’t. Markets that look like winner-take-all from inside the wave reliably resolve into winner-take-most, with the runners-up still hitting scale threshold.

3. AI in 2024 is a brand-new game. The old patterns don’t apply. Reality: The pattern has been running for nearly thirty years across three foundational eras. Each era produced its own GREAT and merely GOOD companies, and the variables separating them have been roughly the same for three decades. Today’s frontier-model GOOD is the same shape as yesterday’s morphological-search GOOD and the year-2000 ad-network GOOD. Names change. Patterns don’t. APIs are this era’s accelerant, not its secret.

4. Big proprietary data is a moat. Reality: Data alone is not a moat. One of the largest exclusive consumer datasets in retail history sat inside a company for thirty years and never compounded past consultancy scale. Most of the proprietary datasets in this study turn into no advantage. Data is the opposite of oil. With oil, the extraction is most of the work. With data, extraction is cheap. The refinement is the game.

5. Real focus means one bet at a time. Reality: The companies that compounded ran several uncomfortable bets simultaneously, most of them looking like distractions. The bets paid off in combinations that weren’t in any plan: surface A’s data made surface B’s product work, which made surface C viable. The slower companies ran one (signal) bet at a time and waited for evidence before authorizing the next. They got one answer per year. Their counterparts got three. Real focus is narrow interaction primitive, not narrow scope of action.

6. The companies that take longer are missing something obvious. Reality: They weren’t. They were thoughtful, articulate, and wrong. The merely-GOOD CEOs can and do explain on the record exactly why they aren’t doing what their faster-scaling competitors are doing. The explanations are correct in every internal sense. They are also disastrous. Thoughtful coherent decisions are not enough in a complex field. Messy probing is how you discover the thing no memo could justify yet. Which also explains why there is no playbook.

If best practices are wrong and there’s no playbook, what’s left to learn? Six concepts that held across the study, deep, researched, and accompanied by real stories from the people who made the decisions at the time. The point of doing this research was to figure out what I can do to make sure our company goes from PMF to scale status as fast as possible. The six concepts are an answer.

Now let’s talk about the population of the study and what struck me as interesting right away.

Bad Boys Move in Silence

David Senra at Founders likes to say bad boys move in silence, he is right.

Not morally bad. The companies that matter often don’t announce themselves as the ones that matter.

Ask an AI founder which companies they study and you get the same list: OpenAI, Anthropic, DeepMind, Cursor, Midjourney, maybe NVIDIA, maybe Google if they are feeling historical. It is not a bad list. It is just a loud one. Loud companies are not the population. They are the press cycle.

So I tried to build the full list, removing the “loud bias” at first.

The task was simple enough: find every company I could verify, anywhere on earth, across the last thirty years, that reached the scale threshold outcomes with an algorithm-heavy, ML-heavy, or AI-native product at the core.

Not “used AI.” Not “had a recommendation feature.” Not “mentioned machine learning in the S-1 because the market was paying for it.” My test was whether the company’s core product would become meaningfully worse, or cease to exist, if the algorithmic system were removed.

I expected more than what I found: 86 candidates I could defend as “core algorithmic/ML/AI product”. On the entire planet. Across three eras: algorithm-native, ML-native, AI-native.

That number did two things to me.

First, the field felt smaller. For all the noise, the actual population of algorithmic companies that reached this scale is not that big.

Second, once you leave the loud canon, the field gets weird fast.

DoubleClick should be required reading for every AI founder and isn’t. Overture got hissed at on stage before inventing the paid-search architecture that ate the internet. Meitu reached public markets with selfie apps, loss-making phones, and later a crypto gain larger than full-year operating profit. dunnhumby knew more about Tesco’s customers after three months than Tesco knew after thirty years and still became a consultancy. LookSmart was running data-centric AI in 1999 with two hundred professional ontologists before anyone outside the room had a name for the discipline.

And behind those sat an entire Chinese computer-vision-and-speech wave (iFlytek, SenseTime, Megvii, CloudWalk, Yitu, Unisound, Horizon Robotics) that Western AI discourse mostly treats as background noise (”they don’t matter because they are from China and subsidized” - not true in terms of this research, not what the data and the stories say).

This is why the article does not start with OpenAI.

OpenAI is loud. Anthropic is loud. Cursor is loud now. Useful, yes. But loudness is not evidence.

How I Tried Not to Mistake the Press Cycle for the Population

I used six rules.

1. Build the base population first. I looked for every company I could verify that reached the scale threshold outcomes with an algorithm-heavy, ML-heavy, or AI-native product at the core. That produced 86 candidates. Not all of them made it into the final study. Some were too opaque, some could not be paired cleanly, and some had too little revenue data to compare honestly.

2. Use $100M revenue / ARR as the scaling threshold, not valuation. Valuations are noisy, especially across eras. Revenue is also imperfect, but less stupid to compare. $100M is arbitrary in the way all thresholds are arbitrary, but it is high enough to rule out demos and low enough to compare across eras. For older companies, I inflation-adjusted so that a 1999 company is not being judged against a 2025 dollar. The threshold is operational, not financial. It is the moment a company crossed into “this is real revenue, not narrative.”

3. Use matched pairs, not vibes. I stole the Jim Collins move: start with a population, separate GREAT from GOOD by a wide performance gap, then match companies that began from roughly comparable starting conditions. Matched pairs cancel out some of the weather. If both companies ride the same hype cycle, the hype matters less. What remains is more likely to be the variable you care about.

4. Study three eras, not just the current AI wave.

The AI-native era is too young and too polluted by hype to study alone. ChatGPT is not the beginning of the story. It is the moment the story became obvious to everyone.

The pattern came in three waves: algorithm-native companies from roughly 1995–2005, ML-native companies from roughly 2005–2021, and AI-native companies from 2021 onward. The names changed: ad matching, search ranking, speech recognition, computer vision, recommendation, generative language. The operating problem did not. Each wave had companies trying to turn data into better predictions, predictions into better products, and products into more data.

That is why the old cases matter. DoubleClick is not historical decoration. Yandex is not nostalgia. dunnhumby is not a retail tangent. They are earlier runs of the same machine under different constraints.

Hypotheses that only explain ChatGPT-era companies are probably takes. Hypotheses that survive all three eras are worth taking seriously.

5. Build hypotheses backward. Test them forward. The old companies generated the hypotheses. The new companies tested them. This matters because otherwise you fall in love with whatever Cursor or Anthropic did last week and call it a law of physics. The AI-native companies were the test set, not the training set. Last-to-first kills the “this is the new thing” bias.

6. Throw away companies I could not compare honestly. The base population started at 86 candidates. 84 of them had enough confirmed data for the population-level analysis. 46 had enough detail and a credible matched pair to make it into the final 23-pair study. That means I cut a lot. Not because they were uninteresting, but because interesting is not enough, I need data.

Then I wrote the thing you are reading.

The Matched-Pair Sample

Each pair contains one GREAT and one GOOD company.

GREAT does not mean morally great. It means fast. The GREAT in each pair reached $100M in annual revenue / ARR significantly faster than its matched GOOD, starting at 1M ARR. This is important, as founding and reaching 1M ARR is a very different game than going from that 1M to 100M.

The matching is not based on industry labels. Industry labels are often the trap. DoubleClick and Pandora do not look like competitors. One sold ad infrastructure, the other sold internet radio. But both were algorithmic matching businesses founded before the dot-com crash, both matched inventory to users in real time, both depended on feedback loops, both reached scale. The relevant similarity was the algorithmic substrate. The relevant difference was the architecture of the loop. Pairing on industry would have missed that.

Same logic with Google and Yandex: same problem (search), same era, different regulatory and market geography. If a pattern shows up in both, it isn’t a U.S. tech-culture artifact.

Same with Meitu and Lightricks: same product surface (face manipulation, mobile), different countries (China, Israel), different financial regimes. If a pattern shows up in both, it isn’t local.

The goal was to cancel obvious external variables and leave the internal operating differences exposed. Some pairs will feel odd at first. Good. If the pair is too obvious, it often teaches less.

Across the final 23 pairs, the GREATs reached $100M roughly twice as fast as the GOODs in every era.

First hint that the pairing was not complete nonsense: the gap stayed consistent across eras. The interesting thing is that the speed gap held up across thirty years and three completely different technology paradigms. Whatever separates them is not era-specific. It compounds.

What the Population Already Said

Five things were striking about the 84-company dataset before I had done a single pairwise comparison.

1. Asia is much bigger than the Western canon suggests. Across all 84 companies, Asia is 25% of the total. In the ML era specifically, fourteen of thirty-three companies are Asian — 42%. The computer-vision-and-speech wave was meaningfully run out of China and Korea, not Silicon Valley. The AI-native cohort is more US-heavy at the moment, but it is also young: the four Asian AI-natives in this dataset — Manus, Zhipu, MiniMax, Moonshot — all crossed $100M ARR in the last twelve months. If your AI history is mostly American, your pattern recognition is already biased.

2. India is strangely absent. I expected India to show up alongside China. It does not. Indian-founded companies in this dataset are Uniphore, Icertis, and CIBIL, and the first two scaled from the US. There is no Indian GREAT in the strict sense across thirty years of data. The absence matters because India has the talent, the software export base, and the English-language advantage. The missing GREATs are not an obvious supply-side story. I don’t have a clean explanation. I think it’s worth one.

3. Africa is absent entirely. Zero companies. I tried. I didn’t find any. That does not mean no important algorithmic companies exist there. It means none cleared this threshold with enough verifiable data to enter the study.

4. Founder age doesn’t matter. I had assumed the AI-native era especially would be a young founder’s game. The data doesn’t bear it out. Neil Clark Warren founded eHarmony at sixty-six. Anton Osika founded Lovable in his early thirties. David Holz founded Midjourney in his late thirties after Leap Motion. The 84-company dataset has founders ranging from late-twenties through their sixties, with no correlation to the GREAT/GOOD verdict in any era.

5. The ML era was the slowest of the three. Median months from launch to $100M ARR: algorithm-native 66, ML-native 84, AI-native 20. The ML era is the slowest of the three. I do not have a clean causal story yet. But it matters because it breaks the obvious progress narrative. The ML era had better cloud, better tooling, more venture capital, and still scaled slower than the algorithm era on median.

How to Read the Rest of This Article

You’re not gonna be drowned in data, instead I’ve chosen to use stories (usually about pairs) to give you the ideas without too much of hard data processing on your end. So:

• When a pair feels weird, don’t ask “Are these two companies competitors?” Ask “What variable is this pair trying to isolate?”

• When a company sounds obscure, don’t ask “Why haven’t I heard of it?” Ask “What did it prove before the loud companies had a name for it?”

• When a claim sounds too current, ask whether it also showed up in the algorithm and ML eras. If it didn’t, it’s hype.

No single case gets to carry the argument alone.

Caveats

Estimates. Almost none of these companies disclosed exact $1M / $10M / $100M dates. What they did disclose: revenue numbers in specific years, user counts at specific moments, funding events with implied revenue ranges, employee counts, IPO filings, founder retrospectives. Grammarly is the canonical fair-estimate case. Public breadcrumbs put them at roughly $1M ARR around 2011–2012 and roughly $100M ARR around mid-2022. Not perfect. Good enough to compare against Gong’s better-disclosed five-year path.

What this approach won’t catch. I missed companies. I ditched companies because I couldn’t argue clearly that the product is AI at core. Several Chinese companies are too financially opaque to verify. There are real GREATs out there not in the 84. Also, era assignments are based on each company’s original core technology, not what they run on now. Grammarly was founded in 2009 but compounded in the AI wave. Synthesia sits awkwardly between ML and AI. The assignments are defensible and good enough for the research method. They are not airtight.

Bias toward paper trails. The dataset is biased toward companies that leave paper trails. That is unavoidable. It is also why I treat absence (India, Africa, certain industries) as a finding to investigate, not a final truth.

Finally, here’s the full list of pairs studied:

Now let’s get started with the research hypotheses! I put them into six “Chapters” one for each major hypothesis I run a deep data analysis on (then refined the hypothesis and ran another analysis on).

Chapter 1: Build the labeling machine

Why every GREAT algorithmic product is a labeling machine in disguise.

“We shape our tools and thereafter our tools shape us.” — Marshall McLuhan

“Learning is not compulsory… neither is survival.” — W. Edwards Deming

In 2005, Tim Westergren explained Pandora’s strategy with a straight face: they were going to “really understand the sound of the music.”

They meant it. Thirty musicologists. Four hundred and fifty attributes per song. A multi-year effort to label the genes of music by hand. The Music Genome Project was a serious piece of work.

It was beautiful. It was also slow.

Pandora’s matched pair in this study is DoubleClick. Same broad era, same data hunger, same basic job: match one thing to one person. Pandora matched songs to listeners. DoubleClick matched ads to visitors.

Both believed in data. Both collected a lot of it. Both built matching systems before we called them AI.

The difference was that Pandora built a labeling project. DoubleClick built a labeling machine.

Pandora took roughly a decade to reach $100M in revenue. DoubleClick got there in a fraction of the time and sold to Google for $3.1B in 2007. The clue is in the name of a DoubleClick business unit from 1998: Closed-Loop Marketing Solutions. Nearly thirty years before everyone started saying “AI product,” DoubleClick had already named the thing that matters.

The product is the labeling machine.

I came in expecting the Bitter Lesson version of the answer: more data, more compute, more scale wins. That was wrong. GREATs and GOODs both love data. The difference is not how much they collect. It is whether the product turns the next user action into the next label.

My refined question: If both Pandora and DoubleClick spent a decade collecting and processing more behavioral data than nearly anyone else in their era, what’s the structural difference?

The finding is the Learning Tripod. A product learns fast only when three legs stand up together:

1. A narrow interaction primitive. One surface, one feedback unit, one repeatable user action per session.

2. A capture mechanism. Some invented or controlled technology that reads behavior at the right granularity.

3. An in-session loop. The user’s current action becomes signal for the next session’s product behavior.

Remove one leg and learning does not slow slightly. It falls over.

GOODs usually have one or two legs and often polish them beautifully. The missing leg is what kills compounding. In the study, 18 of 23 GREATs run all three legs actively. Only 3 of 23 GOODs do. The pattern replicates across industries and eras. The gap between Pandora and DoubleClick looks a lot like the gap between Harvey and Abridge (an AI era pair).

1. Narrow is a primitive, not a market.

The Learning Tripod isn’t a research result. It’s a discipline. It means working on all three legs shortly after the PMF milestone, often inventing weird pieces of technology to get them standing.

The first leg: a narrow interaction primitive. One product surface, one interaction unit, one tight feedback event per user session.

Lovable does one thing. Prompt → preview → edit → redeploy. That is the primitive. Not “AI app builder.” Not “no-code.” One repeated action unit: intent becomes running app, user edits, app updates.

Osika calls Lovable “the last piece of software.” Ignore the grandiosity. The useful part is that the product collapses everything into one repeated primitive: prompt, preview, edit, redeploy.

Anton Osika’s GPT Engineer already had 50,000 GitHub stars before Lovable incorporated in late 2024, so the headline “eight months to $100M ARR” needs context. I count from $1M ARR to $100M ARR, and by that measure Lovable is still a GREAT. The important thing isn’t the marketing timeline. It’s the primitive.

Why do narrow interaction primitives matter? Because the narrower the feedback machine, the more focused the signal.

ChatGPT handles every topic in software history. That looks like the opposite of narrow. But measured at the product level, ChatGPT has exactly one interaction primitive: message, receive, thumbs or regenerate. In that sense, the interaction primitive is narrower than that of browser with all its buttons. Every conversation on every topic runs through the same feedback unit.

iFlytek is the inverse. If you don’t follow the Chinese AI market, you probably haven’t heard of them. iFlytek is the country’s speech-recognition champion, publicly traded since 2008, designated a Chinese national “AI Champion” in 2018. They process billions of daily voice interactions. They are genuinely dominant at what they do.

Their market is narrow. Just speech. Their primitives are not. They sell translators, AI tablets, learning machines, in-car voice systems, government systems, industrial models, a bionic robot dog, and recently spun up a semiconductor entity. Thirty product surfaces. Founder Liu Qingfeng admitted it himself: “No single technology will solve the existing problems.”

Twenty-five years of execution, and no single surface became the compounding loop. There was always another surface taking the next round of attention.

Harvey will matter again later. For Leg 1, the point is simple. AmLaw is a narrow market. Legal work is not a narrow primitive. Harvey has been pulled toward multiple feedback units: chat questions, document workflows, end-to-end procedures, workflow builders. A narrow buyer is not the same thing as a narrow loop.

2. The product is the labeling machine.

David Holz founded Midjourney in August 2021 after turning down two Apple acquisition offers. He took zero VC. The Discord bot shipped February 2022:

“If you look at the v3 stuff, there’s this huge improvement… it’s mind-bogglingly better and we didn’t actually put any more art into it. We just took the data about what images the users liked, and how they were using it. And that actually made it better.”

The users labeled it for them.

The parallel to DoubleClick is direct. Midjourney didn’t invent diffusion models. They invented something weirder. DoubleClick didn’t invent ad serving. They invented the DART cookie, a piece of software that could read a user’s behavior across every publisher in a network, in 1996. A click was not just a click. It was a priced action, a relevance label, and a row in the next targeting model.

Today that sounds like “just cookies.” In 1996, it was a real capture invention: a way to observe behavior across publisher surfaces when that was still treated as impractical.

Midjourney? You type “/imagine <prompt>” into a Discord channel (used mostly for gaming). Midjourney returns a 2×2 grid. The grid is not just output. It is the capture mechanism. You press U1–U4 (upscale, “this is my favorite”), V1–V4 (variations, “explore this one”), or reroll (“none of these”). Every click is a labeled preference datapoint tied to a prompt, a user context, and a public channel where other users’ preferences on your image also become training signal.

Hundreds of millions of labeled events per week.

The UI is a labeling machine dressed up as a product.

The critical distinction Leg 2 forces on you: technology invention doesn’t mean novel ML. Midjourney invented the forced-choice interface. DoubleClick invented the cookie that could see across publishers. The invention is in capture, not in the model.

Pandora had the narrow market AND the narrow primitive (recommend music). It even had a form of closed loop. Thumbs-up and thumbs-down adjusted station weights in real time. But Pandora treated those thumbs as station-adjustment weights, not as the central training substrate. The authoritative labels still came from musicologists. The user was allowed to steer. The user was not allowed to become the labeling machine.

What happened in the music recommendation space? Spotify bought The Echo Nest in 2014 for $100M. The Echo Nest was a labeling machine. Its crawlers, audio analysis, playlists, skips, saves, and listening behavior gave Spotify a machine-readable map of taste that Pandora’s hand-labeled genome could not match at speed. One year later, Spotify launched Discover Weekly. By 2018, Spotify had 83 million paid subscribers. Pandora had 6 million.

That is Leg 2: don’t ask whether users can give feedback. Ask whether the product turns feedback into labels the model can actually use.

3. In-session, or it never closes.

Shiv Rao, a cardiologist, and Zach Lipton, a ML professor, founded Abridge in 2018, based on one thing: the clinical note. In the US, the standard tool for capturing clinical notes is Epic, which doctors sign.

Abridge went from PMF to $100M ARR within 18 months. Big clients like Mayo Clinic and Johns Hopkins. A partnership with Epic itself.

“We’re not going to fully automate doctors. We’re going to force-multiply them.” (Rao)

So what’s special about Abridge? It sounds just like voice-to-text.

The capture invention is called Linked Evidence. Every span of every generated note is hard-linked back to the exact transcript segment and audio that produced it (you click play to listen). When a physician edits the draft (changes a word, moves a finding from Assessment to Plan, deletes a line), the edit isn’t just a note change. It’s a labeled correction, tied to the exact audio where the model got it wrong.

Abridge has a narrow primitive (read, edit, sign). The loop closes within one session.

Why is session closure so important? Let’s look at Harvey. Harvey is the legal-industry version of Abridge. Same vintage, AmLaw-100 customers. Strong on Leg 2, weaker on Leg 1 because legal work sprawls across multiple primitives, and blocked on Leg 3 by design.

Harvey’s Trust page commits to zero training on customer data. That’s not a missed opportunity. It’s a feature law firms demand. But it structurally prevents in-session loop closure. So Harvey substitutes: scheduled expert-review sessions, A/B tests on golden datasets, and roughly 350 forward-deployed engineers embedded with customers doing Palantir-style work. Human bandwidth in place of algorithmic feedback.

It works. Harvey got to $100M ARR. In roughly twice the time Abridge took.

Why does in-session matter? Because delayed feedback decays. Ask someone what they ate five minutes ago and you get a label. Ask three days later and you get a story. The same thing happens in products. If the correction happens while the user is still doing the work, you capture the event. If it happens in a review meeting next week, you capture a reconstruction.

In-session does not mean the model retrains instantly. It means the label is captured before context decays. Abridge doesn’t need to update the model in real time. It needs to capture 100% of what it can capture while the source event is still attached to the work.

The three legs aren’t new. None of them is a research breakthrough. DoubleClick was running the loop in 1998. They’d named the business unit Closed-Loop Marketing Solutions before some of the founders shipping AI products today were born. Each leg, on its own, is something a competent product team can name and half-build. What the GREATs in this dataset do is run all three at once, on the same product, in the window where compounding starts to matter.

And the hard part is rarely engineering. Twenty-three pairs in, the pattern got clearer with every one: when a GOOD breaks a leg, the failure is almost always strategic, not technical. iFlytek lost Leg 1 because they sold thirty surfaces to thirty kinds of buyer. Pandora lost Leg 2 because they outlawed the labeling machine on principle. Harvey lost Leg 3 because AmLaw firms won’t let them close the loop. None of those are engineering problems. All of them are business-model problems wearing engineering costumes.

4. The Learning Tripod Test

Pick one product loop and answer:

1. What is the primitive? Not the market. Not the persona. The repeated user action.

2. What captures the signal? A cookie, a linked transcript, a forced-choice interface, an authoring trace. If the answer is “analytics,” you probably don’t have a capture mechanism; you’re just reusing what everyone else does.

3. Does the label happen in-session? If the user has to remember later, reconstruct later, or review in a meeting later, the loop is already slower and distorted.

If you can’t answer all three, you don’t have a labeling machine. You have a product with feedback.

The Tripod, at a glance

Nothing about these inventions or closed loops is fancy. It’s cookies, links, and weird gaming chat tools. But it works.

Chapter 2: Rotate at 8/10

Why the most rational short-term moves slow you down in five years

“When the facts change, I change my mind. What do you do, sir?” — John Maynard Keynes

“Only the paranoid survive.” — Andrew Grove

George Bell said this in 1999:

“If Excite were to host a search engine that instantly gave people information they sought, the users would leave the site instantly.”

He was explaining why he had just walked away from buying Larry Page and Sergey Brin’s company for $750,000.

Under the cost-per-impression ad regime of 1999, Bell’s logic was tight: better search meant fewer page-views meant less revenue. He did the rational thing and polished the portal. Then the regime changed, and rationality became bankruptcy.

The strange part is that Excite is a GREAT in this study. It hit $100 million in revenue inside the 24-month window that defines the category. Bell ran a winner. Three years later, the winner disappeared.

Excite did not fail because it lacked a flywheel. It failed because the revenue regime told it to keep polishing the wrong node. That is the problem this chapter is about.

Every company in this study has some version of the same flywheel: data → algorithm → product → more data.

In practice, “product” includes the surface, infrastructure, distribution, and monetization layer: whatever turns capability into more usage. Chapter 1 walked the mechanics of how that loop closes. Both GREATs and GOODs build flywheels. So the existence of a flywheel cannot be the variable. The variable is what the company does when one node becomes good enough and the bottleneck moves.

The finding is Rotation Discipline. GREATs rotate at roughly eight out of ten. Once a node is good enough to keep compounding, they move investment to the next constraint. GOODs keep polishing the node current revenue still rewards.

The gap looks small in the quarter. It becomes five years of speed.

In their scaling windows, GREATs rotate two to three times. GOODs rotate zero or one.

1. Google rotated before anything was perfect.

Google’s scaling window runs roughly from October 2000, when AdWords V1 launched and meaningful self-serve ad revenue started flowing, to early 2002, when revenue crossed the $100M run rate. That’s a 24-month window. Here is what Larry Page and Sergey Brin did inside it.

Rotation 1: algorithm → infrastructure (product). PageRank had been their Stanford PhD work. By late 1999 it was shipping and clearly superior to AltaVista and Excite on relevance, but noisy on tail queries and struggling with spam. Rather than polish it further, Brin and Page reallocated investment to the infrastructure needed to serve it at scale: commodity hardware, custom storage, distributed indexing. The binding constraint had moved from algorithm quality to query throughput. The early engineering hires in 1999-2000 (Urs Hölzle, Jeff Dean) were infrastructure hires, not search-quality hires. Through 2000 and 2001 the data-center architecture they built let Google serve orders of magnitude more queries per dollar than AltaVista (yes, that was still a company back then). By 2001 it was handling substantially higher query volume at a fraction of the per-query cost.

Rotation 2: infrastructure → monetization (data). AdWords V1 launched in October 2000 as a CPM product. It tied the flywheel to money for the first time and brought in a new data stream: advertiser behavior on top of user behavior.

Rotation 3: monetization → relevance-ranked auction (algorithm). In February 2002, AdWords V2 shipped with a per-click auction ranked by bid multiplied by predicted click-through rate. The company went from $86M revenue in 2001 to $440M in 2002.

Three rotations in 24 months. None of them waited for the prior node to be perfect (or even great). PageRank was still imperfect when investment shifted to infrastructure. Infrastructure was working but far from finished when investment shifted to AdWords. AdWords V1 was a bridge product when investment shifted to V2. Each rotation happened while the prior node was working but imperfect, somewhere around eight out of ten.

The pattern showed up across the rest of the dataset. No GREAT waited for a single node to reach ten out of ten before moving investment to the next one. GREATs rotated two or three times in their scaling window. GOODs tended to rotate zero or one.

What does 8/10 mean concretely? Gut feel. The moment when the marginal return on further polish on the current node falls below the marginal return on starting the next one. A stable data pipeline. A working algorithm at acceptable depth. A product with enough users that the next data generation will compound. The exact threshold doesn’t matter. The existence of the threshold does. What matters is the feeling that the bottleneck has moved, and the courage to shift fast.

2. GOODs polish the node that still pays.

Yandex stands for “Yet Another iNDEXer,” coined in 1993. Arkady Volozh and Ilya Segalovich built the company around one real insight: Russian-language morphology is much more complex than the stem-and-character methods Western search engines used. So the strategy was obvious and defensible: build the best Russian search algorithm in the world.

And then keep polishing it.

That was not stupid. It worked. The morphology work is still cited in academic NLP papers. Russian advertisers paid for it. Yandex.Direct (their AdWords equivalent, launched 2001) gave every additional increment of morphology a direct revenue signal. The problem is that the same signal kept telling the company to deepen the node that was already good enough.

The outcome: 84 months to $100M against Google’s 24. Inside the scaling window, there was one rotation (Yandex.Direct) and the rest of the investment went into deepening a node that was already past 8/10 by 2003.

Polish the algorithm until you die.

Picsart is the second case, and from the outside it looks like a success story. Founded in Armenia in 2011 by Hovhannes Avoyan, Picsart grew to 45 million MAU by 2014, 100 million by 2017, 150 million by 2024. Their 86-month scaling window runs roughly from first meaningful revenue in 2015 (Sequoia Series A) to 2022. What they did inside the window: kept adding consumer features, moved from free to freemium with Picsart Gold at $4.99/month, scaled their consumer audience internationally, added AI generative tools in late 2022. Each addition made the product surface better. Each addition was something users would pay for. None changed the bottleneck.

Their matched pair, Megvii/Face++, is the counter-example. Megvii rotated through every piece of the flywheel in four visible waves inside their 36-month scaling window.

Wave 1: data rotation. Founded in 2011, Megvii launched Face++ as a facial-recognition API in 2012 and deliberately kept it free through 2013 to amass training data. Every developer call generated labeled image data, which trained better models, which attracted more developers. Within two years the free API had 300,000 developers.

Wave 2: algorithm rotation. By 2015 they had enough data to justify building their own deep-learning stack. Brain++ was an in-house productivity system for training models, designed so they could customize face recognition per customer without rebuilding from scratch. That turned the algorithm from an expensive R&D cost into something they could productize repeatedly.

Wave 3: product rotation. In 2014 Alibaba selected Face++ to implement “pay-with-your-face” in Alipay. This consumed a significant fraction of Megvii’s engineering capacity. A single customer demanded enough scale, latency, and reliability that the team reorganized around making it work. It paid off. The Alipay integration became the reference deployment that won them Face ID contracts with roughly 90% of China’s top 200 internet companies.

Wave 4: new data sources. Starting 2017, at the edge of the scaling window, Megvii pivoted into smart-city contracts where the buyer paid per-deployment in the millions.

Four waves. Four nodes touched. Same 36 months. Picsart spent 86 months polishing one node beautifully and never forced the rotation.

3. Revenue chooses the bottleneck unless you force it not to.

So far this chapter has covered when to rotate: at 8/10, not 10/10, two or three times in your scaling window. That’s half the Rotation Discipline.

A company does not rotate by willpower. It rotates because revenue gives it room to move. Revenue funds more data collection. Revenue funds the ability to pivot between waves. More revenue means more users, which means more data, which means better models, which means more users still. Kill the revenue and the flywheel stops. (If there’s no revenue at all, your flywheel is likely already broken.)

Which means the real question at every quarter isn’t just “which node does the flywheel technically need next.” It’s “which node will someone pay us to work on next.” Those two questions have the same answer less often than founders think.

Google’s rotations inside its scaling window read like they were about technology. The decisive ones were economic. PageRank → infrastructure was a technical rotation. AdWords V1 to V2 was not. Moving from CPM ads to a per-click auction weighted by click-through rate changed the unit of revenue from “impression” to “relevant click.” Under CPM, the most profitable ads were whichever bid the highest, regardless of whether users wanted them. Under Bid × CTR, the most profitable ad was the one the user most wanted to click. Relevance became revenue, mathematically, in a single formula. That’s the move that made the technical flywheel spin faster. Google’s incentive to improve search quality and Google’s incentive to maximize revenue stopped being separate vectors and became the same vector.

The Yandex story shows the same force, pulling the other way. Russian advertisers in 2001-2005 had a specific willingness-to-pay curve. Russian-language queries matched through deep morphological analysis converted better than queries matched by stem-only or character-n-gram methods. Every increment of morphological depth Yandex added had a direct, measurable revenue payoff through Yandex.Direct. Russian advertisers were willing to pay for exactly the node Yandex was already best at. The short-term economic signal Yandex received, every quarter, from revenue data, was “keep polishing morphology, the advertisers are paying for it.” They were right, inside the window of a Russian-language, desktop, 2001-2008 advertising market.

Yandex was rationally forced by the economic incentives. Google used brute force to align the economic incentives with where they wanted to go and make the flywheel turn faster.

The bottleneck a company perceives usually isn’t the technical bottleneck of its flywheel. It’s the economically capturable bottleneck, the node their current buyers are willing to pay more for, inside the monetization regime they’re running. The two are usually different. When they diverge, the company’s perceived pivot is rational under today’s revenue and starves the flywheel the company actually depends on. It’s a simple short-term-versus-long-term mismatch, and humans systematically overweight the short term.

That is the trap: revenue sounds like truth, even when it is only yesterday’s bottleneck paying rent.

4. The Rotation Discipline Test

Pick the flywheel that matters and answer:

1. Which node is currently 8/10? Not the one you’re proudest of. The one where the next quarter of polish returns less than starting work on a different node.

2. Which node is the actual bottleneck now? Not the one with the loudest internal owner. The one limiting the next turn of the flywheel.

3. Which node does current revenue reward you for polishing? This is the dangerous one. If buyers pay you to improve yesterday’s bottleneck, revenue will sound like truth while it slows you down.

4. When did you last rotate? If “never,” you’re Yandex. If “every quarter,” you’re not rotating, you’re thrashing.

For the builders this study is ultimately for, the Rotation Discipline is continuous. AI-native flywheels compound on rotation, and rotation is a decision the builder has to re-make every quarter for the whole scaling window. Not just which node does the flywheel need next, but which node will the current revenue allow them to build. The hardest version of the question: which node would you rotate to if your current revenue did not exist?

Getting those two things mixed up is what took Excite from GREAT at the milestone to Chapter 11 three years later.

The rotations, at a glance

Chapter 3: Stack on the Axis

Why thirty years of unique data became a consultancy, and three years became $29B

“The whole is greater than the sum of its parts.” — Aristotle

“The greatest danger in times of turbulence is not the turbulence; it is to act with yesterday’s logic.” — Peter Drucker

If you showed me the dunnhumby case study without telling me the ending (and the name), I would have called the company a masterpiece. On a November morning in 1994, in a boardroom in Cheshunt, Hertfordshire, a husband-and-wife consulting team, Clive Humby and Edwina Dunn, presented a three-month loyalty-card pilot to the board of Tesco (Britain’s biggest supermarket chain). When Humby finished, Lord Ian MacLaurin said something Humby has been quoting in interviews ever since:

“What scares me is that you know more about my customers after three months than I know after thirty years.”

SIDE NOTE: What’s striking about this is that it starts exactly like the story of Capital One. A small bank, a pair of outside consultants walking in, an internal team that realizes how amazingly valuable their proprietary data could be. Same opening scene. Different ending.

The Clubcard launched eleven weeks later. By 2025 it was handling eighty percent of Tesco’s transactions across twenty-four million UK households. Humby and Dunn wrote the book on what they did, Scoring Points. A decade after that boardroom, at a marketing summit at Kellogg in 2006, Humby coined the line that would become the AI era’s favorite cliché: “data is the new oil.”

Now look at the research. dunnhumby is in my twenty-three-pair dataset as a GOOD. One hundred and twenty months to one hundred million dollars in revenue. Bloomberg classifies the company as “advisors, analysts and marketing services consultants.” A technology-and-consulting services company, not the compounding software platform the data should have made possible.

The problem was not that dunnhumby lacked oil. The problem was that the oil never moved.

I’ve been operating on a thesis for a couple of years now: get access to proprietary data, pump it all into a competent flywheel, and outstanding returns follow.

Turns out I was wrong.

That leaves an uncomfortable question.

Proprietary data appears in 10 of the 23 pairs in this study. Most of those companies ran a competent flywheel on the data they held. So the data was not the variable. The flywheel was not the variable either.

What was?

For proprietary data, the answer is axis discipline. The GREATs identified the direction their buyer’s economic value actually moves in, then stacked more narrow primitives along that direction, each one its own Tripod. The GOODs found one valuable point on the axis, perfected it, and stayed there forever. 7 of 10 GREATs in the proprietary-data subset ran this discipline. 0 of 10 GOODs did. Off-axis surfaces don’t compound. They just share a logo.

1. Data gets you one point. Axis discipline gets you the stack.

The useful comparison is not another grocer. It is Presight AI, a UAE company that began with the same rare asset: privileged operational data from an anchor relationship. Dunnhumby had Tesco’s checkout. Presight had the UAE government. Different buyers, different politics, different market. Same starting shape:

Exclusive, ambient access to operational data from a single anchor relationship. For dunnhumby in 1995, the anchor was Tesco’s checkout. Every transaction, every customer, every basket, via the Clubcard. For Presight in 2020, it was the UAE government. Data streams from ministries across defense, finance, energy, and human capital.

Both companies built a flywheel on the data. Both ran the Tripod from Ch 1 with reasonable competence. The capture was ambient. The loops closed. The primitives were narrow.

The difference shows up only when you ask what they did next.

Dunnhumby’s customer was a grocer. A grocer’s economic value moves in a recognizable direction: purchase data leads to relevant offers, relevant offers lead to personalized engagement, personalized engagement leads to ad targeting, ad targeting leads to operational decisions about what to stock and where. That direction is the grocer’s axis of value. Each successive point on it is worth more to the grocer than the one before, because each one moves closer to a decision the grocer can monetize directly.

Dunnhumby found the first point on the axis (purchase data analysis) and froze there. They built that one point beautifully, deepened it for two decades, delivered the work as PowerPoint decks. PowerPoint decks are where proprietary data goes to become someone else’s strategy. The first advertising product built on Clubcard data, Tesco Media and Insight, shipped in November 2021. Twenty-six years after the Clubcard went live. By the time dunnhumby moved to the second point on the axis, the market had built its own versions of points three, four, and five.

Presight did the opposite. In roughly four years, it stacked six lenses on the sovereign-AI axis.

First, it turned raw agency data into analytics-grade signal (TAQ). Then it turned that signal into enterprise decisions (Vitruvian and Connect, the Enterprise AI Suite, July 2024). Then it collected more data with IoT and video telemetry (IntelliPlatform). Then it let signal cross agency boundaries (DataHub). Then it focused the shared signal into vertical agency primitives: policing (AI-Policing Suite), emergency response (LifeSaver with NCEMA), media regulation (Unified Media AI Platform with the UAE Media Council).

Finally, with ENERGYai, it pushed the stack from decision support toward agentic execution in energy operations: lower costs, lower emissions, more automated decisions.

The product names matter less than the sequence. Each lens focused what the previous one captured.

Dunnhumby kept improving one lens. Presight kept adding the next lens on the same line.

Edwina Dunn, looking back in 2019 on the industry she and Humby helped create: “Dunnhumby was rear view mirror, so too is the data science across most of the industry. Companies tend to look only at their own data.”

Ch 1: build the Tripod on a narrow primitive. Ch 3: stack more primitives along the axis of customer value, each one its own Tripod, all on the same direction. Dunnhumby had one magnifying glass at one point. Presight had a sequence of magnifying glasses, each focused on the same line, each one multiplying the focus of the one before it.

2. The right axis is named by the buyer’s budget, not your product surface.

The hard part of the axis isn’t recognizing that you should stack on one. The hard part is naming the right one. The axis lives where the budget lives, which is rarely where the product currently lives.

Products have surfaces. Buyers have gravity. Name the axis at the surface and you keep asking “how do we make writing better?” Name it at the buyer and you ask “who pays when communication fails, deals slip, forecasts miss, or decisions slow down?”

Let’s compare Grammarly with Gong.

Both companies started with the same kind of asset: ambient access to the substance of professional knowledge work, captured at scale, by default, as people did the work.

Grammarly: a writing assistant inside the browser, the email client, the document, the messaging app. One million daily active users by 2015. Thirty million by 2020. If you wanted to know what knowledge workers actually wrote, not what they said they wrote, Grammarly was the one company on earth that knew.

Gong: a meeting bot inside enterprise sales calls. The conversations that actually decided whether deals closed, captured by a bot that joined the call automatically. By 2021 the company was valued at $7.25 billion. By 2025, over 4,000 customers.

Two companies. Same starting assets. Very different choices about whose axis they were on.

Eilon Reshef, Gong’s CPO, has told the design-partner story a few times now. Twelve sales teams in 2015–2016 trying out an early version of the product. They started complaining that the bot wasn’t joining every call, just the ones the rep manually flagged. Gong hadn’t built that yet. They built it. Once they implemented universal recording, the design partners went quiet, “happily relying on the tool for every sales conversation.”

That’s the first primitive locked in. The bot joins by default. Recording is the norm. Opt-out is the exception. The captured calls weren’t just transcribed. They were rendered into the seller’s own workspace as judgments. A flag in Salesforce: this deal is at risk because the prospect’s CFO hasn’t spoken in the last two calls. A coaching note: your three top sellers all ask this question at minute fourteen, and you don’t. The seller acted on the judgment before the next conversation. The next conversation generated more data. The model retrained per-deal, daily.

Two primitives on the axis. Both about the seller closing the next deal.

The third move came on October 8, 2019, and you can read Udi Ledergor’s first-person account of it on his blog. Gong’s marketing team announced the company was leaving the existing category, “conversation intelligence,” and creating a new category called “revenue intelligence.”

This sounds like positioning. Annoyingly, it was strategy. It named the axis at the buyer.

Conversation intelligence sold to sales operations, individual sales reps. Revenue intelligence sells to the Chief Revenue Officer, where budget is millions. The product was substantially the same. The axis Gong was now stacking on was different: the CRO’s axis runs through forecast accuracy, deal velocity, and quota attainment, and every product Gong shipped after October 2019 (Forecast, Engage, Coaching, the deal-desk tools) landed inside that scope because they’d named the axis where the larger budget lived. Gartner picked up the category about a year later.

Now Grammarly.

The frame Brad Hoover settled on as CEO in 2011, and stayed inside until 2023, was writing goals. Not communication outcomes. Not the actions writing leads to. Not what someone does with the email after it’s drafted. Writing. Goals.

You can see the frame in the words Hoover used for fifteen years. From the IVP profile, recounting how the early team aligned in 2011: “we coalesced around a vision of building Grammarly into a broad-based communication assistant that went far beyond spelling and grammar, enabling people to fully accomplish their writing goals.“

The frame is writing goals. It’s a product description, not a buyer description. It doesn’t ask whose budget cares about better writing, or who would pay more for that writing to do something specific (close a deal, prevent a misunderstanding, get a decision through faster).

What got built reflected the frame. Native apps for Windows and Mac in 2017. Mobile keyboards in 2018. Tone detector in 2019. Each one a deeper, more accurate version of “help people write better in the place where they’re writing.” None of them moved up the value chain to the manager who pays for better team writing, or the operations leader who pays for fewer miscommunications, or the chief of staff who pays for faster decisions.

GrammarlyGO, the first generative-writing feature, the first product that could compose something rather than fix something, shipped in March 2023. Four months after ChatGPT shipped. The CEO who steered the writing-assistant frame for twelve years, Hoover, stepped aside the same month. Coda acquisition: December 2024. Superhuman acquisition: mid-2025. Corporate rebrand to Superhuman Platform Inc.: announced late October 2025.

Grammarly did not miss the future because it lacked data. It missed the buyer.

Name the axis at the product and you keep improving the surface. Name it at the buyer and you move toward the budget. Gong did the second move in October 2019. Grammarly did the first move for fifteen years, then realized it had to acquire its way out.

3. Surfaces compound only when they share the same axis.

This is where axis discipline becomes dangerous to copy. From the outside, it looks like “add more surfaces.” Inside the loop, it is the opposite: add only the surfaces that feed the same buyer outcome.

Cursor is the contemporary version because every new surface touches the same buyer outcome: developer ships code (not writes code). Inline tab captures micro-acceptance. Chat captures intent. Composer captures multi-step delegation. Background tasks capture unattended work. Slack and CLI move the loop outside the IDE. Seven surfaces, same axis, shared reward loop.

In September 2025 Cursor published the formula behind that loop on their engineering blog: accept gets +0.75, reject gets −0.25, weights roll every ninety to one hundred and twenty minutes on four hundred million requests a day. They were not worried about anyone copying it, because the formula travels but the axis discipline does not. dunnhumby could ship the same formula tomorrow and it would land on PowerPoint decks for grocers. Grammarly could ship it and it would run on the writing surface for another decade. The math is portable. The choice of which surfaces to stack so signal flows between them is not.

Here is the Axis Discipline Test. Pick one product line (based on proprietary data) and answer it honestly.

1. Who is the buyer whose budget gets bigger when this works? Not the user. Not the team that likes you. The buyer.

2. What direction does their economic value move in? From signal to judgment? From judgment to action? From action to automation? Name the line.

3. What was the last surface you added? Did it compound the same loop, or did it just share the logo?

If it does not feed the same loop, you are not stacking. You are collecting furniture.

Humby called data the new oil in 2006. Twenty years later, dunnhumby is a consultancy because the oil never moved. Cursor is a billion dollar coding IDE because it did.

Companies referenced in this chapter

Chapter 4: The Signal Was Worth the Loss

Why the fastest companies made data and algorithm bets that didn’t pencil out as products.

“Character is destiny.” — Heraclitus

“All happy families are alike; each unhappy family is unhappy in its own way.” — Tolstoy

Meitu had appeared in two earlier chapters. Both times I thought I had explained it. Both times I kept coming back to it in my notes.

The company was listed on the Hong Kong Stock Exchange in December 2016 with ninety-five percent of revenue coming from selling smartphones at a loss. Read that again. The IPO prospectus of a publicly traded company was carried by a hardware line that lost money on every unit. Under product economics, the company shouldn’t have existed.

Then it licensed the phone brand to Xiaomi for a thirty-year royalty stream. Then it disclosed a forty-million-dollar Bitcoin and Ether treasury position in March 2021. Then it sold the crypto in 2024 for a gain larger than its full-year operating profit and paid out a special dividend. Cai Wensheng, the founder, later expressed regret about the crypto position. Not because they lost on it. Because they won, and the win wasn’t strategic. The focus, he said, was now on AI.

The founders, Cai Wensheng and Wu Xinhong, are in their forties. You cannot find either of them on LinkedIn. The website still looks like 2014.

The more I studied Meitu, the less it looked like strategy and the more it looked like a company that had decided product economics was someone else’s problem.

A Meitu, for the rest of this chapter, is a company whose winning moves were locally stupid as products and rational as data bets. The phones lost money. The face-image dataset they captured did not. The first half of that sentence is what most builders see. The second half is what made this company.

So how many more companies in this study made moves that looked obviously wrong as products and turned out to be data or algorithm bets in disguise?

Holy shit, lots.

DoubleClick paid $1.7B in 1999 to merge anonymous cookies with offline household profiles, triggering an FTC investigation. That wasn’t a marketing play (would’ve been a pretty terrible one). It was a bet that fusing the two datasets would matter more than the potential backslash and legal troubles.

Anthropic held its flagship model back from public release for seven months while OpenAI ate the consumer market.

Cursor ran negative gross margins on inference for an entire year. That wasn’t a pricing mistake. It was the cost of capturing four hundred million daily keystrokes of accept/reject signal.

Manus shipped a model wrapper as a stealth product in early 2025 with invite codes trading hands at six figures.

Three things kept showing up.

• The move never made sense alone. It made sense as part of a bundle.

• The slow side saw it, reasoned about it, rejected it on product logic, and lost anyway.

• The disposition that produced the bundle wasn’t strategic. It was the founder’s tolerance for running data and algorithm bets the product math wouldn’t approve.

1. The move made no sense as product. It made sense as signal.

Between 2012 and 2014, Meitu didn’t just launch one strange product. They launched a sprawl of free apps: BeautyCam in April 2013, Meipai in May 2014, BeautyPlus in April 2013. All generating face-image data at zero direct revenue. None with any clear monetization path. While that app sprawl was running, they launched the Meitu Kiss smartphone at RMB 2,199, a loss-making phone aimed at women selfie users.

At the launch, Cai Wensheng framed the strategy: “the best structure for mobile internet businesses is software + hardware + cloud.” The apps captured the faces. The phones, sold below cost, pulled the apps’ users onto a controlled hardware surface that captured higher-quality face data and behavioral signal. The cloud layer fused both streams. Hardware revenue ramped from 59.7% of total in 2013 to nearly 90% by 2015. Every dollar of that hardware revenue was subsidizing a data-acquisition channel.

The matched-pair company, Lightricks, founded in January 2013 in Jerusalem by five Hebrew University PhD students, did one thing through the same period: subscription mobile creative apps. Facetune launched March 2013, Facetune 2 with the subscription pivot in 2016, then Enlight, Photoleap, Videoleap. Thirteen years of clean subscription compounding to a $1.8B Series D in September 2021. Beautiful product economics. The unit math worked at every stage. The founders of Lightricks could explain every decision in a single sentence.

Lightricks ran the rational moves. They won inside one regime. In February 2026 they had to split the company in two to chase the AI multiple the subscription business never gave them a reason to build.

My guess: Meitu would not have needed a clean business-unit split to chase the AI multiple. It would have just chased it. Lightricks needed the move to make organizational sense first. That is the difference between product economics and signal economics in one sentence.

Cleaner companies run fewer ugly bets. That is why they look better in the board deck. It is also why they get fewer chances to discover a combination whose value only exists after the pieces touch. A signal bet rarely pencils out alone. It pencils out as part of a bundle.

Seventeen years earlier, DoubleClick ran the same pattern. The DART cookie read behavior across publishers. DART for Publishers and DART for Advertisers put the company on both sides of the ad market. Then DoubleClick bought Abacus and tried to fuse anonymous browsing with offline household profiles. The FTC investigation arrived by early 2000. Google still bought DoubleClick for $3.1B in 2007. The move looked ugly as product and dangerous as PR. It made sense as signal.

Two GREATs, seventeen years apart. Both running multiple bets at the same time. Both winning a combination they couldn’t have specified in advance, because the value of the combination only existed in signal space, not in product space. The harder question is why the slow side, watching the whole time, wouldn’t make those bets.

2. The slow side wasn’t asleep. It was running the wrong economics.

Aidan Gomez sat down with McKinsey in 2024 and explained, fluently and on the record, why Cohere wasn’t building a consumer product. “What has helped us succeed in the enterprise world is the fact that we’re only focused on enterprise. We’re not trying to build a consumer service at the same time as we’re trying to build this enterprise platform.”

Clean and rational. It’s also the answer of a CEO whose company would cover the same revenue ground from 2023 through 2025 that Anthropic covered in twelve months. $87M ARR in January 2024 to $1B by December.

Anthropic spent the years leading up to and through that window doing several things that violated startup common sense.

They held Claude back from public consumer release until July 2023, roughly seven months after ChatGPT. They published the Responsible Scaling Policy in September 2023, a public commitment to pause development at safety thresholds, in writing, in front of investors. They ran on Constitutional AI, the research that let them substitute cheap RLAIF for the expensive RLHF labor pipeline OpenAI was paying for. A methodology bet that, if it worked, replaced an entire vendor category of human-labeled training data.

Cohere watched all three moves and chose not to make any of them. Gomez can tell you exactly why. He’s right that running a consumer service while building an enterprise platform is hard. He’s right that focus is a real advantage. He’s running product economics, perfectly executed. And product economics under regime shift produces the wrong answer.

That’s the uncomfortable part. The slow side isn’t asleep, isn’t outflanked, isn’t missing the memo. They’re thinking. They’re making coherent strategic arguments. They’re losing anyway, because the strategic arguments they’re making are correct under product economics in a moment when the true focus should be signal economics.

Cursor went from $1M ARR to $100M ARR in twelve months between January 2024 and January 2025. In that year, Cursor forked the entire Visual Studio Code IDE rather than ship a Microsoft-style extension, ran inference at negative gross margins to capture every keystroke, trained a custom Tab autocomplete model on accepted/rejected suggestions, and acquired Supermaven in November 2024. Aman Sanger had articulated the rationale on Latent Space in August 2023, before Cursor had any meaningful traction: “in the long term, you’re going to need to design just a very different UX that the extensions don’t give you.” He wasn’t talking about user experience. He was talking about signal architecture. The UX matters because it produces the training signal, not because users like it.

The matched pair, Suno, covered comparable revenue ground in the same window with episodic batch generation and a polished surface across web and mobile. No continuous in-product capture loop. Mikey Shulman went on 20VC in January 2025 and gave his own version of the answer: “At some point, I don’t know if it’s version 4 or version 5, there will be a last model release that is released as a model. Everything else is just product releases.” It’s a reasonable theory of where value lives. It’s also wrong if signal is the unit. Suno is running product economics, beautifully. Cursor is running a different game.

In both pairs, the slow side could articulate exactly why they weren’t doing what the fast side was doing. The articulation was correct under product economics. The moves weren’t strange because the slow side missed something. They were strange because they violated a logic the slow side correctly understood.

Coherence under the current economic regime is what gets you the wrong answer at exactly the moment the regime changes.

3. Disposition shows up as which economics you trust.

“when your user base is big enough, you can do anything.” (Cai, CEO of Meitu, 2017)

It’s not a strategy. It’s not even an argument. It’s a personality. Whatever Meitu happens to be doing on a given Tuesday (selling phones, holding crypto, licensing IP to Xiaomi, pivoting into enterprise AI), Cai is the kind of person who will keep doing more of it on more surfaces until something stops him.

Zeev Farbman at Lightricks said something different and just as durable. November 2018, deep into Lightricks’ subscription compounding: “this field of creativity lends itself well to the exciting, and in many ways, new business model of consumer mobile subscription.” That’s also not really a strategy. It’s a description of what Farbman finds exciting: subscription mobile creative apps, specifically. He’s optimizing for subscription unit economics, which is a perfectly defensible product frame. Lightricks spent the next eight years inside that frame until February 2026, when they had to surgically split the company in two to chase a multiple they hadn’t built. Farbman wasn’t wrong about subscription. He was right about it for a decade.

The cleanest explanation I can give is uncomfortable: The pattern is which economics the founder trusts when forced to choose between them. (Product economics, or signal economics?)

It’s a simple question for YOU: If you’re confronted with a choice between building a better more profitable product, and an opportunity to gain more signal into an unknown space. Will you go with the likely good known product? Or will you go with the signal, and trust that, over time, it will lead you to even more profitable products? It’s easy to say “but” but those founders didn’t say but. They choose the signal, even if times are hard, not just in the good times when they have “money to throw around on experiments.”

This is also the answer to what the previous three chapters were really about. The Tripod, the Rotation, and the Axis are not three frameworks. They are three things a signal-economics disposition will do.

• The labeling machine costs product surface area.

• Rotating at eight-out-of-ten costs short-term unit economics.

• Stacking on the axis means adding surfaces that don’t pencil out individually.

A founder who trusts product economics will not run any of them. A founder who trusts signal economics will run all three without being told.

Whether their disposition would have been right for a different moment is a question the dataset can’t answer, and one the founders themselves probably couldn’t either.

Here is the Signal Economics Test. Pick one move your company killed in the last six months and answer honestly.

1. Why was it killed? If the answer is “the product math didn’t work,” keep reading. If the answer is “it was illegal” or “we didn’t have the cash,” stop here. This test isn’t for you.

2. Would it have produced data, training signal, or algorithmic position your competitors could not buy later? Not “better user experience.” Not “improved retention.” A dataset, a feedback loop, or a methodological position someone else would have to spend years rebuilding.

3. Who in the room argued against it? Listen to them. They may be right. But in this study, the slow side often sounded most intelligent right before it lost.

No table this time. The founder-disposition pattern shows up across the other chapters. The point is simpler: when product economics and signal economics disagreed, the GREATs trusted the signal.

The CFO usually had the cleaner slide. The winner usually had the uglier loop.

Chapter 5: Stacking the Boring Parts

Why the GREATs run all four boring parts of data-centric AI. The GOODs run two and call it strategy.

“Amateurs talk strategy. Professionals talk logistics.” — military proverb (often attributed to Omar Bradley)

“In God we trust. All others must bring data.” — W. Edwards Deming

You already know the Cohere/Anthropic gap.

By now, you also know it wasn’t one thing.

It wasn’t just the product surface. It wasn’t just the buyer axis. It wasn’t just signal economics. It wasn’t just the willingness to do locally absurd things.

Those were the visible decisions.

This chapter is about the machinery underneath them: the boring data system that made the decisions compound.

Anthropic did not just have a better model. It had a better failure machine.

Cohere ran pieces of that machine. Anthropic ran the whole thing.

And that is what makes this chapter irritating: the machine was not hidden.

Andrew Ng popularized the phrase data-centric AI in 2021. Karpathy had made the data-as-leverage argument earlier in his 2017 “Software 2.0” essay. By 2024, the field had a whole tooling and workshop ecosystem around data quality, labeling, governance, and evaluation. Fine. The operating questions were older than the literature.

In fact, they were already visible in 1999, inside a directory company with two hundred editors. The editors were not called labelers. They were called ontologists.

“The Looksmart directory is professionally edited by Looksmart ontologists (experienced editors who specialize in content classification and organization) into 26,000 categories and the keywords”

The four questions are boring enough to miss:

• What counts as right?

• How fast does right change?

• Which errors decide tomorrow’s data?

• Who is allowed to label?

Across the dataset, the GOODs usually had one or two of these. The Verbits and the Uniphores both had labeling pipelines. The Anthropics and the Coheres both retrained against feedback. The GREATs answered all four on the same loop.

The gap isn’t awareness. It’s stacking.

1. LookSmart was already running the boring stack in 1999.

In 1999 a directory company called LookSmart went public on NASDAQ at a billion-dollar valuation on the back of two hundred paid professional category editors and an Editor-in-Chief. The directory they curated was the substrate behind a meaningful fraction of MSN search traffic. Microsoft was paying them thirty million dollars up front and five million a year. For accuracy.

What counts as right? The editors knew. They described their duties to Traffick in October 2000 as “ontology and content oversight.” Ontologists. Not labelers. After the October 2000 Zeal acquisition, LookSmart added a managed volunteer corps gated by a quiz on the same editorial standard, with tiered admission and a mentor program. The apparatus existed to make sure volunteers labeled to the same standard the paid editors did.

How fast does it change? The contract forced the answer. Editor review of new submissions in three business days. Listings live on MSN within a month.

Which errors come first? Microsoft told them. From LookSmart: “the test results will affect Microsoft’s decision to renew the distribution agreement, and whether to continue to distribute some or all of our paid listings after the agreement expires.” A paying customer running A/B-style quality comparisons. With the renewal as the prize. The errors Microsoft flagged were the errors LookSmart fixed first.

Who labels? Professional category editors. Domain judgment applied by people whose job title named the domain.

Four questions, one loop, running together, in 1999.

BizRate, founded the same year (later renamed Shopzilla after a 2004 acquisition), ran the opposite playbook on the same go-to-market. Same portal-licensing strategy, same era, same buyers. The substrate was different. ShopRank ran a patent-pending algorithm over machine-aggregated product data and returned shopping results in twenty milliseconds. The labeled-feedback channel was a million consumer reviews per month, but the reviews were structured for merchant ratings, not for refining what got listed in the first place. There was no editorial standard, because there were no editors. The largest hiring pool was engineers.

Both companies were running data-centric AI before anyone called it that. LookSmart hired experts to apply a defined standard on a tight cadence with errors fed back through their paying customer’s own quality tests. BizRate ran an algorithm. LookSmart reached one hundred million dollars in revenue in twenty-four months. BizRate took sixty.

2. Four questions, one loop.

Watch what just happened. LookSmart didn’t have a research breakthrough. It had four answers applied together on the same loop.

What counts as right? A defined standard of correctness applied by humans at scale. A working document that tells a labeler whether output X is acceptable for use case Y. Not a research paper. Not a tone-of-voice deck.

How fast does it change? Days, weeks, not quarters. The loop closes faster than the market can write a competing playbook.

Which errors come first? The hardest, most surprising failures get routed back into the next training cycle before anything else. The GOODs train on whatever data arrives next.

Who labels? People with substantive domain knowledge. Not Mechanical Turk. Not customer staff. Not whoever happens to sit inside the customer workflow.

The GOODs do data-centric AI as a function. The GREATs do it as an operating system.

3. Verbit owned the correction loop. Uniphore rented the workflow.

Two and a half decades after LookSmart, the cleanest contemporary illustration is a pair of transcription companies.

Verbit was founded in Tel Aviv in 2017. A transcription company that reached $100M ARR inside the twenty-four-month scaling window. Their matched pair, Uniphore, was founded at IIT Madras in 2008 and took roughly ninety-six months to cover the same ground. Both companies were doing what looks superficially like the same work: taking enterprise audio, turning it into accurate text, getting paid for it.

Verbit answered all four questions.

What counts as right? Style guides for the transribers by domain. Legal for court depositions. Medical for clinical recordings. Captioning for compliance work.

Who labels? 22,000 freelance transcribers at the Series B milestone, growing to 35,000 plus 600 professional captioners by Series E. Specialists, not commodity labor, at twenty-four to thirty cents a minute.

How fast does it change? Corrections flowed back into the self-learning speech recognition models continuously. The model retrained on its own outputs, edited by experts.

Which errors come first? Funnily, Verbit even invented a patented technology to do the error routing: When a transcriber edits an audio segment, the segment is scored for how surprising the correction was, minimum-Bayes-risk and perplexity, and the high-surprise corrections get routed back to retraining first.

That last part is the tell. Verbit was not training on whatever audio arrived next. It was training on where the model was most wrong.

Uniphore looked like the cleaner SaaS company. API-first. Close to contact centers calling a ton. Founder Umesh Sachdev on Bloomberg Tech Disruptors: “Uniphore has delivered these outcomes by packaging AI solutions as software-as-a-service.” No rip-and-replace. Industry-specific small language models built per engagement through partnerships. Five technology stacks bolted on through M&A.

Sensible. Enterprise-friendly. Easy to put in a board deck.

But Uniphore didn’t own the same loop. No central labeling marketplace. No public domain-by-domain standard. No visible cross-customer failure-routing system. No expert labeler pool applying one standard at scale. The labeling, when it happened at all, happened inside whoever’s call center platform the customer was already running, by whoever that platform employed.

Verbit owned the correction loop. Uniphore rented the workflow. That’s the gap.

4. Anthropic made failure visible. Cohere made failure private.

Cohere’s deployment posture is not a mistake. It is the product a regulated enterprise buyer wants. Keep the model near the customer’s data. Don’t leak anything. Don’t centralize anything. Deploy in VPCs, on-prem, air-gapped if needed. The company wins regulated-industry deals on exactly this commitment: RBC, Ensemble Health, Fujitsu, LG, Bell Canada, the UK and Canadian governments.

Great product economics. Terrible shared failure list.

This is the link to the previous chapter. Cohere’s deployment posture isn’t a strategy mistake. It’s what running product economics, perfectly executed, looks like at the architecture layer. The disposition I named in the last chapter shows up here as code. The same founder who told McKinsey “we’re only focused on enterprise” is the founder whose architecture makes the shared loop much harder to close.

The four questions assume the loop closes globally. Cohere’s commercial choice makes sure it closes locally, if at all.

Anthropic answered all four.

What counts as right? The corpus of RLHF instructions plus the published Constitutional AI principles. The principles function as a self-applied standard the model uses to label its own outputs at scale.

Who labels? Surge AI, an expert-contractor labeling marketplace with substantive subject-matter knowledge in legal, medical, code, math, and alignment. Plus internal alignment researchers and in-house red teams.

How fast does it change? Across the Claude 2, 3, and 4 families, the major-refresh cadence stayed closer to weeks than quarters. Cohere’s cadence in the same window was closer to semiannual flagship releases.

Which errors come first? The Responsible Scaling Policy, published September 2023 and updated through 2024 and 2025, defines capability thresholds and forces evaluation work that surfaces specific failure modes. ASL-3 was activated with Opus 4 in May 2025. Each evaluation campaign produces a continuous, externally visible measurement regime, which means failure modes get surfaced publicly and feed into Anthropic’s next round of training decisions. The function the RSP plays for Anthropic is structurally adjacent to the function Microsoft’s relevancy tests played for LookSmart: an externalized measurement regime whose output is a list of what to fix next.

Cohere’s GPU-in-a-closet architecture makes that kind of shared cross-customer failure list structurally harder to build. That’s not an oversight. It’s strategy. It’s the strategy that costs you the shared loop.

Four answers at Anthropic. Two at Cohere. Same era, same research lineage, different loop.

The boring-stack test

Pick one model that matters and answer:

1. Who defines “right”? If the answer is “the model,” you don’t have a standard.

2. How often does “right” change? If the answer is “quarterly,” your cadence is probably slower than the market.

3. Which errors drive the next data slice? If the answer is “whatever customers report,” you don’t have error-driven data work. You have support.

4. Who applies the standard at scale? If the answer is “general annotators,” don’t pretend you have domain expertise.

Each of the four questions, on its own, is unremarkable. None requires a research breakthrough. None is hard to understand. The thing that’s hard is answering all four at once, inside the small window where compounding starts to mean something, while a competitor with the same talent and the same capital is choosing to answer one or two and call that strategy.

Andrew Ng named the discipline in 2021. The companies that compounded had been running it for twenty-two years already..

Companies referenced in this chapter

Chapter 6: The Distance from Data to Money

Why the fastest companies are rediscovering a loop the internet winners already knew.

“The price is what you pay. Value is what you get.” — Warren Buffett

“To live effectively is to live with adequate information.” — Norbert Wiener

On February 26, 1998, in a hotel ballroom in Monterey, California, a chunk of the TED audience hissed at a man named Bill Gross.

Gross had just demoed GoTo.com, the first commercial paid-search engine. The room hated it because it looked like corruption: people buying their way into search results. Gross’s collaborator Jeffrey Brewer described the objection: “the major objection people had was search should be egalitarian and fair. This is somehow polluting it. People being able to buy their way into search results is just wrong.”

Three of the people in that ballroom would prove the room wrong. Jeff Bezos was there. He’d internalize the architecture inside Amazon’s product page. Sergey Brin and Larry Page were also there, eight months from publishing the Stanford paper that would found Google. In Appendix A of that paper, they predicted on the record that ad-funded search engines would be inherently biased toward advertisers and away from users. Four years later, they shipped exactly the architecture they had predicted would be biased.

The room that hissed at Bill Gross included the founders of three of the largest internet companies that would ever exist, two of whom would explicitly build what they had publicly hissed at.

They saw pricing. They missed architecture.

This chapter is not really about pricing. Subscription, usage, auction, referral, CPM, enterprise license. Those are billing wrappers. The architectural variable underneath is proximity: how close the model decision sits to money, and how close the next user action sits to a training label that itself carries economic meaning.

The thesis in one sentence: every user action immediately following a model decision must be either money, or a label that points at money. If it’s neither, the loop is open.

An economic label is not just “the user clicked.” It is a user action that tells you something about value: money paid, time saved, risk reduced, work accepted, deal advanced, compute earned. The behavioral signal is whether the user did the thing. The economic label is what the thing was worth.

I’ll call the open loop a kitchen. A kitchen is anything that sits between the model decision and the economic label: humans on a sales process, batch attribution reports, redirects to a partner’s surface, weekly retraining cycles, contractual no-training clauses, off-platform inference, enterprise privacy boundaries. Kitchens slow the loop. The companies that compounded in this study spent thirty years finding ways to remove the kitchen, on one surface, in one architecture.

1. The click was the cash register

Brewer described what GoTo actually was: “all we had was one box. On the page, no advertisements on the front page, no other content, no news or other editorial. It was just a search box.” When you typed a query, paid listings appeared, ranked by bid. When you clicked one, two things happened immediately: the advertiser was billed, and GoTo collected revenue.

Crude? Yes. But architecturally important. The click was not yet Google’s relevance-ranked training signal. It was a priced performance signal. If an advertiser bought the wrong query, the mistake showed up in their wallet. If the traffic converted, they bid more. If it didn’t, they stopped paying. Relevance was not fully automated yet, but economic reality had entered the loop.

That was Gross’s breakthrough. Not a clever pricing trick. A shorter distance between search intent, user action, and money. GoTo made the click the cash register. Google’s later move was to make that same click part of the ranking machine.

GoTo went live June 1998. Revenue 1997: $22,000. Revenue 2000: $103M. Yahoo bought the company, by then renamed Overture, for $1.63B in October 2003.

DoubleClick ran the display-ad version of the loop. DART was not an auction in the GoTo sense; it was ad-serving, targeting, tracking, and reporting infrastructure. When DoubleClick served an ad, it could record the impression, read or set the user cookie, target future ads, and measure campaign performance across the network. Not bid-label-dollar in one event. But far closer to the money than the old media-buying kitchen.

The matched pair to Overture is Skyscanner.

Founded in Edinburgh in 2003, Skyscanner did flight search. Same broad user intent: a person looking for a thing. The architecture was different. Skyscanner aggregated airline fare data and presented options. When you clicked the option you wanted, you were redirected to the airline’s own site to actually book. The booking happened on the airline’s surface. The airline paid Skyscanner a referral fee, weeks later, after attribution.

Skyscanner’s own “How Skyscanner Works” page made the architecture explicit: “Skyscanner is not a travel agent. … When you click on a travel option, you will be redirected from our website and will then deal directly with the relevant travel provider.” Founder Gareth Williams, on stage at Skift Forum Europe in February 2017, made a sharper admission. Talking about Skyscanner’s then-new Direct Book program: “By offering a more seamless booking process with as little friction as possible, our direct book partners have experienced significant uplifts in both their conversion and ancillary up-sell rates.”

Fourteen years after founding, the founder realizes direct bookings are a good thing.

The architectural diagnosis: Skyscanner’s algorithm ranks flight options. The data that would tell Skyscanner which ranking actually drove a booking arrives weeks later in a batch attribution report, post-redirect, post-airline-funnel, with attribution loss baked in. By the time the data lands, the user has flown the trip. The model cannot retrain on fresh data because the fresh data does not arrive fresh. There are kitchens at every step: the redirect, the booking flow, the airline’s attribution pipeline, the referral reconciliation cycle.

Overture did 125× revenue growth in twenty-four months. Skyscanner did 180× over nine years. Same broad intent. Fundamentally different architecture.

2. Subscription works when the label still points at money

Here is the puzzle. Two of the cleanest data flywheels in the modern dataset (Cursor and Midjourney) both charge(d) subscription pricing. The user pays a flat monthly or annual amount and uses the product as much (until they hit a limit) as they want. By a strict reading of the Overture model, both should fail.

They don’t. They scale faster than any of their matched pairs.

The resolution: not every label is equal. A click, an accepted code suggestion, a preference ranking, a closed-won deal. These are not just behavioral traces. They are economic labels. They tell the system something about value, not merely taste. The subscription wrapper does not matter if the label underneath carries economic meaning.

Cursor. On September 12, 2025, Cursor’s engineering team published a blog post called “Online RL for the Cursor Tab Model.“ It contained the reward function: “We could assign a reward of 0.75 for accepted suggestions, a reward of -0.25 for rejected suggestions, and a reward of 0 if no suggestion is shown. … Currently, it takes us 1.5 to 2 hours to roll out a checkpoint and collect the data for the next step.” Four hundred million tab requests per day. New checkpoint every 90 to 120 minutes.

Every keystroke trained the next model. Every two hours the model went live. That’s not a flywheel. That’s a fire hose.

The accept/reject is an economic label because the developer is, in the act of accepting or rejecting, telling Cursor whether the suggestion was worth the cognitive cost of reading. The accept of a working completion saves time the developer is paid for. The reject of a broken completion saves time the developer would have wasted debugging. Each event has measurable economic content in the user’s own production minutes. The label is behavioral on its surface and economic underneath.

Three months earlier, in June 2025, Cursor had also moved the revenue side closer to compute reality. Pro stopped being priced around request counts and started including dollar-denominated frontier-model usage at API rates, with higher tiers for heavier users. The users producing the most accept/reject signal were now also financing the most inference. Nobody else in the AI era did that on purpose.

Midjourney. On April 4, 2025, the day after V7 launched, a paying Midjourney subscriber opened the app to generate images and was shown two hundred image pairs to rate before the model would respond to a single prompt. To use the new model, every user had to sit through approximately 200 forced image-pair preference ratings, building what Midjourney called a personalization profile. On June 17, 2025, V7 with personalization became default for every user.

Separately, Midjourney maintained a page at midjourney.com/rank where existing subscribers can rate image pairs to earn Fast GPU hours. Labeling labor literally exchanges for compute.

Midjourney’s preference label is not a dollar outcome. But it is economically priced inside the product: capability access and Fast GPU hours are exchanged for ranking labor. Revenue is pooled into the monthly tier. The label is metered, gated, and rate-limited.

Gong is the enterprise version of the same pattern. Chapter 3 covered why Gong named the axis at the CRO instead of the conversation surface. The proximity read is the architectural layer underneath: the seller’s behavioral response to Monday’s deal-health score lands later as closed-won or closed-lost dollars in the customer’s Salesforce. Those dollars retrain the model. Pooled subscription revenue. Economic labels inside the customer’s own system.

Grammarly is the negative case. Chapter 3 treated Grammarly as a buyer-axis mistake: it named the game as “writing goals” instead of communication outcomes. The proximity layer is the same failure one level lower. Grammarly captures behavioral labels everywhere — accept, reject, type, send. It does not capture the economic outcome of the writing: reply, interview, meeting booked, proposal accepted, deal closed. The integration access exists. Grammarly chose not to instrument it.

Grammarly did not lack data. It lacked an economic label.

3. Adding surfaces multiplies the kitchen

Grammarly built one surface with a kitchen baked in. Some companies build five surfaces, each with its own.

One surface, one loop. Each new surface adds its own kitchens.

In September 2001, Robin Li made a decision at Baidu that violates everything you’d write in a board deck. Baidu had been a profitable B2B business, licensing search technology to Chinese portals like Sohu and Sina. Portal licensing was 45.5% of revenue in 2002. Li walked away from it. He pivoted Baidu to a consumer search engine, ran the Overture-style PPC auction on Chinese-language queries, and let the licensing revenue collapse. By 2004, portal licensing was 2.2% of revenue. Paid search was 91%.

Side Note: Baidu’s founder Li also invented one of the first advanced search technologies for websites using hyperlinks, a result that was later cited by Sergey and Brin (not in the original paper but in their patent application).

The decision wasn’t strategic diversification. It was architectural concentration. Portal licensing required humans negotiating deals quarterly. Paid search ran the auction architecture in milliseconds. Li chose the surface with no kitchen and let the surface with kitchens go.

Excite ran the opposite play. Founded 1994 by six Stanford grads, IPO’d April 1996. Inside the scaling window, Excite added a portal, “My Excite Channel” merchandising, community features, banner advertising sold by humans for months at a time, and a $6.7B @Home cable broadband merger in January 1999. CEO George Bell, years later: “we all fell victim to the idea that we were going to be the mall and the one-stop shop for all of your application needs on the web; and that we would be able to monetize any and all those through advertising.”

Five surfaces. Five kitchens. By September 2001, Excite was in Chapter 11.

The same pattern shows up in the AI-era pairs in slightly different costumes. Cohere meters per token. Harvey charges enterprise license fees. Mistral has API revenue from its closed frontier models. None of those pricing models is what’s actually doing the work. Cohere’s customer-VPC architecture means corrections never leave the customer’s environment. Harvey’s Platform Agreement §10.8 commits the company in writing: “No Training. Harvey will not train any AI models using Your Content or Customer Data.” Mistral’s open-weights distribution means most of the inference happens off Mistral’s surface entirely. Each is a different mechanism for building a kitchen. The subscription, the per-token meter, the enterprise license, the open-weights torrent. Those are just what got billed.

This is the architectural layer underneath the previous two chapters. Disposition shows up as architecture. Architecture either closes the loop or builds the kitchen.

4. The proximity test

Pick one model/algorithm/AI decision your product makes all day long. Now answer:

1. What is the next user action after the model decision? Click, accept, reject, edit, book, buy, reply, close, churn?

2. Does that action carry economic meaning? Not engagement. Not activity. Money, saved time, reduced risk, won deals, retained users. Something the customer already pays to improve or avoid losing.

3. How long until that action becomes a training label? Milliseconds? Hours? Weeks? Never? If the answer is “weeks” or worse, the model is retraining on stale signal. Your competitor with hourly checkpoints is not.

4. Where is the kitchen? A redirect, a human sales process, a batch attribution report, an enterprise privacy boundary, an off-platform deployment, a no-training clause?

If you cannot point to the kitchen, you probably live inside it.

The companies that compounded spent thirty years removing the kitchen. They didn’t all do it by making every click a dollar. Half of them did it by making sure every click was a label pointing at a dollar.

Pricing is wrapping paper. The loop is the business.

Companies referenced in this chapter

So what?

Eight weeks. 100+ hours. Four books I won’t recommend. 23 pairs. 46 companies. One question.

The answer is what I told you on page one. The 15,000 words in between are why I believe it now: the GREATs weren’t smarter than the GOODs, weren’t better-funded, weren’t first. In half the pairs in this study, the GOOD was first to market, better-funded, better-credentialed, and still ended up at a fraction of the valuation. Sometimes a fraction of a fraction.

The GREATs shipped weird things and kept going. The GOODs reasoned themselves carefully into the wrong answer, with articulate, defensible reasons, every step of the way.

The GREATs did the locally absurd thing anyway. Not because they were braver or wiser. Because they could tolerate the mess long enough for the loop to start compounding.

So here is the last test.

Which chapter did you most want to argue with?

Start there. The thing you most want to reject is probably the discipline you would most reason yourself out of when it counts.

That is where the GOODs lost. Not where they were stupid.

If you’ve spent your career close to data, you’re probably better positioned to build AI products than most product managers in Silicon Valley. I haven’t seen anyone say that yet, so let me make the case. (Yeah I know, I might have a bias here ;))

It’s not because of technical skill (I for one don’t think they are important at all). It is because of how you think.

I’ve now spent sixteen months as Head of Product for an AI system, after years in product & data — BI startup founder, data PM, Head of Marketing for a data tool. Every single SaaS instinct I brought with me was inverted. Not slightly off. Inverted. And I still hear “other products do it this way” every week from smart, reasonable people who are pointing at SaaS products and call them role models for something that isn’t SaaS anymore.

Let me walk you through why I think they’re wrong.

SaaS product management is a convergent discipline. You face one uncertainty — does solution X solve pain Y? — and you reduce it (and manage the risk). Research, prototype, test, ship, measure. Every sprint narrows the gap. Convergence IS the job. “I don’t know yet” is a temporary state you’re trained to exit as fast as possible.

AI product management is a divergent discipline, and that turns everything on its head (at least from my experience). You face two uncertainties that no PM toolkit can resolve (correction: that NOTHING can resolve, that’s the whole point). The jagged frontier: you genuinely cannot predict which tasks AI handles brilliantly and which it botches — no research reveals this, only use at scale (and it cannot, it’s inherent in the idea of a general purpose technology). The capability explosion: what’s impossible today becomes trivial in six months. Constraints decay on a six-month half-life. I’ve bet my career on the belief that AI today is at 1% of what it will be. I mean that literally. A hundredfold better in a decade, in a hundredfold more things. I don’t see a ceiling.

In SaaS, the PM reduces uncertainty. In AI, neither type yields to PM tools. So the job inverts: from “converge on the answer” to “build a product that thrives without one.”

Read the right column for a second. Comfort with irreducible uncertainty. Building systems where signal emerges through use, not specification. Letting reality update your model instead of forcing your model onto reality. Designing for compounding improvement over time.

Now if you’re a SaaS PM reading this: the good news is that convergent skills aren’t useless — they’re just not sufficient anymore. The transition is uncomfortable, but it’s learnable. Get comfortable with “I don’t know yet at all and will never know.” Get comfortable with betting big, and without clear paths to success.

If you’ve spent years close to data — leading data teams, founding data companies, studying how truth actually emerges from evidence — you’ve internalized the divergent mindset already. The academic discipline of letting evidence lead. The builder’s patience with signal that takes time to resolve. That comfort with “I don’t know yet, and I can’t force the answer” isn’t a weakness. It’s exactly what AI products require. You might be closer to AI-PM-ready than you think.

AI product value vs. SaaS product value is all about absorption

The entire value of an AI product is driven by two forces of uncertainty. Not by how well you reduce risk. Not by how polished your current features are. By how well you bet under uncertainty.

To me (and my math brain) this looks something like this:

• t = today: SaaS value = known problem + known solution + execution quality = 10 + 10 + 10 = 30.

• t = 6 months: that value ≈ 0 (constraints died, capabilities doubled, your solution solves yesterday’s problem)

• AI product value at ANY t = what the frontier reveals through use + what each capability doubling unlocks — and both terms compound = (something unknown)^t.

• no matter where the SaaS value starts, it decays. The AI product value goes up exponentially.

In SaaS, the most valuable PM is the best risk reducer and quality builder. In AI, the most valuable PM is the smartest bettor under uncertainty. It’s a different game with a different winner.

Here’s how I think about it: your customers are outsourcing two things to you. (1) Understanding what AI can do today — the jagged frontier they can’t see. (2) predicting where AI will be in six months — the capability curve they can’t forecast. They don’t need to know the knowledge cutoff of the underlying LLM. They don’t need to know which model is best for which task. They don’t need to decide whether web search should be on or off. They’ve outsourced all of that to you. And it’s your job to get it right for at least 80% of their use cases (for each individual user).

Think about it like electricity or the internet. When you buy an appliance, you don’t think about voltage regulation. When you open a browser, you don’t manage TCP packets. That’s the job of the product in between. Same here — and no, the answer is definitely not “teach everyone prompting”.

So your product has one job: be an absorption machine for technological progress of this big fat general purpose technology. Every product decision either increases or decreases your absorption surface. The seven inversions below are the seven ways SaaS instincts shrink it.

1. Don’t ship even if they desperately want it

The SaaS instinct goes something like this: customers are asking for it, sales is hammering on your door, ship it. Customer-driven development is the gospel.

Business case - Granola: The Granola team had exactly this problem. Their AI meeting assistant could only handle 30-minute meetings because of context window limitations. Customers wanted long-meeting support — I did too. Most teams would’ve done the “responsible” thing: spend months building complex chunking algorithms and token management solutions. Instead, Granola improved every other part of their tool but this one. When bigger context windows arrived months later, they plugged in overnight. 70% weekly retention. $250M valuation.

At MAIA, we had a similar situation. Our customers kept asking for a translations feature. “Build this and we’ll ditch our DeepL subscription.” We said no. We invested in richer context instead — glossaries, domain terminology, company-specific language.

Last month, our sales rep forwarded a message I didn’t expect: “Customer says MAIA translates better than DeepL.” Third time in sixty days. We don’t build a translator. We build enterprise AI knowledge management. But enterprise translation isn’t a language problem — it’s a context problem. DeepL can hit grammar and tone. It doesn’t know your project language, your approved terminology, your supplier jargon, your abbreviations. MAIA translates better not because it’s smarter, but because it’s been onboarded into your world.

SIDE NOTE: We’re still in a weird place with AI. That means both customers and companies building AI products will have to work hard to get the elusive productivity gains that AI has (I’m a true believer, because I’ve seen it again and again across industries and users). For product builders, that means making amazing products. For customers, it means they’ll still have to basically “onboard” their AI tools for some time to come. Check out that article from me on that topic if you’re interested.

And now customers want the next thing: 40-page document translation, just like DeepL does. Will we build it? Nope, same principle. Output context windows will be big enough in 6-12 months that models handle this natively. And by then, our translations will be 2-3x better — not because we engineered around the page-count constraint, but because we spent those months deepening the context that makes translations actually sound like they came from inside the company.

We made the same bet with web browsing — said no, invested elsewhere, a capability expansion solved it without us building anything.

The difference is in time horizons. We should be better at forecasting capability curves than our customers. They’re outsourcing that job to us, and we should be grateful for the trust. Of course, you can only say no to features that aren’t the core thing your product does. If you’re a translation product, you translate. You can hold off on the 40-page constraint because you’re still delivering massive value on 5-page documents. The “no” only works when you can confidently say: “We’re delivering this other value to you right now, and the thing you’re asking for will be better when we get there.”

Every feature you ship to satisfy today’s demand is a feature you maintain instead of absorbing tomorrow’s capability. The hardest word in AI product management is “no” — said to a customer who is correct about their pain and wrong about the solution.

2. Friction is your AI’s food

The SaaS instinct: reduce friction everywhere. Every extra field kills conversion. Get to value in under 60 seconds.

Business case — Ramp could have done what every expense tool before them did: minimize input fields, auto-fill everything, get the receipt submitted in three taps. Instead, their AI agents are trained on patterns from 50,000+ customers, and they work precisely because users provide rich expense context, policy documents, historical patterns. In October 2025 alone, Ramp’s AI made 26.1 million automated decisions across $10 billion in spend. The richness of the input IS the intelligence. Strip that away in the name of friction reduction and you have a dumb calculator with a $32 billion valuation’s worth of potential left on the table.

At MAIA, we turned on mandatory interrogation-style onboarding that refuses to accept “Product Manager” as a sufficient description of what you do. The sales team hammered on our door (”are you sure? We should definitely turn this off for customer XYZ”). Six months later? The only thing we hear is praise. “How does MAIA know she should adopt the answer for an industrial marketer working in Asian markets?” is the only question we get now.

How do you actually pull this off with thousands of existing users? Two things. First, you tell them why — “we need this to give you dramatically better results.” Second, you show them why — immediately demonstrate the quality difference. And of course you make the friction itself as seamless as possible. We use AI-assisted onboarding that makes the five minutes feel like a conversation, not a form. The friction isn’t in the UX. The friction is in the information — and that information is your AI’s food.

SIDE NOTE: In data, you have GIGO: garbage in means garbage out. Most SaaS PMs have spent theirs believing that less in means faster out. Those are opposite instincts.

Five minutes of input friction creates compound value across every future interaction. The shortcut you remove isn’t a step you skip — it’s signal you’ll never get back.

3. Every option you add makes your AI dumber

The SaaS instinct: give users control. More options, more configuration, more “empowerment.” Let them choose.

Business case - Cursor, the AI coding tool that hit $2 billion in annualized revenue faster than any B2B product in history, made one of its smartest moves when it temporarily removed model selection entirely from its interface. Users could no longer pick between Claude, GPT-4, or Gemini. The backlash was brief. When Cursor restored the option with “Auto” as the default, developers stopped caring. Each manual model selection had been a micro-decision that pulled developers out of flow state. By automating routing, Cursor let the AI do what it’s better at — matching the right model to the right task — and freed users to focus on their actual work.

At MAIA, we had the same pattern. Users could pick GPT-4 vs. Claude vs. Gemini. They picked the optimal model 15% of the time. We removed the choice. Auto-selection. Optimal model usage jumped to 95%. Three persistent customer problems vanished overnight. Not because the AI got smarter. Because we stopped letting users make it dumber.

And you know what? Just like for cursor this means, users automatically get the best model when there’s an upgrade in the back. You’re handing the best tech to them and roll it out to 100% of your users right away. Every single option cuts pieces of those 100%.

Here’s the dynamic most people miss: your users have outsourced the prediction to you. That’s what they’re paying for. When you give them an option to override the AI’s judgment, you’re telling them one of two things — either you don’t trust your own system, or you were too lazy to build the smart logic that makes the right call automatically. Neither is a good look. And both make your product worse.

And honestly, it also makes you lazy. Every toggle you add is a solution you didn’t build.

Instead of figuring out how to make the AI smart enough to make the right call, you punted the decision to users who know less about AI capabilities than you do.

Every decision you force on users is a decision the AI can’t make autonomously. The products users call “smartest” are the ones that ask the fewest questions about how to operate.

4. Ship for the model that’s coming, not the one you have

The SaaS instinct: ship the best product possible today. Optimize for current constraints. Users need solutions now, not promises.

Business Case - Replit launched Ghostwriter in October 2022 as basic autocomplete — four features at $10 a month. The product was, frankly, mediocre. But the team made a critical architectural choice: they built a modular “society of models” where any component could be swapped independently. They didn’t engineer complex workarounds for reasoning limitations or context window constraints. They accepted those constraints and built clean primitives that were ready for the next generation.

When Claude 3.5 Sonnet dropped, Replit Agent could suddenly plan, code, test, and deploy entire applications from natural language — not because Replit built those capabilities, but because their architecture absorbed them. AI-generated apps grew from 50,000 in 2023 to 1.5 million in 2024 to 5 million in 2025. Revenue went from $16 million to $253 million. That’s 1,556% year-over-year growth from an architecture decision, not a feature launch.

This is the same bet Granola made with meeting length — accept the constraint, build for absorption, win when the constraint dies.

At MAIA, when Claude 3.7 integrated into our system, 90% of our prompting challenges disappeared overnight without us building anything. The best engineering hours we spent were the ones where we built nothing — we just made sure nothing blocked the next model from working.

SIDE NOTE: this is the Constraint Decay Law from my RAG article applied to product decisions instead of engineering decisions. Same law, different victim. In engineering it kills your architecture. In product it kills your roadmap.

How do you actually do this? The Granola trick is the template: YES you get meeting transcripts, but only up to 30 minutes. YES you get translations, but only for 5 pages at a time. You deliver genuine value within the current constraint, you make the constraint visible and graceful rather than hidden and hacky, and you build your architecture so that when the constraint dies in six months, you absorb the improvement without touching a line of code.

The team that ships the “worst” product today ships the best product in six months. Every engineering hour spent working around a constraint that dies in six months is negative value — not zero, negative.

5. Every approval gate you add is a lesson your AI never learns

The SaaS instinct: keep humans in the loop. Responsible AI. Risk mitigation. Never let the machine decide without oversight.

Sierra AI built the clearest proof of what happens when you replace approval gates with intelligent autonomy. Their architecture chains a reasoning agent with a supervisor agent — if each is independently 90% accurate, chaining them yields 99% effectiveness. No human in the loop for routine decisions. The result: customers see 70-90% autonomous case resolution with quality scores around 4.5 out of 5. Sierra hit $100 million in ARR in 21 months.

The distinction isn’t “no guardrails” vs. “all the guardrails.” It’s teach vs. cage. Give the AI context, principles, and goals — not restrictions and approval gates.

At MAIA, our Insight Hub automatically collects learnings from every interaction and shares it with the whole team. Yes, that’s scary. My engineers weren’t happy about it the autonomous part. We had a heated discussion, everyone wanted to add deletion options, opt-ins, switches and everything that stops the system from learning automatically. But in the end, even the sales team caved and realized that we have to make it autonomous if we want it to have any impact at all.

Our engineering team did an amazing job and added four levels of security. The insight collection happens because that’s how the product learns. Every time a human gate prevents the AI from acting, a learning opportunity dies. The AI doesn’t just fail to complete the task — it fails to get smarter from completing it. Multiply that across thousands of interactions and you’ve built a system that’s structurally prevented from improving.

“Responsible AI” that prevents AI from acting produces less responsible outcomes than teaching AI to act well and showing its work.

6. Make it trustworthy, not magical

The SaaS instinct: make it magic. Hide the complexity. The best UX is invisible. “It should just work.”

AI is not plumbing. AI is a collaborator. And trust in a collaborator doesn’t come from hiding how they work — it comes from seeing enough to calibrate. That might be showing reasoning chains. It might be a loading signal that communicates “searching 400 pages right now.” It might be the AI flagging what it can’t do. It might be sound, imagery, animation — whatever signal the user needs to calibrate their trust. The mechanism varies. The principle doesn’t: users need to calibrate trust, and magic prevents calibration.

SIDE NOTE: There’s a saying in the cyber sec space that “feeling safe and being safe” are completely separate things in humans. You can have either without the other. Perfect example? The little green lock next to an URL. Do you know what SSL really is? ⇒ Think about trusting autonomous systems the same way.

Harvey AI, the $11 billion legal AI platform, developed its own Source Score metric. Their standard: an answer is not complete unless it accurately refers to source material through inline citations. When they integrated newer models with “capability awareness,” the AI started flagging what it can’t do — actively telling users where its reasoning is uncertain. Showing limitations builds more trust than hiding the gaps. Lawyers grant Harvey autonomy precisely because they can see its reasoning and verify its sources.

At MAIA, we have two killer features. One of them is the High Precision Mode. It does something simple: It generates a full response to a question, then extracts all facts and assumptions made in the answer (usually 20-50) and then verifies them again using all source material available (and other knowledge sources we connect to). As you might imagine, this takes 50% longer than simply generating a response.

So previously, we had the option to turn this on when users wanted it (10% did so), now we simply have it on by default, always (100%). Turns out, noone cares about 50% additional waiting time every single query, but everyone cares about getting well grounded responses! (And no, we do it different than others. We check whether we think the fact is a straight fact - green below - or whether it is a conclusion we drew from existing facts. A derivative truth).

The black-box product wins demos. The trustworthy product wins renewals. Every demo you lose on polish, you win back tenfold in retention.

7. Your AI is only as smart as its worst dimension, not its best

Each of the six unlearnings above targets a different dimension of how your AI product contacts reality — how much users tell it, how much it can do on its own, how fast it learns, whether it’s built for tomorrow, whether users can calibrate trust, whether you ship for real demand or predicted demand.

Core thesis: these dimensions don’t add — they multiply. A zero in any one collapses the product of all others.

You can be world-class at five and still have a dead product. Your brilliant transparency means nothing if the AI can’t act on what it knows. Your rich input means nothing if the system doesn’t learn from it. “Being great at one thing” doesn’t work in AI the way it works in SaaS.

Here’s why this is life-or-death, not theoretical: your product’s value distributes across your user base, across each customer, across each user’s use cases. Turn off any dimension for any slice, and that slice gets zero value from your product over the medium term. Not reduced value — zero. Because it’s multiplication, not addition.

I keep having heated discussions with our engineering team about this. I say “we will NOT allow users to turn off web crawling.” They say “are you serious? We promise trust. If they really want that control, they should have it. I can easily tell you ten cases where it’s absolutely necessary.” I say “well, then we should build a good AI in front that makes that judgment call.” “Why would you piss off our users?”

The reason isn’t stubbornness. It’s multiplication. If we turn off web crawling, some fraction of use cases for each user gets zero value from our product. Not reduced. Zero. Over the next six months, that’s a dimension of their experience where we’ve delivered nothing while capabilities doubled around us.

You don’t have to piss off users. You DO have to protect every dimension. Smart defaults, sensors, resets, AI-powered judgment calls — lots of options. The one option you don’t have is letting any dimension hit zero.

This IS how data people already think. Bottleneck analysis. Pipeline thinking. The weakest link determines throughput. Chain-linked processes where a 10% improvement in the wrong step produces 0% improvement in the outcome. You’ve been doing this analysis your whole career. Now point it at the product layer.

“Other products do it this way.”

I’ll hear it again next week. The sales team will want something easy to demo. A stakeholder will ask why users can’t pick their own model. Someone will insist on human approval for a decision the AI makes better. A customer will beg for a feature that solves a constraint that dies in six months.

They’ll be right about every SaaS product they’ve ever worked on. They’ll be wrong about this one.

You know that feeling of watching a dashboard tell you something you didn’t expect, and instead of explaining it away, sitting with it until the signal resolves? That’s the muscle. You’ve been training it for years — on messy data, on pipelines that break, on stakeholders who want certainty you can’t give them yet.

The SaaS PMs will keep converging. They’ll reduce friction, add approval gates, optimize for constraints that die in six months. And they’ll feel like experts the whole time.

You don’t need to learn ML. You need to unlearn your SaaS instincts. And if you’ve spent your career close to data, you’ve already started.

The models will double again in six months. Your product either absorbs that, or your best instincts prevent it. Now you know which ones.

Stuff I suggest you read as follow up

• Nicolas Bustamante, CEO at Fintool, shared a few related ideas I really liked. In his piece “Model-Market Fit” he explains nicely “The question isn’t whether to be early. It’s how early, and what you’re building while you wait.” tackling a slightly different angle. Also he uses equations, I love equations.

• Ethan Mollick, professor and researcher on general purpose technologies (kind of), coined the term “jagged frontier” and has a great article describing it, based on his landmark study (the BCG one you likely have heard about all the time, it’s become the basis for a lot of AI thought leaderhip and “best practices” - see the piece I’ll publish in a few weeks on that in general.)

• Chris Pedregal, founder of Granola (used as business case above), already shared a couple of related thoughts almost 2 years ago. Worth a read, still true.

AI tool usage graphs look exactly like dashboard usage graphs. I’ve been staring at both for six years, and the curves are identical — spike, cliff, silence.

I have eleven AI tools on my stack right now. I use two. The other nine are as brilliant and as ignorant as the day I installed them. ChatGPT writes perfect SQL nobody at my company would run because it doesn’t know rev_adj_2 is adjusted revenue (seriously, if the engineers would see what crap I put into AppSmith, well, let’s just say, I’m happy they usually don’t look). A coding assistant that’s never seen our models or best practices. World-class capability multiplied by zero knowledge of my world.

That multiplication isn’t a metaphor. It’s actually the equation that killed your dashboards, and it’s killing your AI tools right now. I think of it like this:

Value delivered on a specific job = Capability × Specificity

What killed your dashboards? Its not that “they” weren’t good. It’s that they lack the level of specificity needed to make great decisions (which is, why you’re the one injecting that if you want to make your dashboards suck less).

Specificity means the tool can absorb context that is specific to you and your company (and the job!) — and actually use it effectively for the job you need done. If specificity is zero, the model doesn’t matter. Zero times anything is zero.

So in my experience, AI tool adoption dies for three reasons:

• you never defined the job,

• you never onboarded the tool,

• or the tool can’t absorb your reality.

Most teams are running all three failure modes simultaneously. Which is great new for you, it means you have a lot of levers here!

If you only do one thing this week: Pick one AI tool. Define its job in one sentence. Write the onboarding checklist a working student would need for that job. Then ask whether the tool can actually absorb that material. If it can’t — it’s dead on arrival, and now you know.

Let me show you what I mean.

Failure Mode 1: You never defined the job

“Coding assistant” isn’t a job. “Write SQL our team would actually run” is a job, a specific one (and this likely tells you why your data teams adoption of cursor isn’t at 100%). “Meeting tool” isn’t a job. “Take notes that capture the details I’d miss and coach me through calls” is a job.

If you hired a working student for one narrow task, you’d define exactly what you need before their first day. But that’s how most teams adopt AI tools — they subscribe, play around for a week, and never once define what done looks like for this tool at this company.

If you can’t state the job in one sentence, you can’t onboard. And if you can’t onboard, specificity stays at zero, even if you “connected the SharePoint, and loaded the data catalog”. By month three, nobody remembers why you’re paying for it.

Examples of different jobs: I use (a customized project in) ChatGPT to write SQL because I don’t really need to write “SQL our tam would run” but rather “fast insights into our data and creative analysis” whereas our engineers will hook up cursor with an MCP into the database to write productionized versions of SQL for dashboards (and of course the App itself).

SIDE NOTE: Context engineering won’t save you. As Steven Pressfield would say, you have to do the work, period.

Failure Mode 2: You don’t have the onboarding checklist

Even when teams define the job, they skip the onboarding entirely. They expect the tool to figure it out. Would you do that with a human?

When a working student joined my data team at Unite for the job “write SQL our team would actually run,” here’s what they got on day one:

• Company context — the handbook, the team handbook, the onboarding docs.

• How we work — Jira tickets, definition of done, our specific workflow.

• What “done” looks like — a complete example ticket end-to-end, with commentary from the requester, user feedback, and final evaluation. Style conventions — linting rules, SQL standards, commenting practices.

• Technical context — databases, tool stack, schemas.

• Business language — data catalog, a walkthrough from a lead data engineer explaining what things are called and why.

After that? Ready to contribute. Before that? Brilliant but useless. Exactly like your AI tools.

Now the same logic for a completely different job. Granola’s job for me is “take smart meeting notes and coach me through calls.” If I hired a human for that, they’d need:

• My profile — strengths, weaknesses (I’m a big-picture thinker, I lose details — flag them).

• My thinking patterns — default questions, what I value. (As recipes in Granola)

• Meeting context — who’s in this call, what we discussed last time. Note structure — my template, relationship history with this person. (On top of each meeting)

• Live input — my thoughts during the meeting as they come.

Two different tools. Two different jobs. The exact same onboarding logic. You have this checklist for your human hires. You don’t have it for your AI tools. Create it.

Failure Mode 3: The tool can’t be onboarded — and you never checked

This is the failure mode nobody talks about because it means admitting you bought the wrong thing.

Some tools literally have no mechanism for absorbing your reality. No custom instructions. No project files. No knowledge base. No connected repos. No memory. Nothing. They’re the working student who showed up on Monday but you’re not allowed to give them the onboarding packet. Doesn’t matter how brilliant they are — they’ll never know your world.

Others have the mechanism but don’t actually use it. You upload your documentation and the tool ignores it. You write detailed custom instructions and it defaults to generic output anyway.

The question most teams never ask: for each item on my onboarding checklist, can this tool accept it? And if I give it, will it actually use it for this specific job?

Granola survived on my laptop because I can do all of this — inject my profile, set up recipes for thinking patterns, drop participant context into each meeting, structure templates, type live thoughts. The nine tools that died? Most of them couldn’t accept a single item from the checklist.

What happens when you actually onboard: MAIA accidentally beat DeepL

Three customers told me in sixty days that MAIA translates better than DeepL. We don’t even build a translator.

I’m Head of Product at MAIA, where we build AI knowledge management for industrial companies. DeepL is one of the best translation tools on the planet. So the first time I heard this, I was excited, but cautious. But by now, I’ve heard this so often from so many customers that I’m confident about the results: For our niche customers, industrial companies, deep technical knowledge, MAIA translations are way superior to the ones from DeepL. (So much that customers will work around the page limitation we have, and DeepL does not!)

These companies had onboarded MAIA deeply. Over months, it had absorbed corrected terminology, accumulated glossaries, internal abbreviations, supplier jargon, product names, standards — the stuff that lives in people’s heads and was never formally documented. Then AI capabilities improved underneath. Better models dropped. And those better models got multiplied by deep, accumulated company context. Translation quality nobody at MAIA designed just... emerged.

SIDE NOTE: I talked to the DeepL chatbot who’s able to admit that DeepL sucks for some customers, DeepL of course has a “glossary,” but the only part of DeepL that acknowledges how important context is, is their case study on a company with a 30,000 word glossary (poor person who must maintain that one). Thank you DeepL for making the lives of your customers so hard, makes it like taking candy from a child.

DeepL gets the exact same model upgrades. Multiplied by zero company-specific context. It becomes a generically better translator every quarter — a brilliant working student who keeps getting smarter but was never onboarded. It’ll never know that your company calls a specific part “KV-Flansch” internally while the industry standard is something else entirely.

A customer got a capability nobody sold them, nobody planned for, and nobody at MAIA designed. They got it because they had done the onboarding work — and then AI got better underneath. In fact, customers asked for this specific capability a ton of times, and I shot it down. Thankfully.

Punchline: onboarding isn’t just about making tools useful today. Every model improvement coming over the next year gets multiplied by the context you’ve already built up. The onboarded tool compounds. The un-onboarded tool just becomes a faster stranger. The companies that invested in teaching their AI tools will wake up one morning to capabilities they never asked for. But only if specificity is above zero when those improvements arrive.

Product Builder Note: If you’re building an AI tool, flip the lens. The process outlined here is genuinely hard for your users - but right now, it is necessary. They don’t have time to go into the depth to write onboarding checklists. They don’t know what context you need. They barely know what job they’re hiring you for. That’s YOUR job. Know your users so well that you can extract the right kinds of specific context from them — with minimal friction, at the right moments, in the right formats. Your job isn’t to build a bigger context window or a fancier RAG pipeline. Your job is to be a chief specific context extractor. Figure out what onboarding your tool needs, then make it effortless for the user to provide it. I believe MAIAs product principles already do a good job of conveying these ideas for builders ⇒ New job title: Chief Context Extractor.

Think about doing this now

Block 30 minutes. Bring your team if you’re a lead.

Step 1: List every AI tool you or your team is paying for.

Step 2: Define each tool’s job in one sentence. Not “coding assistant” — “write SQL our team would actually run.” Not “meeting tool” — “capture the details I miss and coach me through calls.” If you can’t write the sentence, you’ve found Failure Mode 1.

Step 3: Write the onboarding checklist for each job. What would a working student need? Company context, how you work, what “done” looks like, style conventions, technical context, business language. If you don’t have this checklist, you’ve found Failure Mode 2.

Step 4: For each item on the checklist, ask: can this tool accept it? Custom instructions, project files, knowledge bases, connected repos, memory, templates — is there a mechanism? And if you give it, will it actually use it? If the tool can’t absorb your onboarding, you’ve found Failure Mode 3. It’s dead on arrival. Cut it now.

Step 5: For the tools that pass — actually do the work. Block the time. Write the instructions. Upload the docs. Build the templates. This is the onboarding you skipped.

Step 6: After two to three weeks of real use with full context, the tools that still feel like strangers get cut. The ones that feel like your working student after month two — the one who knows your systems, your shortcuts, the one you actually rely on — those are your keepers.

Most of your tools will fail at step 4. That’s the point.

The curve hasn’t changed

Spike, cliff, silence. Dashboards ran it because they didn’t know your decisions. AI tools are running it because they don’t know your reality. Capability × 0 = 0.

The tools that survive won’t be the smartest. They’ll be the ones that stopped being strangers. Stop configuring. Start onboarding.

Further reading

• This article is about selecting the right (AI) tools, and that’s a key point at where tons of companies are at at this moment. But of course, the fundamental question isn’t “which tools?” but rather “how do we become better? (and how do we do this with AI?)” I’ll write about this as soon as I get around it, I have a pretty clear way of doing that myself. But in the meantime, I do still recommend to read “Working Backwards: Insights, Stories, and Secrets from Inside Amazon” in particular about how they used the Six Sigma approach to optimize their work processes. I basically believe, if you substitute the optimize steps with “optimize with AI” you’re already there - Same story there, hard work first, tools don’t matter in the end.

• Also another interesting piece in that direction is “The lantern and the flame” (by the Exponential View - an excellent publication), highlighting places to use AI and where not to use it, in writing that is.

• Finally, I personally think the way Ethan Mollick thinks about using AI is very much aligned with how I believe AI should be used. Oh and he has the research to back it up. Read from him on “One Useful Thing” (he posts about once a month) and consider reading his book “Co-Intelligence: Living and Working with AI.” (strongly encouraged read for every employee over at MAIA)

The entire “agentic” wave optimizes the same proxy. Here’s what I think should actually exist instead.

On a Tuesday, a founder called me in the morning. He’d read most of what I’d written about BI, about how AI is commoditizing dashboards. He agreed with all of it. We’d had a long conversation about what the real opportunity looked like, about decision making and driving business outcomes, the stuff nobody builds.

Then he said the sentence: “Sven, we gotta make money today.”

A week later he launched a BI tool for data analysts.

That afternoon, I had a call with a senior executive at one of the larger BI vendors. Totally different context. We totally agreed on the biggest challenges and the vision. In fact, I was impressed — this company has had this outlook for years. Then he dropped the line on me: “Sven, we see all of this. In fact, we’ve been working on this from the beginning. But we have to make money today.”

Two conversations on the same Tuesday, same sentence. One founder who sees the future but builds the past. One executive who’s been seeing the future for years and still ships the past every quarter. Both trapped by the same five words.

I’ve now heard some version of “we gotta make money today” from enough founders, VPs, and CEOs that I can tell you exactly what it means. It means: I know what’s wrong, I can describe it in detail, but I can’t see a way out.

They’re wrong. Not about the difficulty — building decision infrastructure (= enabling better decisions) is harder than shipping another dashboard with AI bolted on. But about the inevitability. They act like the cage is permanent. It’s not. It’s a structural trap with a specific shape, and once you see the shape, you can build around it. If you’re an incumbent, this could be your map out of it. If you’re a startup, I think this is one of the biggest greenfield opportunities in enterprise software right now.

Let me spell out the cage first. Then we’ll talk about what to build instead.

Note: “The Last Mile of Analytics” was/is this hot trend/concept in analytics. The idea was exactly what is now begetting the downfall of the sector: Insights must be turned into actions otherwise there’s no value for the company AT ALL. The analytics sector correctly identified this, and then expertly failed to execute on this insight, assuming that we “first must get lots of data, then analyse it, and then turn it into action” (Ask any decision maker and you’ll notice, he’ll be just fine making decisions without first consulting an analytics team first.) ⇒ The “Last Mile of Analytics” might really turn into the Last Mile of the Analytics Industry.

Six vendors, same sentence, same trap

I went through every major BI vendor’s latest “agentic AI” announcement — if you want to do so too, I suggest the 2025 Gartner Maigic Quadrant for Analytics and BI, plus every hot startup like Hex, Omni, Lightdash, Metabase, Count, Zenlytic, Definite, Preset, dbt Labs. A sample (more details here):

It’s basically the same product with different logos.

Every vendor optimizes a different facet of the same thing: making the analytics artifact (dashboard, chart, report) faster or easier to produce. Tableau makes it agentic, ThoughtSpot makes it conversational, GoodData makes it governed, Looker makes it embeddable, Power BI makes it accessible, dbt makes it consistent.

But none of them touches the decision. (Seriously, feels like analytics companies now aren’t able to say “decisions” anymore)

And for what it’s worth — in those two Tuesday conversations, it was pretty clear that both the founder and the executive weren’t really concerned with decision-making inside companies. Not at the macro scale, not as the thing they were building for. They were concerned with data analysis, with dashboards, with making the analytical artifact faster. But that’s what happens when you reduce BI to data analysis. You stop seeing the thing BI was always supposed to serve.

And it’s not because they don’t see it. GoodData’s CEO Roman Stanek said: “Most companies don’t need more dashboards; they need clarity.” Looker’s VP of engineering acknowledged BI has been “the same dashboards and reports” for twenty years. And both then shipped more dashboards with AI.

And that’s the weird part, right? Individual humans inside these companies diagnose the problem perfectly. But the organization — its revenue model, its customer expectations, its Gartner rating, its roadmap, its analyst relations — structurally cannot escape. The CEO sees the trap, but the company basically is the trap.

This is why every “agentic analytics” announcement is basically the same product. It’s not a strategy choice, it’s a structural inevitability. The old pattern can only produce more of the old pattern.

The best way I can describe what’s happening: it’s putting a jet engine on a treadmill. Genuinely impressive engineering. You’re running faster than ever. And you’re still not going anywhere. Spotter, Tableau Next, Copilot for Power BI, Gemini in Looker — they’re all jet engines strapped to treadmills. The destination — a decision process that actually improves over time — was never part of the machine.

SIDE NOTE: Gartner themselves predict that over 40% of agentic AI projects will be cancelled by end of 2027 due to escalating costs, unclear business value and inadequate risk controls. So the decay might already be built in. “Agentic” is looking more like a marketing cycle than a product category - and at the same time, agentic is super charging all of my processes (including the writing of course), so the tech is powerful, it’s just not used with the right goal in mind.

The proxy trap: why CEOs can’t escape

So why does every vendor build the same product? Because the trap isn’t strategic, it’s structural.

Companies don’t have a data problem. They have a decision-making problem. Nobody designed how decisions get made. The decision process was never built. It’s accidental, political, meeting-based, vibes-based. But fixing that is invisible, cultural, and hard — there’s no vendor for it. So organizations do the legible thing: hire data people and buy tools. “We need better decisions” becomes “we need a data team.”

The proxy is born. And then it runs on autopilot. Let me walk you through how this plays out, step by step.

First, the proxy gets invented instead of the fix. “We need better decisions” becomes “we need a data team” becomes “we need dashboards” becomes “we need Tableau.” The stand-in replaces the fix before the fix was ever attempted.

Then the proxy grows its own economy. Data teams justify headcount by producing dashboards. Dashboards need tools. Tools need vendors. Vendors market to data teams. An entire industry services a substitute for the thing nobody built.

And here’s the really tricky part: the proxy actively prevents the fix. Leadership says “we’re data-driven, we have a data team.” The dashboard thing absorbs the anxiety. This is why almost no company does PR/FAQ or WBR — they already feel like they’re addressing the decision problem because they have dashboards.

On top of that, the proxy can’t diagnose itself. A data team can never tell you “you don’t need us, you need a decision-making process.” Even when CEOs personally see it — like Stanek, like the Looker VP — the organization can’t act on it.

And then AI comes along and commoditizes the proxy without fixing anything underneath. AI commoditizes SQL, dashboards, and insights. But it doesn’t fix the decision process. Companies that relied on that substitution are suddenly naked.

So the industry panics and builds proxy-for-proxy. That’s the vendor table above. Thirty-plus companies building shinier dashboards at double speed.

That’s the cage. Your product can’t be adopted through proxy channels — data teams, BI budgets, analytics conferences — because those are the proxy’s immune system. Incumbents will never build the fix because their organizations structurally can’t. And the window is now, because AI is stripping the proxy away and organizations are about to discover they have no decision process underneath.

The way out, I think, is building the thing that was never built in the first place: decision infrastructure. The processes, systems, and feedback loops that make decisions visible, trackable, and improvable. The stuff Amazon, Airbnb, and Netflix built internally — the stuff that made them “data-driven” — but that nobody has ever productized.

The companies we hold up as “data-driven” exemplars are actually decision-process-driven companies that happen to use data. Amazon didn’t fix BI. Amazon built decision processes and then used data inside those processes.

That’s what decision infrastructure is. And I think that market is basically empty.

What this means for you — and what you should build instead

Let me walk through what I think the implications are, and what could be built.

(1) Build for after the decision, not before it

This is, in my opinion, the biggest gap in enterprise software.

Every vendor in that table builds faster pipes for before decisions. NLQ so you can ask questions faster, auto-dashboards so you can see charts faster, semantic layers so the data is consistent faster, agents so the whole pipeline runs faster.

Nobody builds anything for what happens after.

No outcome tracking. Nothing like “a decision was made, here’s what was expected, here’s what actually happened, here’s what we learned.” That feedback loop literally does not exist anywhere in the market, not partially, not in early stages.

Every company makes thousands of decisions a year. Not one of them has a system that records what was decided, what was expected, what actually happened, and what was learned. Decisions happen in meetings, in Slack threads, in hallway conversations — and then they vanish. So build the after-decision layer. Make decisions into first-class objects. That road has thirty vendors and a jet engine on the other side of it. This side is completely empty.

(2) Sell to operations — or arm the data people fighting from inside

If you’re building decision infrastructure, your first problem isn’t technology. It’s that every company has a data team whose jobs depend on the proxy remaining in place. When you show up with something that threatens that, they will resist. Not because they’re bad people, but because their headcount is justified by dashboards.

You have two lanes.

Lane one: bypass data teams entirely. Sell to COOs, VPs of Operations, CEOs of 200-person companies — people who make decisions and know they have no process for it. The tools that don’t sell to data teams aren’t called data tools or BI tools right now. And that’s fine. The whole space has spent twenty years selling to a dying department type. The demand for decision support is exploding in every department that was never served by the old pattern — operations, product, finance, the CEO’s office.

Lane two: arm the data people who are already fighting the proxy from the inside. Not every data person is trapped. The best ones already know dashboard factories are dying — they tried to reposition toward business impact and got pulled back into ticket queues. These people are your inside champions. Give them a tool that makes them decision process designers instead of SQL translators. Make them 10x more valuable to their leadership.

The middle ground — “better tool for existing data team workflows” — is the trap every vendor in that table fell into. If your product plugs into the proxy, you become the proxy.

(3) Don’t integrate with the proxy stack — it goes all the way down

The proxy doesn’t just grow laterally, it grows downward. Dashboards need semantic layers. Semantic layers need standards. Standards need governance tooling. Governance needs conferences.

SIDE NOTE: dbt Labs and Fivetran merged for around $600M in combined ARR. Gartner elevated the semantic layer to “essential infrastructure.” The proxy’s plumbing has become an industry in its own right.

The moment you integrate with a semantic layer or build on top of a metrics store, you’ve plugged into that economy. You’ll get pulled into their ecosystem, their conferences, their buyer persona. You’ll start solving for “is the metric consistent?” when the question should be “what decision are you making about this metric, and how will you know it worked?”

Build your own data layer if you have to. Keep it minimal. Treat data as an input to your decision infrastructure, not as the foundation your product is built on. Every dependency on the proxy stack pulls you deeper into it.

(4) Study Amazon’s WBR, not Tableau’s roadmap

PR/FAQ, WBR, decision logs, memo culture — these are the actual fixes. They’re cultural, not technological. “You can’t buy this from a vendor” sounds like a problem. It’s actually the insight.

The product that wins makes the cultural change stick. Think Notion: it didn’t replace writing culture, it made writing culture easier to adopt. The decision infrastructure equivalent: build for the leader who already wants to run WBRs but lacks the enforcement mechanism. Build for the VP who tried PR/FAQ once and it fell apart because there was no system to hold it together.

Amazon’s PR/FAQ structure, WBR cadence, and six-page memos aren’t cultural artifacts. They’re product requirements. Encode them into software — not the data part, the process part. “WBR-as-a-service” is a product. Data plugs in as an ingredient, not the main course.

And this type of process support is now possible with AI in a way it never was before. You can build a system that enforces structure, tracks cadence, connects predictions to outcomes, and surfaces gaps — all programmatically. The technology exists today, and I haven’t seen anyone implement it. Not as a feature, not as a startup. Nobody.

SIDE NOTE: I brought WBRs to my current company, MAIA, into the leadership team and it is regarded as one of the most effective things we’ve done in a year. And yet, I don’t know a single company also running true (!) WBRs. (Hurdle #1 apparently: You’ll have to read and study the book on it…)

(5) Steal from experimentation platforms, not from BI

You don’t have to invent decision infrastructure from scratch. It already exists — just not in BI.

Business Case — Optimizely and Statsig: Both treat experiments as decision objects with measured outcomes. You define a hypothesis, the system tracks expected vs. actual results, it feeds back what you learned. That’s a closed decision loop. It works.

Business Case — Aera Technology: Records decisions with context, rationale, and outcomes. Gartner has a whole category for it called “Decision Intelligence Platforms.”

Business Case — Celonis and Anaplan: Celonis tracks how operational processes perform against expectations. Anaplan connects plans to actuals and forces recalibration.

These companies have revenue and customers who love them. Not one of them competes in BI or shows up at Tableau Conference. The decision infrastructure pattern is proven in adjacent markets and completely invisible to the BI world.

Optimizely treats “experiment” as a first-class object. You should treat “decision” as a first-class object. Statsig closes the feedback loop on experiments. You should close the feedback loop on all decisions. The architecture exists. Port it. Don’t start from a blank sheet and don’t try to “innovate” your way to decision infrastructure by iterating on BI. The answer is in the next aisle over.

(6) Pitch decision cycle time, not dashboard creation time

Sell “analytics” and you compete with Tableau, ThoughtSpot, Looker, Power BI, thirty startups, and the entire proxy economy. Sell “decision quality” and you compete with nobody.

The buyer isn’t the data team lead. It’s the COO. The VP of Ops. The CEO of a 200-person company who just realized they have no decision process — just a collection of dashboards nobody opens and a data team that processes tickets. The budget comes from a different line item. “We reduced decision cycle time by 40%” is harder to pitch than “we reduced dashboard creation time by 80%.” But the first one is what the CEO’s bonus depends on.

Gartner already has a category for this. No BI vendors compete in it. The few companies that do come from completely different lineages. This isn’t a crowded market with a new angle. It’s an empty market. Pitch the outcome: “Your leadership team made 47 strategic decisions last quarter. You have outcome data on zero of them. We make that number 47.”

(7) Design for disappearance, not for demos

Amazon’s WBR isn’t called BI. Dynamic pricing isn’t called AI. The more something actually works at making decisions better, the less visible it becomes. It just becomes “how we work.”

This is a product design principle. If your product looks flashy in a demo — beautiful dashboards, conversational AI, real-time visualizations — you’re probably building more proxy. The proxy is inherently visible, it’s designed to be seen. That’s why it gets funded, bought, and demoed.

Decision infrastructure is inherently invisible. When it works, nobody notices it. The WBR just happens. The PR/FAQ just gets written. The outcome review just occurs. You don’t demo water. If someone can look at your product and say “oh, that’s a BI tool,” you haven’t escaped.

(8) Force the thinking, don’t automate it away

Here’s what AI should actually do in this space. Not “conversational analytics,” not auto-generating documents. It should be the enforcement layer.

The point of AI is not to write the PR/FAQ for you. It’s to force you to write it. And yes, help you write it — by questioning you relentlessly. “What’s the expected outcome?” “How will you measure it?” “What’s your confidence level?” “What would make you abandon this decision?” The AI doesn’t reduce the cognitive work. It makes the cognitive work inescapable.

AI that won’t let you move to the next stage without answering the hard questions in writing. AI that surfaces what you should be asking during your WBR but aren’t. “You predicted 15% conversion. Actual is 9%. You haven’t discussed why in three consecutive reviews.” That’s not a dashboard. That’s an accountability engine.

A good decision intelligence tool won’t reduce the time an executive spends deciding. It will do the opposite. It will make a good executive spend almost all of their time making decisions — which is what they’re paid to do. And they only need a couple of great decisions in a given month to be worth gold. The tool that helps them make those two decisions 20% better is worth more than every dashboard their company has ever built.

Every vendor in that table uses AI to accelerate the production of charts. The opportunity is using AI to enforce the discipline that turns charts into decisions into outcomes into learning. That’s three steps past where anyone is building.

The founder from that Tuesday morning will read this. The executive from that afternoon might too. Both will agree with most of it.

That’s the thing about “we gotta make money today.” It’s not ignorance, it’s something closer to surrender. Every person who’s said it to me understood the proxy trap. They could name it. They could diagram it on a whiteboard. They just couldn’t see a way to make money from the fix.

And they’re right that it’s harder. Decision infrastructure doesn’t demo as well as a dashboard. The pitch is harder, the buyer is different, the sales cycle is different.

But the competition is also different. As in: there is none.

Thirty-plus vendors, tens of billions in combined market cap, thousands of engineers, all fighting over faster dashboards with AI. The market for actual decision infrastructure is empty. Not thin, not early. Empty.

The company that fills it won’t be called an analytics company. It probably won’t be called an AI company either. It’ll just be how good companies work.

Further reading (aka the hard work most people like to ignore):

• Working Backwards - single best book on most of Amazons decision making processes. (Also see the Everything Store for additional notes). All of Jeff Bezos writing (being the one who set up tons of those processes) is great, for a comprehensive read, I suggest “Invent and Wander”

• Ray Dalio’s “Principles” are another great piece of writing about systematic decision making (involving next to no data, albeit being the foundation that built the largest hedge fund in the world.)

“Hey Sven, we’ll think about this, but we need to figure out some more important things first. We’ll get back to you in six months.”

I’d spent a week on that presentation. Real revenue numbers from ML initiatives we’d already shipped — millions, not projections. Clean slides. Sharp charts. Three senior executives in the room. They liked the numbers. They nodded in all the right places.

And then, six months of nothing. For millions in proven revenue (in theory).

I didn’t have a data problem. I had a format problem. I just couldn’t see it because the format was designed to be invisible. My slides were optimized for ease — glanceable, clean, professional. And that’s exactly why three executives could consume them, feel like they understood, and move on without deciding anything.

SIDENOTE: Kahneman called this WYSIATI — What You See Is All There Is. Your brain checks “understood” and stops thinking. It’s a neat concept and I think it explains a lot about why dashboards and slide decks feel productive but aren’t.

The format made consuming feel like deciding. It wasn’t. And I think I can now count exactly why.

The five-question scorecard

Before you ship your next data output — dashboard, deck, email with a chart, whatever it is — ask these five questions. The answer to all of them should be yes. For most dashboards, the answer to all of them is no.

1. Does it force a story? Not metrics floating in space — a beginning, a middle, a “so what,” a recommended action.

2. Did the person who created it have to struggle? Not technically — intellectually. Did the format force the producer to actually think through the meaning, not just pull numbers?

3. Does it take real effort to consume? Not a 10-second glance. Minutes of focused reading or study from the person receiving it.

4. Can you point at any number in it and name exactly who to call? Not “the data team.” A specific person who owns that number and its interpretation. If the answer is “I don’t know” — that’s a clear No.

5. Is there a built-in process for others to challenge the reasoning? Not polite nodding. Actual scrutiny, expected and structured.

Score 0–5. That score predicts whether anyone acts on it.

My slides that day? 0/5. The session that actually got me the budget — a whiteboard, a marker, and 60 minutes of live reasoning? 5/5. Same person, same data, different format, completely different outcome.

For me, this isn’t a dashboard problem. It’s a format problem. Dashboards are just where you feel it first. Let’s walk through why each of those questions matters — and what to do about it.

1. Why these five properties force decisions

ach question maps to a property that catches a specific way your brain fakes understanding. Miss one, and that failure mode gets a free pass. Let me walk through them.

Narrative structure forces the reconstruction of causality. You literally cannot write “show me revenue by region” as a coherent narrative without confronting the question you haven’t asked: “what decision does this support?” Without narrative, the consumer never connects the number to a real-world action. The data just sits there, looking important.

Creator friction means the person producing the output had to do real interpretive work — not just technical work. Pulling a dashboard view takes 30 seconds and zero thinking about what it means. Writing a narrative analysis of the same data forces the analyst to confront gaps, weigh tradeoffs, and commit to an interpretation before anyone else sees it. The difficulty is the filter: if the format didn’t force the producer to think, the producer didn’t think.

SIDENOTE: And here’s a distinction I think is really important — a junior analyst spending 40 hours building a dashboard is high effort for the wrong kind of work. That’s builder friction, not creator friction. Builder friction means you worked hard on layout and SQL. Creator friction means you worked hard on meaning. Those are very different things.

Recipient friction means the decision-maker has to struggle to consume it. A dashboard is designed to be glanced at. A dense memo takes 20 minutes. That’s the point. When consumption is easy, the executive’s brain pattern-matches on red/yellow/green and moves on without rebuilding a real-world model. Easy consumption feels efficient. But I think it’s actually the mechanism that lets data pass as “understood” without anyone actually understanding it.

Reasoning accountability means you can point at any number, any claim, any interpretation in the output and name exactly who owns it. Not “the analytics team” or “it’s in the dashboard” but a specific person who will pick up the phone and answer every question about why that number is what it is and what it means. If you point at a metric and the answer is “I don’t know who’s responsible for that” — you don’t have accountability. You have a number with no owner, and numbers with no owners drive zero decisions. I’ve seen this more than once.

Structured challenge means the format creates a pathway for others to poke holes. Not just consume — challenge. A Slack message saying “looks good” is not structured challenge. A review where attendees spend 20 minutes reading and 40 minutes in line-by-line debate is. Without it, one person’s plausible-sounding story goes untested. And plausible-sounding is not the same as accurate.

2. Score your own formats and watch them collapse

Let me just put a couple of common formats in there so you can see what I mean:

I wrote an entire piece on making dashboards suck less. The best I could do with all of that? Upgrade from 0 to about 2. Real improvement, sure — but three properties still completely untouched.

And here’s a thing I think a lot of people miss: copying the WBR chart format without the WBR meeting is why companies get 2/5 and zero decisions. The chart is not the thing that works. The system around it is.

So if the formats you use every day top out at 2 — what actually scores higher?

3. Three formats that force decisions, and how to run them

So let’s stop upgrading dashboards. Instead, choose formats that already have the properties baked in. Yes, they’re harder. That’s the point. Instead of 500 dashboards and 0 decisions, you get 10 well-formatted outputs and 8 actual decisions. That math looks terrible to a service desk. But it looks pretty great if you’re a business leader.

The written memo + structured review

Bezos banned PowerPoint and replaced it with six-page narrative memos. Some teams write ten drafts — the format forces the producer to confront every gap in their reasoning before anyone else reads it. The meeting then starts with 20 minutes of silent reading, followed by line-by-line debate.

How to run it:

1. Decision question at the top: “Should we approve X?” or “Choose A vs B.” This forces narrative.

2. Silent read 15–20 minutes. No pre-read allowed — everyone engages fresh.

3. Line-by-line challenge. The author defends every claim. Every number has an owner — and it’s them.

The whiteboard session

Jensen Huang near-totally banned PowerPoint at NVIDIA. His team ensures a whiteboard is available wherever he goes — one former executive recalled a whiteboard so large it took five people to move it into the room. I love that. Slides let people hide incomplete thoughts behind polished formats. A whiteboard doesn’t let you hide anything.

How to run it:

1. Start with the value chain or logic structure on the wall. Draw it live — no pre-made slides.

2. Write assumptions and numbers as you go. Sources visible. Your hand, your claims.

3. Force objections on the wall: “What would make this wrong?” The room challenges in real time.

The structured data review (WBR-style)

This is the only version where a dashboard-like artifact scores 5/5 — and only because the system around it forces every property. Amazon’s WBR charts are dense and deliberately hard to skim. But the chart is never consumed alone. The presenter built the interpretation and owns it by name. The meeting is a challenge protocol, not a status update.

How to run it:

1. Ban consuming the charts alone. Interpretation happens live, with the person who built it present.

2. The presenter states what the data means and owns it. Point at any number — they answer.

3. The room’s job is to challenge: “Why do you think that? What are you missing?”

I don’t think you can optimize decisions by optimizing ticket volume. You optimize decisions by choosing formats that force you to actually think.

You know how I personally got our top management to buy into my machine learning initiatives? Full budget for a year for a whole team?

I didn’t build a dashboard or a slide deck. I didn’t send a report.

I bought 10 meters by 2 meters of whiteboard — the adhesive kind you glue onto a wall. Got it installed. Booked 60 minutes with my exec. And I spent that hour at the wall, sketching out our value chain, walking through where ML could push the bottlenecks, running base numbers together right there on the board.

He didn’t glance at a chart and nod. He followed the logic for an hour. He questioned the numbers. He challenged assumptions. My hand was on the marker, my reasoning was on the wall, and when he pushed back I had to defend it — live, with nothing to hide behind.

That session scored 5/5. I didn’t know it at the time. I just knew it worked.

Next time someone sends you a dashboard request, don’t build it. Score it.

Here’s what my data team proposed when asked for AI use cases at Unite:

• Recommendation systems.

• Marketing ML.

• Personalization improvements.

“Interesting, let’s prioritize,…. or not.”

Here’s what we proposed after a 30-minute exercise:

• Identify every company in Europe that should be on our network but isn’t.

• Find businesses linked in the real world but missing from our platform.

• Detect companies doing a fraction of their potential business through us — meaning they had connections we could pull onto the network.

Same team. Same afternoon. Different question.

The first list improves metrics. The second list changes economics. Management didn’t nod politely at the second list. They funded it, let me expand and designate a whole team to it.

What changed wasn’t our creativity. It was one question, asked differently, that opened up a space we’d been trained to ignore. Here’s what we did, I call it the Perfect World Session.

Perfect World Session — the 30-minute split format:

1. Pick X (the value-chain choke point where better knowledge changes economics, not just features)

2. State the rule: no feasibility talk. None. Not yet.

3. Ask the question: “If we knew everything about X, what would we do that’s impossible today?”

4. Generate as many “impossible” actions as you can. Go wild. Stay in the perfect world. 15 minutes.

5. Break. Walk around. Get coffee. Let the ideas settle.

6. Come back. For each idea, ask: what data gets us 60-80% there? What’s the smallest prototype that would prove this works?

It’s simple, and very hard, no fun. Session 1 is imagination. Session 2 is engineering. They must not happen at the same time, or you’ll end up with the list from above.

“Where could we use AI?” always produces the same list

Someone senior says “we need to find AI opportunities.” You break into groups, fill whiteboards, come back with sticky notes. Chatbots. Report automation. Recommendation engines. Churn prediction.

You know what’s on every other company’s whiteboard right now? The exact same things. I’ve talked to 50+ data leaders and the overlap is embarrassing — as if there’s a universal AI brainstorm template everyone secretly downloads from the same place.

Most AI roadmaps are automation backlogs pretending to be strategy.

Zapier CEO Wade Foster recently celebrated how Fetch shut down their entire company for a week-long AI hackathon — over 1,000 employees — and the celebrated outcome was “hundreds of automations built.” Of course it was. The CEO of an automation company told a thousand people to find ways to use AI, and they built automations. That’s the hammer-and-nails problem dressed up as corporate transformation. None of those hundreds of automations will change Fetch’s business economics. They’ll save time on tasks that already exist (though more likely, they will add complexity and create cost, rather than save time). That’s fine. That’s not strategy (thank you, Wade).

The problem isn’t creativity. The problem is the question. “Where could we use AI?” starts from the technology and scans for places it fits. You end up with chatbots. Every time. The 10x idea? Not visible. Not from this angle. Not ever.

If we knew everything about X, what would we do that’s impossible today?

Back in 2022, Unite was pivoting toward becoming a B2B network. My data team needed to prove it could do more than serve dashboards. I needed ideas good enough that management would actually invest in ML capability, not just nod politely and move on.

So after staring at our sad little list of recommendation engines, I studied success stories, failures, and good old business history. What I came up with was the Perfect World Exercise. I got a bunch of smart involved people in front of a whiteboard, started to map parts of our new business strategy and asked one question:

“If we knew everything — literally everything — about X, what would we do that’s impossible today?”

Replace X with the part of your value chain that matters most: customers, suppliers, products, transactions, competitive landscape, network graph. This is hard work — not a fun brainstorm. You need deep business and strategic understanding to choose the right X. Which means you have to understand your value chain deeply first.

How to pick X:

• Good X = where better knowledge would change economics (growth, margin, retention, risk)

• Bad X = where better knowledge improves a feature (nice-to-have optimization)

• Test question: “If we knew everything about X, would we ship a feature… or redesign the business?”

Pick the wrong X and you get incremental ideas with perfect-world wrapping. Pick the right one and the room goes quiet in a different way.

At Unite, X was “every company in Europe.” There was this awkward pause where people looked at me like I’d asked a trick question. One person started with “well, we’d obviously improve our matching algo—” and I stopped them. No. Forget the matching algorithm. Forget our current product. If you had perfect knowledge about every business in Europe, every relationship, every transaction, every connection — what would fundamentally change in the value we deliver?

Then someone said, almost hesitantly: “We’d know which companies should be on our platform but aren’t.”

And the energy in the room shifted completely.

Not “improve recommendations for existing users” — that’s optimizing the current game. Instead: which of all the companies in Europe would be a perfect match inside our network? That’s the growth engine, not a feature improvement.

In a normal brainstorm, this idea gets killed in ten seconds flat. “We don’t have external company data, that’s not realistic, let’s move on.” But we stayed in the perfect world a few minutes longer. And more ideas dropped out, each one weirder and more interesting than the last: companies linked in the real world but not yet connected on our platform. Companies doing only a fraction of their business through us.

None of these are “apply algorithm X to business case Y” ideas. They’re hard. They require building things that don’t exist yet.

Then we took a break. Came back. And did the translation — the part where engineering earns its seat:

1. What would prove this is true? (What signals would we need to see?)

2. Where could we get those signals? (What data sources exist, even imperfect ones?)

3. What’s the smallest model that would be useful? (What gets us 60-80% there?)

The potential value dwarfed anything on the original list — because we weren’t optimizing an existing feature, we were changing the growth economics of the entire business.

That’s what I pitched to top management. It got funded. But the real outcome wasn’t the budget. That second list allowed me to split off part of the team as a dedicated ML team and position them not as a support function but as a value creation engine. Not “we help other teams make better decisions.” Instead: “we find revenue the business didn’t know it was leaving on the table.”

The first list would have kept us as a service desk with fancier tools. The second list changed what the data team was for.

Your feasibility filter is running on 2022 intuitions

Most “AI brainstorming” is just feasibility triage in disguise.

Before an idea even fully forms, someone in the room — often you, inside your own head — asks “but do we have the data for that?” or “that sounds massive, let’s stay realistic.” The idea dies before anyone evaluates whether it’s actually valuable. You think you brainstormed all possibilities. You didn’t. You brainstormed the possibilities that survived the feasibility filter. That’s a much smaller, much more boring set.

Here’s why this matters more right now than it ever has: AI has moved the boundary of what’s possible so far that the ideas you rejected as “unrealistic” two years ago are buildable today. LLMs can extract structured information from unstructured sources at a scale that was genuinely impossible for a mid-sized data team in 2022. The space of “things we could know if we tried” has expanded by an order of magnitude.

But your feasibility filter hasn’t updated. You’re rejecting 2026 possibilities with 2022 intuitions about what’s buildable. You dismiss perfect-world thinking as fantasy, so you propose chatbots — because chatbots feel realistic.

The 10x idea lives in exactly the space you dismissed as impossible.

Taiichi Ohno, a machine shop manager at Toyota — not the CEO, not a strategist — didn’t ask “how do we speed up our assembly line?” He asked “what would a perfect supply system look like?” and invented just-in-time manufacturing. JIT only works if you have perfect information about all suppliers and ongoing processes. Toyota asked that question. And you should, too.

Five questions that tell you if your AI roadmap is strategy or a to-do list

Pull up the AI roadmap your team produced last quarter. Ask yourself:

1. Can I point at a single item and say “this will deliver 10x value to our customers”?

2. Would a competitor produce the same list in an afternoon?

3. Did we start from “where could we use AI?” or from “what would change everything if we knew it?”

4. Did anyone kill an idea because “we don’t have that data”?

5. Is there a single item on this list that made management do anything other than nod politely?

If none of these questions sting, you’re either exceptional — or your roadmap is lying to you.

If your AI agent can’t reliably operate on basic business principles, it’s probably not the model. It’s that your company has three definitions of the same metric — and humans have been quietly patching that over for years.

When Brian Chesky asked Airbnb’s data teams which city had the most bookings the previous week, Data Science and Finance gave different answers. Different tables, different metric definitions, different business logic. Both correct. Neither agreed. That’s an AI evaluation prompt, and your company would fail it right now. A human analyst muddles through — squints at both numbers, walks down the hall, asks someone. An AI agent picks whichever definition it encounters first and acts on it a thousand times before anyone notices.

AtScale made this concrete: an LLM against raw enterprise data without semantic grounding was wrong 80% of the time. With a layer telling it what each metric means — 92.5% accurate. The gap isn’t intelligence. It’s meaning.

Here’s the rule: if a business concept, a metric, isn’t deterministic, owned, and encoded, your agent cannot be trusted. That’s the minimum bar. And almost nobody is meeting it.

A minimum viable semantic contract looks like this:

• Metric/ concept name — e.g., “active customer”

• Definition — plain English, no ambiguity

• Formula / logic — deterministic, not LLM-inferred

• Canonical source — one table, one query

• Owner — person or team accountable

• Change process — how updates happen, who approves

• Drift test — alert when two systems disagree

If your company doesn’t have this for every metric an agent touches, you don’t have an AI reliability problem. You have a definitions problem.

AI agents can’t run on the ambiguity that analytics lived on

Analytics could tolerate fuzzy definitions. A dashboard with 90% uptime is fine. Two teams using slightly different churn calculations causes a confusing Monday meeting. The whole system ran on human judgment as the error-correction layer.

AI agents can’t tolerate any of that. They don’t walk down the hall. They pick one definition and act on it — in front of your customers, without supervision, at machine speed. The demand shifted from “can humans roughly agree on what churn means” to “can machines making thousands of decisions per second operate from deterministic shared definitions.” Analytics never had to meet that bar.

Snowflake’s Chief Data Analytics Officer, Anahita Tafvizi, named the dynamic: “The combination of great AI models and bad data governance brings chaos at scale. You previously had chaos; now you have scaled your chaos.” Her line about training is sharper:

This is why 95% of enterprise AI pilots deliver zero measurable return. Not because the models are bad. Because the definitions underneath them aren’t frozen.

And yet that’s the legacy the dying data teams leave us with.

The invisible function that used to hold meaning together

So who was keeping the definitions roughly consistent before? That’s the part nobody tracked.

Every company has a person whose job title says “senior analyst” or “head of analytics” but whose actual function is walking into meetings and saying “that’s not what we mean by churn.” The questions that separate these people from queue workers aren’t about technical skill. They’re about who defines what should be measured, who generates hypotheses before touching data, who tells you you’re wrong. That’s not analytics. That’s organizational meaning-making.

Riley Newman was Airbnb’s version. Employee #10, first data scientist. His role, in his own words, was “thought leadership and teaching people how to think about things.” He made sure “booking” meant one thing everywhere. He put as much weight on communication as on technical rigor.

And even he broke at scale. That Chesky question — two teams, two answers, both correct — happened on his watch. Benn Stancil diagnosed why: “We have the tools for governing tables, and we have tools for governing dashboards, but we’re still pretty sloppy about governing the space between the two.” That space between is where meaning lives. And humans can’t hold it past a certain scale.

When Snowflake hired its first CDAO, she found the same problem internally. Active accounts had three definitions. Her fix was centralizing teams and creating a metrics council. She became the human semantic layer.

Now those humans are leaving. 108,000 tech jobs cut in January 2026. Salesforce named data analytics roles specifically. Roughly 80% of organizational processes remain undocumented. The knowledge walks out with the person. Nobody is encoding anything on the way out — at the exact moment AI is demanding something those people were never designed to provide.

Semantic contracts are the only analyst that scales to agent-speed decisions

Even Riley Newman couldn’t hold shared meaning at scale — so Airbnb spent four years building Minerva: 12,000 metrics, 4,000 dimensions, 200 data producers. Because the human function broke. Three of Newman’s colleagues founded Transform. dbt Labs acquired them. The function kept seeking a body that scales.

That body is the semantic contract. It doesn’t just encode what Riley did with judgment. It upgrades it to a standard Riley could never have met. Riley held shared meaning for humans in meetings. The semantic contract holds it for AI agents — deterministic, always-on, machine-readable.

dbt Labs made this explicit when they open-sourced MetricFlow: “Metrics should not be probabilistic or depend on an LLM guessing each calculation. They should be deterministic.” In the old world, a smart human could hold “roughly consistent” definitions across a few teams. In the new world, “roughly consistent” gets you agents acting on wrong definitions at machine speed. Deterministic or nothing.

The industry converged on this in 2025–26. Snowflake, Databricks, and dbt Labs all shipped native semantic layers within a year. In September 2025, 17 companies — including Snowflake, Salesforce, BlackRock, ThoughtSpot, and Mistral AI — formed the Open Semantic Interchange initiative. VentureBeat called it solving “AI’s most fundamental bottleneck.” Fierce competitors publicly agreeing that fragmented definitions are the largest barrier to AI adoption. That happens because the problem is structural and everyone is hitting the same wall.

Questions to answer this week

If you’re shipping an agent on top of company data, stop and answer these before anything else:

1. What are the 10 metrics my agent is allowed to act on? If you can’t list them, your agent is freelancing on definitions nobody agreed to.

2. For each metric: where is the one canonical definition, and who owns it? If the answer is “it’s in a Confluence page somewhere” or “Sarah knows,” you don’t have a definition. You have folklore.

3. If two dashboards disagree today, which one is wrong — and how would you know automatically? If the answer is “we’d notice eventually,” your agent won’t notice at all.

4. Is the agent allowed to execute actions when the metric definition is missing or ambiguous? It shouldn’t be. Build the guardrail now.

5. What’s your drift alarm? Tests and monitoring that fire when two systems report different values for the same contract metric. If you don’t have one, you won’t know your agent is wrong until a customer tells you.

Your best analyst was never writing SQL. They were freezing meaning. Either encode what they did into infrastructure, or watch your agents scale chaos.

In 2019, a colleague gave a talk featuring a tool called “data built tool.” It was made by some weird consultancy called Fishtown Analytics. It had 1,000 GitHub stars. We figured we could always ditch it later. A few years later, this little project had created an entirely new job title — “analytics engineer” — and the company behind it was valued at over four billion dollars. Dbt Labs became a unicorn not by building revolutionary technology but by undoing a kink in a hose. **

The core invention was templated SQL and a folder structure. That’s it. I’ve spent a decade watching moments like this. Products that became ten times better than everything else, and products that quietly died. The Google Searches, the Netflixes, the Adobes — and the dashboards nobody opens, the analytics startups nobody remembers, the “AI-powered” features nobody uses twice. The difference was never better engineers or fancier algorithms. The difference was that the winners had found a source of power in their data, and had a deliberate way of channeling it. Richard Rumelt, who I consider the best living strategy thinker, defines a good strategy as two things: a source of power, and a guiding policy that channels that power. Not a vision. Not a roadmap. Not OKRs. A data strategy, then, is a source of power that comes from data, plus a guiding policy for how you channel it into your product. Most products don’t have one. They have data activities.

If you only have 5 minutes, I suggest you read this later, it’s worth it. This piece is longer than usual, but I truly believe it to be worth your time.

The One Thing Nobody Talks About

Most data-heavy products (yes AI is just data) fail, a few special become 10x-100x products.

The difference isn’t better engineers, more funding, or fancier algorithms.

The difference is that the winners have a data strategy. And I don’t mean the document your CDO presents once a year at the board meeting. I mean something much more specific, backed into your product.

A good strategy (according to Rumelt) has two things: a source of power, and a guiding policy that channels that power. That’s it. A source of power — something that gives you leverage — and a deliberate way of using it.

A data strategy, then, is a source of power that comes from data, plus a guiding policy for how you channel it into your product.

Find yours right now. Fill in these blanks:

• Power: “We win because ________.”

• Policy: “Therefore we will ________ (and stop ________).”

• **Bet: “**We’re betting this unleashes ________”

If you can’t fill these in by the end of this article, you don’t have a data strategy. You have data activities.

Example (dbt - Fishtown Analytics):

Power: “We win because we found the kink in the hose of decision-making — the wall between data engineers and analysts.”

Policy: “Therefore we remove it by building a bridge on templated SQL (and stop trying to be a complete data platform).”

Bet: “This unleashes decision-making velocity for every medium-sized company.”

Now, data isn’t like other things. And that matters enormously for strategy. It has six properties that are genuinely unique: it’s copyable, compounding, context-dependent, intangible, exponentially growing, and network-effect-ish. Three of these generate most of the strategy landscape. Miss them, and you’ll never find your strategy.

Data can be copied for free. If your data isn’t unique, it isn’t a source of power — anyone can get it. But if you do have unique data, protecting it creates an enormous moat.

Data compounds. A recommendation engine with 10 million data points isn’t just 10x better than one with 1 million — it’s qualitatively different. This is why flywheels are so devastating in data.

Data’s value depends entirely on context. Adobe had decades of photo-editing logs sitting in their servers doing nothing — until generative AI arrived and suddenly those logs were the most valuable training data on earth. Power often hides in plain sight.

These three properties create three families of power. Compounding drives accumulation — systems where data grows and improves over time. Context-dependence drives unlocking — finding power that’s already there but stuck. Copyability shapes how you build — by protecting proprietary data or opening it strategically. The seven strategies are the stable patterns inside these families. If data compounds you design loops; if value is contextual you hunt constraints and native interactions; if data is copyable you decide what to protect vs. open — those pressures produce the seven moves.

Quick diagnosis:

• If your product improves with usage → Accumulate.

• If value is trapped in handoffs or medium change → Unlock.

• If you must manufacture advantage → Build.

You don’t need all seven. You need one.

Power That Accumulates Is the Easiest to Mistake for Luck

You’re in Accumulate if doubling usage improves the product without hiring more humans. If not, jump to “Power That’s Stuck.”

The flywheel that ate the internet. In 1998, Google had one thing going for it: PageRank, a PhD project that produced slightly better search results than AltaVista or Yahoo. That was the initial push.

More people used Google because the results were better. More usage generated more data — what people clicked, how quickly they bounced back, which links they ignored. That data made the algorithms better. Better algorithms produced better results. Better results attracted more users.

This is what I call the DMVD flywheel:

• more Data feeds better Models,

• which create more Value for users,

• which drives more usage and thus more Data.

It’s not a metaphor — it’s a mechanical description of how certain products accelerate. A flywheel describes momentum, not growth. Any constantly accelerating company will eventually outgrow even the fastest linearly growing competitor. That’s why Google has maintained dominant market share for years. Once the flywheel spins fast enough, you can’t catch up by running harder.

What most teams get wrong. I’ve watched dozens of product teams try to “build a flywheel.” “Let’s add AI, collect user data, create a virtuous cycle!” They build a feature, ship it, and wait for the magic.

It never comes, because they missed the crucial part: the transitions have to be almost automatic. If one step doesn’t naturally trigger the next, it’s not a flywheel — it’s a wishlist. Google tracked how often users returned to the same search results after clicking a link — a deliberate move to enforce the transition from “more usage” to “more useful data.” They even built Chrome (a whole browser!) to get richer data. They asked every single day: what accelerates this?

Any point in the flywheel can be a starting point — the algorithm (Google), the data (Netflix, who had years of DVD rental data before building Cinematch - if you even remember that), or hand-crafted value (Amazon, who started with human-curated top-10 lists before replacing them with algorithms - yes there was a war going on between the algo and the human curation team for years).

If you sell B2B, your flywheel isn’t “more users” — it’s “more usage per account” or “more queries per workflow.”

Ask yourself: What happens if your user count doubles overnight? Does the core experience get noticeably better? If “not really” — you don’t have a flywheel. If “yes, but only if we also improve the algorithm” — you have a flywheel that needs a push. If your product doesn’t compound with usage, stop trying to force it. You’re probably in Unlock or Build. If you notice it’s “stuck” you might want to align it so that the transitions start to be automatic.

And one warning: don’t fight the bully. Your flywheel must turn faster than anyone else’s in your market, or you’ll eventually be eaten alive. DuckDuckGo niched into privacy-focused search — smart — but Google’s flywheel simply spins faster. No amount of running harder closes that gap.

Power: usage data improves the model which improves the product.

Policy: engineer the transitions (instrumentation + incentives) until the loop is automatic.

Monday move: pick one transition (usage→data, data→model, model→value) and instrument it with a metric + an incentive.

The shorter, more violent cousin

The DVD loop skips a step: more Data creates more Value creates more Data. No model improvement — the data is the product.

The Farmers Business Network exploits a brutal asymmetry: seed companies know failure rates, yields, and prices across the entire industry. Individual farmers know their own numbers and maybe their neighbor’s. FBN’s solution was a shared data platform — share your data, get access to everyone else’s. More farmers join, more data flows in, the platform becomes more valuable, more farmers join.

Glassdoor works the same way: you can only access the full salary database if you share your own salary first. That’s a direct incentive enforcing the transition in the loop.

The DVD loop is fast and simple, but fragile — it runs entirely on data quality and incentive alignment. If the data turns to garbage, the value proposition collapses overnight. If free-riding becomes easier than contributing, the loop starves.

Direct vs. indirect: Glassdoor requires every user to contribute — you can only access the full salary database if you share your own salary first. That’s a contribution gate: the incentive is baked into the access mechanism itself. GitHub and Wikipedia don’t require contribution — a small percentage creates content, the majority consumes it. That’s a contributor ladder: status, reputation, and visibility reward the people who build.

Contribution gates are faster to start but brutally dependent on data quality — one wave of fake Glassdoor salaries and the whole thing unravels. Contributor ladders are slower to reach critical mass but more resilient once spinning.

First question for a DVD strategy: must every user contribute, or can a subset carry the load? Monday move: either build the contribution gate (Glassdoor) or the contributor ladder (GitHub), and ship the quality enforcement mechanism alongside it.

Power: the data is the product; more contributors = more value for everyone. Policy: design the contribution gate (or contributor ladder) and invest relentlessly in trust.

Before you spin, you need something to spin

And then there’s the foundation that makes flywheels possible in the first place: proprietary data. But not the kind you think.

When generative AI hit, every photo editing company had access to the same technology — the same APIs, the same model architectures. Six months after the breakthroughs, the tech was available to everyone.

But Adobe’s generative fill was magic, and everyone else’s was mediocre. Why? Because Adobe had years of professional photo editors’ workflows logged — how they inpainted, outpainted, replaced backgrounds, adjusted colors — plus one of the largest stock image catalogs in the world. When the technology arrived, Adobe had the training data to make it sing.

The conventional lesson is “collect the exhaust.” But that’s the wrong lesson.

Adobe didn’t construct that data pile strategically. They moved to cloud to save their subscription business. The data was a byproduct — dark data sitting in servers for years. They got lucky. When the context changed externally, they happened to have the right pile.

Luck isn’t a strategy. Here’s what deliberate construction looks like.

Renaissance Technologies didn’t “have better data.” They built better inputs by failing for years.

“They collected every piece of data they could — including lunar phases and sunspots — to test its viability. Most tests failed.”

Most tests failed. That’s the key phrase. Renaissance wasn’t sitting on a goldmine. They were building one, brick by brick, running tests that mostly didn’t work.

The result: 66% average annual gross returns since 1988. Competitors with 100x more “proprietary” data, with 30 years to catch up, never closed the gap.

Renaissance didn’t collect more data than their competitors. They collected different data — weather patterns, shipping manifests, satellite imagery — data their competitors thought was worthless. They bought it cheap precisely because nobody wanted it. Their early data was garbage. The edge came from construction — years of systematic cleaning, combining, and testing to make worthless inputs valuable.

By 1997, more than half of the trading signals they discovered were “non-intuitive” — patterns they couldn’t explain. They traded on them anyway. They called the faint patterns “ghosts” — trends so subtle that most investors couldn’t notice them.

Renaissance never published. Never attended conferences. Never shared insights. For 30 years. When employees leave, they lose access to the Medallion Fund. Knowledge stays inside the building.

Jim Simons once quoted Animal Farm: “God gave me a tail to keep off the flies. But I’d rather have had no tail and no flies.” That’s how he felt about publicity.

The difference between Adobe and Renaissance is the difference between collecting and constructing. Adobe organized what existed and got lucky when the context changed. Renaissance deliberately built inputs that looked wasteful, bet on patterns that looked like noise, and compounded in silence for decades.

Three decisions separate constructors from collectors:

1. Measure what others won’t. Renaissance bought weather patterns and crop reports when competitors thought it was garbage. What data would look wasteful to collect for 12 months before it might pay off?

2. Reject the consensus. More than half of Renaissance’s signals were patterns they couldn’t explain — “ghosts” that contradicted conventional wisdom. What industry KPI or “best practice” are you willing to bet against?

3. Compound, don’t publish. Every insight you share is value you’ll never compound. Renaissance kept signals private for 30 years. What would you never put in a deck?

Collected data commoditizes. Constructed data compounds.

Power: Everyone thinks certain data is garbage — so you can buy it for nothing and construct something massive before anyone notices.

Policy: Make huge, strategic bets on constructing complex data sets that look wasteful — then use the product revenue to fund more construction.

Power That’s Stuck Doesn’t Need More Data — It Needs New Eyes

If customers complain about “handoffs,” “waiting,” “manual stitching,” you’re here.

Not every great data product is built on accumulation. Sometimes the power is already there, sitting in plain sight, and all you need to do is remove the thing that’s blocking it.

The kink in the hose. In 2019, a colleague mentioned a tool called “data built tool” created by “some weird consultancy called fishtown analytics.” It had 1,000 GitHub stars. We figured we could always ditch it later.

A few years later, this little project had created an entirely new job title — “analytics engineer” — and the company behind it was valued at over $4 billion. Dbt Labs became a unicorn not by building revolutionary technology but by undoing a kink in a hose.

All decision-making follows the same sequence: data → info → insight → decision → action. I call it the datacision cycle. Every process has a bottleneck somewhere. What Tristan Handy realized was that in most medium-sized companies, the bottleneck was always in the same place: the wall between data engineers and analysts. Data engineers could collect and store data fine. Analysts could produce insights fine. But the transition — moving collected data into a form analysts could work with — was broken.

Dbt solved this with templated SQL and folder structure. That’s it. It gave analysts the ability to do transformation work that previously required a data engineer, using the language they already knew. And yet that tiny change unleashed enormous power — because the bottleneck wasn’t a local inefficiency. It was the constraint on the entire datacision cycle for thousands of companies. Remove it, and the whole pipeline flows faster.

Finding the real bottleneck is harder than it sounds. When one step is constrained, every other step adjusts its quality to match. That’s why teams misdiagnose bottlenecks — it looks like everything is equally strained. Tristan saw through this: when companies got 10x more diverse data, the system didn’t slow down — it broke entirely at the engineer-analyst handoff. That’s how he found the true constraint.

And there’s the moving bottleneck problem. Release one kink and another appears. Dbt solved transformation; now companies are hitting bottlenecks in data integration, in decision-makers absorbing insights, in pipeline orchestration. Every solution brings you to the next challenge.

If you find a bottleneck — and if it’s common across your target market, it’s a business.

Power: the constraint on the datacision cycle, combined with the mass caught in front of it.

Policy: remove it so thoroughly that the next constraint becomes visible.

When the medium changed but the product didn’t

There’s a second kind of “stuck” power. It’s when the medium you’re building on has capabilities nobody is designing for yet.

TikTok, Uber, Google Maps — they’re not apps that happen to run on a phone. They’re built on the unique strengths of the smartphone: the camera, the GPS, the always-in-your-pocket. The difference is between skeuomorphic and native product design. Skeuomorphic: take an existing process and make it faster with new tech. Native: do something only possible because of the new medium.

Take Granola AI. It’s a meeting note-taker — a small app that sits on top of your video calls, listens to the conversation, and gives you a clean, structured summary afterward. A digital tape recorder with better handwriting. That’s a skeuomorphic product: the old process (someone takes notes) made faster with new tech.

But Granola also lets you ask questions during the conversation. Mid-sentence, while the other person is talking, I’ll glance at Granola and ask it to suggest follow-up questions based on what was just said — questions I wouldn’t have thought of because I was busy listening. Or I’ll ask it to clarify something the other side said three minutes ago that I half-caught but didn’t want to interrupt for. No human note-taker can do this. No recording-after-the-fact can do this. Only a model that’s listening live, processing context in real time, and surfacing intelligence while the conversation is still happening can do this.

That’s a native product — something only possible because AI can sit invisibly inside a live conversation. The medium isn’t “better notes.” The medium is an always-on cognitive partner embedded in the interaction itself.

Native products kill skeuomorphic ones. DoorDash killed phone-ordering pizza. Uber killed calling a cab. Once Granola shifted from “better notes after” to “better thinking during,” every traditional note-taking tool became irrelevant — and every AI meeting tool that only delivers a summary afterward became the next cab company.

For your product, ask: what can my medium do that others can’t? What can users do now that was physically impossible before this medium existed? The internet separates intent from compute on a worldwide scale. Smartphones combine camera, GPS, and always-on connectivity. AI embeds intelligence inside processes that used to be purely human. The native strengths are where the 10x product lives. If you’re only using new technology to do the old thing slightly better, someone will build the thing that’s only possible in the new world.

Monday move: list the three things your medium can do that the previous medium couldn’t. If your product only uses one of them, you’re skeuomorphic — and vulnerable.

Power: the medium enables actions previously impossible.

Policy: design the product around the medium’s native strengths before someone else does.

Power That’s Built Is the Hardest to Copy

You’re here if you can’t out-data incumbents and there’s no obvious kink — you need to manufacture an edge.

Sometimes you don’t have data that compounds, and there’s no bottleneck to release or new medium to exploit. Sometimes you have to manufacture the advantage. Hardest path, but extraordinary moats.

University research that became infrastructure. In 2009, researchers at UC Berkeley were working on a distributed computing problem. Hadoop wrote intermediate results to disk — slow, painful, limited. The Berkeley team kept data in memory. They called it Spark.

Spark didn’t just make processing faster. It made an entire category possible: real-time analytics at scale, iterative machine learning, interactive data exploration.

Databricks formed in 2013 to commercialize Spark. The strategic decision: open-source Spark while building proprietary tools on top. Open source drove adoption. The proprietary platform (managed Spark, MLflow, Delta Lake) captured value.

This is the core tension of Data R&D: you have a temporary advantage from research, and you must decide what to open vs. lock down.

New processing tech for a new use case (like Spark) → open up aggressively. You need the ecosystem. If you need other systems to adopt you, openness buys integration.

New algorithms for an existing solution (like PageRank) → lock everything down. The use case is understood; opening up just helps competitors.

In between → careful balance. ChatGPT keeps algorithms tightly controlled but offers broad API access.

The uncomfortable truth: R&D advantages are temporary. Always. Commoditized in 18 months. Databricks didn’t stop at Spark — they built MLflow, Delta Lake, Unity Catalog. R&D only works if you use the temporary advantage to build something more durable — a flywheel, a proprietary dataset, an ecosystem. R&D is the spark (pun intended), not the fire.

Power: algorithmic or technological edge from research.

Policy: use the temporary advantage to build durable structural power (flywheel, ecosystem, proprietary data).

When no single piece is impressive, but the system is

The last strategy is the one most product managers instinctively avoid, which is exactly why it’s so powerful.

Synthesia is an AI-powered video creation platform valued at over a billion dollars. The video generation isn’t as good as dedicated research models. The text-to-speech is competent but not remarkable. The UI is clean but not revolutionary.

And yet people use it to create thousands of corporate training videos. The product works — not because any piece is exceptional, but because the pieces work together so seamlessly that the whole is dramatically greater than the sum of the parts. That’s a chainlink product.

Building a chainlink means building multiple components simultaneously and integrating them tightly. Terrifying. But that’s what creates the moat — the value lives in the integration, not in any single component. A competitor can’t copy one piece and replicate your product. They’d have to copy the system.

Two paths: build from scratch around a narrow use case (Synthesia for corporate training videos), or add links to an existing strong product (Adobe Premiere with AI features layered on top). Both work; they produce different products optimized for different segments.

Monday move: pick one narrow use case; list the 3–4 links; define the integration moments where the chain must feel seamless.

The risk: commoditization. If one link becomes a free API, the ecosystem shifts to commoditize the next. Your defense is tightening the integration so the system stays unique even as components become available elsewhere.

Power: integration creates system-level value competitors can’t copy link-by-link. Policy: narrow use case + tighter seams + continuous integration advantage, and a long term perspective.

The Choice That Changes Everything

If you’ve read this far, you might be thinking: “Great, I’ll combine the flywheel strategy with proprietary data and add some R&D for good measure.” That sounds comprehensive. Strategic, even.

It’s the opposite of strategy.

The whole point of this framework is to help you identify your one source of power and channel everything into it. Here are all seven. Read them as a diagnostic — which one describes the leverage that already exists (or could exist) in your product?

1. Proprietary Data — you own data nobody else can replicate. You’re this if your competitors would pay a lot for your dataset.

2. DMVD Flywheel — usage creates data that improves models that creates more usage. You’re this if usage improves the model.

3. DVD Loop — the data is the product, and more users means more data means more value. You’re this if the raw data is the value, no model needed.

4. Bottleneck — you remove the constraint in turning data into action. You’re this if handoffs kill throughput.

5. Native Design — the medium changed and you exploit what’s now possible. You’re this if your product is impossible without the new medium.

6. Data R&D — you have an algorithmic or technological edge, and you know what to open vs. lock down. You’re this if your advantage is a research breakthrough.

7. Chainlink — the integration is the moat, not any single component. You’re this if no single piece is best-in-class but the system is magic.

Here’s what to do Monday morning. Four questions, one piece of paper:

1. What is our power source? If you can’t name it in one sentence, you don’t have a data strategy.

2. What is our guiding policy? “We use data to improve the customer experience” is not a policy. “We enforce every transition in our DMVD flywheel by measuring bounce-back rates on every search result” — that’s a policy.

3. What do we stop doing? Strategy means saying no.

   • Accumulate: stop all projects that don’t feed the loop.

   • Unlock: stop “collect more data” as the default; map the constraint instead.

   • Build: stop feature-parity shipping; invest in the edge (R&D / integration seams).

4. What is the one transition, bottleneck, or integration we bet on? Name it specifically.

In 2019, my colleague didn’t know he was showing us a four-billion-dollar company. Neither did the people who built it, probably. What Tristan Handy knew was that there was a wall between data engineers and analysts, and that wall was the constraint on every decision cycle in every medium-sized company he’d ever worked with. Templated SQL was how he removed it. That was his source of power. That was his guiding policy. One constraint. One bet.

Google’s bet was bounce-back rates on search results — one transition in one flywheel, enforced every single day. Adobe’s was dark data sitting in servers for years, data they collected to save their subscription business, not to train AI models that didn’t exist yet. FBN’s was asking farmers to share what they already knew.

None of them started with seven strategies. They started with one.

So here’s what you do Monday morning. Take a piece of paper. Write your power source in one sentence — if you can’t, you don’t have a data strategy, you have data activities. Write your guiding policy, and not “we use data to improve the customer experience” — something with teeth, something that names what you’ll stop doing. Name the one transition, bottleneck, or integration you’re betting everything on. Name what moves in thirty days.

If you can’t fill in those sentences, you’re not allowed to build anything new this week.

Write your power and policy. Then cut half your roadmap.

As you may know, I’ve already written a short book on those data strategies, but I’m contemplating about writing a fully updated version. If you’re interested, reach out to me!

Conventional fundraising wisdom says start raising six months before you run out of money. If you raised 24 months of runway, that means month 18. Plenty of time to hit metrics, prove PMF, then raise from strength.

This is backwards. You’re not raising from strength at month 18. You’re raising from schedule.

Airbyte, the Open-Source ETL Tool, raised their Series A three months after closing seed—with 15 months of runway still in the bank. They didn’t need the money. They had edge: usage was exploding, the right partner showed up, and they could say no to bad terms. So they moved.

The founders who waited until month 18? Many of them hit a market that had turned cold. Same pitch, same metrics, vastly worse outcomes. Down rounds nearly quadrupled between Q1 2022 and Q1 2023. Startup shutdowns jumped 62%. These weren’t worse companies. They were companies that raised on schedule instead of raising on edge.

Professional gamblers have a rule for this. It’s called Kelly Criterion: only bet when you have positive expected value, and size your bet to your edge. If you don’t have edge, the optimal bet is zero—regardless of how much bankroll you have.

For founders, runway is your bankroll. It tells you how long you can play. It doesn’t tell you when to play.

Runway isn’t your trigger. Edge is.

Kelly Criterion for Founders: Why “Raise When You Need It” Is Mathematically Backwards

Professional gamblers don’t bet when they have money. They bet when they have edge.

This is Kelly Criterion in one sentence: only bet when you have positive expected value, and size your bet proportionally to your edge. The math is brutal in its implications. If you don’t have edge—if the conditions don’t favor you—the optimal bet is zero. Not a small bet. Zero. Regardless of how much bankroll you have.

For founders, your runway is your bankroll. It tells you how long you can play. It doesn’t tell you when you should play.

The conventional wisdom violates Kelly completely. “Raise when you need it” translates to “bet when your bankroll forces you to.” Kelly’s math predicts exactly what happens next: you enter the market at your weakest moment. Investors sense the desperation. Your leverage evaporates. The terms you get reflect your lack of options, not your company’s potential.

And here’s where it gets worse. Kelly violations compound. A bad raise from a desperation position doesn’t just hurt once. The dilution guts your ownership. The liquidation preferences eat your upside. The wrong investors poison your cap table. The valuation you accept becomes the ceiling for your next round. You’re not just losing one bet. You’re degrading your ability to win every future bet.

The 2022-2023 fundraising massacre proved Kelly’s prediction at scale. Down rounds nearly quadrupled in a single year—from 5.2% of all rounds in Q1 2022 to 18.7% in Q1 2023. Same companies. Same founders. Same business models. Different market timing. The founders who raised in early 2022 had edge—the market was eager, competition for deals was fierce, terms favored founders. The founders who waited until their runway forced them into the market got crushed.

Startup shutdowns told the same story: 467 in 2022, then 761 in 2023—a 62% increase. These weren’t worse companies. They were companies that bet without edge because their bankroll told them to.

That’s not a planning failure. That’s a Kelly violation The market didn’t care about the spreadsheets.

Fractional Kelly: What Airbyte Understood

Airbyte raised their Series A three months after closing their seed round.

They had 15 months of runway still in the bank. The spreadsheet said they had nearly two years before they needed to think about this. By every conventional metric, raising was premature. Unnecessary. Maybe even irresponsible—why take dilution you don’t need?

Here’s why: they understood fractional Kelly.

Professional gamblers don’t even use full Kelly—they use “fractional Kelly,” betting one-half or one-quarter of what the formula suggests. Why? Because edge estimation is uncertain. Markets shift. Conditions change. Fractional Kelly reduces volatility and preserves optionality for future bets. You’re not just optimizing this bet; you’re protecting your ability to make the next bet from a position of strength.

Airbyte’s translation: raise when edge is present, even if you don’t “need” the money. Preserve optionality for the months when edge disappears.

I asked Jean Lafleur, Airbyte’s co-founder, what drove them to move so fast. His answer was a masterclass in recognizing edge:

Signal: “Very strong pull from the market—open-source usage was a huge hockey stick.” Their Docker pulls went from 2,500 to 40,000 in three months. The curve spoke for itself.

Timing:“We found great partners with Benchmark, who went through this already several times—Chetan was at the board of Mulesoft, Elastic and Mongo—and who were already contributing a lot strategically. So we wanted to formalize that partnership.” The right partner showed up. That window doesn’t stay open.

Leverage: “We didn’t need the money per se.” They could be selective. They could say no. That’s not a nice-to-have—that’s the difference between founder-friendly terms and getting squeezed.

Here’s the part that matters most: they didn’t plan the timeline. When I suggested they’d set a deliberate 9-month deadline to force fast decisions, Jean corrected me: “Market was on fire, perfect partner showed up, we grabbed the opportunity—didn’t plan the 9-month timeline, it just made sense when it happened.”

That’s Kelly in action. They weren’t following a playbook. They weren’t raising because their runway told them to. They recognized when all three conditions converged—and they moved.

Same stage, same market, opposite outcome from the founders who waited. Airbyte became a unicorn. The founders who followed the Month-22 playbook became a statistic.

Signal, Leverage, Timing: The Three Conditions That Mean Your Window Is Open

Edge isn’t a feeling. It’s three conditions you can measure.

Condition 1: Signal. Do you have proof that something is working?

Signal means metrics that tell a story without you having to sell it. MRR growing 15-20%+ month-over-month for three or more consecutive months. Retention curves that flatten instead of decay. Organic acquisition accelerating—word-of-mouth, referrals, inbound interest you didn’t pay for. Investors reaching out to you without a pitch.

The test is simple: if you showed your last 90 days of data to an investor with zero context, would they lean in—or would they ask what else you have?

Airbyte’s signal was unmistakable. 16x growth in Docker pulls over three months. No explanation needed. The curve spoke for itself.

Condition 2: Leverage. Can you negotiate from strength, not desperation?

Leverage comes from options. Multiple investors expressing serious interest—not “let’s keep talking,” but term sheets or clear intent. Twelve or more months of runway remaining, so you can walk away from bad terms without dying. Alternatives if your top-choice investor passes.

The test: if your preferred investor said no tomorrow, would you have comparable alternatives at similar terms? Or would you have to take whatever you could get?

Airbyte had leverage because they didn’t need the money. They could be selective. They could say no. That’s not a nice-to-have. That’s the difference between founder-friendly terms and getting squeezed.

Condition 3: Timing. Is the external environment favorable?

Timing is everything you don’t control. VC deployment cycles—January through May and September through November are peak windows; summer and December are dead zones. Sector sentiment—is your category “hot” or facing headwinds? Public market health—when public markets tank, private markets follow with a lag. Recent comparable raises—has a competitor or adjacent company raised successfully in the last 90 days, validating the space?

The test: if you started raising today, would the market environment help you or hurt you?

Timing killed more companies in 2022-2023 than bad products did. The founders who raised in Q1 2022 rode a favorable wave. The founders who waited nine months entered a completely different market—same pitch, same metrics, vastly worse outcomes.

Your window is open when all three conditions are present. Signal, leverage, and timing. When they converge, raise—even if you have runway to spare. Even if your spreadsheet says it’s not time yet. This is your Kelly moment. You have edge. Use it.

Your window is closed when any one is missing. Don’t raise. Don’t “test the market.” Don’t start conversations you can’t finish. You’d be betting without edge, and Kelly’s math is unforgiving. Wait. Build signal. Extend runway if you have to. Protect your ability to raise from strength when the window opens again.

John Farrall has spent years in the alternative data world, brokering deals, advising data businesses, and now serves as Chief Commercial Officer at SymetryML. He’s seen hundreds of companies pitch their data as the next big revenue stream. When I asked him about the biggest misconceptions, he didn’t hesitate.

“This is going to generate lots of money for me, immediately,” he said. “That’s the first thing everyone believes.”

Then he drew me a 2x2 matrix. High-value versus low-value. Easy versus difficult.

“Everyone thinks they are high value/easy,” he told me. “But they’re really low value/difficult.”

“Data is sold, not bought,” Farrall said. “If you’re waiting for your data’s value to be self-evident, you’ve already lost.”

Here’s why: data value isn’t collected. It’s constructed. And construction isn’t a “data team” activity—it’s three CEO decisions:

1. Measure what others won’t

2. Reject the consensus

3. Compound—don’t publish

Data doesn’t have value. Decisions do.

FWIW, John also writes about the fascinating world of alt data.

If you only have 5 minutes: here are the key points

• Most data has no inherent value—value is constructed through deliberate, long-term decisions.

• Three CEO-level choices create defensibility: measure what others don’t, reject the consensus, and keep signals private to compound over time.

• Renaissance Technologies succeeded not by having better data, but by treating garbage data as raw material for construction, betting on non-obvious patterns, and never publishing.

• CDOs fail when tasked with collection, not construction—real moats come from decisions beyond their job scope.

• Collected data commoditizes; constructed data creates long-term advantage.

• If your data strategy feels easy, it’s probably low-value. The hard, high-value work is strategic, expensive, and long-term—and starts with the CEO.

Renaissance didn’t “have better data.” They built better inputs by failing for years.

“They collected every piece of data they could—including lunar phases and sunspots—to test its viability. Most tests failed.”

Most tests failed. That’s the key phrase. Renaissance Technologies wasn’t sitting on a goldmine. They were building one, brick by brick, running tests that mostly didn’t work.

The result: 66% average annual gross returns since 1988. Competitors with 100x more “proprietary” data, with 30 years to catch up, never closed the gap.

The conventional story is that they hired smarter mathematicians. That’s true but insufficient. Other firms hired mathematicians too. The difference was what those mathematicians did with data.

Renaissance didn’t collect more data than their competitors. They collected different data—weather patterns, shipping manifests, satellite imagery—data their competitors thought was worthless. They bought it cheap precisely because nobody wanted it.

Their early data was garbage. “The trove of data Simons and others had collected proved of little use, mostly because it was riddled with errors and faulty prices.” The edge came from construction—years of systematic cleaning, combining, and testing to make worthless inputs valuable.

Collectors lose twice: first the product, then the leverage.

If collecting data creates moats, Yahoo should have won the internet.

Yahoo had everything: first-mover advantage, the largest user base, all the search data. They employed a “Chief Ontologist” to organize the internet by hand.

Google had two grad students and an algorithm.

Between 2000 and 2004, Yahoo literally paid Google to do search. The company with all the data outsourced to its competitor because it couldn’t make the data work.

The difference wasn’t who collected more. Yahoo collected and organized. Google constructed PageRank—a system that found patterns in hyperlinks nobody else was looking for. Same internet. Different approach to value.

Foursquare tells the same story. They had 14 billion check-ins, the “living, breathing map of the world.” Now the consumer app is dead.

Here’s the irony: Apple, Uber, and Microsoft all use Foursquare’s location data today. Other companies extract more value from Foursquare’s data than Foursquare ever did. Collectors become vendors. Constructors become kings.

The CDO job is optimized for infrastructure & dashboards, not moats.

The average Chief Data Officer lasts 2.5 years. 85% of big data projects fail. (And don’t even get me started on the “Chiefs of Nothing”)

CDOs fail not because they’re incompetent. They fail because they’re hired to do the wrong thing.

Look at any CDO job description. Centralize. Democratize. Govern. Enable access.

All of that is collection. None of it is construction.

Construction means deciding what to measure that nobody else measures. Construction means rejecting consensus about what data matters. Construction means protecting insights instead of publishing them.

Those are CEO decisions. They’re not in any CDO job description.

Your CDO can execute construction decisions brilliantly. But they can’t make them. They’re measured on adoption metrics and data quality scores—not competitive moats.

Renaissance Technologies didn’t have a Chief Data Officer. They had Jim Simons—a CEO who made construction decisions for 30 years.

Note: Read the “Chief of Nothing” to see the striking similarities here between RenTech and Capital One.

Decision 1: Build inputs competitors can’t buy.

This is a capex bet, not a dashboard request.

While competitors collected obvious price data, Renaissance bought weather patterns and crop reports. Congressional voting records. Satellite imagery before anyone knew what to do with it.

Your CDO collects what exists. They don’t decide what should exist. Construction means measuring things before you know they’re valuable—spending money on data collection that might not pay off for years.

“Do something new. Don’t run with the pack,” Simons once said. “If I’m one of n people doing the same thing, I probably won’t win.”

Most companies do the opposite. They collect the same data as competitors, just more organized. They build the same dashboards. They measure the same KPIs. Then they wonder why their data doesn’t create differentiation.

Billy Beane found value in on-base percentage when everyone else measured batting average. The data existed. Nobody valued it. But here’s what happened next: Beane published his methods. Michael Lewis wrote a book. His edge lasted three years.

Renaissance’s edge has lasted 30 years. The difference? What you do with Construction Decision 3.

Decision 2: Bet against the story everyone tells.

By 1997, more than half of the trading signals Renaissance discovered were “non-intuitive”—patterns they couldn’t explain. They traded on them anyway.

Peter Brown, their co-CEO: “If there were signals that made a lot of sense that were very strong, they would have long-ago been traded out. There are signals that you can’t understand, but they’re there, and they can be relatively strong.”

They called the faint patterns “ghosts”—trends so subtle that most investors couldn’t notice them. Simons eventually came around to a view that the whys didn’t matter, just that the trades worked.

“Any time you hear financial experts talking about how the market went up because of such and such—remember it’s all nonsense,” Brown said.

Construction means betting against industry wisdom. It means trusting patterns that look like noise to everyone else. That takes CEO cover. Nobody else in your organization has the latitude to reject consensus.

Decision 3: Keep the signal private long enough to compound.

Every insight you share is value you’ll never compound.

Renaissance never published. Never attended conferences. Never shared insights. For 30 years.

Jim Simons once quoted Animal Farm: “God gave me a tail to keep off the flies. But I’d rather have had no tail and no flies.” That’s how he felt about publicity.

When employees leave Renaissance, they lose access to the Medallion Fund. Knowledge stays inside the building.

Your CDO is measured on “insights delivered.” Every dashboard shared, every report published—that’s their output metric. They’re literally incentivized to broadcast value.

Renaissance built tiny advantages and compounded them for decades. The signal that’s worth 0.1% today might be worth 10% in five years if nobody else finds it. The moment you publish it, the edge starts decaying.

“Visibility invites competition. The less competition, the better.”

Collected data commoditizes—constructed data compounds

Collected data is the mindset that says: our data is inherently valuable, we just need to organize it. The CDO’s job is to collect what exists and make it accessible.

Constructed data is the mindset that says: data value must be deliberately built through strategic choices. The CEO’s job is to make construction decisions the CDO can’t.

Everyone in Farrall’s meetings thinks they’re high-value/easy. They believe collecting and organizing will unlock obvious value.

They’re actually low-value/difficult. Without construction, they’re organizing commodity inputs that create no differentiation.

Renaissance assumed their data was worthless and spent a decade proving otherwise through systematic construction. Most companies assume their data is valuable and never construct anything.

The 10-Minute CEO Data Construction Scorecard

Measure

• What are we measuring that would look wasteful for 12 months?

• What data do we pay to create that competitors don’t even have access to?

Reject

• Which KPI or “industry best practice” do we believe is misleading?

• Where are we explicitly betting on a non-intuitive signal?

Protect

• What insight or model would we never put in a deck?

• Who outside the core team has access to our highest-leverage analysis?

Compound

• Do we have a policy for what not to publish internally?

• Are we building reusable “signal factories,” or shipping one-off dashboards?

Accountability

• Which CEO-owned construction decision will change this quarter?

If you can’t answer these, you’re collecting—not constructing.

Your board will ask about data ROI at the next meeting.

If you’re collecting, you’ll show dashboards and adoption metrics. The board won’t be convinced.

If you’re constructing, you’ll need to answer three questions only you can answer:

What are we measuring that nobody else measures?

What industry wisdom are we systematically ignoring?

Are we compounding insights or publishing them?

Your CDO can’t make these decisions. The construction choices are yours.

The moat isn’t in the data. It’s in the decisions only you can make about what to build, what to ignore, and what never to share.

Monday, 08:12.

A cloud giant announces Managed YourProject™.

Same API. Same docs. Same migration path.

Different logo. Different margins.

By Friday, half your inbound turns into one question:

“Why wouldn’t we just use the managed one?”

Here’s the adult version of open source:

Open source isn’t ideology. It’s competitive strategy.

A permissive license isn’t a virtue. It’s an invitation.

And yes — the “community outrage” pattern is real. But it’s messy:

Sometimes the backlash is authentic. Sometimes it’s authentic and strategically amplified.

Note: Today we’ll be doing something different, this is a tactical, immediately actionable piece, with all the meat and none of the fat. Enjoy, it’ll be a quick (but hopefully very valuable) read.

The OSS War Doctrine

Here is what it really looks likes to me:

1. Code spreads. Interfaces trap. Brands endure.

2. Open what spreads. Close what earns.

3. Assume the fork is coming — build what it can’t copy.

The 7 tactics cheat sheet

OS warriors have 7 moves to fight this, prevent this, use this:

ATTACK (steal distribution):

1. Fork + out-resource the original

2. Implement their API, not their code

3. Commoditize the lock-in layer

DEFEND (make “Managed You” expensive):

4. Switch licenses before hyperscalers care

5. Weaponize authenticity (the fork can’t buy “original”)

BUILD (create compounding moats):

6. Hook developers free, gate what enterprises require

7. Give away what spreads, keep what earns

If they ship “Managed You” this week do this within 72 hours

• Message (everywhere): “We’re the original authors. We control the roadmap. We’ll be here in 5 years.”

• Publish: Fork FAQ (compatibility claims, roadmap diffs, trademark boundaries, migration reality)

• Publish: 2-release fork-proof roadmap (SSO/audit/control-plane/integrations — pick what they can’t ship fast)

• Publish: “We are the source” landing page (maintainers, governance, enterprise plan, customer logos, security posture)

• Do: trademark everything you can today

• Do: pre-brief top customers so they don’t learn your story from the competitor

The 3 questions that decide any OS strategy today

1. What will they copy first: your code, your API, or your distribution?

2. What can you ship that a fork can’t in 6 months?

3. What enterprise requirements do you own (that devs don’t care about)?

Now the playbook.

ATTACK

Win their market without writing their code

1) Fork + out-resource the original

The play: Fork under the permissive license and fund momentum until your fork becomes the default.

Your move:

• Fork fast. Speed beats elegance.

• Win the narrative: “We’re keeping it open.”

• Ship the neglected pain: the feature requests they “couldn’t prioritize.”

• Recruit frustrated contributors (names create legitimacy).

Case file: AWS → Elasticsearch → OpenSearch

Elastic changed licensing to stop hyperscalers reselling Elasticsearch as a managed service. AWS forked, shipped its own distribution, and marketed it as the “true” open alternative. Then came the credibility move: “neutral governance” optics + ecosystem logos + momentum.

Quick nuance:

Foundations are instruments: sometimes they produce real neutrality, sometimes they produce neutral-looking governance.

Also: OpenTofu vs Terraform

Terraform moved to BSL → coalition forked to OpenTofu → foundation backing → shipped long-requested improvements quickly. Same mechanic, different scale.

Note: HashiCorp still “closed what earns” and earned a 6.4 billion USD acquisition.

2) Implement their API, not their code

The play: Copy the interface. Skip the license. Capture the ecosystem.

Your move:

• Identify the interface moat (wire protocol, API, SQL dialect, plugin contract).

• Rebuild compatibility on your infrastructure.

• Market it plainly: “Works with X.”

• Compete on leverage: scale, cost, distribution.

Case file: DocumentDB vs MongoDB

AWS didn’t need MongoDB’s code. It needed MongoDB’s shape. Implement the protocol, inherit drivers + tutorials + mental models, and customers migrate without rewriting.

3) Commoditize the lock-in layer

The play: Don’t fight the incumbent where they’re strong. Remove the thing they’re strong at.

Your move:

• Name the lock-in layer (orchestration, data format, workflow contract).

• Open-source (or champion) a standard that breaks the trap.

• Wrap it in legitimacy (foundation / neutral branding).

• Then compete above the standard.

Case file: Kubernetes

Standardized orchestration weakened pure infrastructure lock-in. AWS still won plenty — but it was forced to support the standard because customers wanted optionality. The board changed.

Micro case file: Iceberg vs proprietary table formats

Open table formats made storage + compute more interchangeable. The moat moved from “we own your data layout” to “we own your ecosystem and execution.” Standards don’t kill incumbents — they relocate the fight.

DEFEND

Make “Managed You” legally and commercially expensive

4) Switch licenses before hyperscalers care

The play: Start permissive to spread. Switch once you’re valuable — before the giants arrive.

Your move:

• Decide your endgame early.

• If you’re growing, change licensing before you’re worth forking.

• Frame it as protecting contributor investment and sustainability.

• Assume a fork is coming anyway; plan around it.

Case file: Airbyte (early switch, low backlash)

Airbyte tightened licensing early while keeping the protocol open — standard stays free, resale gets blocked, business stays viable. Early = strategy.

Note: Another point in my case that the founders of Airbyte are hiding their unnatural talents in OS warfare.

Case file: Redis → Valkey (late switch, instant fork)

Redis changed after years of expectations. Hyperscalers forked quickly. Late = revolt + permanent fork energy.

5) Weaponize authenticity (the fork can’t buy “original”)

The play: The source matters. Treat it like a moat.

Your move:

• Trademark everything that matters.

• Make “original authors” a product feature — repeat it everywhere.

• Build direct customer relationships before marketplaces capture them.

• Ship integrated advantages forks can’t match (hosted control-plane, managed scale, proprietary integrations).

Case file: MongoDB vs DocumentDB

DocumentDB copied compatibility. MongoDB keeps winning higher-stakes buyers by leaning on “we are the source,” roadmap authority, long-term accountability, and a managed platform story.

Case file: Elastic vs OpenSearch

Originals can keep winning if they ship faster, market “source of truth,” and bundle differentiated capabilities forks can’t replicate cleanly.

BUILD

Turn open source into compounding leverage

6) Hook developers free, gate what enterprises require

The play: Make adoption frictionless. Gate compliance, governance, and scale.

Your move:

• Make starting stupid-easy: no sales call, no demo, no “talk to us.”

• Gate what enterprises require:

  • SSO / SAML / SCIM

  • audit logs & retention

  • encryption / key management

  • compliance packages

  • disaster recovery

  • support SLAs

• Instrument the funnel: individual → team → production → enterprise.

Case file: MongoDB’s funnel logic

Developers adopt because it’s easy. Teams standardize because it works. Enterprises pay when governance/compliance/security becomes mandatory.

7) Give away what spreads, keep what earns

The play: Open-source what creates dependency. Keep what captures value.

Your move:

• Open-source: standards, SDKs, client libraries, tooling, reference implementations.

• Keep proprietary: infrastructure, management plane, hosted scale, enterprise governance.

• Make your paid product the default for anyone who adopted the standard.

Case file: Cloudflare (open the tool, keep the machine)

Cloudflare can open-source serious infrastructure components and still win because the real moat is the network + operations. The open piece spreads patterns. The closed piece prints money.

Checklist (think about this now)

1. What will they copy first: code, API, or distribution?

2. What can we ship that a fork can’t in 6 months?

3. Which enterprise requirements are we deliberately gating?

4. What standard do we want the ecosystem locked into?

Open source isn’t charity—it’s competitive strategy.

If you can’t name the specific business outcome you’re trying to achieve, you’re not “doing open source.” You’re publishing code and hoping the internet turns it into distribution.

So do this before you touch a license or write a README:

Name the outcome. Pick the battlefield.

There are only four real outcomes open source reliably produces:

1. Market-making: make a standard exist so you can win the market it creates.

2. Ecosystem: get other people to extend your product and build businesses on top of it.

3. Reputation: become the trusted expert so users, talent, and buyers come to you.

4. Exploration: learn what the market actually wants before you bet the company.

Pick one. Most teams pick zero. They ship a repo, write a launch post, and wait for GitHub stars to become revenue by osmosis. Two years later: drive-by PRs, “community,” and no business impact.

And if you pick the wrong battlefield, you don’t just waste time—you can lose the war you thought you were fighting.

June 4, 2024: Databricks announced it would acquire Tabular—the company founded by Apache Iceberg’s original creators. Iceberg was supposed to disintermediate Databricks. Instead, the commercial center of gravity ended up inside the incumbent.

Iceberg the project won adoption. Tabular the company lost the business war.

#1 Market-making wars: To win a standard, you have to give it away

The objective: Make the market exist so you can win it. Create a protocol/format that breaks an incumbent’s lock-in—and turns your product into the obvious “best implementation” of the new default.

What you sacrifice: Control. You’re trading ownership for adoption. You’re betting the pie grows faster than your slice shrinks.

How you die: You succeed technically…and lose commercially. You create the standard, then a bigger player becomes the center of gravity (distribution, enterprise deals, defaults), and you become “the people who started it.”

You’re in a market-making war if…

• You keep saying “we need this to become the standard” unironically.

• Your buyer won’t switch unless the ecosystem around the thing exists (connectors, integrations, vendor neutrality).

• Your “competitor” isn’t a product—it’s a lock-in (cloud defaults, proprietary formats, entrenched workflows).

• If the market stays fragmented, you lose. If it converges, you finally have a shot.

Do this next week

1. Write the disintermediation sentence.

   “If this becomes the standard, it breaks ____’s lock-in by decoupling ____ from ____.”

2. Choose whether you’re actually willing to give it away.

   Market-making requires real openness—commercial reusability included. If you restrict commercial use, you’re not fighting a standards war. You’re doing controlled distribution and calling it a revolution.

3. Define where you control the standard.

   Winning a standard is rarely about the license alone. The real leverage usually sits in one or two places:

   • who ships the default (managed service, marketplace, cloud console)

   • who controls compatibility (test suites, certification, “works with” badges)

   • who owns governance and the name

   If you can’t point to at least one control point, you’re not market-making.
   You’re donating infrastructure.

What it looks like in the wild

When Google open sourced Kubernetes, they weren’t being benevolent. They were disintermediating AWS. Kubernetes decoupled container orchestration from any single cloud, weakening the lock-in layer and shifting power to the clouds that executed best around it.

Databricks played the same game with Delta Lake. Open table formats threatened “Databricks clones,” so open sourcing Delta was a standards move: win the format, slow competitor convergence, keep control of the commercial center of gravity.

MongoDB did it for NoSQL. The category needed a shared language across ecosystems—drivers, integrations, tooling. That only happens when commercial actors can participate freely.

And then there’s the nightmare outcome.

Iceberg had the technical win. Engineers loved it. Adoption grew. But Tabular couldn’t win the business war fast enough. Databricks announced it would acquire Tabular—the company founded by Iceberg’s original creators. The project meant to disintermediate the incumbent ends up with its commercial center of gravity inside the incumbent.

That’s the core danger of a market-making war:

You can be right. You can even win adoption.

And still lose the war.

If you’re not willing to truly give it away—and you don’t have a plan to become the default implementation—you’re not market-making.

You’re cosplaying.

#2 Ecosystem wars: Ecosystems only work until you try to tax them

The objective: Get other people to build your product for you. Plugins, modules, connectors, templates, integrations, consultants—an economy that extends your surface area faster than your team ever could. You become the hub everyone orbits.

What you sacrifice: Future extraction flexibility. The ecosystem only forms when builders believe they can create their own commercial value on top of you—without asking permission every step of the way.

How you die: You win adoption…then panic and overtax. You change the rules once the ecosystem depends on you. The builders fork, the partners leave, and the center of gravity snaps away from you overnight.

You’re in an ecosystem war if…

• Your roadmap is fundamentally unscalable without third parties (there are too many “edges”).

• The “real product” is hundreds of integrations, not one killer feature.

• You want consultants and agencies selling implementations because that’s your distribution.

• Your best case is: a thousand small businesses depend on you, and that dependence compounds.

Do this next week

1. Define what third parties should build—and what they must never need you for.

   List the top 10 extensions you want outsiders to create (modules, connectors, add-ons). Then draw the boundary: what’s core, what’s extensible, what’s off-limits. If builders can’t predict the boundary, they won’t invest.

2. Write the “tax policy” before you have leverage.

   Ecosystems don’t die because companies monetize. They die because monetization feels like rule-changing. Decide now: what will always remain open? What will be paid? What’s the line you won’t cross once people bet their livelihoods on you?

3. Pick a license that matches the war.

   Ecosystem wars require commercial reusability. If third parties can’t legally sell on top of you, you’re starving the ecosystem’s oxygen supply.

What it looks like in the wild

WordPress didn’t win because Automattic built everything. It won because millions of creators, agencies, and plugin businesses made money on top of it. The ecosystem was the moat.

Terraform did the same thing in infrastructure-as-code: modules, providers, consulting practices, enterprise integrations—an entire economy orbiting HashiCorp’s center.

Then comes the inevitable trap: at some point you want to capture value.

You attracted builders by being open. Now you want to extract.

That’s where ecosystem wars are decided.

HashiCorp pushed too hard. The move to the Business Source License signaled: “Those commercial uses you built? Now you need our permission.” The ecosystem responded the only way it can: OpenTofu forked—fast.

If your goal was ecosystem longevity, that was catastrophic. If your goal was liquidity, maybe it was rational—IBM closed the acquisition on February 27, 2025 for $6.4B.

But here’s the punchline:

You can run the attract-extract play once.

After you change the rules, the ecosystem won’t trust you a second time.

If you’re in an ecosystem war, your main enemy isn’t a competitor.

It’s your own temptation to tax too early, too hard, and too unpredictably.

#3 Reputation wars: Win the conversation before you try to win the market

The objective: Become the trusted expert. Use open source to earn credibility, mindshare, and talent—so when buyers show up, you’re the default choice before they compare features.

What you sacrifice: Speed to “big outcomes.” Reputation compounds slower than a standards win. You don’t get to declare victory with a protocol everyone adopts. You build authority brick by brick.

How you die: You ship code and call it “community,” but never become the reference point. No point of view. No teaching. No narrative. Your repo exists, but your name doesn’t.

You’re in a reputation war if…

• You don’t have distribution, but you can earn trust.

• The buyer needs conviction (“this is safe, real, credible”) more than they need a spec.

• Your product category is fuzzy and people need vocabulary to even describe the problem.

• The best talent you want could choose ten other companies—credibility is your recruiting weapon.

Do this next week

1. Pick the hill you’re going to die on—opinionated and specific.

   Not “we’re open.” Not “we’re modern.” A real stance: “X is broken because Y, and the new default is Z.” If your thesis can’t offend anyone, it can’t recruit anyone either.

2. Turn your repo into a credibility machine.

   One golden path demo. One “why” doc that teaches the mental model. One brutally honest “when not to use this.” The goal isn’t completeness—it’s trust.

3. Make contribution legible.

   Clear issues, fast maintainer feedback, public roadmap signals. Reputation is built in the comments section. If contributors feel ignored, you don’t look “open.” You look understaffed.

What it looks like in the wild

dbt Labs didn’t win a standards war. They didn’t build a giant plugin economy first. They won a reputation war so hard it turned into category creation.

Before dbt, “analytics engineering” wasn’t a job title. It wasn’t an identity. dbt didn’t just ship a tool—they packaged a worldview: how analytics should be built, tested, reviewed, deployed. Then they reinforced it with community, content, and a clear point of view.

The open source project let practitioners try it without permission.

The community let them talk about it with peers.

The content let dbt own the language.

Every “analytics engineer” job posting is a downstream win—even at companies that don’t use dbt.

That’s the power of a reputation war: you win the conversation first, and the market follows later.

If you’re early-stage, this is the most underrated battlefield. It’s survivable, it’s compounding, and it doesn’t require you to outspend incumbents.

You just have to be relentlessly useful—and unmistakably opinionated.

#4 Exploration wars: Use open source to learn before you commit

The objective: Reduce risk. Validate demand, discover real use cases, and let users tell you what matters—before you spend 18 months building the wrong thing.

What you sacrifice: Ego. Exploration requires admitting you don’t know yet. It’s not “we’re the standard.” It’s “help us find the truth.”

How you die: You treat it like reputation (“look at our stars!”) instead of learning. You optimize for optics, not signal. You collect GitHub applause and miss the actual product insight.

You’re in an exploration war if…

• You’re not sure who the real user is, or what they’ll pay for.

• You suspect there are 3–5 different use cases and you need to see which one bites hardest.

• Your market is noisy and everyone claims demand, but nobody has pull.

• You need real-world edge cases more than you need more code.

Do this next week

1. Instrument for signal, not vanity.

   Track: what gets installed, what gets configured, where people drop, what issues repeat. Stars are applause. Usage is truth.

2. Force feedback into the product.

   Add a “what were you trying to do?” prompt in docs/issues. Add templates for bug reports that capture context. Your goal is to extract use cases at scale.

3. Write the pivot criteria now.

   “If we see repeated demand for X from Y users, we commit.”

   “If we don’t see it by Z, we kill it or reposition.”

   Exploration without decision rules becomes endless wandering.

What it looks like in the wild

Exploration is how you earn the right to escalate.

It’s also how you de-risk buyers: enterprise customers like open source because it’s a hedge. Even if you die, the artifact survives. That check-box alone closes deals sometimes—not because they expect you to fail, but because procurement needs the exit hatch.

The founders who win treat open source like a radar system:

ship → observe → learn → narrow → commit.

If you start with market-making ambition when you only have exploration-level understanding, you don’t look bold.

You look doomed.

You’re not Databricks: Pick the war that fits your position

Most founders describe their open source strategy using market-making language.

“We’re going to be the standard.”

“We’re going to disintermediate X.”

“We’re building the open alternative to Y.”

That’s not a strategy. That’s a vibe.

Here are the three questions that decide whether you’re being real—or just repeating the Databricks soundtrack:

1) Do you have distribution to win a standards battle?

Market-making wars are won by whoever becomes the default in enterprise buying paths: cloud marketplaces, managed services, procurement relationships, integrations, benchmarks, the “recommended” button.

If you don’t control a channel that can make you the default, you can still create the standard—but you can’t guarantee you’ll own the center of gravity.

That’s how you end up as the Wikipedia footnote.

2) Do you have 3–5 years of runway to wait for ecosystem effects?

Ecosystems don’t form on your timeline. They form when enough third parties believe they can build real businesses on top of you—then slowly, visibly, they do.

If you need monetization this quarter, you’ll be tempted to tax early, change terms, or close doors.

That temptation is the fork factory.

3) Can you survive if a bigger player adopts your standard and out-executes you on it?

This is the Iceberg nightmare: you win technically, the market converges, and the incumbent simply absorbs the commercial surface area.

If the answer is “no,” market-making isn’t brave. It’s suicidal.

You can’t afford to give it away like Google

Google could give away Kubernetes because the payoff wasn’t Kubernetes revenue. It was cloud leverage. Weakening AWS’s lock-in was worth far more than anything they could charge for orchestration.

Databricks can fight market-making wars because they have distribution, budget, and the ability to buy outcomes—sometimes literally by acquiring the winners of wars they didn’t start.

You probably can’t.

So stop asking: “Which war sounds best in a pitch deck?”

Start asking: “Which war can we actually win?”

4 Questions to tell which war you are actually in?

Do you need the market to exist before you can win it? → Market-making war.

You’re trying to create a standard that disintermediates an incumbent.

Do you need others to extend your product? → Ecosystem war.

You’re trying to become the hub developers and partners build on.

Do you need credibility, talent, or early demand? → Reputation war.

You’re trying to own the conversation so adoption follows.

Do you need to learn before you commit? → Exploration war.

You’re trying to derisk, discover pull, and find the real wedge.

Sequence matters: Airbyte’s path is the blueprint

Airbyte didn’t become a unicorn by opening a repo and hoping.

They escalated the battlefield based on stage:

• Reputation first: earn trust with data engineers, show up relentlessly, prove you understand the pain.

• Exploration alongside it: learn which connectors mattered, which workflows were real, where incumbents were weakest.

• Ecosystem next: let others extend the surface area faster than the core team could.

• Market-making only after: once they had earned distribution and legitimacy, they could fight bigger wars.

That’s the point most teams miss.

They start with market-making ambition when they only have exploration-level understanding and reputation-level resources.

And then they’re surprised when “open” doesn’t turn into “outcome.”

Pick the battlefield that matches your resources, your timeline, and your position.

Because two years from now, you’ll either have a business outcome you can point to—

or a repo with a lot of stars and a blog post you barely remember writing.

Monday morning, 9:07.

The Head of Growth drops one line in Slack:

“Which campaign drove repeat purchases this week—and what should we change today?”

A year ago, that question triggered a ritual: ticket → analyst queue → dashboard → meeting → “we’ll revisit next week.”

Now it’s a different ritual: ask → answer → action.

No dashboard. No “data request.” No waiting.

The companies happy with Tableau aren’t switching. They’ll abandon BI tools altogether. And the ones who already abandoned don’t want a new platform. They want one tool that moves one metric.

If you’re building “Tableau but with AI,” you’re already dead.

It wasn’t a switch. It’s an extinction.

The buyer is shifting from “analytics leaders” to “operators who own the metric.” And many companies skip BI entirely—they never develop the habit in the first place.

Incumbents are trapped in the old world. Here’s the playbook for building the company that replaces them.

If you only have 5 minutes: here are the key points

• The traditional BI stack is dying—not because it’s broken, but because modern operators never build the habit to need it.

• BI incumbents (like Tableau and Looker) rely on outdated models: dashboards, seats, and centralized teams.

• The real shift: buyers are no longer analytics leads but operators who want direct answers in their workflow, not dashboards.

• This mirrors the Netflix vs. Blockbuster playbook: win by serving the “haters”—the customers incumbents structurally can’t serve.

• Winning products will:

  • Remove the “trip to BI” by delivering insights directly in tools like CRMs or ad platforms.

  • Replace dashboards with actions: lists, segments, triggers.

  • Deliver value in days, not months—no setup, no analysts.

  • Build compounding moats through telemetry, feedback loops, and embedded automation.

When do you even buy BI?

Think about it, for a start up growing into a series business, how many people would it take to think about buying central BI:

10 people? No.

20 people? No.

40–100 people? You won’t see it coming.

Somewhere in that range, companies used to centralize data and buy a BI stack. But if AI tools let operators answer their own questions inside their own workflows—before anyone thinks to centralize—that purchase never happens.

If you never centralize data, you never buy the central BI stack.

The category doesn’t shrink. It fails to form.

Netflix didn’t beat Blockbuster by making better stores

They won by serving a customer Blockbuster couldn’t. The Haters.

Blockbuster’s customer: people willing to drive, browse, pay per rental, and accept friction.

Netflix’s wedge: people who didn’t want the trip, didn’t want the penalty, and didn’t want the ritual.

By the time Blockbuster “adapted,” adapting meant burning down their core business model. Late fees weren’t a feature—they were 16% of revenue. They got sued over them. And they still couldn’t give them up, because the whole machine depended on that lever.

Netflix scaled the wedge with distribution centers and mail logistics—the unsexy compounding advantage.

That playbook is opening up again.

BI’s Blockbuster customer is disappearing

Tableau, Looker, ThoughtSpot—classic BI is built for analytics departments, central teams, dashboard production, governance-heavy pipelines, implementation projects measured in months.

That customer existed because functional teams couldn’t answer questions themselves.

But functional teams don’t need that mediation anymore.

Marketing asks. It gets an answer. Sales asks. It gets a list. CS asks. It gets churn risk and a next step.

They’re not “doing analytics.” They’re doing work.

Work hates queues.

The Netflix playbook: serve the customer the incumbent can’t profitably serve

Stop asking: “How do we beat Tableau?”

Start asking: “Who is Tableau structurally unable to serve?”

Here’s the playbook.

1. Find the “late fees” (the profit lever they can’t give up)

Blockbuster didn’t just have late fees. Late fees were the model. 16% of revenue. The thing they got sued over and still couldn’t stop.

BI’s late fees:

• Seats (priced for teams of 15–25)

• Dashboards (the artifact that justifies seats)

Everything else—implementations, governance, analyst workflows, “centers of excellence”—exists to defend those two.

Incumbents can add copilots. They can add chat. They can announce “agentic BI.”

But if they truly serve operators directly, they collapse the need for the artifact and the org that buys it.

They can’t delete dashboards without deleting what they sell.

Same reason Blockbuster couldn’t delete late fees.

2. Pick the non-customer (the person who currently avoids BI)

Netflix didn’t target “movie lovers.” They targeted “people who don’t want the trip.”

Your non-customer isn’t “someone who wants a different dashboard.”

It’s the person who refuses BI outright:

• Growth lead living in ads managers and Shopify

• RevOps lead living in Salesforce and spreadsheets

• CSM living in Zendesk and Gainsight

• Product lead living in events, cohorts, and retention curves

They don’t want a BI tool. They want their metric to move.

The positioning that works: “No IT involvement. No data analyst required. Actionable insights in days, not months.”

That’s not “better BI.” That’s a different customer.

3. Remove the trip entirely

Blockbuster required a trip to the store.

BI requires a trip too: leave workflow → open BI → find dashboard → interpret → export → act somewhere else.

Your wedge is to remove the trip:

• Answers delivered inside the workflow (CRM, support tools, ad platforms)

• Outputs are lists and actions, not charts to interpret

• “Show me who to call” not “show me a visualization”

• Actions triggered automatically when something is true

The positioning that works: “Instead of dashboards and reports, get actionable intelligence where you already work.”

If your user has to “go to BI,” you’ve already lost.

4. Compress time-to-value until the old workflow looks like theatre

Old BI feels like: “It’s in the roadmap.”

Operator-grade systems feel like: “It’s live this week.”

Netflix didn’t just remove late fees—they removed the wait. No more “is it in stock?” No more “drive there and find out.” The DVD showed up.

The moment an operator experiences “answer + action” without a queue, the patience for “please file a ticket” dies fast.

The old world doesn’t lose on features. It loses on speed-to-outcome.

If your first value delivery takes weeks and requires an implementation project, you’re still selling to the old buyer.

5. Scale the unsexy advantage

Netflix’s compounding advantage wasn’t brand. It was operations: distribution centers, inventory flow, logistics. The stuff nobody wanted to copy because it wasn’t glamorous.

Your compounding advantage:

• Operational telemetry (what users actually do, not what dashboards say)

• Feedback loops (did the intervention work?)

• Automation (actions that happen without humans)

• Memory (what the system learns per account, per segment, per workflow)

Every time an operator acts on a recommendation, you learn whether it worked. That’s data Tableau never sees.

That’s how you get a moat that isn’t a model wrapper.

Why ThoughtSpot won’t follow—for now

All incumbents are caught in a dilemma: They see it, and they still can’t see it. Like Fish, they can’t see water. They can only swim.

ThoughtSpot sees the world moving. So they push “agentic BI”—agents that help you build, model, visualize, and distribute faster.

Here’s the problem:

That’s optimizing the existing ritual: analyst workflow → dashboard artifact → distribution.

It’s like Blockbuster launching “an AI that helps employees re-shelve tapes faster.”

Cool. But the customer is leaving the store.

They can’t delete dashboards without deleting what they sell. Same reason Blockbuster couldn’t delete late fees.

Serving operators means dashboards become optional, then irrelevant, then absent.

That’s a business model shift, not a feature release. And business model shifts are exactly what incumbents can’t do.

What to build: direct-access systems, not dashboards for analysts

If the buyer is now “operators who own the metric,” the product has to feel like this:

The system speaks the operator’s language.

Operators speak:

• “Who’s about to churn?”

• “Which segment is slipping?”

• “What changed since last week?”

• “Give me the list.”

• “Fix it.”

Outputs are actions, not charts. The operator wants a list to call, a campaign to pause, a workflow to trigger, a segment to message.

The UI lives where the work lives. Embed in CRM. In support tooling. In ad platforms. In Slack with one-click action.

Default is “no setup.” Dashboards require setup, ownership, maintenance, governance. Operator systems default to: connect → ask → act.

Monday questions

If you’re building in BI-adjacent markets, answer these. No AI buzzwords allowed.

1. Who is the operator who refuses BI—and where do they live all day?

2. What artifact must die for you to win? Dashboard? Report? Ticket?

3. What do you deliver in 7 days with zero translators?

4. What action triggers automatically when the metric slips?

BI isn’t dying because charts are bad.

It’s dying because queues are unacceptable.

Netflix didn’t win by perfecting the store. They won by making the store irrelevant.

Marcus is the Head of AI at a Series B startup. His team spent two months building a RAG system from scraped documentation. Last week, OpenAI released a model that does the same thing out of the box. If you ask him what’s actually defensible about his product now, he’ll stare at the wall in the same Zoom room where he just demo’d it to the board.

I see teams do this every week.

If your advantage is “we built a thing around a model,” you don’t have a moat. Your moat is behavioral data only you can observe. If you don’t you that, you’re toast.

Everything that feels defensible in AI turns into a checkbox fast—fine-tuning, retrieval tricks, prompt scaffolding. Your wrapper gets commoditized. Congrats, you built a feature flag for someone else’s roadmap.

Your behavioral data however doesn’t commoditize. It compounds.

If you only have 5 minutes: here are the key points

• Models aren’t moats: Building around a model is not a sustainable competitive advantage—models get commoditized quickly.

• Your true moat is behavioral data: Specifically, the behavioral signals that emerge only inside your product. These can’t be scraped or replicated.

• Focus on three data streams:

  • Abandonments: Reveal what jobs users gave up on—not just where they dropped off.

  • Retries: Surface where your activation flow breaks or where second chances reveal friction.

  • Workarounds: Point to unmet needs users are solving manually, which are high-signal feature requests.

• Mining behavioral data is manual but crucial: It requires reaching out to real users, watching them use your product, and asking uncomfortable but specific questions.

• Next step? Send tailored emails to churned users, returning users, and power users to uncover real insights that compound into defensible advantages.

The data moat that compounds: behavioral exhaust

What doesn’t get commoditized? Data that only exists inside your product. Behavioral patterns that emerge only when your specific users interact with your specific features.

I’ve watched companies raise entire rounds on this. Not because their model was better—everyone’s model is “better” for about six months—but because they’d accumulated behavioral signal no competitor could replicate. The gap between them and a new entrant wasn’t code. It was thousands of micro-observations about how real users actually behave.

Here’s what I’d look for first. Three specific data streams create this compounding advantage: abandonments, retries, and workarounds. These signals aren’t in your dashboard at all. You have to go mine them, probably by hand.

But as the saying goes, if your hands aren’t dirty, you’re probably already inside the grave.

How to mine it

Abandonments reveal the job your product didn’t complete. Abandonment doesn’t mean “stopped at this well-defined click path.” It means the person abandoned what they wanted to do. A user might complete every click in your flow and still abandon their goal.

Yoodli started as an AI speech coach. Varun Puri and Esha Joshi built features for interview prep, presentation practice, general speaking improvement. Users came. Most evaporated.

Puri and Joshi could have looked at their dashboards and seen standard metrics. Drop-off at step 3. Churn after week 2. The kind of data that tells you something is wrong but not what.

Finding real abandonments is extremely hard. Mining this requires surveys sent to churned users, discovery calls with people who tried once and never came back, uncomfortable conversations where you hear things you don’t want to hear.

What Yoodli discovered: users who came for public speaching practice often abandoned the general speech coaching entirely. They wanted to practice specific conversations—not become better speakers in the abstract.

So they pivoted. Yoodli is now “Yoodli AI Roleplays”—same founders, same technology, focused on what users actually came for. Google uses it to certify 15,000 sales reps. Databricks and Snowflake use it for onboarding.

The data that drove this decision? It couldn’t be bought. It couldn’t be scraped. It existed only in the behavioral patterns of Yoodli’s own users—and extracting it required talking to actual humans, not querying a database.

If you’re thinking “we track churn already”—nope. Different thing. Churn tells you who left. Abandonments tell you what job they gave up on.

Retries show where activation is actually breaking. Retries don’t always look like retries. Sometimes a retry is a user trying your product multiple times across different sessions before it finally clicks. Sometimes it’s the same person downloading the app, using it once, abandoning it, and coming back three weeks later.

Granola makes an AI note-taking app for meetings. But meetings only happen once. A user doesn’t “retry” the same meeting. So where’s the behavioral signal?

What does Granola do? They follow up. Not with automated drip campaigns—with personal emails. When the Granola team notices someone has tried the product twice but hasn’t stuck, someone actually reaches out. “Hey, noticed you gave us another shot. What happened the first time? What made you come back?”

I know this because they did it to me.

Every conversation reveals friction you’d never find otherwise. “The notes were good but I didn’t know how to share them with my team.” “It worked great on Zoom but I couldn’t figure out how to use it on phone calls.” “I loved it but my boss thought it was recording video, which freaked her out.”

Granola raised $40 million at a $250 million valuation. Not because they had better AI—the transcription market is crowded. They raised because they understood their users’ behavior in ways competitors couldn’t access.

Workarounds are feature requests with proof. When I was building a data platform for 700 people at Unite, I noticed a strange pattern: certain dashboards got used constantly, but only briefly. People would open them, glance at something, and close them within seconds.

That’s weird behavior. Dashboards are supposed to be analyzed, not glanced at.

So I asked users directly. “Show me what you do with this data.” Not “describe your workflow”—show me.

When I asked Jana from the procurement team to show me, she shared her screen: open dashboard, export to CSV, close dashboard, open Excel, manipulate data, paste into a completely different system.

The dashboard wasn’t the product. The dashboard was a waypoint to a workaround.

The workaround IS the feature request. Except it comes with proof of demand—someone already built it themselves.

When I discovered the export-to-other-system pattern, I immediately evaluated integrations with those systems. Built them. They became the most successful parts of the data platform.

I would’ve never found this in analytics. There’s no event for “user left our product and did something useful elsewhere.” You only find workarounds by watching.

You’re up now

Next Monday, I want you to email a lot of people.

Not “send a survey.” Not “add a question to onboarding.” Email humans.

Pick 15 people total:

• 5 churned last month

• 5 who tried twice but aren’t active

• 5 power users

Then send these.

1) Churned users (goal-abandonment)

Subject: Quick question

When you signed up, what were you trying to accomplish? Did you accomplish it before you left?

One sentence is perfect.

2) “Tried twice” users (retry signal)

Subject: What changed?

I noticed you gave us another shot. What went wrong the first time—and what made you come back?

If you reply with 2–3 bullets, I’ll owe you one.

3) Power users (workarounds)

Subject: Can you show me your workflow? (10 min)

Can you screenshare your full workflow end-to-end? Everything before and after our product—especially what you do right after you close it.

I’m trying to find the workaround you’ve built so we can turn it into the feature.

Rule: Don’t ask “why did you churn.” Don’t ask “any feedback.” Ask what they were trying to do, and what they did instead.

When replies come in, bucket them into:

1. Missing capability (they needed something you don’t have)

2. Trust/compliance fear (someone else blocked them)

3. Workflow mismatch (your product didn’t fit how they actually work)

The model you’re fine-tuning today will be obsolete in six months. The behavioral data only you can observe compounds forever.

Feel free to DM me if you feel like this isn’t working for you (though I’ll likely tell you that means you’re doing something completely wrong).

Carolin, our CEO, was on stage at our company all-hands, doing the usual leadership cadence: wins, misses, priorities.

Then Nico stood up.

Nico is a sales rep. Not “data-driven” in the way LinkedIn posts mean it. More like… pragmatic. Fast. Impatient. The kind of person who will happily run a business on gut feel, if the alternative is waiting two weeks for a dashboard.

He plugged his laptop in.

On the big screen: a dashboard titled something like “Churn Risk — This Week” (he didn’t workshop the name, obviously). Customers listed row by row. Next to some names: a flashing red “+”.

It was obnoxious.

It was also perfect.

Each flashing red plus meant: this account is about to churn — and right beside it was everything you’d need to do something about it: last order date, ticket volume, product usage collapse, segment tags, owner notes, contract size. Not “insights.” Actionable ammunition.

Carolin squinted at the screen, then turned to me:

“Nico… did you suddenly learn how to code?”

Nico didn’t learn to code.

Nico learned something more dangerous.

He learned that the analytics team is optional.

Because three months earlier, Nico’s workflow looked like this:

Nico: “Can I get a dashboard for accounts likely to churn?”
Analytics: “We’re swamped. Maybe next quarter.”
Nico: goes back to Excel, vibes, and praying.

Now he built it himself in 15 minutes.

Not because he’s a wizard.
Because he did what everyone is doing right now, quietly: he connected a schema to an AI tool and stopped waiting.

And here’s the part nobody wants to say out loud:

If your analytics team’s core function is translating business questions into SQL, dashboards, and recurring reports… you are funding a role whose economic foundation just collapsed.

Not next year.
Not “once governance catches up.”
Already.

So yes — this article is, in practice, a guide for CEOs to do something uncomfortable:

Cut the analytics queue. Keep the judgment. And move on before your board forces you to do it badly.

If you only have 5 minutes: here are the key points

• AI has made traditional analytics queues obsolete: Business users like product managers and sales reps are now using AI tools to answer their own data questions instantly—without waiting on analytics teams.

• 80% of analytics roles are vulnerable: Roles focused on translating questions into SQL and maintaining dashboards are being replaced by AI-powered self-service.

• The elite 20% are more valuable than ever: Analysts who deeply understand the business, use AI fluently, and shape strategic decisions are becoming 10x more impactful.

• Restructure or risk blunt cuts: CEOs and leaders must proactively identify top talent, embed them into business teams, cut queue management layers, and invest in AI tooling.

• The payoff is speed and cost-efficiency: Decision velocity increases dramatically, costs drop, and strategic iteration accelerates—despite some growing pains like metric drift and lost institutional memory.

The analytics queue was never a strategy — it was a patch

The modern analytics team exists because companies had a gap they didn’t know how to bridge.

A decision-maker has a question:
“Which customers are likely to churn?”
“Why did activation drop last week?”
“What changed in retention by cohort?”

But they can’t answer it. Not because they’re stupid. Because answering it used to require:

• knowing where the data lives

• knowing what tables mean

• knowing SQL

• knowing BI tools

• knowing how not to lie to yourself with metrics

So we invented a system: the analytics queue.

And we staffed it with people whose job is basically: translation.

Business question → SQL → chart → interpretation → meeting → decision.

The problem is that translation has an ugly property:

It doesn’t scale.
It creates waiting.
And waiting destroys decisions.

In the old world, that was still tolerable because the alternative was nothing. You couldn’t just hand a PM the database and say “go explore.” They’d break things and then blame you.

So the queue stayed.

And the industry built religion around it: governance, rigor, centralized truth, semantic layers, certified dashboards, KPI catalogs, metrics stores, “single source of truth” decks that are mostly aspirational fiction.

Then AI showed up and did the one thing you weren’t allowed to admit was the majority of the job:

It learned to translate.

AI didn’t kill analytics. It killed analytics middlemen.

Let’s separate two things that companies keep confusing because it’s convenient:

Execution work vs judgment work.

• Execution work is: write SQL, maintain dashboards, rebuild reports, answer tickets, format charts, re-run queries, export CSVs, stitch metrics together, “quick analysis for tomorrow’s meeting,” etc.

• Judgment work is: decide what matters, define metrics that don’t rot, interpret shifts correctly, generate hypotheses, design experiments, call out bullshit, prevent people from optimizing the wrong number, and connect data to business reality.

AI is eating execution work alive.

And it’s doing it in the most humiliating way possible: not by being “better,” but by being fast enough that people stop asking permission.

A PM types:
“Show weekly active users by acquisition channel for users who signed up in Q1.”

They get working SQL.

They paste it into their tool.

They get a chart.

They move on.

No ticket. No queue. No “can you prioritize this.” No analytics standup.

Decision time collapses from 11 days to 90 seconds.

If you’ve ever run a data org, you know what happens next: the official process stays intact on paper, while the real work moves around it.

People don’t announce it. They just… stop filing tickets.

And yes, your analytics team sees it happening.

So they do what humans do when they feel the ground moving under them:

They lean on the sacred language.

“Self-service is dangerous.”
“Without governance we’ll get metric drift.”
“We need statistical rigor.”
“We can’t let people query production.”

All true, by the way. But also a smokescreen.

Because none of those arguments answer the real question:

What are you paying 8 people for if the business can get 80% of the answers on its own?

Most analytics teams are 80% translators and 20% strategists

I ran a BI platform for roughly 700 users.

Brilliant analysts. Technically excellent work. Clean dashboards. Good SQL. Correct joins. Fresh data. Great documentation (for the two people who read it).

We measured the usual things: dashboard adoption, freshness, performance, number of deployed dashboards, number of tickets closed.

Then we asked users what actually helped them.

And 90% of them didn’t open the dashboards.

Not because dashboards were bad.
Because dashboards weren’t the constraint.

Most people don’t need “a dashboard.” They need:

• a decision

• a recommendation

• a sanity check

• a short list of plausible causes

• the confidence to act

Dashboards are built for the 10% who already know what they’re doing and want a monitoring cockpit.

Most organizations keep building for the 10% because it’s measurable, fundable work: “we shipped a dashboard.”

But the real value — the reason you hired analytics in the first place — is the part that isn’t easily counted:

judgment.

So here’s the pattern I keep seeing:

• 80% of the team is doing queue work (translation + delivery)

• 20% of the team is doing judgment work (decision support + strategy)

AI is making the 80% redundant.

And it’s making the 20% terrifyingly powerful.

The best analysts become 10× better not because they write SQL faster, but because they stop spending their attention on execution and spend it on thinking.

That changes what your company should optimize for.

You don’t want more translators.

You want fewer, better judgment holders — embedded close to the decisions — and tools that let everyone else self-serve the routine stuff.

Five questions that expose who you must keep

This is the part CEOs avoid because it feels like “culture.” It’s not culture. It’s cost structure.

If you restructure wrong, you lose the only capability that matters and keep the wrong people because they were busy and visible.

So don’t guess. Use filters.

Here are five questions that separate judgment holders from queue managers.

1) Do they generate hypotheses before touching data?
When conversion drops, do they immediately say:
“Probably onboarding, pricing page, or channel mix,”
or do they ask:
“What exact query do you want me to run?”

2) Is AI invisible in their workflow?
I don’t mean “they tried ChatGPT once.”
I mean: you hand them a messy business question and execution just… happens.
Draft plan. Query. Breakdown. Caveats. Next steps.
No drama. No ceremony.

3) Are they decision-proximate?
Do they sit in product planning? Marketing reviews? Ops postmortems?
Or do they show up at the end with a chart?

If they don’t know what decisions are being made, they’re not analysts. They’re data technicians.

4) Do they define what should be measured?
Do they come back with frameworks: leading vs lagging indicators, segmentation logic, “this metric will be gamed,” “this definition will drift,” “this is noisy”?
Or do they wait to be told what metric you want?

5) Will they tell you you’re wrong?
This is the big one.
You don’t need eight people who agree with you and can format charts.
You need one or two people who can say:
“That’s a comforting story. The data doesn’t support it.”

That’s your elite 20%.

The rest aren’t bad people. They just occupy a role that AI is devouring.

The only restructuring that actually works

There’s one viable path through this shift. And you can’t half-do it.

If you only cut headcount, you’ll create chaos.
If you only buy tools, you’ll keep the same bottleneck with shinier UI.
If you only keep the elites but keep the queue, you’ll never get the leverage.

You need all three moves together.

Move 1: Kill the central analytics queue.
Stop treating “analytics” as a service desk.
The service model creates wait times, and wait times destroy decisions.

Move 2: Concentrate your judgment holders.
Keep 2–3 truly senior analysts (however many you actually have).
Embed them directly into product, marketing, and ops.

Their job is not “answer tickets.”
Their job is: make the organization harder to fool.

They own:

• definitions

• metric integrity

• experiment sanity

• narrative quality

• decision velocity

Move 3: Spend the savings on leverage.
Buy (or build) whatever makes self-service actually work:

• safe query access

• semantic layer where it helps (not religion)

• AI-assisted analytics workflows

• guardrails, templates, reusable patterns

Let the PM type:
“Why did signup-to-activation drop last week?”
…and get a credible first answer in minutes.

Not perfect. Credible.

Then the elite analysts do what only humans with context can do:
stress-test the interpretation, prevent mistakes, and guide the actual decision.

“But what about governance?” Yes. Things break. Here’s the real trade.

Three things improve immediately:

Decision velocity jumps because the queue disappears.
Exploration explodes because asking becomes cheap.
Cost structure flips from linear output to leveraged output.

Now the honest part: three things genuinely get worse if you’re sloppy.

Metric definition drift.
Marketing calls “activation” one thing. Product calls it another. Six months later you’re arguing about whether activation is up or down, and everyone is technically correct.

Statistical rigor decay.
Someone runs an A/B test on 47 users and declares a 12% lift. Congrats — you invented noise-driven strategy.

Institutional memory loss.
The analyst who remembers why Q3 2019 looked weird is gone. Now you spend hours rediscovering something that used to take 30 seconds to explain.

So no, I’m not selling a utopia.

I’m saying something more annoying:

These risks are easier to manage with 2 elite analysts than with 8 mixed-capability ones.

Because mixed teams create a false sense of safety.
And the queue creates a false sense of rigor.

The elites catch drift because they know which definitions matter and why.
They catch statistical stupidity because they understand business mechanics.
They preserve institutional memory by being embedded where it’s used, not stored in dashboards nobody opens.

Your board is going to ask why you’re paying for an 11-day answer

Here’s what will happen over the next 12–24 months in most companies:

• The business will quietly self-serve routine analysis.

• The queue will get slower because ticket volume drops but complexity rises.

• The analytics team will defend itself with governance rhetoric.

• The board will notice the cost and ask why decision velocity still sucks.

If you wait, you don’t get a careful restructure.

You get a blunt cut:
“Reduce G&A by 30%.”

And blunt cuts destroy the only thing you needed: judgment.

So if you’re a CEO, the correct move is not “fire analytics.”

The correct move is:

Fire the queue model.
Keep the judgment.
Build leverage.

That’s how you get the same strategic capability with triple the speed and half the cost.

Questions to answer on Monday morning

No philosophy. Just look.

1) What percentage of analytics requests are basically “build me a dashboard showing X”?
If it’s more than 50%, you’re paying for translation.

2) Which dashboards from last quarter are still opened weekly?
If fewer than ~30%, you’re building artifacts, not decisions.

3) Who can produce three plausible hypotheses before touching data?
That number is roughly how many analysts you actually need.

4) Who in product/marketing has stopped filing tickets?
Those are your “Nicos.” The shift is already underway.

5) If your analytics team vanished tomorrow, what would truly break?
Not what would be annoying. What would be strategically dangerous.

Write the answers down.
Then restructure deliberately — before someone else forces you to do it badly.

Data engineers should be at the core of your AI team. Not supporting them. Not “helping with infrastructure.” Core team members, from day one, with equal authority. The AI industry got this backwards. Your product breaks on production data that looks nothing like your test set. Deployments take down the system. Your AI team stares at throughput issues they can’t diagnose. Something’s wrong with how the industry structures these teams. Your AI product processes terabytes of novel data every week—from users, from production, from contexts your test set never imagined. And you’re handling it without experts who know how to build systems that process data at scale without breaking. This is the AI-First Trap: optimizing for what AI conferences celebrate while your product breaks on what they ignore.

If you only have 5 minutes: here are the key points

• AI teams today lack production-grade data expertise. Most AI engineers are strong in model development and software deployment—but not in handling real-world, evolving, large-scale data.

• Data engineers should be core team members, not support. They must be involved from day one with equal authority and decision-making power.

• Vendors oversold abstraction. Platforms like Databricks and Snowflake convinced companies they could skip hiring data specialists. This created fragile AI systems prone to data-related failures.

• The real failures aren’t in models—they’re in data pipelines. Systems break due to scale issues, invalid inputs, schema drift, and lack of monitoring—issues AI engineers are often untrained to handle.

• The best AI teams think like data engineers. Teams that built data infrastructure early on tend to have stable, scalable AI products.

• Hire for war stories, not tech stacks. Look for data engineers who’ve debugged real failures, not those focused only on frameworks or architecture diagrams.

Data platforms sold the tools, not the expertise you need

The data platform vendors created this disaster. They made billions convincing companies to skip the people who knew how to handle production data.

Here’s what they promised:

• Databricks: “Lakehouse architecture eliminates data engineering complexity”

• Snowflake: “Zero management data warehouse - no specialists required”

• Azure: “Serverless data processing - focus on insights, not infrastructure”

• Supabase: “Backend as a service - ship products, not infrastructure”

Every vendor pitched the same fantasy: our platform abstracts the complexity, you just focus on models. Data engineering became the bottleneck everyone learned to route around. Too slow, too bureaucratic, blocking shipping. AI teams waited weeks for infrastructure that should take days. Executives watched competitors ship faster and demanded speed. The vendors provided an answer: skip the specialists, use our platform, move fast.

The result: an entire generation of AI engineers—software engineers who learned machine learning—exceptionally skilled at building production services but completely unprepared for production data pipelines. They can deploy services at scale but have never built systems that handle data drift. They can handle 10K requests per second but have no framework for validating terabytes of constantly evolving input data. They know production software engineering but not production data engineering.

The platforms handle storage and compute brilliantly. But they don’t solve the unique challenges of production data: schema evolution, validation at terabyte scale, handling the infinite varieties of brokenness that real-world data exhibits. The vendors sold the tools. They didn’t sell the expertise.

LinkedIn hiring followed. “AI Engineer” roles exploded—software engineers with ML skills. “Data Engineer” roles disappeared from startup job boards or appeared as support roles—infrastructure team, reporting to engineering, helping when needed.

You kept hiring for model optimization and production software skills. Your product kept breaking on production data challenges. The AI-First Trap in action.

Here’s what actually breaks:

Failure 1: Your product goes down when data volume increases

Your model works on the test set. You deploy. Traffic increases 3x. The pipeline breaks. Your product goes down.

Your AI team can’t diagnose throughput issues in the data pipeline. They know how to scale services—add instances, load balance, optimize APIs. But they never learned to design data pipelines that scale on unknown input data. They optimized models on carefully curated datasets sized for laptop memory. When production data grows, the pipeline can’t handle the load.

They try adding compute. Increase batch size. Parallelize where they can. The problem persists because it’s not a compute problem—it’s data architecture. The schema doesn’t partition efficiently. The transformation logic doesn’t stream. The validation creates backpressure.

A data engineer sees this in minutes. They’ve built dozens of pipelines that process terabytes. They know which operations scale and which create bottlenecks. They design for 10x growth from day one because they’ve watched systems collapse under success.

Failure 2: Bad input data crashes your product

A null where the model expects a value. A string where it expects a number. An out-of-range value that breaks an assumption. Production incident.

Your AI team never built validation layers for production data. They know how to validate API inputs—type checking, bounds checking, standard software validation. But production data validation is different. User data evolves. Schemas drift. New edge cases appear constantly that no test suite anticipated.

Every edge case is a surprise. Every surprise is a production incident. They patch reactively—handle this null, catch that exception, wrap that transformation. The codebase becomes spaghetti.

A data engineer builds validation infrastructure from day one. Schema contracts that reject malformed data before it touches the model. Sanity checks at ingestion. Monitoring that alerts when distributions shift. They’ve seen every way data can break.

Failure 3: Every deployment is Russian roulette

Thirty percent of your deployments break something. You find out when customers complain.

Your AI team has no staging infrastructure for data systems. They know how to deploy services—blue-green, canary, rollback strategies. But they deploy models to production and pray the data behaves like test sets. It never does.

Data engineers build shadow mode, staged rollouts, automatic rollback on data regression. They’ve seen enough disasters to never deploy without it.

The infrastructure-first trap: When data engineers become the bottleneck

Not all data engineers think production-first. Some will want 6 months to spend on architecture diagrams before shipping anything to customers. That’s the Infrastructure-First Trap—same disease as the AI-First Trap, different job title.

This is why executives learned to route around data engineers in the first place.

The production-first data engineer operates differently. They ship to production on week one with three critical pieces: basic validation, monitoring that alerts on data anomalies, and staged rollout infrastructure. Not perfect. Just enough to catch problems before customers see them. Then they add infrastructure as they learn what actually breaks in production.

Infrastructure-first data engineers want to build for imagined problems. Production-first data engineers build for problems they’ve actually seen destroy systems. You want the latter.

I Thought Unite’s ML engineers were normal

You know what’s funny? When I first arrived at Unite, I thought the ML engineers were like every other ML team I’d seen. Five engineers building production ML systems for thousands of customers, interfacing with lots of other teams. They shipped constantly. Systems just ran. No weekly production incidents. No emergency debugging sessions. Everything nicely integrated into production-grade infrastructure.

Only later did I realize this ISN’T normal.

Why? Their upbringing was different.

They joined when there wasn’t enough ML work. So they spent their first year making production ETL work for 700 people—handling real data failures, debugging data pipelines at 3am, learning what breaks data systems under load. Messy data from dozens of sources. Learning to validate systematically instead of reactively. Learning to deploy data pipelines without gambling.

By the time they moved to ML work (in which some of them had a PhD!), they thought like data engineers who happened to build models. They designed for data scale from day one. They built validation layers before first deployment. They set up staging and monitoring infrastructure for data pipelines. They treated data quality as foundational, not optional.

The AI industry would call their first year wasted—no papers, no models, just boring data infrastructure. That “wasted” year is why their products never broke while everyone else’s did. The industry measures the wrong thing.

Hire data engineers as equals with veto power

Your product breaks every week. Stop hiring more AI engineers.

You know where production-first data engineers come from? They have battle scars.

Put them at the core from day one. Not as support. As equals designing the system alongside AI engineers. They own data architecture, validation infrastructure, deployment pipelines, monitoring. They’re in every design discussion. They have veto power over approaches that won’t scale with production data.

Your interview should test for war stories, not theory:

Question 1: “Walk me through a production data pipeline failure. What broke? How did you find it? What did you build to prevent it happening again?”

Question 2: “I’m about to deploy a model that processes 100K events per second. Our validation currently runs synchronously. What breaks first and what’s your fix?”

Question 3: “Describe a time you prevented a production failure before it happened.”

Red Flags:

• Wants to spend a month on architecture diagrams before shipping anything

• Resume emphasizes technologies and frameworks over production systems

• Can’t describe specific production failures they prevented

• Asks about your tech stack before asking about your data volume

Green Flags:

• Tells you about debugging pipeline failures at 3am with specific details about what broke and why

• Describes data pipeline failures in terms of customer impact

• Asks about your production data volume and growth rate first

• Can explain schema evolution strategy for your specific use case

The data engineer should be employee 3-5, not employee 15. By the time you realize you need them, you’ve already accumulated technical debt that takes 6 months to unwind. Hire them when you’re building the foundation, not after it’s already broken.

Stop optimizing for benchmarks

The AI-First Trap is measuring success by model performance while customers leave due to data failures.

You can keep hiring for what the industry celebrates—model optimization, production software engineering, API design. Your product will keep breaking every week on data problems.

Or you can put data engineers at the core. Build infrastructure that handles production data at scale without breaking. Design validation that catches data problems systematically. Create deployment practices for data pipelines that don’t gamble on customer surprises.

The AI industry celebrates what gets you conference talks. Your product breaks on what they ignore. Stop hiring for benchmarks. Start hiring for production.

Data engineers at the core, from day one. Or keep wondering why your product breaks every week.

In 2006, Amazon wasn’t a cloud company. They were a retailer with a massive infrastructure problem — and Jeff Bezos saw something that would become a trillion-dollar insight.

Every team at Amazon was building their own infrastructure. Their own servers. Their own storage. Their own compute. It was expensive, slow, and stupid. So Bezos mandated a different approach: standardize the interfaces, make everything swappable, let teams pick the best tool for each job.

Don’t build a power plant. Build a grid.

AWS became the grid. Any compute, any storage, any database — plug it in, swap it out, upgrade without rebuilding. When better services launched, every AWS customer got access instantly. The grid compounds because it absorbs every improvement from everywhere.

OpenAI is the anti-AWS, for themselves at least.

Two hundred million users, and they’re locked into a power plant. When Claude improves, ChatGPT users can’t access it. When DeepSeek proves you can match frontier performance at a fraction of the cost, ChatGPT users can’t access it. OpenAI is trapped by OpenAI.

Sam Altman warned founders in 2024: “If you’re just wrapping GPT-4, we’re going to steamroll you.” He was right. But he missed the bigger picture: OpenAI is wrapping GPT too. They just wrapped their own model.

Vertical integration feels like a moat until the market moves faster than you can. Then it’s a prison.

The AI products that survive won’t have the best features. They’ll have model-agnostic architecture — the same architecture that made AWS dominant. Here’s three principles that will work. Bezos proved them. Apply them or get steamrolled.

If you only have 5 minutes: here are the key points

• OpenAI has a “wrapper problem” too: Despite Sam Altman’s warning to founders not to just wrap GPT-4, OpenAI itself has wrapped its own model — locking users into one model, one set of guardrails, one pricing structure.

• AWS vs. OpenAI: AWS won by building a model-agnostic infrastructure — the “grid” — letting users swap in better tools instantly. OpenAI, by contrast, is a vertically integrated “power plant” that can’t absorb external breakthroughs.

• The grid compounds AI progress: Model-agnostic products capture 100% of frontier improvements from all labs, while locked-in stacks get only a fraction. The gap compounds fast.

• Three-layer architecture that survives every model drop:

  1. Socket Layer – Standardize interfaces so switching models is a config change, not a rewrite.

  2. Routing Layer – Automatically select the best model per task; users shouldn’t have to choose.

  3. Replaceability Layer – Make every component (models, vector stores, safety layers) swappable to prevent vendor lock-in.

• Moral of the story: Don’t build your stack around any single model provider. Build (or plug into) the grid — it’s the only structure that scales with AI’s pace.

OpenAI trapped 200 million users inside their own moat

The screenshot test feels brutal: take your product’s input/output, paste it into the newest foundation model, see how close the raw model gets to your value. Is it even better?

Example: Granola is an amazing meeting notes app, but transcripts are pretty easy to get nowadays. Go try it out, take a look at your granola notes from a meeting, copy the transcript + a screenshot of the video meeting and paste all of it into ChatGPT (of course in a privacy preserving way!) and tell ChatGPT to write “Granola style” meeting notes. ⇒ That’s what a potential wrapper problem looks like (which is sad because I do think the CEO of Granola is a top strategic thinker on exactly this topic!)

Thank you, ChatGPT, now that’s a reason to feel absolutely destroyed today…

If the answer is “uncomfortably close,” you have a wrapper problem. But OpenAI has a wrapper problem too. They wrapped their own model (very thinly!) and called it a product.

Think about what happens when Claude 4 drops with better reasoning. Or when Gemini ships superior code generation. Or when the next open-source model matches GPT-4 at 1/10th the cost.

AWS customers get access to whatever’s best. That’s the whole point — the grid doesn’t care who produces the electricity. It just delivers the best available power to whoever needs it.

OpenAI customers get GPT. Period. OpenAI’s improvements only. OpenAI’s guardrails only. OpenAI’s pricing only.

This is vertical integration’s trap. It feels like control — we own the whole stack! — until the stack starts losing to competitors you can’t absorb.

The datacenter companies learned this in the 2000s. They built their own infrastructure, which felt powerful until AWS customers could tap into whatever was best at any moment. When better hardware appeared, AWS customers got it. Datacenter owners waited years for their next refresh cycle.

Same dynamic, different decade. When better models appear, model-agnostic products get them. OpenAI waits for their next training run.

Model-agnostic gets 100% of all AI progress — locked-in gets 20%

Here’s the math that should terrify every vertically integrated AI company.

If you’re locked into one model provider, you get 100% of their improvements and 0% of everyone else’s. Five major frontier labs now. You’re capturing maybe 20% of total AI progress.

If you’re model-agnostic — if you’re a grid — you get 100% of all improvements. Every lab’s breakthroughs become your breakthroughs. The gap compounds with every release cycle.

AWS understood this from day one. When Lambda launched, every AWS customer could use serverless compute immediately. When Aurora launched, every customer got access to a better database. AWS didn’t build all these services to be generous — they built them because the grid that offers the most options wins.

Now apply that to AI.

When Anthropic improves Claude’s reasoning, model-agnostic products route reasoning-heavy queries to Claude. Their users get better answers. OpenAI users get nothing.

When DeepSeek proves frontier performance is possible at 1/10th the cost, model-agnostic products cut their API spend overnight. OpenAI users keep paying full price.

When the next breakthrough happens — wherever it happens — grids absorb it instantly. Power plants wait and hope their internal R&D catches up.

The compounding gap only widens. More labs reaching frontier capability. Release cycles accelerating. The tax for being locked into a single provider gets more expensive every quarter.

You can’t out-feature this gap. You have to out-architecture it.

1. The Socket Layer: Standardize interfaces so model switches become config changes

AWS won because every service speaks the same language.

S3’s API is S3’s API. The underlying storage infrastructure has changed a dozen times since 2006. Customers don’t care. They never rewrote a line of code. The interface stayed stable while the implementation improved.

This is the socket layer principle: standardize the interface, not the implementation.

Your AI stack needs the same. A unified abstraction that every model plugs into. No GPT-specific prompt formats in your business logic. No Claude-specific schemas in your codebase. No Gemini-specific function calling syntax anywhere near your application layer.

Everything goes through the socket.

Thing is, sockets are actually hard to build. OpenAI have already built very different APIs. Even the functionality of the models are very different. Meaning you’ll have to put in extra work to make it work (but that’s why it will turn into a moat!).

When a new model drops, you add a translator to your socket layer. Your business logic never changes. Your prompts don’t get rewritten. Your application doesn’t know or care which model is generating the response.

AWS didn’t ask you to rewrite your application when they upgraded their hardware. Your AI stack shouldn’t ask you to rewrite prompts when you switch models.

Without a socket layer, every model switch is a rewrite. With it, every model switch is a config change.

That’s the difference between the grid and the power plant.

2. The Routing Layer: Stop making users pick models — they’ll pick wrong 85% of the time

AWS doesn’t force you to use one database.

Need key-value storage? DynamoDB. Need relational queries? RDS. Need high-performance analytics? Redshift. The platform offers options. You pick the best tool for each job.

More importantly: you don’t have to become an infrastructure expert. AWS provides enough guidance that a developer can make reasonable choices without understanding the internals of every service.

Your AI stack needs the same principle: automatic selection of the best model for each query.

I learned this the hard way at MAIA.

When we launched, we gave users a choice between GPT-4, Claude, and Gemini. Felt like good UX — give people control. Then I looked at the data: only 15% of users picked the best-performing model for their specific queries. The other 85% stuck with whatever default they’d set months ago, even when a different model would handle their question dramatically better.

We removed the choice. Made the system pick automatically.

Success rate jumped from 15% to 95%. Three persistent customer complaints vanished overnight — not because we retrained anything, but because we stopped making mechanical engineers become AI model experts.

The override rate now? Under 5%. And falling.

That’s not users losing control. That’s users trusting the system because it makes better decisions than they would.

AWS figured this out years ago. They don’t expect every developer to understand the tradeoffs between io1 and gp3 EBS volumes. They provide sensible defaults and let the platform optimize. The best infrastructure disappears. You just get results.

Your AI routing layer should do the same. Users don’t want to choose models. They want correct answers.

3. The Replaceability Layer: If your vendor died tomorrow, recovery should take hours not months

AWS services come and go. You can swap.

SimpleDB gave way to DynamoDB. Classic load balancers gave way to application load balancers. Old instance types get deprecated, new ones launch. The ecosystem evolves constantly.

But AWS customers don’t rebuild their applications every time. They migrate. They swap. They upgrade. Because AWS designed for replaceability from day one — no single service becomes an architectural dependency that can’t be changed.

Your AI stack needs the same principle: every component hot-swappable.

Not just the language model. Everything.

Embeddings. If you’ve hardcoded OpenAI’s embedding model into your retrieval system, you can’t switch when a better embedding model drops. Abstract the interface. When Cohere or Voyage releases something better, you should be able to switch in an afternoon.

Vector stores. Pinecone today, Qdrant tomorrow. Your application logic shouldn’t know which one it’s talking to.

Safety layers. If you’ve baked OpenAI’s content filtering into your pipeline, you’re locked into their moderation decisions. Abstract it. Make it swappable.

The test is simple: if [vendor] disappeared tomorrow, how long would it take you to recover?

If the answer is “months,” you have architectural dependencies that will eventually become liabilities. Every dependency you can’t swap is a bet that this vendor will always be the best option. That bet gets worse every quarter as the market evolves.

AWS never bets on a single vendor — including themselves. They offer multiple options for almost every category. They know lock-in is a trap, even when it’s their own lock-in.

Build your AI stack the same way. Every component replaceable. Every vendor swappable. Every model expendable.

The grid wins, so bet on the grid.

Bezos figured this out in 2006.

Don’t build a power plant. Build a grid - or plug into it. The grid absorbs every improvement from everywhere. The grid compounds. The grid survives.

OpenAI built the world’s most impressive power plant — and locked two hundred million users inside it. When the next breakthrough comes from Anthropic or Google or DeepSeek or a lab that doesn’t exist yet, those users are stuck. They’ll watch the grid customers absorb the improvement instantly while they wait for OpenAI to catch up.

Your product will face the same test.

Every model drop, the screenshot test gets harder. Every release cycle, the gap between “your carefully designed product” and “paste this into the new model” gets smaller. You can’t out-feature that gap. It compounds too fast.

But you can out-architecture it.

Socket layer: standardize the interface, swap models freely. Routing layer: let the system choose the best model for each job. Replaceability layer: every component hot-swappable, every vendor expendable.

That’s the grid. That’s what Bezos built. That’s what made AWS a trillion-dollar business.

OpenAI is the anti-AWS. Vertical integration. One model. Their stack or nothing.

Tap into the grid instead.

What happened here?

Just the regular ;) Analytics leaders still trying to convince everyone they won’t become obsolete.

Meanwhile, smart analysts and analytics engineers start to change their own marketing (which might look something like this on LinkedIn, good example from the ThDPTh reader Prashant):

Dive deeper:

• You don’t have 47 data problems. You have one.

• I stopped hiring analysts. You should too (unless you are one).

• AI isn’t the tool (it’s just an ingredient)

• Why smart companies waste millions on ‘proprietary data’

The dashboard shows 47 alerts. The lineage graph shows 200 dependencies. You’re still grabbing duct tape.

Six months ago, you bought the observability tool. Monte Carlo, Metaplane, Bigeye—doesn’t matter which. The pitch was compelling: visibility into your data pipelines. Know when things break before stakeholders complain. Finally get ahead of the firefighting.

Now you have visibility. You can see exactly how broken everything is. The alerts ping Slack at 6 AM. You fix three issues before standup. Four more appear by lunch. Everything looks equally urgent. Everything looks equally broken.

I’ve been on both sides of this. Bought the tools. Watched the alerts multiply. Then found the actual fix—and it wasn’t more dashboards.

Here’s what the observability industry won’t tell you: the dashboard is telling the truth, and that’s the problem.

You don’t have 47 problems. You have one. The other 46 are quality matching—your entire system adjusting to operate at bottleneck speed, creating the illusion that everything is equally strained. Observability tools show you the illusion in high definition. They’re not built to show you the constraint.

They never will be. Their business model depends on more alerts, not fewer.

⏱️ If you only have 5 minutes: here are the key points

• You don’t have 47 separate data problems—just one true bottleneck. The rest are symptoms, amplified by system-wide quality matching.

• Observability tools amplify noise. They show real symptoms but can’t identify the root constraint causing them.

• Stop asking “what’s broken?” and start asking “what breaks first under stress?” Use the volume, velocity, variety framework to stress-test your system.

• Trace alerts back to convergence points. That’s where the bottleneck lives.

• Fix the constraint, and the 46 echoes disappear. One fix often resolves the cascade.

• Cancel the dashboard if it’s not driving action. Instead, invest engineer time in mapping and fixing the system architecture.

Quality matching: why your gut was right all along

You’ve suspected this for months. Every time you fix an alert, two more appear. The dashboard never gets greener. The firefighting never stops. Something feels wrong about the whole approach.

Your gut is right. Here’s why.

When a system has one true bottleneck, every other component adjusts to match it. Upstream processes slow down—no point producing faster than the bottleneck can consume. Downstream processes degrade—they’re starved of quality input. The whole system synchronizes to the weakest link.

This creates a brutal illusion. You look at your platform and see twenty things failing. But they’re not separate failures. They’re one failure, echoing.

Observability tools can’t tell the difference. They show you every symptom in real-time. They generate 47 alerts because technically, 47 things are below threshold. What they can’t show you is that 46 of those alerts vanish when you fix the one that matters.

This is why the tools feel useless. Not because they’re lying. Because they’re telling you the truth about symptoms while hiding the disease. You’re not bad at using them. They’re bad at solving the actual problem.

Every data leader I know who bought observability tools and still drowns in alerts has the same quiet suspicion: this isn’t working. They’re right. It was never going to work. The architecture of the solution is misaligned with the structure of the problem.

What actually works

When I took over the data team at Mercateo, the data platform was drowning. The company moved from a monolith to microservices, and suddenly the data team had 20+ sources to ingest instead of one. The symptoms were everywhere:

• Lead times to add new data sources: exploding

• Lead times to create reports and dashboards: exploding

• Data quality across the system: declining

We could have bought observability tools and watched the decline in 4K. And guess what, we did. We implemented tracking, tracing, lineage, everything we needed to. Took us months of development time only to confirm: Stakeholders still are very unhappy. Only to send us fire fighting every single day.

So then, we asked a different question.

Not “what’s broken?” but “what breaks first when we stress it?”

We stress-tested three dimensions. Could we handle 10x more volume? Yes—the warehouse scaled fine. Could we handle 10x more velocity? Yes—latency wasn’t the issue. Could we handle 10x more variety—new sources, new schemas, new domains?

The system collapsed. In hindsight, obvious, but not at all when you’re in fire fighting mode.

Our legacy ETL architecture couldn’t adapt. Little testing. No CI integration. Every improvement meant fighting the system itself. So improvements didn’t happen. Quality degraded everywhere. Lead times expanded everywhere. Everything matched the bottleneck.

One constraint. One fix—migrate to ELT with dbt and CI/CD.

Data failures dropped by a factor of 10.

Not because we triaged better. Not because we had better visibility. Because we found the one thing that was actually broken and fixed it. The 46 other “problems” were never problems. They were echoes.

The three-fold test

Observability asks “what’s broken?” Wrong question.

The right question: “what breaks first when you stress it?”

Volume, variety, velocity.

• Can your system handle 10x more data of the same type?

• Can it handle 10x more diverse data—new sources, new schemas?

• Can it handle the same data 10x faster?

Whichever dimension breaks first is your constraint. Everything else is quality matching.

Trace your noisiest alerts backward. Don’t fix them—map them. Somewhere, those alert paths converge. A transformation layer. An ingestion bottleneck. A legacy system choking on schema changes. That convergence point is where you apply the stress test.

Two hours with a whiteboard will tell you more than two years with a dashboard.

Cancel the dashboard

Let’s talk about incentives.

Monte Carlo’s business model depends on you having alerts to monitor. Metaplane profits when your lineage graph is complex. Bigeye wants you to set more data quality rules so you get more alerts so you need more Bigeye.

No observability vendor will ever ship “find the one constraint and make 46 alerts disappear.” That’s the opposite of their retention strategy. Their product gets more valuable when your system gets more broken.

Do you think when we migrated our system the first thing we did was to fire up the observability again? No, because we already had found the bottle neck! We could get back to delivering business value, fast.

They’re selling you a flashlight to watch the flood. What you need is a pump.

The $50k alternative. Cancel the subscription. Take one data engineer off the alert treadmill. Give them 30 days to do nothing but find bottlenecks.

Not triaging alerts. Not building dashboards. Not responding to Slack pings. Just finding the constraint.

Map the system. Apply the three-fold stress test. Find where the paths converge. Fix it or build the case to fix it.

One engineer focused on the actual problem will resolve more in 30 days than two years of dashboard-watching.

The math

Here’s what nobody in the observability industry wants you to calculate:

At Mercateo, before we found the constraint, our data team was spending at least 10 hours a week on firefighting. That’s 500 hours a year. Add the tool cost. Add the cognitive drain. Add the slow bleed of morale when the dashboard never turns green.

We were spending six figures annually to manage symptoms.

The architectural fix took effort. It wasn’t free. But it was one thing. And when it was done, it was done. The failures didn’t drop by 10% and creep back up. They dropped by 90% and stayed down.

That’s the difference between treating symptoms and curing disease.

The observability industry built its business on a simple premise: if you can see the problem, you can fix the problem.

That’s just plain wrong, you have to see the right problem, and observability, tracing, lineage isn’t bringing you closer to that.

Seeing 47 problems doesn’t help when you have one problem generating 46 echoes. Visibility into a quality-matched system isn’t insight—it’s noise at higher resolution.

Your gut knew this. Every time you cleared an alert and felt nothing change. Every time the dashboard stayed amber. Every time you wondered if the tool was actually helping or just making the chaos more visible.

You were right to doubt.

Now stop watching the flood and find the pump.

I stopped hiring analysts six months ago.

You should too (unless you are one).

Other companies will.

If you’re an analyst or lead an analytics team, act now or disappear.

It doesn’t matter what you defend anymore. Tool skills, business context, strategic partnership—watch what hiring managers do, not what analysts say.

Last quarter I was planning to hire a senior analyst at $120K. Someone who would “be a business partner,” “ask the right questions,” “provide strategic context.”

Last month I needed to understand why user activation was dropping. I opened Claude, connected it to our database, and started exploring.

Three hours later I had the answer.

I deleted the position that week.

It’s here.

The defense everyone is making

Every analyst knows AI can write SQL and build dashboards. So the defense shifted: “We provide business context. We ask the right questions. We’re business partners. We empower you to use AI. We use AI!”

It’s the consensus defense now. LinkedIn is full of it.

Excel made you faster. Tableau made you faster. AI makes you unnecessary.

Electricity didn’t make gas lamp maintenance faster. It eliminated gas lamps.

You’re the gas lamp expert.

What changed

I wasn’t using AI to help me analyze. I was analyzing while AI did what analysts do.

My context + AI = analyst.

The business context didn’t protect the role. It just made me the analyst.

Picture the room

A room with 100 analysts in 2025—junior, senior, “analytics engineers,” all levels.

The same room in 2027: 20 people are still there as analysts, managing 3x the analytical output.

The other 80 are gone.

Demand for analytic tasks: 3x. Analyst headcount: 0.2x. The gap is AI.

20% moved to pure judgment layer—they’re not doing analysis, they’re deciding what matters.

30% pivoted early to adjacent roles before the market forced them.

50% are still doing what you’re doing right now.

You’re in that room. You’re in one of those groups.

You don’t want to be on those 50%.

Your window is closing

Right now you’re choosing from strength. You have a job. You have leverage. You can explore options.

In 18 months you’ll be competing with hundreds of other displaced analysts for roles that don’t exist.

20% moved up. 30% moved out. 50% stayed.

The window is closing.

50% will keep making the “business partner” defense while the room empties.

The alarm is going off.

You’re hitting snooze.