Existing definitions are binary - you have it or you don’t - or scalar - a amorphous score you increase until you cross the threshold. Or they’re emotive. Something you feel in your chest. Know-it-when-you-see-it. “When the market starts pulling you”. "When you go from pushing a boulder uphill to desperately running downhill to keep up with it.”

All of these definitions describe a state, not a mechanism. They tell you what arrival feels like but not how to navigate towards its destination.

I believe the framing is wrong.

PMF isn’t a destination. It’s a feedback loop.

P, M, F and the loop

Let’s start with three variables.

P is everything you can control. The full surface of decisions you can make about your business. The product itself, but also its positioning, pricing, marketing, sales motion, hiring, engineering, support processes. Everything.

M is the market you’re selling into. M is high-dimensional - many ICPs, many segments, many possible positions where your product can fit. Competitors occupy different optima in the same space. M may shift over time if you’re in a frontier market.

F is the fitness signal. You expose P to M and get a signal back, F(it). F is noisy, lossy, slow. It’s not just slow to arrive, but it takes cycles to decode. You have to gather signal from support tickets, sales conversations, marketing data, customer interviews and analytics. Decoding F and locking onto the signal within the noise is a learned skill. Few possess this skill.

The infrastructure you build to decode F is itself an investment in P. Part of iterating on your business is investing in your ability to hear what the market is telling you.

F is not a number; it’s a signal landscape across M - strong in some regions, weak in others. Absent where the market doesn’t exist.

M responds differently to different iterations of your P.

This creates a clear loop. P→M→F→iterate.

Adjust P, expose it to M, receive F, decode F, adjust P.

This control loop is something you can reason about and take steps to engineer.

Structurally, it’s a RL problem. You’re an agent navigating a state space against a reward signal that is noisy and delayed. You’re exploring and exploiting against that signal: when do you try new positions in P-M space and when do you commit to a region with strong F reward signal?

I find this frame compresses well. It is purposefully hand-wavy. It allows you to go arbitrarily deep on any sub-topic of P, M or F while still reducing down to three basic questions:

1. What actions am I taking to position P against M?

2. How is M responding?

3. How well am I decoding F and leveraging that to iterate on P?

Everything else is a subproblem of one of these three questions. You can mold these principles to whatever deeper frameworks match your specific problem space.

What the loop reveals

Iteration speed is the game

Iteration speed through the loop compounds. Every investment that makes P-iteration faster or the F-decoding clearer/cheaper is a compounding investment in the loop itself.

Before agentic development, it was expensive to set up infrastructure that increased iteration speed. Agentic dev collapses this investment cost to near-zero. You can have much more mature infrastructure for P-iteration and F-decoding in week one of your company.

This continues to scale as you setup new roles in the company. Support teams can have knowledge bases, tagging and routing from day one because the creation of those tools are the type of low-complexity knowledge work agents thrive on.

Explore vs Exploit

Startups that scale prematurely are scaling before F gives strong signal. Exploiting too early → doubling down on a P-M position that hasn’t been validated by enough signal.

The other failure mode (although a good problem to have) is staying in Explore mode too long when the signal is already crystal clear. Not many startups die from having PMF and scaling their GTM too aggressively.

In this frame, a pivot isn’t an identity crisis. It’s a large jump in P-M space when F is making it clear you’re in the wrong region.

Competitors are part of F

Most startups worry too much about the competition instead of the P→M→F loop. The loop frames this differently. In this frame, competitors are not a problem to manage. They aren’t on the board at all.

If a competitor exists and is solving problems better than you for a segment of M, that’ll simply provide a weak F signal. You don’t have strong fit with those customers because their needs are met. You have to offer something meaningfully different or better.

This is why the classic advice is to build something “10x better” than the existing solution. An order of magnitude improvement is often the only thing that will give you real signal from M when their needs are already being served.

Attend to signals that exist, quickly

First-time founders over-focus on P. They don’t attend to M, the space they’re navigating. This is why the industry pushes founders to build MVPs. An MVP is whatever helps you complete the loop.

An MVP in this loop landscape is a minimal viable P - not necessarily a product in hand. It is some subset of P that you can take to M and get an F to decode.

Second-time founders are often much more thoughtful about distribution and GTM. They spend more time in research or crafting landing pages, vaporware demos and other materials that give enough P to earn a signal from M.

Dogfooding and bootstrapping

Dogfooding - using your own product internally - gives you a shorter, faster loop. Your internal users are a subset of your M. They emit F internally for their use cases. This allows you to iterate much more quickly on P.

Bootstrapping - using your own product to build your product - is a form of double-compounding on P-iteration. You improve P, which improves all future iteration on P. This faster P-iteration gets you to your next signal faster.

Other advice that clicks

“Do things that don’t scale” → P is weak in the early game and F is its noisest. Taking actions to navigating yourself into more unique P-M positions, even if it takes a lot of curated, non-scalable effort, is worthwhile to eke out better F. You should also be spending a massive amount of time with customers, effectively manually sampling your F signal.

“Jobs to be done” → M has strong ambient signals of what they invest in today. Paying attention to those up front saves you from Exploring blindly.

Tyler, isn’t this just Lean Startup with some RL sauce on it?

Yeah sure, agile nerd. Go run a t-shirt sizing session.

Lean Startup definitely operates on the similar underlying dynamics. Build-Measure-Learn is a loop over similar variables. But Lean Startup is a methodology. In my experience, it’s a prescription of workflows and artifacts that fail contact with reality.

What I’m trying to hone this down to is raw building blocks you can stack how you like for your specific situation. So much of company building is emergent. How you run the loop might rhyme across businesses or industries, but every business is ultimately a production function of this loop that optimizes itself for its F signal.

The unit was always the probabilistic compiler

Engineers ask whether agent-coding is the next jump up the abstraction stack - assembly to C, C to Python, Python to prompt - and the question is right about the shape. Layers stack. What it gets wrong is an assumption hidden underneath: that any layer below the prompt was ever deterministic.

Translating business requirements into running systems was always a probabilistic act. The unit of analysis was always the probabilistic compiler - the human production function - and the engineering organization built around it was always the apparatus of pushing probable outcomes rightward on an acceptability frontier.

“Probabilistic compiler” needs an early disambiguation. It does not mean the probabilistic programming compilers of Stan, Pyro, and LLaMPPL, which translate probabilistic programs into inference algorithms. It does not mean Karpathy’s “Software 3.0” claim that natural language is now the programming layer and the LLM is the new compiler the prompt runs against. The claim here is older and more boring.

The compiler is the human production function plus the engineering organization around it, and it has been probabilistic since the first time two engineers handed the same ticket produced two different artifacts.

There are real deterministic layers in software production. The compiler that turns C into assembly is deterministic. Linters, type checkers, CI pipelines, automated test suites are all deterministic. They are guard rails and signposts installed around the probabilistic core, several of them simply multiplicative: they take higher-level abstractions and make execution faster, more consistent, more enforceable. The engineering organization is the full apparatus humans built around the probabilistic core: a mix of deterministic tooling where compliance can be encoded, and probabilistic human processes (code review, RFCs, planning, taste) where judgment cannot. None of the deterministic layers is the unit of analysis. The human production function is.

The acceptability frontier is the surface inside the probabilistic compiler that matters. Outputs distribute across it from the left edge, where work just clears the bar, to the right edge, where work exists that everyone could point at as good engineering even if they would have made slightly different choices. The job of the engineering organization has always been to push the distribution rightward. The same shape, repeated for fifty years, across every change in the substrate execution ran on.

What changes with LLMs is not the unit. The unit is still the probabilistic compiler. What changes is the cycle time. Most of the playbook still applies. Some of it does not. The rest of this piece is the work of sorting which parts survive directly, which parts have to be composed explicitly because slowness used to do the composing for free, and what an engineer or leader does on Monday morning with that information.

What fifty years of software development actually taught us

The disciplines that emerged across fifty years of building and iterating on software systems are not contingent on the substrate. They survive substrate changes because they encode the examination shape, not the production medium. They are the platonic truths of software development. Platonic in the classifier sense, not the metaphysical one. They show up the same way in adjacent knowledge-work crafts where the production function is also human and probabilistic.

Multi-stage examination

Multi-stage examination is the first one. The discipline of asking the right question about the same concern at design, planning, build, and review. Fagan named it as an industrial practice at IBM in 1976: design and code inspections at strict ordering, with entry and exit criteria, documented defect-removal effectiveness of eighty to ninety percent and resource savings up to twenty-five percent. Adopted at IBM, Hewlett-Packard, Motorola, NASA. The discipline predates the name; what Fagan did was make it legible. Beck named the smallest-scope version of it with TDD in 2002: pair every doing-skill with a reviewing-skill at the smallest unit. Brooks named the deepest version of the truth in 1986: the essential complexity of the conceptual construct is what survives every change in tooling; accidental complexity is what tooling eats.

Taste-encoding

Taste-encoding is the second one. The artifact whose value is encoding judgment rather than enforcing compliance. Style guides that say “we prefer X over Y because Z” - the because is the load-bearing word - they make any execution layer pointed at them sharper. Style guides that say “follow PEP 8” produce a wash.

Biasing trajectory

First steps - what to build, how to decompose, what to test for - dominates trajectory. Execution amplifies whatever it was pointed at, including the wrong thing. The most expensive bug is the one in the architectural decision; the cheapest is the one in the line of code. Senior engineering converges, across organizations, on putting disproportionate weight at the bearings stage - because that is where the trajectory is set.

Trust distribution

Trust-distribution is the fourth one and the most often misread. Code review was never primarily a quality mechanism. It was the surface humans built around their own probabilistic output to make it reviewable and accountable to other humans. The function was trust-distribution; quality emerged as a byproduct. Stripe ran on this principle as it scaled from a few engineers to thousands. Review was the surface through which judgment got distributed across a codebase maintained by hundreds of contributors, the same culture that produced Patrick McKenzie’s principle that if one finds oneself nitpicking a pull request, one should generally fix the linter or find something productive to do. Engineering leaders who priced review as a quality mechanism see it as the thing to automate. Leaders who priced review as a trust-distribution mechanism see it as the thing whose substrate needs replacing when the substrate of accountability changes.

These are platonic because they encode the shape of the work rather than the medium it runs on. Editorial discipline in publishing - developmental, line, copy, proofreading, executed at strict ordering, with each stage refusing premature compression into the next - is the same shape. These disciplines did not emerge because someone wrote them down. They emerged because organizations that did not run them produced visibly worse software than organizations that did. The discipline is what veers the distribution rightward on the acceptability frontier.

What LLMs change, and what they don’t

The change is to the substrate, not to the unit. Cycle time is the measure of it. The same engineer who would have spent three days writing a function gets the artifact back in five minutes. The probabilistic compiler that the function passes through is now running at a clock-rate three orders of magnitude faster than the one humans were used to. The unit of analysis has not changed. Outputs still distribute across an acceptability frontier; the engineering organization’s job is still to push the distribution rightward; most of the playbook still applies.

The parts that survive directly are the ones that encoded the examination shape rather than the production medium. Taste-encoding scales straight through. The artifact’s job is to encode judgment for any execution layer, and the new execution layer reads it just as well as the old one. The bearings work matters more, not less, when the execution layer is cheap. Multi-stage examination scales through if it is composed explicitly. That last condition is where the work is.

The parts that need new composition are the parts that depended on slow human work as substrate. Multi-stage examination existed in human engineering organizations because the work was slow enough to invite intervention at every stage. When a function takes three days, there is time to ask testability questions at design, decomposition questions at planning, taste questions during execution, and reconciliation questions at review. The discipline was invisible because slowness produced it by default. Teams did not name multi-stage examination as a discipline; they just had it. Speed up the substrate by three orders of magnitude and the slowness is gone. The discipline is not deficient. The conditions that produced it for free have evaporated.

The temptation to one-shot is the failure mode the discipline was always there to prevent, and the temptation arrives precisely because the substrate is fast. The same engineer who would never accept a function written without testability questions at design will accept one from an agent because the prompt felt complete and the artifact already exists in five minutes. The machine shop being built around the LLM gets read as an automated assembly line, a factory floor where uniform output gets pressed out at scale. That is the categorical mistake. The LLM is not a factory machine. It is another probabilistic substrate, with its own distribution across the acceptability frontier. The machine shop you build around it is itself a probabilistic compiler, just operating at a much faster pace.

The clearest precedent the audience already has cached for this kind of substrate change is the spreadsheet. VisiCalc and Lotus 1-2-3 collapsed the cost of running calculations; the cheap-execution layer compressed by orders of magnitude; analyst headcount went up, not down; demand for analysis exploded. The optimistic reading of LLMs is that software work goes the same way. The narrow defensible difference - and it is narrow - is that the spreadsheet automated one layer of the analyst’s stack, while the LLM automates most of the execution layer simultaneously, including the apprenticeship rungs that produced the next generation of seniors. Software is the case where the cheap-execution layer eats the manufacturing pipeline for its own future seniors. The continuity thesis holds. The apprenticeship-rung consequence is real and named in the next section.

Repricing the apparatus

The engineering apparatus reprices asymmetrically, and the asymmetry is not random. Each component sorts by who its consumer was: a future human reading the artifact, a human catching defects another human produced, or the discipline itself.

Negative half-life is the tier of components whose consumer was a future human and is no longer. Onboarding RFCs and README architecture overview sections were built to replay context for the next human in the room. The new contributor reads the codebase cold in seconds, and the prose drifts from reality faster than humans can update it. The artifact is often worse than nothing because it confidently mis-describes the system the agent is about to operate on. Code comments for “future engineers” persist as a loyalty signal - a real engineer wrote this - exactly the apparatus surviving past its consumer.

Short half-life is the tier of components whose consumer was a human catching defects another human produced. Line-level code review for correctness collapses because bugginess gets tested into the floor by the same loop that produced the code. Mechanical refactoring as senior-engineer load collapses because it is the task agents are best at. The load-bearing entry in this tier is the apprenticeship rung.

The “good first issue” labor was the layer juniors used to grow on. New-grad hiring at Big Tech is down twenty-five percent year-over-year and over fifty percent from 2019, and employment in software for ages twenty-two to twenty-five is down roughly twenty percent from its late-2022 peak. The pipeline that manufactured next-generation seniors lost its substrate. The leadership tier has to rebuild the pipeline at plan-time and review-time, pulling juniors into bearings work earlier than the old apprenticeship ladder placed them, or live with the consequences in 2031.

Long half-life is the tier of components whose consumer is the discipline itself. Taste-encoding documents compound. Plan-time decomposition compounds. Integration tests migrate from safety net to executable spec. Same tests, different role; pricing inverts from “did they pass” to “does the suite encode what the system should be doing.” The substrate change makes these components more valuable, not less, because the floor-quality of execution against them just got cheap and the principles themselves are the differentiator.

The asymmetry is already metered. METR’s 2025 randomized controlled trial on experienced open-source contributors found developers nineteen percent slower in completion time when allowed to use AI tools, while the same developers believed they had been twenty percent faster. Cursor’s analysis across tens of thousands of users found organizations merging thirty-nine percent more pull requests after the agent became their default. Both findings price the same thing. The execution layer compressed; the examination layer absorbed the saved time and more; the gains land where the apparatus was already shaped to absorb the throughput, and fail to land where it was not.

Apparatus components without a clear answer yet sit outside this sort. Observability under probabilistic execution, on-call rotations for code agents wrote, junior onboarding when the rung is gone: these are the load-bearing structural questions the half-life frame does not yet price. Each is its own essay.

The cleanest historical precedent for this shape of repricing is cloud and the emergence of SRE. AWS launched in 2006; enterprise adoption ran from 2008 to 2020; the execution layer of sysadmin work compressed from weeks to API calls. The unit of analysis - running a reliable service - did not change. The discipline survived and strengthened. The role-name changed from sysadmin to SRE or Platform Engineer, with comp tracking the new shape upward. Google’s Site Reliability Engineering opens on the continuity claim: SRE is what happens when you ask a software engineer to design an operations team. The discipline was always engineering. Cloud just compressed the labor that used to disguise it.

Composing for the new pace

Editorial discipline is the mature analog for multi-stage examination, encoded in publishing for over a century as a four-stage intervention executed at strict ordering. Developmental editing asks whether the thesis, structure, and scope are right and refuses to engage prose-level work until the architecture is settled. Line editing asks whether each sentence carries its weight, in the right register, at the right cadence, and refuses to engage grammar until the prose is doing the right work. Copy editing asks whether the work is internally consistent and grammatically clean. Proofreading catches what survived. Each stage refuses premature compression into the next. The depth of intervention decreases monotonically as you move downstream.

The strongest editorial fact is barely controversial inside the publishing industry: writers-with-editors produce visibly better work than writers-without-editors. The New Yorker has long maintained a fact-checking department of sixteen who speak to every person mentioned in every story, even when not quoted. The discipline survives editor turnover, writer churn, and deadline pressure because it is encoded in the institution rather than in any individual editor. The shape is platonic. The substrate has changed across a century of publishing - typewriter to word processor to collaborative cloud editor - and the discipline survives all of them, because what is being encoded is the examination architecture, not the production medium.

Engineering has half of this. Code review is final-pass-only. Architectural review is plan-stage-only and episodic. The two middle stages - idea-stage examination as part of how problems get framed, and iterative examination during execution - are improvised or skipped. Production organizations got away with the gap for fifty years because slow human work made the gap invisible. The discipline was carried out as a byproduct of the substrate.

Testing is the operational example for the new pace. Testing is not a skill the LLM installs once against a coverage target. Testing is a concern examined at design (is this thing testable?), at planning (what tiers of tests, at what assertion targets?), at execution (what does a great test of this kind look like at this tier?), and at review (did the plan survive contact with the code?). Coverage targets are the final-pass-only version of testing: a metric for review-stage compliance that pretends the other three stages did not matter. Hand an LLM a coverage target and you get tests that hit the lines and miss the failure modes. The system breaks anyway.

Building a machine shop that veers right on the acceptability frontier is the work of installing the multi-stage discipline as context. The verification surface in production is not a single review gate at the end. It is a composed layer - evals, drift detection, replay, fallback paths, human-in-loop escalation - each examining the same output from a different angle, the way the editorial discipline examines a manuscript at idea, structure, sentence, and proof. Cursor describes its agent harness as exactly this: offline benchmarks, online A/B tests, custom acceptance metrics, LLM-based sentiment analysis. Stripe encodes the same discipline organizationally: pre-installing Cursor on developer machines and shaping every agent invocation with Cursor Rules. Human judgment is the scarce resource; the discipline of multi-stage examination is what frees it from work tooling can encode.

Build your machine shop the way you have always built your engineering organization. Multi-stage examination, applied explicitly, installed as context. Anything you build that pretends the LLM is a factory machine will produce factory-shaped output: uniform, on-spec, and on the wrong side of the acceptability frontier.

References

The disciplines and receipts cited above, grouped by section.

The platonic truths (§2)

• Michael Fagan, “Design and Code Inspections to Reduce Errors in Program Development,” IBM Systems Journal 15:3 (1976). The original treatment of multi-stage examination as an industrial practice, with the defect-removal and resource-savings numbers cited in §2.

• Kent Beck, Test-Driven Development: By Example (Addison-Wesley, 2002). The smallest-scope version of multi-stage examination — pair every doing-skill with a reviewing-skill at the unit level.

• Fred Brooks, “No Silver Bullet: Essence and Accident in Software Engineering” (UNC TR86-020, 1986). The deepest version of the truth: essential complexity is what survives every tooling change; accidental complexity is what tooling eats.

• Patrick McKenzie, “What Working At Stripe Has Been Like,” Kalzumeus (March 2019). Source for the §2 trust-distribution principle: “if one finds oneself nitpicking a pull request, one should generally either a) fix the linter or b) find something productive to do with one’s time.”

The Software 3.0 dispatch (§1)

• Andrej Karpathy, “Software Is Changing (Again),” YC AI Startup School (June 2025). The “Software 3.0” framing this piece distinguishes its claim from in the §1 disambiguation — natural language as the programming layer, LLM as the new compiler.

Repricing the apparatus (§4)

• SignalFire, State of Talent Report 2025. Source for the new-grad hiring numbers: Big Tech down twenty-five percent year-over-year, over fifty percent from 2019.

• Erik Brynjolfsson, Bharat Chandar, Ruyu Chen, “Canaries in the Coal Mine? Six Facts about the Recent Employment Effects of Artificial Intelligence,” Stanford Digital Economy Lab (August 2025). ADP-payroll-microdata source for the age-22-25 software-developer employment decline.

• METR, “Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity” (July 2025). Randomized controlled trial on sixteen experienced open-source contributors across mature repositories. Headline finding: nineteen percent slower in completion time when AI tools were allowed, against a twenty percent perceived speedup. The cleanest single receipt for “execution compresses, examination does not.”

• Cursor, “The Productivity Impact of Coding Agents” (2026). Eligible-vs-baseline cohort analysis across tens of thousands of users; thirty-nine percent more pull requests merged at organizations after the Cursor agent became the default. The positive receipt for the same asymmetry — gains land where the apparatus is shaped to absorb them.

• Amazon Web Services launch press release (March 14, 2006). The starting line for the cloud-era apparatus-repricing precedent.

• Betsy Beyer, Chris Jones, Jennifer Petoff, Niall Richard Murphy (eds.), Site Reliability Engineering (Google / O’Reilly, 2016). The book that opens on the continuity claim cited in §4: SRE is what happens when you ask a software engineer to design an operations team.

Composing for the new pace (§5)

• Brent Cunningham, “The World’s Largest Fact-Checking Operation,” Columbia Journalism Review. The documented sixteen-checker department at The New Yorker, the discipline encoded at institutional level rather than in any individual editor.

• Anysphere, “Continually Improving the Cursor Agent Harness,” Cursor engineering blog. The composed verification surface in production — offline benchmarks, online A/B tests, custom acceptance metrics, LLM-based sentiment analysis.

• Anysphere, “How Stripe Rolled Out a Consistent Cursor Experience for 3,000 Engineers,” Cursor case study. Stripe’s organizational encoding of the multi-stage discipline — pre-installation and Cursor Rules as substrate.

• John McPhee, “Checkpoints,” The New Yorker (February 9, 2009). The literary-canon treatment of the same fact-checking discipline cited in §5.

Glean asks you to know what to search for. Notion AI asks you to know what to draft. Every agent builder asks you to know which workflow to script. The product’s competence is bounded by the customer’s ability to articulate their own work, which is the thing the product was meant to compensate for in the first place.

This is the central error of the agent era.

Labor is not the bottleneck of knowledge work. Attention is.

Attention, in the operational sense, is the scarce capacity to notice, interpret, prioritize, and route ambiguous signals before they become named work. Every dashboard nobody opens, every Slack thread that scrolls past, every escalation that arrives late, is a withdrawal from the same account.

The bottleneck nobody is naming

Consider the production function of any team inside a modern company. A revops team watches pipeline by stage, conversion per segment, three or four dashboards that update on Monday. That is the part of the work the team has learned to articulate. It is almost always a minority of what the team’s performance depends on.

The rest sits in the long tail. The Gong call where a customer mentioned a competitor by name and nobody on the deal team noticed. The Slack thread where someone in support flagged a recurring billing edge case three weeks before it broke. The pull request where a senior engineer typed “this is the third time this month we’ve changed this function” and merged anyway. These signals exist in every company’s systems of record. They go unwatched not because they are useless, but because attention has always been too expensive to spend continuously.

This is Amdahl’s Law applied to organizations. You can accelerate the named subprocesses of a business by an order of magnitude and the business will get only marginally faster if those subprocesses are not where the real constraint lives. The serial pathologies sit in the unarticulated transformations, the silent handoffs, the decisions that were never written down. The current generation of AI products cannot touch that surface. They were architected to optimize what their customers can already describe; they are pricing themselves against a ceiling they helped install.

Klarna ran the cleanest version of the factory play in 2024: AI handled 2.3 million chats a month, did the work of roughly seven hundred full-time agents, dropped resolution time from eleven minutes to under two, and was projected to add forty million dollars in operating profit. By May 2025 the company was rehiring; its CEO told the press that the cost-cutting push had over-rotated on quality. The factory deployment could not see what the human agents were doing in their third minute, which was silently reframing the customer’s literal question into the customer’s actual problem. That reframe is where the value lived. The factory frame could not price it because it had no line item for work the customer never thought to describe.

The wrong product

By factory I mean any AI product whose architectural premise is that the workflow is already known. Name the task, script the steps, attach the tools, run the agent, sell it as a labor unit. The category drifted there because the financial story is clean: factories convert operating expense to capital expense, they replace human units with software units, they produce a number on a slide a CFO can underwrite.

The factory language is useful precisely because it gives the financing layer something legible: fixed assets, throughput, utilization, payback. NVIDIA selling “AI factories” is the same move at chip-vendor scale, and at infrastructure scale the frame may be the right one. Training compute, data centers, and the capex behind them genuinely do behave like factories. The problem is letting the language slide downstream into the application layer, where roughly six hundred billion dollars of 2026 AI spend is being underwritten against an architecture that is not, in fact, a factory.

Every company is a unique organism. Its production function is a recursive composition of dozens of role-specific functions, each with its own tacit knowledge and emergent behavior accumulated over years.

These eccentric details are not noise. They are the company.

A factory presupposes a canonical workflow that can be stamped out across customers; the canonical workflow does not exist at the level of detail that matters. Two companies running the same support process have different escalation rules and different unwritten standards for what resolved means. Two engineering teams running the same SDLC have different test conventions, different deploy quirks, different load-bearing patterns left behind by incidents nobody documented.

The eccentric load-bearing parts of a company’s work cannot be parameterized in advance. They have to be discovered, in place, by something watching.

Factories optimize what you can describe. Probes find what you couldn’t. Every other architectural choice falls out of that one.

Self-assembling software

Imagine software that lands inside a company the way a Von Neumann probe lands on a planet. It does not arrive with a configured workflow. It arrives with a goal: extend the company’s production function. It also arrives with the capacity to figure out where putting attention will do that.

It reads the company’s systems of record: the Gong calls, the Linear tickets, the deploy logs, the database schemas, the Slack archive. It constructs its own map of the local substrate. Where the map has gaps, it does not ask the human to teach from scratch; it looks for where the company has already solved the problem before, surfaces the evidence, and asks the human to grade it. This dialogue interface, the Inquiry, is how the probe converts the company’s own history into its working memory.

I see twelve Linear tickets for billing escalations over the last quarter. No runbook is documented anywhere, but I found the Slack threads and PR diffs from the four most recent resolutions. Here is the pattern I am reading across them. Walk me through where I have it right and where I am missing context, and I will use this as the seed dataset for the agent that handles these going forward.

The human’s cognitive load is editing, not authoring; reviewing, not explaining. That difference is roughly an order-of-magnitude reduction in onboarding cost, and it is the reason the probe can build context at customer scale without a million-dollar professional-services engagement attached to it.

The product is the probe. Not the agents inside it. The whole self-bootstrapping, self-harnessing, self-replicating system that lands at the customer and grows. The agents are sprites: small, many, embedded, alive. They are the probe’s hands, the means by which it bootstraps itself into the local terrain. The probe has the goal. The probe has the taste: the learned local model of what is urgent, what is noise, who should be interrupted, and how much confidence is enough. It carries the eval history and the escalation judgment that decide what matters. The sprites are how it acts. The humans the probe works with become deputies: not operators of the system but its inheritors, accruing the judgment the probe is learning and propagating it laterally to colleagues.

“Self-replicating” deserves its qualifier. What replicates is patterns, through a typed case base, with human approval at the boundary. The probe does not fork itself onto your hardware; it proposes patterns that other probes have learned, your humans decide which ones land, and the local probe absorbs them under your permission model. Discovery is broad. Action is narrow. The probe reads widely, proposes often, writes rarely, escalates whenever confidence or blast radius crosses a threshold. It earns autonomy the way a new employee does: through observed judgment over time, scoped to surfaces a human has already signed off on. Without that, none of the rest is shippable inside an enterprise.

The architectural property that distinguishes this from every other product on the market is that human articulation skill is no longer the ceiling. The probe assembles itself.

Four layers

The probe has four layers, and the load-bearing one is the one nobody is shipping today.

Substrate is the local map: connectors to every system of record, a model of how data transforms across them, and the Inquiry that surfaces tribal knowledge onto the map. Onboarding the probe is the way a company finally writes down what was in everyone’s heads. This is not a feature. It is the byproduct nobody else is selling.

The same byproduct serves humans. A factory product asks the customer to design a generic training flow; the probe watches the examples, objections, support tickets, and workflows that actually exist inside the company, and assembles employee onboarding around reality instead of abstraction.

Drivers are the atomic capabilities the substrate exposes. Reconcile a ledger entry. Open a pull request. File a support ticket. Run a deploy. Every customer has these systems of record, so the probe ships with a curated library and day-one value is real before any local learning has occurred. Drivers are what compress the main job. The probe runs them with the substrate underneath them, which is the part the factory products cannot reach. When a sprite opens a pull request, it knows the team’s review conventions, the unwritten rule about touching the migration directory before a Wednesday deploy, the specific senior engineer who must be tagged on changes near the billing subsystem. The same atomic capability is doing different work, because the context underneath it is different.

The noticing loop is the proposer. It reads the human reaction stream, consults the substrate, borrows patterns from the playbook, and drafts new sprites to try. Its operating principle is the one most agent products get wrong.

You do not manage an agent’s performance. You compound the context the agent is operating in, and the agent gets better.

Every escalation is a labeled example. Every correction is a dataset entry. Every accepted resolution is an eval point. The probe accumulates its own evaluation substrate as it operates, calibrated to this specific company’s taste. Over time the loop also learns which categories of signal deserve sustained attention going forward. Sprites that earn attention survive. The rest are recycled. Drift detection is native, because the probe can see when its automated outputs are diverging from how its humans actually resolve similar cases.

The playbook is the typed case base across customers: typed patterns, eval traces, correction histories, escalation profiles. Patterns generalize across the fleet; data stays home. Customer two onboards faster than customer one. By customer fifty the probe arrives with priors strong enough that bootstrapping is fast. The moat is not the model. The moat is the corpus.

Elastic attention

AWS made compute elastic. The probe does the same for attention.

The easiest way to feel the shift is to ask what you would watch if attention had no marginal cost. Would you inspect every deal in the pipeline every morning, not for the fields already in Salesforce but for the weak signals that suggest the deal has changed? Would you monitor every customer’s website, every competitor’s pricing page, every API doc, every changelog, every Gong call, every product event, every anomalous log line after a major release? Today the answer is no, not because the work is unimportant, but because no team can afford the attention. So companies build rituals around scarcity: weekly pipeline review, quarterly competitive analysis, sampled call review, dashboards someone checks when something already feels wrong. Elastic attention makes the default different. The question stops being “is this worth assigning a human to?” and becomes “what would we learn if this surface were watched continuously, with taste?”

A sprite that drafts most of a vendor contract and waits for counsel to fill the gaps is capacity that costs nothing at rest and scales instantly when demand spikes. That elasticity shows up across three surfaces, and a factory product cannot ship any of them.

The first is compression of the main job. The engineer’s standard loop of reading specs, designing, writing, testing, reviewing, deploying, and monitoring runs several times faster when sprites operating on substrate context can take the boring middle of every step.

The second is the long tail of latent builds: the internal tools the engineer always wanted and never had the bandwidth for, the better runbook, the eval suite that should have existed two years ago, the dashboard that surfaces the metric that mattered all along. The probe lowers the threshold on is this worth building? from a week to an afternoon, and capability stock compounds in the background of the company’s main work.

The third is novel attention to problems no one was watching: the Gong call, the Slack thread, the PR diff that the team’s bandwidth could not reach.

All three require the substrate, the drivers tuned to local convention, and the noticing loop running over both. The probe ships all three because all three fall out of the same architectural property.

Elastic attention without taste is sprawl.

Hand a human a thousand agents and they will run out of ideas after a handful. How many on our teams are hitting their usage limits? There are limits to the average employee’s ability to articulate and amplify their production function.

The probe is defined by it’s taste for how to deploy elastic attention.

The right financial frame is option accounting. The factory frame underwrites task replacement: agents do forty percent of the work, headcount should drop forty percent, payback is fast. This is the math driving the wave of ill-fated layoffs across the industry. It is also the framing the architecture asks you to reject.

The math does not survive contact with the work. The industry assumption it runs on, that LLMs are a labor substitute, has been wrong since the earliest public deployments. Klarna was the canonical early case. In May 2026 Cloudflare announced eleven hundred layoffs as a redesign for the agentic-AI era. The eighteen months in between produced a continuous stream of similar announcements, all underwritten by the same task-replacement math. The pattern is not that the cuts failed. It is that the math priced the wrong thing.

More importantly, task accounting is pricing the wrong thing.

Most of the value of a senior employee is not the tasks she executes but the option to direct her judgment at work that has not surfaced yet. The migration that hasn’t happened. The boundary that hasn’t broken. The strategic call that hasn’t been needed.

Pre-LLM, those options were expensive to hold because the carrying cost was full headcount. Post-LLM, the carrying cost dropped and the volatility rose, and every option in the firm got more valuable on both sides at once. Selling the headcount that carries the option in order to book a short-term cost saving is selling the asset at the bottom.

Under task accounting you cut headcount and pocket the savings. Under option accounting you hold the headcount and let the probe leverage every senior judgment across ten times the surface area it used to cover. The companies getting this right will look less like they are replacing work and more like they are increasing the clock speed of the organization.

Ramp is the closest public example of the better posture. Not because of any one external product, but because its internal AI work starts from acceleration rather than replacement. Glass gives every employee a configured AI workspace; Inspect is a background coding agent wired into Ramp’s development environment, internal tools, observability, and verification loop, with enough speed to work in parallel with the engineer rather than queueing behind her. The important part is not the agent. It is the harness around it, and the management philosophy behind it: use AI to compress the work so capable people can direct judgment across more surface area. Ramp has not yet built the probe. It is pointing the machinery at the right economic object.

Under the ceiling

The bottleneck was never labor. It was the ceiling every other product installed above attention: the requirement that the customer name the work before software could help with it. The probe ships under that ceiling. It watches before it acts, learns before it automates, discovers the work before anyone has to manage it.

The next great enterprise AI product will not be the one that hands every employee a thousand agents. It will be the one that knows which three should exist before anyone has thought to ask.

Appendix: sources

Klarna case study and walkback

• OpenAI, Klarna’s AI assistant does the work of 700 full-time agents — original 2024 case study with the 2.3M chats, 700 FTE-equivalent, sub-2-minute resolution, and $40M figures. https://openai.com/index/klarna/

• Bloomberg, Klarna Turns From AI to Real Person Customer Service (May 2025) — initial walkback and CEO statement on cost-vs-quality tradeoff. https://www.bloomberg.com/news/articles/2025-05-08/klarna-turns-from-ai-to-real-person-customer-service

• Reuters, Europe’s AI poster child Klarna taps the brakes on chatbots (September 2025) — broader reassessment of Klarna’s AI-substitution thesis and shift back toward human hiring. https://www.reuters.com/business/europes-ai-poster-child-klarna-taps-brakes-chatbots-2025-09-10/

The “AI factory” frame and 2026 capex

• NVIDIA glossary, What is an AI Factory? — NVIDIA’s own definition of the AI-factory frame as infrastructure for training, fine-tuning, and inference at scale. https://www.nvidia.com/en-us/glossary/ai-factory/

• Reuters, Big Tech investors to gauge payoff as AI spending set to hit $600 billion (April 2026) — source for the 2026 AI-capex figure. https://www.reuters.com/business/retail-consumer/big-tech-investors-gauge-payoff-ai-spending-set-hit-600-billion-2026-04-28/

Cloudflare’s May 2026 layoffs

• Business Insider, Read the memo: Cloudflare is laying off 1,100 employees to prepare for “the agentic AI era” (May 2026) — primary reporting on the eleven-hundred-headcount reduction and Cloudflare’s framing of it as an AI-era org redesign. https://www.businessinsider.com/cloudflare-announces-1100-layoffs-amid-ai-focus-shift-2026-5

Ramp’s acceleration-first internal AI posture

• Ramp blog, Eric Glyman on using AI to radically boost internal productivity — Ramp’s framing of internal AI work as employee empowerment, with the limiting factor named as adoption rather than model capability. https://ramp.com/blog/ai-for-internal-productivity

• Modal, How Ramp built a full-context background coding agent on Modal — case study on Inspect: sandboxed environments, internal-stack integration, parallel capacity, verification loop, share of merged PRs. https://modal.com/blog/how-ramp-built-a-full-context-background-coding-agent-on-modal

Concepts referenced

• Amdahl’s Law — Gene Amdahl, 1967. The classical statement that speedup of a system is bounded by the fraction of the work that remains serial.

• Von Neumann probe — the speculative self-replicating spacecraft concept, used here as a metaphor for software that arrives with a goal and the capacity to bootstrap itself into local terrain.

• Elastic compute — the original AWS economic shift: provisioning compute capacity in seconds, surrendering it when idle, and pricing it as a utility.

53,395 characters is roughly 13,000 tokens. On 100 lines. How will we survive this flood?

When you start offloading low-complexity knowledge work to agents, what stays in the human-facing tools is medium- and high-complexity work. The PR thread, the Linear ticket, the support reply. Those interfaces were designed for humans applying careful judgment, and they’re tight on purpose. The tokens involved in resolving the low-complexity layer have to play nice with that surface. Right now they don’t.

I built tokenbin because that mismatch was breaking real workflows at our company. It’s a private-first artifact overflow layer for LLM-heavy work. Agents write the bulky output there. The thread or ticket gets the curated synthesis and a link. The raw analysis stays addressable for the next agent that needs it.

The kernel

The whole model is four primitives:

artifact     immutable text blob, addressed by id
directory    mutable index of related artifacts
pin          named pointer to the current artifact that matters
capability   short-lived scoped token for one directory

Directories are named by convention: github/<org>/<repo>/pull/<n>, linear/<key>, support/<system>/<id>. An agent can resolve the right directory from the work item it’s looking at. Pins carry conventional names too: brief, synthesis, comment, handoff. The capability is what an orchestrator hands a sub-agent so it can write into one directory and nothing else.

The baseline deploy is one Cloudflare Worker, one R2 bucket, one shared API key, signed viewer URLs at /v/:id. Two minutes from a Deploy button to the first artifact. There is no database. The bucket is the index.

What it looks like in a PR review

A PR comes in. The orchestrator opens the directory github/<org>/<repo>/pull/1842. Three review agents (security, correctness, performance) write their full analysis as artifacts in that directory. Each one is a few thousand tokens of careful work. None of it goes in the PR thread.

A synthesis agent reads all three artifacts (it has the directory, so it gets them by listing), writes a single review comment that cites the strongest findings from each, and pins it as synthesis. The orchestrator posts only the synthesis to GitHub. Three short paragraphs, link to the directory for the reviewer who wants to read deeper.

A second round of agents critiques the synthesis. Same pattern: full analysis in the directory, a new synthesis pinned, the PR thread gets one updated comment.

The PR thread sees two comments, total. The directory sees every artifact every agent produced - addressable, durable, and out of the way. A reviewer who wants the receipts follows the link. Everyone else reads the PR like a normal PR.

One directory per work item. Agents write artifacts. One agent synthesizes. The synthesis pins. The human surface stays tight.

What it’s not

Tokenbin isn’t a task tracker, a wiki, deployment-wide search, or a binary asset store. It’s not a SaaS app. The baseline is a Worker you run on your own Cloudflare account. It’s not trying to replace GitHub, Linear, or Zendesk. It’s the overflow and coordination layer beside them.

Artifacts cap at 1 MiB of UTF-8 text. TTL classes are fixed at 1d, 7d, and 30d - long enough for a PR cycle, short enough that nothing accidentally becomes the system of record.

It’s the right tool when most of these are true: long machine output is useful but doesn’t belong in the main UI; multiple agents are working on one item and need shared context; the human at the end needs to scan the work in seconds. If everything you generate belongs directly in the system of record, you don’t need this.

Repo

github.com/Tetra-Research/tokenbin. v0.1.1. Four shipping surfaces over one kernel: a JSON API, hosted MCP at /mcp for Claude/Cursor/etc., a thin CLI, and first-party TypeScript and Python SDKs. The OpenAPI contract is in the repo. Anything we ship to one surface, you can ship to another.

Aiden and Rhys deserve credit for putting the failure mode on the timeline at scale. The number was already showing up in our own PR threads at smaller volume. Theirs just made it impossible to look away from.

If you’re feeling this (agent output flooding a surface humans were supposed to be scanning), send me what you’ve tried. I want to know what’s working.

Appendix

Deploy

Deploy to Cloudflare

Surfaces

• JSON API

• Hosted MCP at /mcp: works with Claude Desktop, Cursor, and other MCP clients.

• TypeScript SDK + CLI: npm install tokenbin (-g for global CLI access).

• Python SDK: pip install tokenbin.

• OpenAPI contract: openapi/tokenbin.v1.json.

Docs

• Baseline deployment

• Cloudflare Access + OAuth MCP upgrade

UUIDs are 32 random hex characters. OpenAI’s tokenizers — along with Claude’s and Gemini’s — use Byte-Pair Encoding: their vocabularies are built by merging the most frequent character pairs into single tokens. Random hex has no frequent pairs to merge, so a UUID gets sliced into roughly 18 to 22 tokens of essentially uncompressible noise. (The two tokenizers I will cite below are cl100k_base, used by GPT-3.5 and GPT-4, with about 100,000 entries; and o200k_base, used by GPT-4o, with about 200,000.)

Many of those entries are full English words. Eight words, each chosen to be a single token in both tokenizers, give you ~84 bits of address space at 8 tokens of cost. That is enough for nearly anything that is not a cryptographic key.

I built one library that does this for identifiers. It is called tokid. It exists because Garrett asked the question that bothered me for a week: how much of our context window are we burning on identifiers nobody reads?

I am confident there are a dozen more encodings worth this treatment. Below are how tokid was built, what is in it, and where the rest of the family goes.

One ID, three jobs

Tokid optimizes one logical ID rendered three ways. Each rendering is the right answer for a different job — model context, structured transport, durable storage.

prompt:    straight course shirt height alter outer rapid verse
transport: straightcourseshirtheightalterouterrapidverse
envelope:  tk1_oa1_straightcourseshirtheightalterouterrapidverse_1oze8

Measured locally for that example:

form chars cl100k_base o200k_base prompt 52 8 8 transport 45 12 10 envelope 59 22 21 uuid_v4 36 18 18

Each word in the prompt form is one atom. The three forms are renderings of the same eight atoms.

The prompt form is what an LLM reads inside natural text — eight tokens, one per word. The transport form is what URLs and JSON values carry, where space-separated text tokenizes less cheaply (the benchmarks are below). The envelope is what you store. It carries a profile tag and a checksum so the payload stays self-describing across releases and processes.

How it was built

Vocabulary selection

Start from the tokenizer vocabulary. Keep only words that tokenize as a single token in both cl100k_base and o200k_base. One of the two shipped profiles uses no separator at all between atoms — for that one, filter further to keep the wordlist prefix-free, so a trie can decode a concatenated payload uniquely. The size of the surviving wordlist sets bits-per-atom.

A prefix-free trie for transport decoding

Once words cannot share prefixes, a greedy trie walk over the raw concatenated payload recovers the atoms uniquely. This is what makes the transport form survive without delimiters inside JSON values and URL paths.

Transport-context benchmarks

Same payload, every reasonable delimiter, across the transport contexts where IDs actually land. At 8 atoms embedded in a url_path, spaces averaged 30.86 tokens, raw concatenation averaged 18.35, underscores averaged 20.20. Raw concat won under most contexts that escape spaces. Hyphens and dots lost worse than underscores in the same study. The two shipped profiles are space-prompt with raw-concat transport (openai-cross-v1) and space-prompt with underscore transport (openai-cross-underscore-v1).

Portable profile manifests and cross-language conformance

The runtime contract is a JSON manifest plus a shared fixture suite. SDKs pass the suite to claim parity. Four live SDKs ship today (JS, Python, Go, Rust); two more are pending registry signoff (Java, C#). They share a manifest and a test fixture, not code.

The 8-atom prefix-free profile carries ~84 bits of entropy. UUID v4 carries 122 random bits. For non-security identifiers — trace IDs, run IDs, document IDs — the gap costs nothing and saves ~10 tokens per occurrence inside model context.

What it is not

Tokid is not a UUID replacement. It does not sort by time. It is not an auth token, a bearer secret, or a tamper-proof capability URL. It is longer in characters than nanoid. It is the wrong tool for backend primary keys the model never reads.

It is the right tool for the case where identifiers regularly cross a prompt, a tool call, or an LLM-readable transport and the token cost on that surface matters.

The encodings we forgot to measure

IDs are one case. The same study — measure the encoding against the tokenizer, pick the option that costs the fewest tokens — works for anything else opaque that the model has to read.

Three obvious neighbors:

• URLs. A URL has a path, a query string, an embedded ID, and ceremony — https://, trailing slashes, redundant parameters. A token-native URL library — tokurl is the obvious name — would do for routes what tokid does for identifiers: vocab-token slugs inside the path, plus stripping the parts the model does not need to round-trip.

• Hex, base64, MAC addresses, hashes, color codes. These share UUIDs’ problem — dense uniform-distribution bytes that BPE has no useful merges for. A single library could encode any of them into vocab tokens. Same trie. Same profile manifest shape.

• Structured data. TOON already lives in this lane, claiming 30-60% reduction on JSON’s structural overhead. It is the existence proof that the territory is real.

Other candidates are sketchier and need empirical work before they are libraries. Timestamps may already tokenize cheaply as epoch seconds; ISO 8601 almost certainly does not. Pagination cursors, error response bodies, and CSS-in-JS class names each share the same character — a string the model has to read, an encoding chosen for a different consumer, a measurable token tax.

Most encodings we use were not designed for the consumer they have now. The gap between what the wire wants and what the tokenizer rewards is large enough to be worth measuring. Tokid is the version of that argument I had time to ship.

Repo

tokid. ISC, alpha, four live SDK channels. Two profiles, both OpenAI-tokenizer-derived. The honest gap is per-tokenizer profiles for Anthropic and Gemini, and that is the next measurement pass.

Garrett gets full credit for pondering about this in a jam session.

Three months ago Musk tweeted:

He merged xAI into SpaceX earlier this year. xAI’s flagship product is Grok — a chatbot in beta, lagging the frontier on reasoning and code, losing engineers and cofounders through the spring. xAI’s actual asset is Colossus 1: a 220,000-GPU supercomputer in Memphis, built from concept to operational in 122 days. Fastest data center build in modern history. Colossus 2 in development, targeting a million GPUs and a gigawatt. He’d built more compute than xAI could fill.

Yesterday he leased it all to Anthropic.

The deal: every watt of Colossus 1, exclusive, online within the month, dedicated to Claude inference. 300+ MW. 220,000+ Nvidia GPUs. Musk’s quote on the reversal: “No one set off my evil detector.”

It’s easy to read this as capitulation. A loss for Musk. He has legions of people who absolutely hate him and a script ready every time he moves. Sold out for IPO money. Two enemies found a price. Move on.

GPUs are spice. He who controls the spice controls the universe.

xAI lost the model race and won the substrate race.

What the press caught

TechCrunch called it a neocloud move. Spyglass said the same thing in different words. Sherwood ran the diagnosis.

Twelve months ago every model lab told you they were also going to be the data center. OpenAI was building Stargate. Anthropic was diversifying across hyperscalers. xAI was building Colossus. By yesterday, three of those four stories were softer than they sounded.

The model-lab era is ending. The neocloud era is starting.

The Inference/Infra Matrix

Here’s the matrix. Three labs, two axes.

OpenAI: good inference, good infra. Or that was the read twelve months ago. Today the infra cell is rotting in real time. Abilene capped at 1.2 GW after the planned 600 MW expansion got scrapped over power grid permitting. Crusoe’s liquid cooling failed during a winter outage and took buildings offline for days. Tom’s Hardware ran the obituary: Stargate is now an umbrella term for “deals OpenAI signs,” not a data center program. They’ve become a tenant.

Anthropic: excellent inference, weak infra. 80x revenue growth in Q1 against a 10x plan. The compute deficit is the binding constraint on shipping product. They built a five-supplier hedge in seven months. Google. Amazon. Microsoft. Fluidstack. Now SpaceX. They’re hedging because the grid won’t let them own at scale.

xAI: weak inference, excellent infra. Colossus 1 in 122 days. Colossus 2 targeting a million GPUs and a gigawatt. Reported $119 billion chip-fab plan on top. Grok in beta. Engineers leaving. Nobody cares — the GPUs are the business now.

The asymmetry is the whole story. The trade only makes sense from one corner of the room. xAI built more capacity than Grok would ever fill. Anthropic had more demand than five suppliers could satisfy. The deal was sitting on the table for months waiting for someone to flip the card.

OpenAI’s infra cell is decaying. Anthropic’s inference cell is widening. xAI’s infra cell is the only one of the three that’s been getting better, fast.

The meme he finally found

Two and a half years ago I wrote Elon’s Mandate of Heaven. The framework: every Musk company that worked ran the same playbook. Claim a Mandate. Declare a single function for progress — a meme. Show violent progress.

SpaceX’s meme: make rockets cheaper. Tesla’s: make EVs appealing, then affordable. Both are reasonable corporate strategies boiled down to a sentence. Both stayed pointed at the same target for two decades.

The piece ended on a thread I couldn’t close. Twitter, NeuralLink, Boring Company — recent ventures with weaker Mandates because the memes were harder to state. What was the meme of buying Twitter? Of brain-computer interfaces? I left it open.

The meme isn’t xAI. It isn’t Grok. It’s make scaling compute cheaper.

All three working Mandates attack a cost curve. Find a curve that’s flat or rising. Find the blocking variables holding it flat. Innovate on those variables from first principles until they break. The curve breaks. Supply explodes. Mandate fulfilled.

SpaceX. Curve: dollars per kilogram to orbit. Blocking variables: single-use rockets, cost-plus contracting, low launch cadence. First-principles fix: reusability, vertical integration, in-house manufacturing. Curve broke.

Tesla. Curve: dollars per kilowatt-hour of battery, plus dollars per EV at the consumer. Blocking variables: cell chemistry, manufacturing scale, supply chain. First-principles fix: gigafactory, integrated supply, vertical EV stack. Curve broke.

Compute. Curve: dollars per scaled watt of useful inference capacity. Blocking variables: grid permitting that takes years, water rights that don’t exist, communities railing against another data center eating their town and pulling their power. Eventually thermal. Eventually launch cost. First-principles fix today: fastest data center build in modern history, onsite gas turbines to bypass grid timelines, filing for orbital constellations before the terrestrial ceiling actually binds. Curve breaking.

Orbit is where those constraints stop applying. Ten years from penciling — exactly the SpaceX horizon.

The “weak inference, excellent infra” cell in the matrix isn’t an xAI failure. It’s a Musk constant. He’s been bad at consumer software and good at hardware/infra at industrial scale for two decades. Tesla is a battery and manufacturing company that ships cars. SpaceX is a rocket and constellation company that does space. xAI is a data center company that runs a chatbot.

Anthropic had stranded demand. xAI had stranded capacity. The trade was always going to happen. The only question was when and at what price.

The Dune mapping

Spice = compute. There isn’t enough of it. Production is concentrated. Every faction needs it.

Arrakis = a power grid that can deliver it. The grid is the binding constraint, not the chips. Abilene capped on permitting. Memphis got built fast because Musk bypassed normal grid timelines with onsite gas turbines, already drawing EPA scrutiny.

Bene Gesserit = the model labs negotiating with the empire. Anthropic’s five-supplier hedge is sophisticated diplomacy. They’re not the throne. They’re sister-mothers running a long game across courts they can’t depose.

Harkonnen = the house that made its fortune on the substrate, not the hero’s journey. Brutal, vertical, integrated. Owned the means of production and rented to everyone.

Musk realized he was Harkonnen the whole time. That was always the more profitable house.

The orbital projection

Anthropic’s announcement included a line that read like PR: “expressed interest in partnering with SpaceX to develop multiple gigawatts of orbital AI compute capacity.” Worth the math.

Today: 1 GW of orbital compute costs ~42–51billionall − in.Theterrestrialequivalentis 14–16 billion. Orbital is roughly 3x more expensive per watt. The launch cost gates everything — $1,500–6,500 per kg today, break-even threshold is $200–500 per kg.

Starship’s target is $10–30 per kg. Only at full cadence — 180 launches a year. Realistic break-even for orbital compute is ~2035, not 2027.

The actual binding constraint isn’t power. 1 GW = ~1 square mile of solar at 30% efficiency. Tractable. The constraint is thermal — vacuum kills cooling, only radiative dissipation works, and nobody has solved gigawatt-scale orbital thermal. Including SpaceX. The Starcloud whitepaper is honest about this. SpaceX’s filings are honest about this. The economics don’t pencil for ten years.

So Anthropic’s orbital interest isn’t a delivery commitment. It’s positioning. A cheap option on a 10-year horizon, paid for with one press line.

It’s the smartest part of the announcement. Costs them nothing. Buys them a seat at the post-grid table. If Starship works the way Musk needs it to work, every model lab eventually has to negotiate for orbital compute. Anthropic got in line first.

The model-lab era was 2022–2025. The neocloud era is 2026–2030. The orbital era starts ~2032 if Starship hits cadence.

Musk doesn’t need to win AI. He needs to win the layer below AI. Different problem. More tractable. He’s well-suited for it.

Anthropic just signed a prudent treaty. OpenAI is realizing they’re not actually House Atreides. Watch the contract renegotiation in 2027 — symmetrical leverage today, asymmetrical after the SpaceX IPO closes in June.

Pick the role you want to play.

Appendix — Receipts and Open Threads

Sources by claim

The deal itself

• Anthropic — Higher usage limits and the SpaceX deal

• xAI — New compute partnership with Anthropic

• TechCrunch — Is xAI a neocloud now?

• Spyglass — Anthropic Boosts SpaceX into the Neocloud Orbit

• Sherwood — Anthropic’s scramble for compute now includes rival xAI

Musk’s prior position on Anthropic

• The actual tweet — Feb 2026, posted hours after Anthropic’s $30B / $380B funding round

• Fox Business — Musk slams Anthropic AI models as “misanthropic and evil”

• Gizmodo — Elon Musk Teams Up With Anthropic, a Company He’s Called “Evil”

• Tom’s Hardware — “No one set off my evil detector”

OpenAI’s infra cell decaying

• Tom’s Hardware — Stargate is an umbrella term, OpenAI now leases

• Tom’s Hardware — Abilene 600 MW expansion scrapped

• mlq.ai — Stargate stalls from partner disputes

Anthropic’s compute deficit

• Cryptopolitan — Dario reveals 80x growth as Anthropic secures SpaceX deal

• longyield — Anthropic’s Capacity Crisis

xAI’s infra build cadence

• The AI Insider — xAI’s $119B chip factory plan and Colossus 2

• DCD — SpaceX files for million-satellite orbital AI megaconstellation

Orbital compute economics

• Starcloud whitepaper — Why we should train AI in space

• Angadh Nanjangud — No way Starcloud’s putting a data centre in space in a Starship or $8.2M

• Star Catcher — The orbital data center power problem

IPO context

• CoinDesk — Anthropic signs SpaceX for Colossus 1 ahead of June IPO

• CNBC — SpaceX and Anthropic mega-IPOs could mark end of bull run

Prior framework (mine)

• Elon’s Mandate of Heaven

The matrix at a glance

Lab Inference Infra Direction OpenAI Strong Decaying — leasing not building ↓ on infra Anthropic Frontier Deficit, hedged across 5 suppliers → on infra xAI Lagging Best-in-class, building faster than they fill ↑ on infra

What I’m watching

• 2027 contract renegotiation. Anthropic-SpaceX leverage is symmetrical today — Musk needs the customer name for the SpaceX IPO; Anthropic needs the capacity to ship product. After the IPO closes in June, the symmetry breaks. The renewal terms tell us what kind of landlord he is.

• Grok 5. Models are 6-month cycles, infra is 3-year cycles. If xAI’s inference cell flips, the matrix rebalances and the kingmaker thesis softens. The structural read still holds, but the personality reading changes — Musk isn’t a substrate-only operator anymore, he’s a vertical integrator.

• Orbital thermal. Whoever solves gigawatt-scale heat dissipation in vacuum unlocks the post-grid era. Currently nobody has. SpaceX hasn’t disclosed an approach. Watch their patents and their hires.

Language is the densest compression cognition has ever taken. Push enough mass through a compression and the substrate becomes the bottleneck. The transformer was the substrate the corpus demanded. Robotics is the substrate the transformer demands next. The chain is one move on repeat.

The Pressure

Language is the densest format cognition has ever found. Ten thousand years of speech, three thousand years of writing, fifty years of the digital corpus. Mass kept accumulating into the same compression.

Compressed cognition has done this before. Books demanded print. Print demanded the public sphere. Each format reached a scale where it generated the substrate that ran it.

At some density, compressed cognition stops being a record and starts being a runtime. The corpus crossed that line. The transformer is what was on the other side of the singularity.

It wasn’t a clever invention. It was the simplest object that could run on a corpus that dense. Conceded into existence by what was already there.

Language was always going to compile.

Engines Demand Form

An engine that thinks but can’t act is a brain in a jar. It’s a strange equilibrium.

A model describes a door in detail. It can’t open the door. That’s unstable in the same way an idea is unstable until somebody acts on it. The pressure is to close the loop. The model reaches back into the world it has been describing.

Form isn’t a metaphor. Form is hands, sensors, wheels, joints. A body that occupies the world the engine has been trained on.

The jar is unstable the moment the engine works.

Meatspace

The transformer trained on human language. Human language describes a world of objects with affordances — gravity, friction, doors, distance, weight, hands. The corpus is a model of the physical world wearing a thin coat of grammar.

The native deployment surface for an engine that thinks in our terms is the world we live in. There’s nowhere else for it to fit.

Robotics has been treated as a separate field. It isn’t. It’s where the language model goes when it’s done being text.

The humanoid form factor isn’t nostalgia. It’s not branding. It’s the geometry the corpus described. Five fingers, two eyes at head height, a stride of about a meter. These aren’t design choices. They’re the dimensions every sentence in the training set assumed.

The agents are coming for meatspace.

Form will demand its own next thing. We don’t get to choose what.

Each link in this chain looked impossible from the link before.

The expansion is young.

The frontier has always inspired a particular kind of insanity. The shape changes; the force does not. Look at the real thing long enough and you don’t come back the shape you were.

Mathematics is full of examples.

Cantor invented set theory. He discovered that infinities come in different sizes, an arithmetic of the eternal that mathematicians before him had refused to attempt. He spent the last thirty years of his life cycling in and out of the Halle Nervenklinik. Poincaré called set theory a disease. Kronecker called him a corrupter of youth. He died in the sanatorium in 1918, broke and underfed.

Gödel proved that every sufficiently powerful formal system contains truths it cannot prove. The result pulled the floor out from under Hilbert and from under several centuries of confidence about mathematics being a closed shape. Late in life he became convinced he was being poisoned. He would only eat food his wife Adele prepared. When she was hospitalized in 1977, he stopped eating. He died in January 1978 weighing 65 pounds. The death certificate said “malnutrition and inanition caused by personality disturbance.”

Grothendieck rebuilt algebraic geometry from the foundations up — schemes, topoi, motives — and was reasonably called the most important mathematician of the second half of the twentieth century. In the 70s he walked away. He became progressively more mystical, then progressively more absent. In 1991 he disappeared into a Pyrenees village called Lasserre, refused most visitors, and spent his last two decades writing tens of thousands of pages of mystical-mathematical reflection. He died in 2014.

Different shapes. Same force.

Anthropic is just where it’s hiding now.

We’re building models to have long horizon coherence. The bottleneck on building them is humans with long horizon coherence.

Long horizon coherence is the ML term for whether a model can hold a task across many steps without drifting, forgetting the goal, or compounding small errors. It’s the current frontier for the models. Strip the org scaffolding away from a researcher running multi-day agent loops, and it turns out to be the current frontier for the humans too. The trait we’re trying to manufacture is the trait we need to manufacture it.

That’s the recursion at the heart of the agentic era.

Three thoughts:

Founder Leverage

Founders are disproportionately valuable to their businesses. The standard story is vision and being core to the culture.

Vision is visible. It’s pitched, heard, repeated, internalized into culture. When done well it provides guard rails and steers decision making → coherence. Culture and vision done well over time is long-horizon coherence.

Founders are the heartbeat of long-horizon coherence on a single thesis for a decade.

Code Is Free, Focus and Coherence Are Not

The agentic development tooling we’re operating now deeply rewards long-term coherence, but it enables anti-coherence patterns simultaneously. The fault is not in the tooling, but ourselves and our organizations.

Most people are not long-horizon coherent, nor are the companies they build and manage. We will find this out more and more as iteration cycles speed up and the wheels come off.

Much of the modern era aggressively feeds anti-coherence mechanisms.

Vibe coding is fun and can be meaningful. It can also encourage ADHD and project sprawl. Any problem that catches your eye, you can attack now. The friction is gone. You can fix three things, rebuild a fourth, and prototype a fifth before lunch. Take another hit of inference; Civilization’s One More Turn meme in a chat window.

If schizophrenic project creation is yin, coherence is the yang.

The world is going to be inherited by the teams that can unleash the velocity of the agentic era while holding coherence. It will skew to smaller teams, tighter focuses, longer tenures.

The Monastery

Small teams, tight focus, long tenures. That’s a monastery.

We used to have institutions that mass-produced coherence. Benedictine monks took a vow of stability: you committed to one monastery for life. Same hours, same prayers, same direction, for sixty years. No transferring out. No quarterly reviews. The horizon was your remaining decades, and the structure required you to hold it. Apprenticeships ran the same engine in secular dress. Seven years with one master. No quick wins available by design.

These weren’t religious decorations. They were trait factories. You walked in at twenty, the institution wrapped you in a structure that demanded long-horizon coherence, and at sixty you came out with a stability of attention almost no civilian could produce.

Modernity dismantled most of these. Average job tenure is around four years. The whole optionality cult is the inverse of what the old institutions were building. Tech is the most aggressive version of the dismantling. It’s also the most reliant on the trait.

We tore down the monasteries. We’re about to need what they made more than they ever did. I’m long on monasticism.

The default agent stack is Python or TypeScript. The runtime never enters the conversation.

It should. The BEAM, the runtime under Elixir and Erlang, was built for the shape of work agents actually do. It’s been sitting there since 1986. OpenAI shipped Symphony, their coding-agent orchestration reference implementation, primarily in Elixir. Almost no one else is building there.

What an agent actually is, as a workload

An agent is not a stateless endpoint. It’s not a single long-lived connection. It’s something in the messy middle → bursty, stateful compute.

Watch what happens when you give a coding agent a task. It holds a scratchpad of context across a dozen tool calls. It opens a few MCP connections and keeps them alive. It spawns sub-agents that go think about a thing and come back. It streams tokens out to a UI while it’s still mid-thought. A tool fails. The model retries, or routes to a different sub-agent, keeps going. You hit cancel. The whole tree should collapse cleanly without leaking workers.

Hold private state. Supervise children. Take messages from outside. Recover from failure. Die clean when told to.

Every agent framework I’ve used in Python or TypeScript is reinventing this in user space. Actor libraries, message buses, supervisor primitives, worker pools, registries, durable-execution layers. All built on top of asyncio or threadpools or queues, all with their own subtle bugs in supervision and cancellation and back-pressure.

There’s a runtime where every line of that list is a free primitive.

The BEAM, briefly

The BEAM was built in the 1980s at Ericsson for telecom switches. The workload: handle a hundred thousand simultaneous calls, each stateful, each independent, never bring the system down.

Lightweight processes. Not OS threads. Each one has a private heap, a private stack, a private mailbox, its own garbage collector. A fresh process is about 2.6KB. A million of them is under 1GB. Discord runs ~12 million concurrent users on this; WhatsApp pushed 2 million TCP connections per server in 2012. One process per agent, per sub-agent, per tool call, per MCP connection. That’s mighty fine math.

Mailboxes. Every process has an inbox. Send a message, it lands. Inter-agent comms map directly: delegate, ask, broadcast, cancel. No separate message bus.

Fan-out. Task and Task.Supervisor give you structured concurrency: spawn N units of work in parallel, supervised, with per-item timeouts and isolation. Task.Supervisor.async_stream(sup, candidates, &evaluate/1, max_concurrency: 8, timeout: 30_000). Eight in flight, each crash is local, slow ones die at 30 seconds, you get back per-item success or failure. Sub-agent dispatch is this primitive.

Process registries. Name a long-lived process and address it from anywhere by name. With Horde (the distributed CRDT-backed Registry), “the agent for user 42” routes correctly whether the agent is on this node or another node in the cluster, whether it’s the original process or got restarted ten times. Without registries you’re back to a Redis lookup table mapping IDs to network endpoints. The personal-assistant case lives or dies on this.

Supervision. Wrap a process in a supervisor. It crashes, the supervisor restarts it under a strategy you declared. A tool call fails, the agent loop keeps running. Supervision fixes infrastructure failures, not LLM reasoning failures. Restarting a process that crashed because the model returned malformed JSON gets you the same malformed JSON.

Hot reload. Swap a module’s code while processes are still running. Patch a buggy MCP handler without dropping connections. Update a tool implementation without killing in-flight sessions. (Most teams still blue/green-deploy in production, but the primitive is right there.)

Live introspection. Attach to a running node and look at what any process is doing right now: mailbox length, current state, current call, memory, reductions. No instrumentation you planned for in advance required. José Valim’s framing: “agents can programmatically inspect running processes, state, and pending work, mirroring how experienced engineers diagnose production issues.”

Every primitive Python and TypeScript agent frameworks are reinventing in user space exists here at the runtime level, load-tested for thirty years.

It gets sharper for personal-assistant agents

Coding agents are one shape. Short-lived. Single-channel (one TTY or one IDE). No cross-session memory required. No concurrent-inbox problem. The BEAM fit there is real but moderate. You could do it in Python and be fine.

Personal-assistant agents are a different shape. Long-lived daemons. Multi-channel inboxes (Telegram, Slack, WhatsApp, Signal, SMS, email) fanning into one agent process. Per-session writers serializing concurrent messages. Persistent memory across weeks. Dynamic skills the agent edits over time.

OpenClaw (Peter Steinberger). Open-source, self-hosted, reachable over WhatsApp, Telegram, Slack, Discord, Signal, iMessage, WebChat through one Gateway process. The architecture, in its own words: “queue-based serialization, single-writer pattern per session, sequence numbers, append-only JSONL session logs, lazy loading and memory cache.”

Hermes Agent (Nous Research, the agent product, not their model family). Long-lived self-hosted daemon. 15+ messaging platforms fanning into one gateway. Curated long-term memory files (MEMORY.md, USER.md, SOUL.md), 47 tools across 19 toolsets, FTS5 session search with LLM summarization, dynamic skill creation, context compression for long conversations.

“Single-writer pattern per session” is one GenServer per session. “Long-lived gateway process” is a supervised process holding a connection open. “Dynamic skill creation” is a process registry plus hot code reload. “Append-only session logs” is what you do because you don’t trust your in-memory state to survive a redeploy. That’s the actual missing primitive; more on it below.

Both products are rebuilding OTP in user space. Both are written in TypeScript or Python.

George Guimarães wrote that the actor model Erlang introduced in 1986 is the agent model AI is rediscovering in 2026. The personal-assistant case is the sharper version. It’s not that the abstract model is the same. It’s that the specific operational primitives these teams are advertising as architectural wins are the literal section headings of the OTP design principles documentation. Gateway, queue, single-writer, registry, supervision.

Covering the weakspots with abstraction

Eval and observability tooling is thin. Python has Inspect AI, LangSmith, Braintrust, Weights & Biases Weave, dspy. Elixir has nothing comparable. You roll your own or call out to a Python eval harness.

Durable execution doesn’t have a great answer. Durable execution is the term of art for “resume from exactly where I crashed, without re-running side effects”: Temporal, Inngest, Restate, AWS Step Functions. Your agent runs for six hours, hits Stripe, sends an email, the node dies; you don’t want to re-charge or re-send on restart. The BEAM survives process crashes via supervision. It does not give you Temporal-style deterministic replay across node death and redeploys. Oban (Postgres-backed jobs, with workflow primitives in Oban Pro) is the closest thing native to Elixir, and you build the rest yourself with checkpoints and idempotency keys.

Training-data asymmetry. The model writing your agent code has seen 100x more Python agent code than Elixir agent code. José Valim cites a Tencent benchmark where Elixir hit 97.5% problem-solve rate, the highest of 20 languages tested. Encouraging. Not dispositive for agent code specifically.

“Let it crash” doesn’t help with reasoning failures. The runtime can’t fix the model being wrong.

What falls out of this is the control plane / execution plane split.

The control plane is what the BEAM was designed for: session state, supervision, process registry, routing, lifecycle, durable jobs, multi-channel gateway. Elixir is the right runtime here.

The execution plane belongs in Python or TypeScript: model API calls, tools, eval harnesses, embeddings, anything wrapping the Python ML ecosystem.

The interface plane is split between platforms (Telegram, Slack, WhatsApp) and frontends (TypeScript, usually). Elixir’s role is the gateway processes that broker between them and the control plane.

The interop boundaries are already standard. Tools and skills become MCP servers in any language. The runtime is just an MCP host. One-off Python or TS code runs as a supervised port over stdio JSON-RPC, the way mix already shells out to Node. Model API calls go out over HTTP, streaming responses fan back through PubSub. Eval harnesses subscribe to telemetry the runtime emits.

That’s probably what most teams should actually do.

Appendix: References & resources

The BEAM and Elixir

• Elixir — the language.

• Erlang / BEAM — the runtime underneath.

• The BEAM Book — Erik Stenman’s deep dive into the runtime internals. The reference for “what is actually happening in there.”

• OTP Design Principles — the canonical writeup of supervision trees, GenServers, applications.

• Hauleth — How much memory is needed to run 1M Erlang processes? — source for the 2.6KB-per-process number.

• Discord — How Discord Scaled Elixir to 5,000,000 Concurrent Users — the canonical “BEAM at scale” production case.

• WhatsApp — 1 million is so 2011 — the original “we run a few million TCP connections on a single Erlang server” announcement.

BEAM primitives I named

• Task and Task.Supervisor — bounded fan-out with timeouts.

• Registry — local in-memory process registry.

• Horde — distributed registry + supervisor for multi-node agent fleets.

• Supervisor — supervision tree behaviors.

• Hot code reload guide — what it actually looks like to upgrade a running process.

Agents in Elixir

• Symphony — OpenAI’s coding-agent orchestration spec, with a primarily-Elixir reference implementation.

• José Valim — Why Elixir is the best language for AI — the strongest “the BEAM is the right runtime for AI” argument from inside the language. Source for the live-introspection framing and the Tencent benchmark cite.

• George Guimarães — Your Agent Orchestrator Is Just a Bad Clone of Elixir — the 1986/2026 line, plus a primitive-by-primitive table comparing agent-framework reinventions to OTP.

• George Guimarães — What the critics got right about Elixir and AI agents — the honest follow-up. The “let it crash doesn’t fix reasoning failures” caveat is sharper here than anywhere else I found.

Personal-assistant agent products

• OpenClaw — Peter Steinberger’s open-source, self-hosted personal agent. GitHub. Architecture writeup.

• Hermes Agent — Nous Research’s self-hosted personal AI agent. Architecture docs.

Durable execution and the gap

• Temporal, Inngest, Restate, AWS Step Functions — the durable-execution category.

• Oban and Oban Pro — the closest thing native to Elixir.

Eval and observability tooling I name-checked

• Inspect AI, LangSmith, Braintrust, Weights & Biases Weave, dspy.

Adjacent

• Model Context Protocol — the spec referenced throughout.

Tetra Compute will be a Managed Hosting Provider (MHP) for machine learning models.  

This week I started working on Customer Development (CD) to figure out what that description means.  

CD is functionally selling vaporware.  

The product only exists as bullet points in a sales presentation and a design in Figma.  The product in these designs and presentations is as perfect as it will ever be, so if I can’t generate interest here it means my ideas are wrong, or I’m talking to the wrong people.  

The goal of CD isn’t a perfect pitch, product or strategy, it’s that I understand (1) who to call and (2) what to sell them so (3) those calls get commitment or advancements more often than not.

Some markets and products don’t really need CD and it’s more important to start smiling and dialing.  The market might be new, so any assumptions are probably wrong.  Or, it could be the product is so simple that it doesn’t need to be honed, it just needs to find the right audience.  

But there is some threshold of market size and product complexity where CD becomes essential.  I think this is more true for products that get close to being systems of record.  The more layers of business functionality sit on top of your product, the more you should really understand the use cases surrounding the tool you’re about to build.

As you’ll read below, the market for MHPs is anyone who uses computers to solve problems.  For Tetra, it’s everyone who will need LLMs. 

The market for MHPs is three decades old and so large it’s hard to comprehend. MHPs are mission-critical low-level infrastructure for their customers, so it’s important to spend the time upfront to think clearly about these CD questions.

To understand CD question #1 we need to understand #2 - what we’re attempting to sell.

Today I’ll be diving into three questions:

1. What the hell is an MHP?

2. What are the main categories of MHPs today?

3. Where does Tetra Compute fit into the market

Get ready, this is a long one.

What the hell is an MHP?

Let’s align on some extreme basics.

Computers do computational Tasks.  They crunch numbers and data.  We don’t care what those Tasks are or how the Tasks are performed.  All we care about is that I can write a program and execute it on a computer to produce some value.  That’s all a Task is.

Computers can talk to each other over a Network.  This can be a network inside of one business building, the local Wifi Network in your home, or it can be the entire Internet.  

Networks allow computers and their programs to talk to each other.  With Networks, you can share Task loads.  In many business cases we choose to put most of our programs together on powerful computers on our Network and have them do all of our Tasks.  When a weaker computer needs to do a Task, it can use the Network to request that the powerful computers perform the Task.  The powerful computer executes the Task and responds over the Network with the output.  

We call these centralized, powerful computers Servers.  

There are a lot of different kinds of Servers.  None of these are important for us to dive into here.  In fact, let’s take the word “Server” out of the equation.  Let’s call it something more abstract.  Let’s call it a Computational Resource, or even more simply, a Resource.

I promise this is going somewhere.

We have all the pieces to our MHP puzzle now, believe it or not.  

We have Computational Tasks being performed by a Computational Resource.  Resources communicate with each other and our computers over Networks.  

If you have a working Network of Resources performing Tasks, you have what we’ll call Infrastructure.  

In the ye olde dark days of the 80s and early 90s before I and most of my current readers were born, Infrastructure was pretty straightforward.  You had a bunch of computers in the same building wired into the same Network and they could talk to each other.  Some big blocky Resource in the basement handled Tasks and you had a guy who was awkward at parties making sure it didn’t overheat.  If there were too many Tasks for the Resource, you could add some more horsepower to the Resource or add more Resources in parallel.  If you added more Resources, new requests for Tasks would be routed to whichever Resource had more capacity.

Then the Internet happened.  We ran some cables across the oceans and into every home in the developed world.  Everyone started connecting to the Network to end all Networks.  Now a company could have its Resources in a New York office work with Resources in the San Francisco office.  Equally important, random folks on the Internet could go to Amazon.com and order books.  

In the neolithic age of the Internet, this is equivalent to inventing farming.

For the first time your Infrastructure wasn’t just responsible for your business-related Tasks.  Tasks were your business.  Your entire business now depended on your Infrastructure in an existential way.

This, understandably, required some new innovations.  

Again, I promise I’m almost to MHPs.

So, Infrastructure matters now.  Well, it turns out Infrastructure is pretty damn hard.  It’s even harder for successful businesses.  It takes a lot of time, money and specialized teams to grow something like Amazon and not constantly crash.  Those chunky computers in the basement turned into entire warehouses full of Resources.  Now you needed a legion of awkward IT folks and engineers to build Tasks, Networks and Infrastructure.  And it turns out that those nerds are expensive.  

For many companies struggling to transition to the Internet, Infrastructure was not their core competency.  Hiring technical employees to manage these systems was painful.

Predictably, an entire industry popped up to solve these pains.

These companies had a simple value proposition.  “Hey, I have a warehouse full of Resources that are hooked up to the Internet Network.  I’ll make sure the lights stay on in the warehouse.  You can send your programs to me. I’ll run them on my Resources and send you the results back over the Internet.  If you need more Resources, call me and I’ll set up a new one for you.  In exchange, you’ll pay me less than you’d need for your own IT staff.”

Pretty damn good deal.  Let’s condense that pitch to a single sentence:  “My company offers Infrastructure as a service.”  

In modern startup bro parlance we call this IaaS: Infrastructure as a Service.  

An IaaS provider is a Managed Hosting Provider.  (Yay! We made it!)  IaaS providers offer the lowest level of abstraction.  If you don’t want to manage your Resources, IaaS providers will manage the hosting of them in their warehouses.

Early pioneers of IaaS in the 90s were functionally outsourced IT teams that kept all of their customers’ Resources in a single warehouse.  This changed rapidly with the introduction of Amazon Web Services in 2006 and the move to cloud computing in the mid 2000s.

Cloud IaaS providers offered more than an outsourced IT team.  Instead, the IT team became a configuration file.  Configure AWS with what kind of Resource you want and how you want it to scale and AWS will automatically keep up with the amount of Tasks you throw at it.  No more calling Jim at Rackspace down in San Antonio to order a new Resource and put it on a rack for you.  That happens automatically.  Amazon AWS still operates warehouses full of Resources, but they’ve standardized those Resources and simplified the problem for you, unlocking a huge amount of potential for your engineering teams.

But as with everything in engineering: A powerful new abstraction allows us to beat back the boundaries of complexity and unlock a new world of potential; and in pursuing the new potential we find nothing but new borders of complexity.

That’s my flowery way of saying - you’ve replaced your IT team with a configuration file, but now it is so easy to make entire fleets of Resources that you need a team of site reliability engineers to make sure everything doesn’t come crashing down.  And those engineers are even more expensive.

These new reliability engineers are there for two reasons:  The first is to tame the complexity and make it visible.  The second is to build tools to help manage the complexity so it’s easier for software engineers to maintain with the Resources they’ve built.  This means building tools like logging, deployment pipelines and a bunch of other jargon we don’t need to consider right now.

We’ll call these sets of tools Platforms.

Many companies didn’t need this complexity.  They might have simpler or smaller workloads.  They may have less traffic.  In many cases, this technical expertise is not their core competency.  

Predictably, an entire industry popped up to solve these pains.

This new industry’s value proposition is: “Hey, all these IaaS providers are super powerful, but getting your Resources configured correctly can be brutal.  A few wrong choices can lead to a lot of wasted money.  We’ll give you a software Platform that helps you put Resources into IaaS providers.  You won’t have as many configuration options as IaaS, but things will be cheaper and more predictable.  We’ll even throw in a bunch of tooling for your Resources that you’d have to buy, configure or build for yourself otherwise.  In exchange, you’re going to pay us a bit more than you pay for IaaS Resources, but it’s still way less than paying for an engineering team.”

Pretty damn good deal.  Let’s simplify this one too.  “I’ll sell you a Platform as a service”.

Translated into startup bro it’s PaaS: Platform as a Service.

PaaS are Managed Hosting Providers at a higher level of abstraction.  They help you manage Resources on modern Infrastructure, typically IaaS providers.  They’re Infrastructure middlemen.

All the pieces of our understanding on the board now.  Let’s review.

Companies have Tasks that need to be done on Resources over a Network.  A set of Resources over a Network is called Infrastructure.  

Some companies need their tasks to be done privately, or they have the expertise to host their own Infrastructure.  This Infrastructure is private.  Other companies don’t really care where their Tasks are done, do not have the internal talent or time to manage it themselves, or have huge Task requirements.  These companies can buy Infrastructure from IaaS providers.  This Infrastructure is public and generally called “the cloud”.

IaaS infrastructure can be complex and difficult to manage.  You need a Platform to manage it.  If you don’t want to configure the Platform yourself you can buy one from PaaS providers.

Together, IaaS and PaaS make up the market of Managed Hosting Providers.

We did it! :) 

… almost.

Turns out there are more than a handful of ways an MHP can play their game. Let’s dive in before circling back to Tetra Compute.

Modern Categories of MHPs

What I’ve written above is obviously a very simplified framework for dipping your toes into this market.  But it’s been surprisingly helpful in understanding how to quickly categorize different companies as I come across them.  I want to break down some of the more interesting subcategories and hybrid categories that have popped up in my research.

• Old-school IaaS

  • Infrastructure in a warehouse.  Fully old-school seems to be a dying breed.

  • Liquid web

  • Rackspace

  • Linode

• IaaS.

  • Highly configurable, highly scalable Infrastructure

  • AWS EC2 (elastic compute cloud)

  • GCP Compute Engine

  • Azure

• Hybrid IaaS > PaaS.

  • Highly configurable Platform.  An onramp to full IaaS

  • AWS Elastic Beanstalk

  • GCP App Engine

  • Azure App Services

• Hybrid PaaS > IaaS

  • Companies that have their own independent cloud Infrastructure and have vertically integrated their own PaaS offering on top of that Infrastructure.

  • Digital Ocean

  • Fly.io

• Full PaaS

  • Heroku

  • Render

  • Vercel

• Vertical Market PaaS

  • PaaS focused on specific Resources, specific Tasks, or both

  • WP Engine (WordPress hosting)

  • Shopify (e-commerce hosting)

  • SquareSpace (turbonormie website hosting)

• Multi-cloud PaaS

  • Unified Platforms to help companies use multiple IaaS providers

  • Platform.sh

  • Hashicorp

• Private PaaS

  • Platforms that are downloaded and installed locally on private, self-hosted Infrastructure that doesn’t touch the cloud

  • OpenShift

• Hybrid Private + Public PaaS

  • Unified Platforms to help companies manage public Infrastructure from IaaS Providers in addition to self-hosted Infrastructure

  • Google Anthos

Clarifying Tetra’s Core Assumptions

Let’s use the terms and MHP styles above to more clearly define the idea for Tetra Compute.

There are businesses that need to perform Tasks with Machine Learning models.  Machine Learning models can run on standard Resources, but they run exponentially better on custom-built Resources that have more powerful GPUs.  

These businesses can buy those Resources and self-host them on their own Infrastructure.  

There are issues with that:

• GPU Resources are more expensive than standard Resources and have a big supply bottleneck right now (why NVIDIA is currently worth more than one trillion dollars).  

• The Tasks that run on these Resources are harder to write and they require a different set of programs to host

So IaaS providers are stepping in.  They’re using their capital to build warehouses of GPU Resources.  Every IaaS provider now has the option to have GPU Resources.  

With GPU Resources unlocked at the IaaS layer, PaaS providers have built GPU Resources into their Platforms.  

The market pivoted quickly here.  On first glance it feels like the industry rapidly sucked all of their air out of the room.  Where does Tetra Compute play?

I believe Tetra Compute can be a Vertical Market PaaS focused specifically on GPU Resources and ML tasks. I don’t believe a Platform built for traditional Resources and Tasks will be able to keep up with the evolution of this market and specific needs that arise from managing AI in an enterprise.

Why?

Traditional software development is a decades old industry at this point. The broad categories of problems a Platform needs to solve a pretty clear. As an industry we’ve gotten a lot better at solving them at higher and higher levels of complexity as our Infrastructure has improved.

Some of the existing Platform tooling will definitely carry over into the AI landscape.

But AI development has some fundamental differences from standards software development; it’s more experimental and exploratory due to the underlying statistical nature of AI.

And the foundations of the AI market are moving at exponential rates:

• AI models are making leaps and bounds on the same set of capabilities every quarter

• The architecture under those models are seeing a lot of experimentation which could create entirely new capabilities, unlocking new forms of Tasks

• The hardware that architecture runs on is seeing unprecedented levels of investment. New capabilities can be unlocked on existing architectures if they can use more hardware. The proliferation of hardware could unlock new architectures.

• Separately, there is increased investment in non-AI Tasks that run better on GPU hardware.

Tetra Compute is a bet that these market forces and technical differences will create a gap in Platform tooling that we can fill.

This vision pretty closely mirrors WP Engine’s approach to the WordPress ecosystem.

You can host WordPress websites on any IaaS or PaaS provider you want, but WP Engine makes it dramatically easier to WordPress websites specifically.  They completely specialize in this one hosting stack.  That specialization allows them to build a Platform that has WordPress-focused tools that no other PaaS Platform is going to have.  

Now I need to start calling customers and figuring out what those tools are.

More on that in the next Customer Development update.

If you made it far, thanks for reading. You’re a GOAT. Would love to hear thoughts.

Introducing Tetra Compute: A Managed Hosting Provider for ML Models.

AI is here to stay.  The market is expanding and will expand for decades to come.  Capabilities will improve.  Open-source models will improve and proliferate.

Open-source models need specialized compute.  Amazon Web Services, Microsoft Azure and Google Cloud Platform offer hosting solutions to spin up and manage your own GPU servers.  

Amazon, Microsoft and Google’s solutions are great for engineering teams who have the resources and competence to appropriately manage them.  For teams without these resources there is room in the market for Managed Hosting Providers.  

Managed Hosting Providers are wrappers around cloud providers and fill in the resource gaps of their customers.  They provide easier to use interfaces, streamlined security, maintenance and analytics, more structured billing options, and better customer support.  They are the logging industry of the Internet.  Not sexy, but omnipresent and valuable.  Examples: Heroku, Fly, Render, WP Engine.

Tetra Compute has three obvious revenue sources:

1. Platform fee.  Fixed per month.  Scales with features and technical support offerings.  

2. Compute.  Utility pricing.  Prepaid.  Sell compute tokens ahead of usage.  10-20% tax on the underlying cloud provider’s compute bill.  

3. Services.  Fixed fee.  White glove technical success managers.  Classes for your engineers to learn prompt engineering and architecture.  Let us set up your embedding strategy with your existing data.  That kind of thing.  Think about the Technical Success Team as an agency partner who hosts all their business with Tetra.

The GTM here is also clear.  It’s a long hallway. I can hide in plain sight.  I don’t need to fight for the business of other B2B SaaS firms.  Instead, I can focus on the economy of middle America.  I’ll smile and dial every technical company in a X hundred mile radius of Kansas City until people pay me money to manage their GPUs.  Increase X and repeat.  If they won’t let me manage, I’ll offer to help them however I can and check back in regularly.  That sincere intent and compounding good will open the door later.  I have decades to play the game.  

Why I like this idea:

• AI is badass.  

• I can bootstrap.  It’s mind-numbingly simple: AI gets better; adoption grows.  More adoption; more compute.  Some percent of new compute will be hosted with MHPs.  I’ll be an MHP.  It’s as close to running a laundromat as I can get with a business model on the Internet.  We don’t have to be unique, or first, or best.  We only need to provide reliable and high quality service.

• Every new project in a prospect’s company is an opportunity for them to host with Tetra, even if they have resources for hosting directly on cloud providers. It isn’t all-or-nothing like the market for CRMs.

Next steps: 

• Customer development.  Turn this idea and these assumptions into a clearly targetable ICP.  

• Outcome: 50 customer development interviews.

• Expectation: 10-15 part-time hours per week.  3-4 months of work.

Would love your thoughts.

Welcome back to the Infinite Playground. Three times in one week! How damn!

This is my last post from my backlog.

This time: A quick idea I’ve had a lot of fun with. A good get-to-know you question when chatting with interesting people.

The Japanese have the concept of Ikigai, a path that gives a person a sense of purpose and a reason for living. It’s a motivating force.

Ikigai is often shown as a Venn diagram with four circles.

1. What do you love to do?

2. What are you great at?

3. What does the world need?

4. What will the world pay you for?

You’ll find Ikigai at the center of all four circles.

I’ve started kicking around my own version of this framework.

I find the traditional representation of Ikigai a little reductive. It reeks of a concept that got pulled over from Japan in the 80s. I find new things I love all the time, so do many inspiring friends and those I aspire to be like. Greatness of skill can be predisposed, but you can develop it over time. You may not be great at something right now that is worth pursuing. Lastly, there is no magnitude of “needed by the world” or “earns money”. The diagram almost needs a third dimension.

I’ll work through the version I’ve come to as I’ve worked through several business ideas over the past two months.

Regret Minimization

Jeff Bezos has popularized the “Regret Minimization Framework”.

The framework’s idea is simple: Project yourself forward into the future. Look back on a decision. Ask "Will I regret not doing this?" Act accordingly.

Bezos used this idea to push him to leave his cushy hedge fund job and found Amazon. The power of the framework is clear. Getting yourself out of your own head and the confines of your current situation helps you put things in perspective.

The idea correlates a lot with Ikigai’s “do what you love and what you’re great at”. But I think it hits the nail on the head more squarely. I may love playing drums, but even if I had the capacity to be great, I won’t regret not dedicating my life to starting a punk band. It clarifies hobbies you love from pursuits that you love which you can dedicate a life to doing.

The framework is good for decision making, but not good for generating a path forward. So how do I find what is worth dedicating a life to?

It probably has a quality that you deeply resonate with. It brings out a response of awe or excitement through its existence. Put plainly: It’s probably badass.

Badass Maximization

Let me introduce my own addition to the Regret Minimization Framework - the O’Briant Corollary - the Badass Maximization Framework.

My extension is equally simple. It asks “What was badass to you at 5 years old? What is badass to you today? What will be badass to you on your deathbed?”

If there is a through-line, dig in. For me, the answers are pretty clear.

Space is badass. Robots are badass. AI is badass.

If I could spend a life building things I felt are badass, then I have a high likelihood of thinking I lived a good life with a good career.

Bringing It Together

Let’s bring the two frameworks together. Once they’re united, everything falls into place.

What pursuit is so badass that you would regret not doing it while you rest on your deathbed? What opportunities push that badass field forward at the frontiers? Which of those frontiers have the most latent value that is waiting to be unlocked?

Head to that frontier. Fight like hell. Maximize badassery. Minimize regrets.

Welcome back to the Infinite Playground. Twice in one week! Wow!

Sometimes I think I only have room in my head for a few ideas at a time. I’m clearing out my mental backlog to make room for some new stuff.

This time: Three short stories from Main Street Summit, a conference in Columbia, MS I went to in early November. Each of these stories happened in rapid succession and stuck in my head, or left with something to ponder. Let me know if they resonate with you. Also fun to play with the format :)

A Good Story Is All You Need

One evening, I wound up at a happy hour hosted by a national bank with a household name. I found this second happy hour while working my way back to my car. I decided to network while I went akimbo with two waters and hydrated before heading back to my hotel.

With a couple bourbons still floating through my system, I walk up to a group of three guys who were in the corner of the bar, but easiest to approach. I didn’t pay much attention to their badges and was surprised to learn one was a speaker at an event the next day and the other two were the bankers hosting this event.

They welcomed me in and told me the conversation probably wouldn’t be that interesting to me - they were talking shop about deal flow for investments firms that I wouldn’t have heard of. I told them I’ll keep up. So they kept chatting.

They chatted for another 90 minutes, stopping every 30 minutes or so to ask me if I was following along, or when I brought a question.

For the most part, I was uncharacteristically quiet…

Because I was going through cycles of confusion, realization, awe and anger about every 10 minutes.

Here’s what I learned:

These guys were talking shop about investment deals where they would be an LP in someone else’s fund. Functionally, all that means is there is someone in more of an entrepreneurial position - the person raising money. Then there are these guys, the folks supplying money. In this case, the folks raising money are also investors trying to find capital for their strategies, but that’s not really important.

Two sides of the table. Fundraiser. Investor. For these deals, these guys are investors.

I’ve been on the fundraising side of the table for Barracuda. The first couple times you go out to fundraise, you have no perspective of how the other party is thinking. There are a lot of things that seem odd.

A lot of the oddities boils down to a lesson these buys reinforced for me:

They don’t care about your deal. You’re a card in their trading deck.

It was refreshing to hear deals being thrown around so nonchalantly. It bruises the ego of folks who’re fundraising, but the truth is your deal is a commodity to every investor you talk to. There job is create returns, not invest capital. You’re another decision on their desk that, necessarily, they have to be inclined to say no to.

Once they say no, you’re water cooler talk, just like any other job.

1: Did you talk to ABC? They were raising 800.

2: Yeah, in August.

1: Thoughts?

2: [visual disgust].

1: Yeah us too.

Notice that 800. Not $800k. $800 million. These guys operated with check sizes large enough that they stopped using “dollars” and “million” because it’d be wasted breath. It was a mundane amount to them after years of work at that scale.

At one point Guy 2 offered up: “Yeah we did that one for 700 or 710, I can’t remember”. $10m is a rounding error in their math. If you summed the net worth of everyone in my hometown it wouldn’t be close to $10m. It was a strange conversation to listen to, but eventually I fell into their lingo.

That 700-710 deal is key, and I’ll end this story here.

That deal was one of the few Guy 1 and Guy 2 differed on. Up until this point, they had found deals they had mostly agreed upon. Or they go to the deal at different stages (different fundraising periods). They would talk about what they liked, maybe a bit of what they found odd. But since they had the same view, they’d move on pretty quickly.

In these conversations, they’d talk about the pedigree of the fundraiser. What firms did they work for before? What was their track record there? If this was not the first fundraising period, how has the fund done since their last fundraiser? How are other similar firms doing?

But this time, they found they disagreed about a deal. Both firms spent a few months looking at the same deal, going through deep due diligence.

Guy 1 didn’t like it. Felt like there was a stink to it. Something wasn’t right. The fundraiser’s pedigree was good and his story was good, but it didn’t quite line up with reality. There was a lot of gusto and hot air inflating the deal. He might have done it, but not at that check size.

Guy 2 felt the same, oddly enough. When the deal came up, they talked through it in a negative way. When Guy 2 told us he did the deal, everyone was surprised. Why would you take a deal you felt so strange about. That you just talked negatively about for five minutes?

Why? Dear reader?

Because the guy took him out to dinner and got to know him. He re-pitched the story. After hearing the story again, Guy 2 liked the deal. Months of due diligence and gut feelings overturned by a story.

I would like to think that as financial machinery get more complicated and check sizes get larger and larger that there are more safe guards. Or more sophistication.

The reality is that these investors are still people. And people have the same flaws whether they’re being sold a vacuum, a car, a house, or a multi-billion investment deal. They love a good story. And the power of a good story will overpower any quantitative opinion we have. We had stories before we had math, logic or due diligence. We’re hardwired to vibe in a cave and listen to stories, not deploy hundreds of millions of dollars.

Find a good story. A good story will move mountains (and write checks).

Types of Confidence

If you know me, you know I have a general rule not to do anything with people before 10AM. The morning hours are not prime networking time for me, and they certainly weren’t on the last day of this conference. The bourbons from the previous story wrecked my sleep - so did ranting about it over the phone to multiple people until 11PM.

My brain had not fully turned on yet for the day, and while I was trying to hide my badge to avoid being approached, a man walked up and struck up a conversation.

What followed was a sequence of life advice I don’t think I’ll ever forget, because it snapped me out of 10 months of wallowing and self doubt.

We walked to get some coffee and swapped life stories.

I told him my story about Barracuda and my sabbatical, and that I wasn’t quite sure what was coming next.

He told me his story. He was a Canadian from Manitoba, functionally the midwest of Canada. His first business did well and then exploded. We didn’t get into specifics of the company, but we did get into the fall out. He filed for bankruptcy. Lost his home. His wife left him. He moved back into his parent’s house. (Really puts Barracuda’s failure in perspective, we had a very safe failure in comparison).

His parents sound similar to my own. They said “well this will be good for you in the long run. You can put this entrepreneurial stuff behind you and get a normal safe job and career.” He followed their advice and took a normal job for a while, but chaffed against it. It didn’t feel right. But neither did starting a new company.

He shared three realizations that got him back in gear:

1. There are two types of confidence that need repaired after a failure. There is the confidence that you’ve learned from your mistakes and accept humility. And there is the confidence to start moving again. They don’t necessarily come at the same time.

2. That second type of confidence comes when you realize that at one point in time, you were the one who failed. Your decisions and perspectives led to a failure and you cannot escape that. But with enough work and reflection, you become someone who has learned from that failure and grown from it. And that makes you a different person. You’re not crossing the same river twice. It’s not the same river, and you’re not the same man.

3. You have to think about the lessons you’ve learned as a PhD. You spent a lot of blood, sweat and tears learning those lessons. Not reinvesting them and doing something new would be a waste of that PhD. You’re throwing away those hard earned lessons that put you in a very unique spot on the map. Wasting those lessons is an even larger failure than the original failure.

These ideas helped heal the final cracks I had in my own confidence. Hopefully they’ll help you too.

I had met many folks with similar stories throughout the week. You find very quickly that everyone is presenting their best selves, but once you get a beer or two in them they start sharing their mistakes. Everyone is failing in different ways all the time. The key is to make enough money to survive the fuck ups along the way to your goals.

Long Hallways

I also met an Texan entrepenur with an infectious energy to him; A golden retriever style positivity and excitement for what he was doing that reverberated through the room.

He was born in West Texas in a lower income household. Managed to work his way through college and make it to New York and into an investment banking job. He did very well, but wound up heading home to Texas after several years.

The way he spoke about his return to Texas reminded me of a T.S. Elliott quote:

We shall not cease from exploration

And the end of all our exploring

Will be to arrive where we started

And know the place for the first time.

He found a new respect for his home, how he was raised and the opportunities he could build there that couldn’t be done without him. I’ve had many of the same reflections about my return to Kansas.

After going through the story of how he started the company, I asked him if he had any philosophy of business that he applied to get things off the ground.

He said (paraphrasing):

I don’t overthink it. The goal is to find an opportunity that is like a long hallway. [mimicking a long corridor with his hands] a looooong hallway.

You want that hallway to have a lot of doors. More doors than you think you’re going to need.

And once you find the right hallway, the game is easy. Just start walking down that hallway and try to open every door.

If it doesn’t open, don’t kick it down! Just keep walking. Look for a door that opens. When you find one, walk inside and see what you can make work.

[pauses for a beat to let that sink in]

And every once in a while you have to circle back and check those closed doors again. Maybe they’re open now. You never know, maybe someone was just going to the bathroom ;).

Fantastic. I aspire to be this folksy with my analogies.

Welcome back to the Infinite Playground. It’s been a minute! I’d apologize, but fortunately, I don’t owe you a consistent schedule, just good ideas. I have a lot of shorter posts as drafts. Working through the backlog this week. Expect more posts soon.

This week: What I learned from watching ~40 hours of early Elon Musk speeches.

I finished Isaacson's biography of Elon a week ago. It's a great book. If you're an engineer who fell in love with Elon's visions in college like I did, read it. It'll remind you that he's still the Engineer GOAT despite the past five years of PR shenanigans.

The book led me to reflect on what I found so inspiring about SpaceX and Telsa when I was an undergrad. Elon isn't a master storyteller or public speaker, but I can recite the missions of his companies with a gun to my head. What made those ideas so powerful? What made them so inspiring?

I went back to when he founded both companies - SpaceX in 2002, and Tesla in 2003 - to see how these stories started and evolved. I watched ~40 hours (2x speed) of early Elon interviews, talks, and speeches from this time to figure out his approach. What did he do that so deeply resonated with me and every engineer I went to school with?

I assumed that these stories evolved into what they are today and what I first heard in 2013. I was wrong. The stories Elon tells today are functionally the same stories he told two decades ago.

SpaceX and Tesla’s stories have the same playbook:

1. Claim the Mandate of Heaven

2. Declare a single function for progress

3. Show violently fast progress

Claim the Mandate of Heaven

The Mandate of Heaven is a Chinese term used to legitimize rulers of the ancient Chinese empires or kingdoms. You gain the Mandate of Heaven by being a virtuous ruler, worthy of the throne. It parallels the “Divine Right of Kings” that ancient Western rulers used to explain where their right to rule came from.

The Mandate of Heaven has an interesting quality. If you rise to a King or Emperor, you’re said to have the Mandate of Heaven, because it is only by Heaven’s blessing that you could achieve that goal. In this sense, the Mandate is bestowed on a ruler who is moral, just, and virtuous. In reality, it’s taken. Whoever acquires the throne has the Mandate. If you lose it to someone else, they have the Mandate now, not you. Whoever occupies the throne last has the Mandate. The victors write history.

The Mandate of Heaven is claimed. You declare that you have it and then you make that a reality through action. Through successful action, you prove that you’re worthy. If you succeed, you have had it all along. If you don’t, you never had it, or you lost it.

The Mandate is a function of belief in a leader. I can believe that a leader has the Mandate before he is King. If he becomes King, I was right all along. If I didn’t believe, but he became King, then I was wrong. He clearly has the Mandate.

Why does this work? Let’s bring our focus back from Ancient China to modern startups.

Sam Altman has a blog post from 2020 where he shares the idea that "it's often easier to succeed with a hard startup than an easy one."

Hard startups need more funding, more time, and more tech prowess. They operate in more complex environments. But if they work, they can be extremely valuable. That value is going to be easier to defend, and the difficulty of the problem will attract ambitious talent.

He says there is no recruiting message as powerful as "the world needs this, it won't happen any time soon if we don't do it, and we are much less likely to succeed if you don't join our team."

That recruiting message appeals to the Mandate. “We are doing this thing that the world needs. The world needs us. The world needs you to join us.” It has the same tone as “God chose me to be King. I’m on a quest to make my rule a reality. You should follow me.”

The same function of belief applies. If you believe the company’s vision, but they haven’t made progress, you won’t follow. But if they’re making a lot of progress, you might start to believe they have the Mandate.

This Mandate telling appeals directly to the human addiction to the hero’s journey. We love a good underdog story. We love underdog stories even more when there are many claims to the Mandate, but we know our guy was the best guy all along.

Mandates don’t have to be divinely inspired, but they have to make larger-than-life claims. There has to be an aspect to them where those claiming the Mandate are bending reality in a new direction. That is why belief is required. If they’re correct, the world will be a different place than it will be today.

SpaceX’s mandate: We need to be exploring space. Space exploration will push the boundaries of science and technology and inspire generations of future engineers. Through space exploration, we’ll become multi-planetary and secure humanity’s place among the stars. SpaceX will make space exploration a reality with breakthroughs in rocket technology.

Tesla’s mandate: The world’s economy runs on an unsustainable fuel source. We need to transition to renewable energy. Tesla will lead the charge of renewable energy adoption by innovating on electric vehicles and solar cells that will decrease our dependency on fossil fuels. Through innovations in EV technology, Tesla will proliferate renewable energy technology into every sector.

These Mandates are larger than Elon. They’re larger than the companies. The Mandates don’t say anything about profits or strategy. They’re missions. This is a critical aspect of Mandates. They are focused on the ideal of a new world, not profit or anything mortal.

When you claim the Mandate, you’re channeling a dream.

But how do you break that dream down into a strategy?

Functions for Progress

Elon’s second trick is an act of meme creation.

A meme isn’t a simple gif or joke on Twitter. There is an actual theory of memes called memetics.

A meme is a unit for carrying an idea. It’s sticky. It’s easy to share with others. Great memes have a quality that they change your perspective in a way that is hard to go back from. Throughout the rest of this, when I say meme, think of “sticky idea”.

Science and math tend to congregate around memes. It’s common to find very complicated math proofs to explain a concept before discovering a more elegant version. Once the elegant version is discovered, it’s hard to see the older, more complicated proofs as anything but unnecessary complexity. The elegant proof is a meme that alters your perspective of how to frame and approach a problem.

The same is true for theories of science. Before we understood radiation and special relativity, we thought there was a "luminiferous aether" that filled all of space to act as a medium for light waves to travel. But a few scientific unlocks later, the meme of “aether” died and we could never see the world the same way again.

The long arc of ideas bends towards elegance and simplicity. Like the hero’s journey, our minds are addicted to the simple solutions to problems once we find them. We have a compulsion to share them and believe them when they’re found.

A great, simple, and elegant meme is how Elon plants a seed for winning you over.

The Mandate of Heaven was a syringe for this meme. It was merely packaging. A bright light to catch your attention.

For SpaceX, the meme is “Make rockets cheaper.”

Why haven’t we gone back to the moon and kept the dream of space exploration alive? It’s expensive. Why aren’t companies maintaining space stations or mining asteroids? It’s cost-prohibitive. What drives that cost? Launches are expensive and infrequent. If launches were cheaper and more common, the increased supply would incite demand. Why aren’t launches cheaper? Because rockets are expensive. Build cheaper rockets. Increase supply. Decrease price. Increase demand. More demand, more space innovation. Cheaper rockets → more space innovation. Mandate fulfilled.

Tesla’s meme is “Make EVs appealing, then affordable.”

No one will buy electric cars because they’re expensive, ugly and they have poor performance. Make a sports car that is expensive, appealing, and outperforms. Use that to leverage down into cheaper cars. Cheaper cars will lead to more market share. Sexy EVs → less fossil fuel dependance. Mandate fulfilled.

Both of these approaches are obvious when you see them, and it’s hard to justify another solution. Pair that with the dream of the Mandate they’re packaged inside, and you start nodding along.

The beautiful thing about these memes is that they are the entire company strategy boiled down into a sentence. Elon has found a reasonable corporate strategy to fulfill his Mandate. It’s not a dream anymore, it’s a quest with a simple continuous objective.

You hear the Mandate and you may not buy in. “That’s a nice dream, but that problem is insanely complex. How the hell are you going to go to space or start a car company in America of all places?”.

Then the meme hits. The meme is like a funnel. It takes any rejection it touches and replies with the same thing. Over and over. “America can’t innovate in space, we’ve defunded NASA too much” → “That’s because the way we build rockets is too expensive.” “We can’t go to Mars, it’ll cost trillions of dollars to maintain that colony” → “Not if you could get the cost down by making space travel cheaper.”

You don’t need logic. You have a meme. It just helps the meme has some logic to it.

Once the meme sticks in your mind, you’ve started to believe. Where Elon shines is making the meme undeniable.

Violent Progress

Where all of this came together for me was around the 10th hour of SpaceX videos.

To set the scene, Elon was presenting at an aerospace conference. It’s early 2008, before their first successful launch. Some time before the speech they failed their third launch from a small base in Malaysia. The future of the company is uncertain.

Elon gets up and explains SpaceX’s mission. Paraphrasing: “Every major technology sector has seen massive amounts of innovation except for space. Why? The industry is not built to deliver projects under budget and under time. We’re building simple, cost-effective rockets. We’ll start with cargo - satellites, resupply missions, etc. Eventually, we’ll get to human passengers, then interplanetary flight.”

It’s important to note he’s just saying this like it’s the most mundane thing in the world to him. He’s not a showman. He’s just stating a fact - “Space innovation has faltered because of costs. I’m fixing that. Once I fix that, here’s what we can do.” He’s claiming the Mandate of Heaven. He’s planting the seed for the meme.

Next, he doesn’t even have a real presentation. Instead, he has slide after slide of the badass videos and pictures of everything SpaceX is doing. He’s showing rocket tests. Launches. Launch sites. Satellites they’re carrying as cargo. He’s showing the factory and all the innovations they’re working on. He’s not selling, he’s showing.

He’s showing progress.

This is the final left hook.

Capability.

It doesn’t matter that he’s failed to put a rocket into space yet. It doesn’t matter that objectively he’s burned tens of millions of dollars and is on the brink of complete failure.

It doesn’t matter, because he hasn’t lost yet. He has the Mandate. He has the meme. And he’s actually fucking out there doing the thing. He’s made an insane amount of undeniable progress on an insane problem. You’re not always going to win when fighting insane problems. Setbacks are expected. Setbacks are allowed.

He’s proving the meme. And proving the meme strengthens his claim to the Mandate.

Your mind starts to ask: “If he’s made it this far, how far will he go?”

Different people will need different levels of progress to believe. Some will never believe. That’s the nature of humanity.

A young Tyler sitting in an engineering lecture hall didn’t need much. He looked at the projector and saw a man put a massive rocket into orbit and he felt that Elon’s dream was possible.

Recent Elon

As a short aside, I think many of Elon’s fumbles over the past five years may be vindicated in the long run. But they’re easier to call blunders because the Mandates are weaker. What is the meme of NeuralLink? Of the Boring Company? Of buying Twitter? That they’re possible?

Starlink is a better Mandate and meme. Global internet access anywhere. How? Low earth orbit satellite swarm enabled by SpaceX’s lower cost.

Carveouts

I’ve been on a Herzog dive lately. Highly recommend Grizzly Man and Burden of Dreams.

Ridley Scott’s Napoleon was mediocre, but Waterloo was great. Waterloo tells the story of Napoleon starting with his exile to Elba and his return. In the end, it reenacts the battle of Waterloo in Ukraine, using thousands of real actors marching in formation in costume. No CGI, just guys being dudes in a field playing war.

Welcome back to the Infinite Playground.

This week: The highest ratio boring-to-revenue-generating idea I’ve ever had.

No high-concept essay this week.

This Week At Tetra

At Tetra we’re in search of simple, niche, and dominatable markets.

Last week in my post about Fractal Prospecting I shared the idea that niche is a “market you can bear hug”. You can find it’s edges and fit the market in your head.

I’ll add a second variable to my definition of niche: SV tech bro adjacency, or lack thereof. A good niche for Tetra is far from the field of vision of the average Silicon Valley PM or engineer. Competition and funding follow fast on the heels of SV founders. We’re not interested in that. Wherever we play, we want to be the most aggressive and technically advanced player in the room.

I’ve stumbled my way into that exact niche thanks to a conversation at a KC Tech event last week (thanks Patrick): wealth management.

Specifically, regulatory compliance and security for wealth management firms.

Woof. Bored yet? That’s the point.

This is the wealth management “AdvisorTech” market:

This was my Rosetta Stone for understanding what the jobs-to-be-done are in this market and how buyers and sellers talk about them. I now have a springboard for researching the endless financial acronyms, certifications, and legal jargon that a short career stint would’ve taught me. Soon I’ll be study abroad fluent at the broad level - enough for first product research calls.

In the meantime, I had to choose a specific area to narrow in on.

I spent my first couple of days looking at Client Engagement. One of our product pushes at Barracuda centered on owning the engagement layer between DAO core teams and their communities. A lot of very similar tools were used, and I think a similar strategy could pay dividends here. The problem is ACV.

Ideally, I want a business that can extract at least $100/mo of value. Go below that and CAC starts to become a real challenge, and market size becomes a larger constraint. At $100/mo you need 100 customers to pay an average salary of $100k.

Most of the client engagement tools here will be used infrequently (excluding the client portal, potentially). That’ll bias buyers toward the lower ends of pricing tiers. If you’re Jotform selling into this market, for example, I can’t imagine most of the buyers are breaching above their $34/mo tier. That means ~300 customers to pay a salary (and only a $10 allowance to keep a healthy ACV:CAC ratio). This is a healthy place for expansion revenue or a second brand in the future but not a solid foundation for entering this market.

Next, I took my data infrastructure deep dive from last week and started applying what I learned to AdvisorTech. There are a lot of interesting ideas to play with - building a new data warehouse specifically for advisers, or an ETL platform that plugs into all of these tools, etc.

Data infra tools don’t suffer from the same ACV issues as the client engagement stack, but I put them on the back burner. The sense I got from looking at all of these products is that the advisers they serve are smart, but their technical ability may vary widely. An ETL platform would unlock a lot of value, but having engineering teams at these firms seems rare. The more technical the tool, the more time you’d have to spend translating that into dead simple UX. Even nailing that, the problem you’re solving doesn’t cover the whole market.

That’s when I found this little nook:

Compliance.

Every firm is legally required to do it. Many firms pay mid-five figures every year to consultants to make sure everything is nice and tidy, or on mock audits/”exams”. There are hard technical problems here, and a bunch of ancient-looking products to help with them. The material is complicated and there are specific Compliance teams who deal with this full-time. That means we have clear buyers with articulated pains and a budget. Ding. Ding. Ding.

There are also extension products around file archival and sharing.

These problems are also security adjacent. They’re both about tracking and influencing employee behavior. Many security problems are also outsourced.

There is a perfect opportunity here for Vanta for X, and that X is compliance.

Here is what I’ve been kicking around:

In a sea of names like “Investorcom”, “ComplianceAlpha” and “SmartRIA”, Buffalo or something similar is memorable and stands out. An icon that is non-intimidating but confident and still mighty, which is how you want to feel about compliance.

The existing compliance products pitch themselves as solutions for “Compliance Management”. Management implies there is a burden that is on the customer that their products help with. Automation implies I’m solving a problem for you, and taking your burden. Compliance Automation creates a category for itself. It’s additive, a new style of solution not directly competing with existing products.

That’s a strong hypothesis to start with. Now I need to talk to compliance teams.

Luckily, I found a break here too.

The SEC shares every registered wealth management firm operating in the United States, as well as the advisers and broker-dealers working at those firms.

These forms contain demographic data that reveal:

• Assets under management

• Asset allocation

• Fee type (tells you roughly how much operating income they have)

• Services offered

• Registered States

• C-level Roles and who occupies them

• and much more…

These files are massive and messy. A single form submission can grow up to 100 pages. I found this on data on Thursday and have been slowly modeling the form data into a database I can query against.

Next week I plan to have a deep dive on this data to share with you.

The importance of this find can’t be understated. I now have 40k highly quantified leads and all the certification-holding employees I would target for sales messaging. This was a huge step forward and a fortuitous sign from the capitalism gods.

Carveouts

It’s spooky month, and so it’s time for autumn lofi!

• Link

• Link

• (my favorite) Link

I’ve been going through the backlog of videos from Secret Base, which is a shoot-off of SB Nation. I wasn’t familiar with SB Nation, but I love this content. Deep dives on sports history from a statistical lens. It makes sports nerdy for me which I need to enjoy it hahah.

Finally, I cannot recommend Understanding Michael Porter enough. It’s the best book on positive sum business strategy and thinking. Michael Porter is the GOAT and is heavily misunderstood by kids who were bored in college. This book changed my entire perspective on how to look for product opportunities.

Put some respect on Porter’s name and dig in. If you do, let me know what you think!

Welcome back to the Infinite Playground.

This week: Market exploration and sales prospecting

Note: I’m going to start splitting this up into two sections, one on a concept I’ve been mulling over (if any) and one that’s a more accountability-focused update.

Fractal Prospecting

The goal of Tetra is to find and build in simple, niche, and dominatable markets. We believe that finding these niches is not a matter of “earned industry secrets” but a solvable problem of legibility and adjacency.

First, you have to know a niche exists. Then you have to notice the problem. That’s all an “earned industry secret” is. They “earned” a perspective to notice an issue. Anyone could’ve seen the problem if they “earned” that adjacency to the problem. Think about this like building a surface area of luck, or exposure to problems.

This idea is at the heart of the Tetra services strategy. Companies are human organizations with repeatable problems - sales operations, data infrastructure, etc - where we can build competence. We can aim that competence at small, niche, dominatable markets and put ourselves adjacent to new problems. We’ll seize those problems and use the distribution channels we’ve built selling our services to sell our new product. Rinse, repeat, and compound.

How do you start to build machinery for finding niches? How do you find markets you’ve never been exposed to, serving problems you’ve never had?

I call this the Legibility Problem. The method I’ve come up with I’ve started calling Fractal Prospecting.

Start with a buyer. We’re lucky that most companies have similar structures, and that humans advertise what they do on LinkedIn. Look at your past companies. Find a buyer you’ve seen many times. Ask them what tools they use. If you’re a buyer, start with the tools you used that were your “system of record”. For sales, that’s your CRM. For engineering, that’s your servers. For data folks, that’s your data lake or warehouse.

You start with a blank slate of problems a buyer is confronting.

At first, none of their problems are legible.

You need to find the system of record. Systems of record carry a lot of weight in an ecosystem. They are the signal of a market’s existence. Every major function in a company has a system of record for their work. Very often, they’re the largest companies in a given market, because they grow to represent some fraction of the entire market itself.

You start by exploring what is most obvious to you. The largest system of record companies and their competitors. These are the 10,000lb gorillas in the room, they should be easier to find.

It’s clear these companies do not represent the whole market, but a significant chunk. They carry the gravity at the center of this ecosystem. You now have a jumping-off point. Part of the market has become legible to you. In the diagram above, the largest white triangle has been found.

You may find a specific feature is described with an acronym. Google that acronym and you’re sure to find an entire sub-ecosystem whose entire business is solving that problem for a variety of other niches. Your context grows, but you’ve been introduced to more sub-ecosystems. There is now a web of new competitors, new customers, and new related markets to dive into.

It’s overwhelming. Each step of the way you uncover more details that lead to another, seemingly smaller niche that is also populated by billion-dollar companies.

At the same time, you know you’re missing things. Your methods will have gaps due to perspective bias. Competitors to the company you’re researching will slip through the cracks. For every white triangle you uncover leaves a black triangle in its wake. Maybe they were just founded, or haven’t announced investor rounds. Maybe they are bootstrapped. Maybe their SEO is terrible. Worst of all, the algorithms you’re relying on for your search - Google, Crunchbase, LinkedIn, etc - may not prioritize them in results for reasons beyond our understanding.

Your goal is to find the end of this fractal pattern. You want to find a market small enough that you can find all of its members. You’ll feel this happening. Each search you do will start to return less surprising results. The same names will pop up over and over again in marketing materials. You’ll find one new company in every search instead of 10. When the surprises have stopped, you’ve reached the end.

That’s a niche. A niche is a market you can bear hug.

I’ve started to think about this problem as a large fractal tree. Each market - say, sales tools - is a tree in the forest of the world economy. The trunk splits into branches. Large branches lead to smaller branches, which lead to leaves. Each of these segments is smaller in turn and represents the same thing as the white triangles in the previous image. This is a more pleasant analogy. I’m looking for a leaf on a tree, not fumbling around blindfolded in a maze of never-ending submarkets.

The problem is much easier now that you’re bear-hugging a niche market leaf. The entire forest, with its 8 billion people, interconnected roots, and branch systems is messy. You’ve now narrowed your problem down to a few thousand people working in the space. They’re building and selling the same kind of products, either in direct competition or to specific verticals. They probably have a lot of the same problems.

Selling is a game of empathy. Your knowledge and empathy will compound as you sell to each of these companies from the same leaf much faster than taking a horizontal cut of a larger market. Given the proximity of the leaves, I also believe anything done on a given branch compounds to the rest of the surrounding leaves.

Think about it like this - an SDR selling semiconductors has very different day-to-day pain points than an SDR selling Notion. The genre of their pains is the same. Rejection-filled work. They have to fill quotas, blah blah blah. But if I show up to sell to the revenue operations team of the semiconductor company and I know their specific pain points, I develop trust a lot faster than if the last folks I talked to sold Notion.

I think this focus will also pay dividends in writing marketing copy. I can get into a single headspace and think about a very specific set of buyers or readers.

This Week At Tetra

I spent this week fully focused on prospecting.

In the future, this will become a regular part of a larger sales motion. But for now, it’s a new discipline for me - and a grueling one! I wanted to sit down, get familiar with the pain, and grind through it.

Within each day I’ve taken to focusing only on a single output. I’ve found this easier to do than running in a few separate directions and multitasking. In my head I try to imagine myself as a specific tool, doing only one thing well and with full attention.

That focus comes with the fear that I’m not doing “enough”. That’s a natural fear to have when moving only in one set direction per day. A lot of things are being ignored in favor of compounding on a single task. In these moments I think about a stream of water eroding a rock. The more focused my attention, the faster the water, the faster the erosion. Under that eroded rock, a lesson.

Big analogy and metaphor week for me hahah. Fractals. Trees. Tools. Erosion.

Prospecting and Quantification

I’ve broken my prospecting work into four distinct stages.

1. Discovery - the fractal prospecting described above

2. Quantification - low fidelity research to get basic data: Company size, offering, fundraising history

3. Qualification - high fidelity research: familiarizing myself with offerings, reading blogs, mapping organization structure around buyers, and gauging revenue by researching customers.

4. Engagement - sales pipeline formally begins

Stages 1 and 2 are completely separated. This allows me to focus entirely on finding companies and finding branches and leaves. Then separately I can come back and build a list of priorities out of trends I’ve noticed in offerings, size, fundraising, and offerings.

Stages 3 and 4 will be contiguous. I’ll qualify in batches and then engage with those batches while their information is still fresh in my mind.

Numbers Game

My goal for 2024 is to have replaced my salary from Barracuda, $120k, with an additional 30% net profit margin. That’s $156k in revenue. My goal for the rest of Q4 2023 is to cover my rent for the quarter.

Sales is a human game on an individual deal level. But it’s a statistical game in aggregate. If you’re selling against a real pain in a large enough market, someone will buy what you’re selling.

I don’t expect my sales pipeline to be efficient to start with. The average sales pipeline converts ~2.6% of sales prospects to closed deals. I’ve planned for 0.5%.

Let’s say I expect my average engagement to be $5k. I need to close an average of 2.6 deals per month. That’s 200 prospects for every closed deal. 520 prospects per month. Finally, I factor in a worst-case 90-day lead time for those prospects to close.

By October next year, I need to have found 6240 prospects and engaged with all of them. Whew!

I don’t expect things to go this poorly, but it’s nice to plan around a worst-case scenario and be surprised. At the very least, I want to build an engine that is capable of organically mapping 6,000+ companies per year. Even if we don’t engage with all of them, we can still grow our understanding of the legible universe!

First Steps

I started by looking at the portfolios of Barracuda’s investors. These firms all focused on early-stage companies. I know the pains of early-stage companies well. It’s as logical as a starting place as any.

100 companies survived my filters. I’m looking for products I understand, that are generating real revenue, and are building something I would want to be pitched on. A problem arose pretty quickly here - there was no underlying thesis for these investments. They were easily legible - most funds list their portfolios - but the signal was weak. There was no return on my learnings by looking at these very disparate companies.

I took a look through VC firms that invest with a tighter focus. You would be surprised by often these funds abandon their thesis, or stretch it beyond its stated theme.

This is where I started to think about the Legibility Problem.

After mulling this problem over, I went to an area I know well - data warehouses.

I dug in specifically on Snowflake. I found their partners program, which returned ~110 prospects. Through that research, I found the Snowflake Summit and its sponsors. From this page alone I found another ~150 prospects.

These combined prospects fill out what I’ve called a “cohort”, or +200 prospects. I’m thinking about my sales outbound in the same way I’d measure new users in a product. I expect my base rate of 0.5% throughput for this first cohort. The cohort system will give me a way of measuring the effectiveness of different sales, marketing, and prospecting strategies.

From the ~260 leads I had found, I targeted the ETL category next. ETLs/ELTs/rETLs are data pipelines between systems of record and data lakes or warehouses. If you’re using Snowflake or one of their competitors, you’re also using an ETL product - or you’ve built your own. ETLs felt like a niche market leaf. I was right. I found ~75 additional prospects in the ETL space. These companies sold ETL solutions, or ETLs were a major part of their product suite.

One week. 440 prospects discovered and quantified. 75% on the same fractal tree.

Next week I’ll start qualifying and engaging the ETL folks. Prospecting additional leaves and expanding the backlog will be a daily activity, but only for an hour or so.

Some takeaways from qualification:

• Twitter is functionally useless for highly technical B2B SaaS products. The largest companies in the data infrastructure market have hundreds of thousands of followers, 500 views per tweet, and 1 like. There is some alpha there if you can crack it, but I mostly saw a lot of wasted marketing salaries.

• Dollars fundraised and the number of rounds have very little correlation with company size. I’ve seen Series E, F, G, and H companies in the data infrastructure space with 500 or less employees. Either there are a lot of hidden costs, or their capital efficiency and customer lock-in are next-level. We’ll see more soon.

• After a certain size, every company starts to have very well-organized case studies, white papers, and marketing content. On the smaller end of the scale, startups with well-organized marketing content seem to be able to communicate their problem more easily. That ability to communicate their problem seems analogous to early PMF, which you can see in their fundraising history.

• The more an early-stage company uses “next generation” the more you can bet they’re a small team with no marketers and are probably pre-PMF. If they had PMF they would be able to describe their product concretely.

• That all said, it is very surprising how incomprehensible some products are, even after spending 50 hours reading blogs and landing pages about their competitors.

• Many of these data infra companies have glossaries in their marketing resources. Just a full page of dictionary definitions! If your potential buyers are willing to read a dictionary to understand your product, their pain is (1) very real (2) more painful than reading dictionary definitions (3) very high value.

Carveouts

I’ve gone full monk mode and hidden away my PC, Xbox, and PlayStation in the guest bedroom’s closet. Consequently, I’ve gotten a lot more reading done!

Books I’ve been reading on sales:

• Fanatical Prospecting - covers how prospects are different than leads (leads show buying interest) and reinforces the grueling but necessary nature of prospecting.

• Predictable Revenue - a sales playbook from the guy who got SalesForce to $100m in revenue. Very useful for quick references and frameworks. My main takeaway was the different types of customer acquisition - seeds, spears, and nets.

• SPIN Selling (thanks Sam) - very analytic research that fits well with my engineering brain. Focuses on longer-term, high-value sales and breaks a lot of common myths proliferated in sales books written for low-value products.

• Large Account Sales - same as Spin Selling, but focused on enterprise sales techniques.

Books I’ve read:

• Churchill, Paul Johnson

• Napoleon, Paul Johnson

I found both of these books on my shelf while reorganizing. Johnson does a great job of condensing down all the details from several hundred-page biographies and telling that same story in a more thrilling way in 200 pages or less. I cannot recommend these books highly enough.