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.

Between March and December 2024, companies appointed Chief AI Officers at record pace. A 70% increase year-over-year, according to Altrata’s analysis of 35,000 companies. Eli Lilly in October. Boeing in March. PwC US in July. Pfizer in August. The entire U.S. federal government created approximately 100 Chief AI Officer positions in May alone.

The LinkedIn posts are all excitement. Boards are “committed to AI-driven transformation.” Companies are “investing in AI leadership at the highest levels.”

Watch the actual conversations:

“What’s your Chief AI Officer working on?”

“Developing our AI strategy.”

“What’s the strategy for?”

“To guide our AI initiatives.”

“What initiatives?”

“The ones we’ll start once we have the strategy.”

It’s a circle of nothing. A corporate ouroboros eating its own tail. Companies organizing around an ingredient instead of building actual tools.

I know that excitement. I know those conversations.

10 months earlier, I was writing those exact LinkedIn posts. “AI trends for industrial companies.“ “How AI is transforming manufacturing.”

I’d spent months on that campaign. Built audience segments. Written dozens of posts. Had a whole project planned to scale it up.

I was falling for it. Completely.

Then one sixty-minute customer call destroyed everything I thought I knew.

If you only have 5 minutes: here are the key points

• Companies are hiring Chief AI Officers at record rates—but often without a clear problem to solve.

• Many organizations are caught in circular logic: building AI strategies to guide future initiatives that don’t yet exist.

• The author shares a turning point: a customer call revealed that AI prompting frameworks fail in domains with deep, tacit knowledge.

• Real value comes not from AI hype but from solving specific problems—like retaining institutional knowledge before experts retire.

• Historical parallels (e.g. the Chief Data Officer wave) show that organizing around technology instead of tools leads to confusion and churn.

• The right question isn’t “How can AI help?”—it’s “What’s our biggest bottleneck, even if AI didn’t exist?”

• Start with the problem. Build the system. Then use AI to enhance it—not define it.

I was on a video call with a customer who needed help with prompting. Standard Tuesday afternoon—him in his home office with engineering drawings tacked to the wall behind him, me trying to teach best practices. Context, clarity, structure. The COSTAR framework (simplified).

I’m Head of Product at MAIA—a knowledge management platform—and I still am sporadically doing customer support sessions myself. Teaching people how to get better results from AI.

This customer wanted specific information about his engineering process. I said what I always said: “You need to give it more context. Like... how would you describe your day-to-day to someone new to your job? Walk me through an average day. Pretend I know nothing.”

He leaned forward, adjusted his reading glasses, and started talking. Slowly at first, then faster as he got into it.

Twenty minutes in, he was explaining why a decision made in 2009 about vendor relationships still affected their material selection.

Forty minutes in, he was walking me through failure modes that only happened when three specific conditions aligned—conditions discovered through six months of testing.

Sixty minutes in, I knew more about engineering complex plastic parts than I ever wanted to. The tolerances. The material properties. The failure modes. The testing protocols. The regulatory requirements. The institutional knowledge about why certain arbitrary-seeming numbers weren’t arbitrary at all.

My cursor was still blinking in the prompt window. We hadn’t even started.

That’s when it hit me—that sick feeling in your stomach when you realize this isn’t going to work.

The context needed here was massive. Years of accumulated knowledge, dozens of edge cases, hundreds of tiny decisions that only made sense if you knew the history. COSTAR and all these prompting frameworks? They don’t scale for domain experts.

Our users don’t need better prompting skills.

They need less “AI” and more “solve my problem.”

I sat there after the call, staring at my other monitor. My LinkedIn campaign dashboard was open. “AI trends for industrial companies”—scheduled posts stretching weeks into the future.

I highlighted everything.

Then I killed it. All of it.

It’s no fun

Except killing it wasn’t the end. It was the beginning of months of hard work and discipline.

That LinkedIn campaign I deleted? It was my most successful content ever. “Love the shit you’re posting here” - I got that comment weekly from our exact ICP. Engagement up 340%.

And I was about to destroy it all because of one sixty-minute phone call.

“We need to stop saying AI,” I told our sales team the next Monday.

Silence.

“But that’s what they’re asking for.”

“I know.”

“That’s what’s working.”

“I know.”

A sales rep looked at me like I’d suggested we stop accepting money.

It took three months to convince marketing. Two months to scrub “AI-powered” from our public roadmap and replace it with “enterprise knowledge management.”

My LinkedIn views dropped 40% in month one.

But then we started developing the alternative. Webinars on product management in industrial companies. Content about knowledge retention. Specific, unsexy, real problems.

The fog cleared.

Focusing on the actual problem forced clarity. It took weeks, but we finally nailed down our exact product principles. Not “democratizing intelligence” but concrete decisions: We capture institutional knowledge. We make it retrievable when people leave. We integrate with existing workflows. (If you’re curious, I believe in transparency)

The product roadmap became obvious. Sales conversations are getting shorter but deeper. Customers who reached out actually need what we built.

The weird part? While I was deleting my AI campaigns, everyone else was doubling down on theirs.

The appointments kept rolling in. The Harvard Business Review publishing thought leadership about “AI transformation.” McKinsey releasing frameworks for “AI maturity models.”

Everyone copying the same playbook. Everyone organizing around the technology.

I’d find myself in these conversations at conferences, on sales calls, in Slack communities. They all sounded the same. The same circular logic, the same empty strategies, the same confusion dressed up as innovation.

“We’re building our AI capabilities.”

“What capabilities specifically?”

“You know, AI-driven insights.”

“Insights about what?”

“That’s what we’re exploring.”

We’ve seen this before

In 1990, Signet Bank (later Capital One) made a massive investment. They turned their credit department into a laboratory. Richard Fairbanks and Nigel Morris tested different credit terms on different customer profiles. For years. The department “lost money.”

But they weren’t losing money. They were building a decision system.

By the time they hired their first Chief Data Officer in 2002—Cathryne Clay Doss—they already knew what problem they were solving: optimize credit decisions. The CDO managed a system that already worked.

Capital One organized around the tool (credit decision optimization). Data and the CDO role supported that tool.

Then everyone else copied the CDO role.

Yahoo hired Usama Fayyad in 2004 as Chief Data Officer. The press release glowed: “responsible for Yahoo!’s overall data strategy, architecting Yahoo!’s data policies and systems, prioritizing data investments.”

Notice the difference? Capital One’s CDO managed a working decision system. Yahoo’s CDO was supposed to... figure out what to do with data.

By 2012, 12% of large organizations had CDOs. By 2018, 68%.

Everyone copied the role. Almost no one copied the system.

Here’s what happened: Average CDO tenure was 30 months. Not because they were fired. Most left “seeking opportunities to create more impact” (MIT Sloan). Corporate-speak for: “I couldn’t figure out what I was supposed to do.”

Harvard Business Review in 2021: “The role is relatively new, so companies are still trying to decide what they want from the person in this position.”

They hired someone, gave them data (the ingredient), and expected value. No clear decision system. No defined problem.

The timeline for companies that copied wrong:

• Year 1: Data governance frameworks

• Year 2: Some pilots

• Year 3: “Where’s the ROI?”

• Month 30: CDO leaves or role eliminated

Reading about Capital One, I felt that familiar nausea. I was about to become Yahoo circa 2004. Marketing the ingredient (AI), hoping customers would figure out the tool (knowledge management).

Same mistake. Just twenty years later.

The real problem

Every discovery call starts the same way now.

I changed the question. No more “How can AI help your business?”

Now I ask: “What’s your biggest challenge?”

The answers are always immediate:

“You know what the Damocles sword is for us? People retiring.”

That exact phrase. “Damocles sword.”

Every industrial company says this now. Different words, same terror. Retirements are the nightmare scenario. When senior people leave, decades of institutional knowledge evaporates.

Six weeks ago, a manufacturing VP walked me through their version.

A senior mechanical engineer had just retired after twenty-three years (the average at this company!). He was the only person who understood why certain tolerances in their flagship product were set to what seemed like arbitrary numbers.

But of course, those numbers weren’t arbitrary. They were the result of six months of failure analysis in 2009 after a batch of defective parts nearly cost them their biggest client. The magic number that prevented catastrophic failure under specific stress conditions.

Nobody documented it. The decisions lived in the engineer’s head. Now he’s gone.

The new engineer wanted to “optimize” those tolerances. Made perfect sense on paper—tighter tolerances, better quality. Would have reintroduced the exact failure mode from 2009.

They caught it because the retiring engineer mentioned it in his exit interview. By luck, not by system.

The VP’s voice cracked slightly: “We almost shipped death traps because we forgot why we do what we do.”

This is the pattern everywhere: institutional knowledge walking out the door with no capture system.

Creating an “AI department” doesn’t solve this.

AI can help you retrieve knowledge. But only after you’ve built the system that captures it.

A better question

After I killed my AI campaigns, I changed how I talk to customers.

Here’s how I approach it when I look at businesses.

Old question: “How can AI help your business?”

New question: “If AI didn’t exist, what’s your biggest bottleneck right now?”

Not “your AI bottleneck.” Your actual bottleneck.

The relief in their voices when they can talk about real problems instead of technology dreams—it’s palpable.

Growth? Why is growth blocked? Need to reduce costs or increase revenues? What specifically stops you? Go three levels deeper. Is it sales cycle time? Customer churn? Product development speed?

Operations? What breaks first when demand spikes? Where do you lose efficiency? What manual process eats the most time?

Innovation? What stops your team from trying new approaches? Is it that nobody remembers why you tried something similar five years ago and it failed?

For our customers, the answer is always knowledge management. Specifically: institutional knowledge that exists only in people’s heads and evaporates when they leave.

That’s our bottleneck. That’s what we built Maia to solve.

Your bottleneck is probably different.

Figure that out first. Get specific. Go deep.

Then yes, AI can help you build a better tool to address it.

But the system you build should solve your bottleneck. AI should support that system.

Not the other way around.

Stop organising around AI

Your senior engineer leaves next month. She’s the only person who understands why your payment system is architected the way it is. The undocumented decisions, the edge cases only she remembers, the reasons for seemingly arbitrary choices.

Capture that knowledge first. Make it searchable. Build the system.

Then AI can help you retrieve it.

Capital One understood this in 1990. They organized around credit decisions. The data and technology supported the decision system.

Everyone else organized around the technology and wondered why it didn’t work.

I almost made the same mistake. Three months from doubling down on campaigns about “AI trends.” Three months from becoming another Yahoo-style failure. Three months from contributing to the noise instead of solving real problems.

The relief of catching yourself before the cliff—it’s physical. Like dodging a car accident and feeling your whole body vibrate with unused adrenaline.

AI is an ingredient. You can’t bake bread by organizing your kitchen around flour.

You can’t retrieve what you never captured.

And you can’t solve problems by hiring someone to figure out what problems AI might solve.

The companies appointing Chief AI Officers right now? They’re about to learn what the CDO wave taught us: organizing around ingredients instead of tools is a recipe for thirty months of expensive confusion.