Hi, I’m Greg 👋! I write weekly product essays, including system “handshakes”, the expectations for workflow, and the jobs to be done for data. What is Data Operations? was the first post in the series.

This week’s toy: a copy of Lululemon, aimed at forcing social change for the makers of activeware.

Edition 300 of this newsletter is here - it’s April 20, 2026.

Thanks for reading! Let me know if there’s a topic you’d like me to cover.

The Big Idea

A short long-form essay about data things

⚙️ Build the info radiator

Every remote worker has the same problem. Somebody in your household (a kid, a spouse, a roommate) needs to know whether you’re in a meeting right now. The information exists on your calendar. But it’s trapped inside your phone, and your phone is the one device in the house that’s designed, from the ground up, to be private.

When my kids were little, they’d hover outside my office door and guess. Fifteen years of remote work has not improved the guessing game, and every remote worker I know has their own version: a partner who can’t tell whether the silence means “in flow” or “went for coffee,” a kid who needs to ask about a permission slip, a housemate with a package question.

When meetings were rare and scheduled in advance, it was easier to say “don’t bother me.” But meetings happen anytime; they move, they get added at 8:57 a.m., they run long.

You end up with a kid trained to be cautious hovering outside a door behind which you are, in fact, reading a meme post.

The phone is a privacy envelope

The real problem isn’t that status information doesn’t exist, it’s that it’s hard to share the outside of the envelope (your free/busy).

A phone notification is a message from one system to one person. The unlock screen exists specifically so your status and your calendar and your messages don’t leak into the room. That’s good when the recipient is one person.

It’s catastrophic when the recipient is everyone except you — the people in your house who need to read your status to decide whether to knock. Your calendar knows you’re busy. Your phone knows you’re busy. Nobody else in your house can read your status.

Public by design

The conference room solved this problem twenty years ago with a little card on the door that says AVAILABLE or IN USE. The status is public because the audience is public. Anyone walking down the hallway needs to be able to read it at a glance.

The placard puts the answer in the room, at eye level, in a form a kid can read, without anybody having to ask for permission or wait for an adult to surface the information.

Households need the same move for the same reason. Some pieces of information exist to be read by anyone who walks past, and those pieces don’t belong on any single person’s phone.

They belong on an object that the whole household can glance at the way they glance at a whiteboard, a calendar on the fridge, or a clock on the wall.

Alistair Cockburn, writing about agile teams in the early 2000s, called the office version of this an information radiator — a board or chart you couldn’t ignore because it was in the room you already walked through. Every household needs a few of those. The information doesn’t need to leave the phone for the phone’s own sake. It needs to leave the phone so the people who don’t own it can read it too.

The test is simple: if a piece of status in your house has to reach more than one person in the room, it belongs on an object, not a phone. Phone notifications are private by design. A radiator is public by design. Match the medium to the audience.

Once you start applying that test, you see the same shape of problem all over the house. Most of the small decisions a household makes in a given day turn on a digital input that someone has to remember to look up:

• Should I knock on the door? → whatever’s on your calendar right now

• What should the kids wear to school? → whatever the weather app says about the next six hours

• What are we eating tonight? → whatever’s in the fridge, minus what’s about to expire, plus what’s already on the meal plan

In each case, the information exists and is boring for software to produce. In each case, it lives in an app on one person’s phone. Let’s change that.

Show the answer, not the inputs

A radiator isn’t useful because it moves data into the room. It’s useful because it moves a decision into the room.

Your brain is full. Every parent has a running count of small choices — jackets, lunches, who-needs-to-leave-by-when, whether to knock — and none of them are individually hard but collectively they are the entire reason you can’t remember what you walked into the kitchen for.

The reason the phone apps don’t help is that they don’t deliver decisions. They deliver raw inputs: 48°F, light rain in two hours, seventeen items in your fridge. You still have to run the heuristic in your head to get the answer.

The value of a radiator is that somebody — or some small piece of software — has already run the heuristic, and what lives in the room is the output. Not 48°F, light rain in two hours. YES JACKET. Not three meetings before 3 p.m. with gaps. IN USE UNTIL 3:00. Not leftovers, chicken breast, spinach, half a jar of pesto. TONIGHT: CHICKEN PESTO PASTA.

Heuristics belong in software. Decisions belong in rooms.

A note on the fridge, not a camera in the hallway

The last ten years of “smart home” have felt slightly off, and it’s not the technology — it’s the direction of the arrow. Nobody wants a camera in every room. Nobody wants a microphone listening for trigger words in the kitchen. All of those are the home watching you.

A radiator is the reverse: it’s the home telling you something you asked it to keep track of.

A sticky note on the fridge is friendly. A camera pointed at the fridge is creepy. They convey related information — the milk’s almost out — but one is a broadcast from a household to itself, and the other is a surveillance feed leaving the house. The radiator stays firmly on the sticky-note side.

Output-only. No microphones, no cameras, no presence sensors. It reads from sources you already own — your calendar, your weather, your meal plan — and it stays on your network. Nothing new is being collected; something existing is being surfaced to the room that needs it.

Ink, not light

Most “smart home” products also feel wrong for a simpler reason: they glow. A tablet in the hallway is a small sun. A wall-mounted iPad is a small sun. At 2 a.m. on a water-glass run, all of those are small suns in your eyes.

The radiator uses a paper-like display on purpose. It holds its image without power, so it’s dark unless there’s light in the room — exactly like a sticky note or a printed calendar. It doesn’t pulse, doesn’t notify, doesn’t beg for attention.

You glance, you read, you keep walking. A household has finite tolerance for glowing things, and most of it is already spent on phones and televisions. A new object in the house that adds zero additional glow is an object the house will actually accept.

The proof of concept

I built one of these information radiators. It’s called doorplate-diy, the software is open source, and it costs about $50 to build it yourself.

The Doorplate uses a color e-Ink display, a small board that drives it, a USB-C cable or battery, and a picture frame (you can use one from IKEA if you like.) To mount it, you pop out the paper insert, drop in the panel, and hang it on the door.

The device runs about a month on a small battery, or forever if you plug it into the wall. The server that feeds it runs on the Mac you already own; the sign checks in every fifteen minutes and goes back to sleep. No cloud account, no subscription, no data leaving the house.

When it’s done, you have an object on your door to display if you’re busy. (Or you could use it for other reasons, but that’s the first one.)

Public by design, answers not inputs, output-only, paper not light — those four rules apply cleanly to each one. I’ve shipped a door sign that solves the “is Dad on a meeting” problem for my household.

Pick one

If you have a piece of household information that everyone except one person has to guess at — whether you’re on a meeting, what to wear to school, what’s for dinner, whether the kid is allowed downstairs yet — pick the one that irritates you most, and make it public.

Everything else is the same principle applied to a different room: the information isn’t missing, it’s just in the wrong place. Take it out of the envelope. Hand it to the house.

Build the radiator.

What’s the takeaway? The test is simple: if a piece of household status has to reach more than one person in the room, it belongs on an object, not a phone. The doorplate example is one idea … you could build more.

Links for Reading and Sharing

These are links that caught my 👀

1/ Fridge Magnets and Memory - As a collector of fridge magnets, I endorse this essay on how they remind us of times past (and some imaginary). Also, reading it taught me some new things about magnets.

2/ Posthog on Agents - The team at Posthog wrote this great piece on agents. Are you building Command Line Interfaces or MCP servers? It turns out agents need them both: the first to make sure they have discrete triggers and actions to call and the second to provide token-efficient surfaces to decide which CLI function to use.

3/ How do Claude PMs think about being a PM - Life as a PM in the age of Claude.

What to do next

Subscribe now

Hit reply if you’ve got links to share, data stories, or want to say hello.

Hi, I’m Greg 👋! I write weekly product essays, including system “handshakes”, the expectations for workflow, and the jobs to be done for data. What is Data Operations? was the first post in the series.

This week’s toy: A version of Breakout that demonstrates how a new library called Pretext makes it easier than ever to manipulate text in a web page.

Edition 299 of this newsletter is here - it’s April 13, 2026.

Thanks for reading! Let me know if there’s a topic you’d like me to cover.

The Big Idea

A short long-form essay about data things

⚙️ Build toys with known outputs

For about four years now, I’ve been asking my computer to tell me dad jokes.

Not constantly. Every eighteen months or so, when some new tool or paradigm catches my eye, I sit down and rebuild the same little thing I built the last time. The API is always icanhazdadjoke. The output is always a groaner. What changes is the scaffolding around it — and, more honestly, what changes is me.

This started by accident. In 2022 I wanted to see if Google Sheets could pull data from a URL, and “a dad joke” was the simplest thing I could think of to fetch. I’ve been repeating the experiment ever since. Five stacks later, I’ve realized the joke isn’t the project. The joke is the instrument I measure the project with.

Why dad jokes?

Three reasons the silliest possible use case has turned out to be my most useful one.

It’s fun. Fun matters more than people admit. Learning a new tool is mostly getting stuck, and getting stuck is a lot easier to tolerate when the payoff on the other side is “my laptop told me a dumb joke.” Fun is what carries you past the first compile error to the second.

I know what output I’m going to get. One punchline. One string. Any environment — a spreadsheet cell, a browser tab, a Slack DM, a terminal — either shows me a joke or it doesn’t. That makes “is it working?” trivial to answer, which means the only real variable in the experiment is the tool.

It keeps me current. Because the target is fixed, whatever is new in the stack shows up as a contrast. What’s easy now that used to be hard? What still needs scaffolding? The dad joke is a tuning fork. I strike it against each new instrument to hear how that instrument actually sounds.

Four years, five stacks

Here is the same request, told five ways.

Sept 2022 — Google Sheets. =IMPORTDATA into a cell, with the Accept header hack to get JSON back as text. I wrote about it in How do you ask Google Sheets to tell a dad joke?. What the joke taught me: spreadsheets are a lot more programmable than I’d given them credit for, if you’re willing to accept that the “program” lives in a cell reference.

Oct 2023 — console.log. Node script, fetch, print to the terminal. See An ode to console.log. What it taught me: when the feedback loop shrinks to a single keystroke, you stop planning and start iterating. The joke showed up in under a second, and I suddenly remembered why I liked programming.

Feb 2025 — Slackbot. An event-driven bot that answered /dadjoke in a channel, which I wrote up in Adventures in building a Slack bot. What it taught me: the hard part of a bot is never the request. It’s tokens, webhooks, deployment, and “who owns the ngrok tunnel?” The joke was the easiest 5% of the project.

Feb 2026 — single-page web site. One HTML file, fetch on page load, a button to re-roll. See Start with a single-page web site. What it taught me: in the AI era, a single page is enough product to test an idea. You don’t need a framework. You don’t need a build step. You need a file and a browser.

Apr 2026 — an agent. Which is where this post ends up, and where the rest of it goes.

Why ask the same question?

Keeping the dad joke API at the forefront of my exploring makes it easier to build new technology as I am goofing off. In the course of different versions I’ve gone beyond “can I hit an API” to “what sort of APIs would work with this” and “where can I make this useful”?

Each iteration teaches me more about building software and gives me product decisions to make while also giving me the opportunity to iterate in a new medium.

As a product manager building applied AI, the best way to learn about the pros and cons of building Agents is to create a scaffold for teams or individuals to create their own Agents. Building the next generation of software demands an agentic approach, so there’s no time like the present to start experimenting.

Why an agent, and why local

I’ve been using Claude and Codex daily, and the thing I keep running into is this: I want them doing work for me without keeping them running all the time.

I don’t want a long-lived chat window. I want small, cheap, scheduled jobs that wake up, do a thing, write a result somewhere, and go back to sleep. An agent for the morning commute. An agent to summarize yesterday’s commits. An agent — yes — to send me a dad joke at 8am.

That’s a framework, not a process. And once I sketched what it needed, the list was short:

1. A CLI to author and run things.

2. A manifest — a declarative file that says what an agent does.

3. A scheduler so I don’t have to babysit.

4. An orchestrator for retries, durability, and history.

5. A store so I can see what ran and what happened.

That list is why I built some-useful-agents, a way to set up little helpers on your computer that do small jobs for you. These could look like “every morning at 9, fetch me a dad joke” or “summarize today’s emails.”

You describe what you want in plain text, and the helper runs it for you: once, on a schedule, or as a chain of steps. Think of it like a recipe book of tiny assistants you can collect, share, and run whenever. It can also talk to Claude or Codex and get more context.

A full tour of some-useful-agents

The CLI is called sua. The quick start is two commands:

npx sua init
npx sua agent run dad-joke

Agents are YAML. Here’s the dad joke agent:

name: dad-joke
description: Fetch a dad joke and print it
type: shell
command: "curl -s -H 'Accept: text/plain' https://icanhazdadjoke.com/"
timeout: 10
author: gregmeyer
version: "1.0.0"
tags: [joke, demo]

That file is the whole agent. The manifest is the contract: name, what type of thing it is (shell or claude), what to run, and some metadata. You can point at a shell command or a Claude Code prompt. One schema, two worlds.

Underneath, there are two execution providers. The local provider runs the agent in-process — good for development and one-offs. The Temporal provider hands it off to a real workflow engine, which gives you retries, history, and scheduling for free. Temporal itself runs in Docker (docker compose up -d), but the worker runs on your host. That split matters: the worker needs access to your shell and your claude CLI, and those don’t belong in a container.

Every run — local or Temporal — gets written to a SQLite store at data/runs.db, so there’s a durable record of what ran, when, and what it returned. A small Express dashboard on :3000 renders that store as HTML for when you want to browse it in a browser instead of a terminal.

And because all of this is addressable from code, there’s also an MCP server so Claude itself can list and run agents as tools. The dad joke agent becomes something Claude can call.

Architecture diagram and full schema are in the README. The short version: YAML in, run record out, scheduled or on-demand, local or durable, your choice.

Why do this?

Pick a toy with a known output. Something silly enough that you’ll actually finish it, and small enough that “is it working?” is a yes-or-no question. Then rebuild it every time the ground shifts under you. You will learn the new tool faster than any tutorial, because the only thing varying in the experiment is you.

My next rung is already obvious. The agent fetches a joke. The next step is chaining it — a pipeline that grabs a joke, runs it through Claude for a rewrite, and posts it to Slack on a cron. Same joke. Same API. New stack. And now that this is a more than a toy, I need to make sure it’s secure, so that’s the next stack to learn about.

What’s the takeaway? Focusing on the same problem over and over is a great way to continue a lifelong learning loop. When you fix one variable in your exploration, it makes it easier to learn the scary new thing you haven’t figured out yet. And Dad Jokes are fun!

Links for Reading and Sharing

These are links that caught my 👀

1/ How do new emoji get made - It’s more complicated than you’d think to get a new emoji added to the official library that makes it to your phone.

2/ On Failure - Rob Zuber is an experienced CTO at CircleCI - this is a great interview and especially the bit at 42:12 where he talks about startups and failure. I won’t spoil it for you - watch it yourself.

3/ Building blocks - A few years ago, it was harder to create software than it is right now. And it’s probably going to get a lot easier. Mitchell Hashimoto writes about the Building Block economy and what type of software we should (and will) be building.

What to do next

Subscribe now

Hit reply if you’ve got links to share, data stories, or want to say hello.

Hi, I’m Greg 👋! I write weekly product essays, including system “handshakes”, the expectations for workflow, and the jobs to be done for data. What is Data Operations? was the first post in the series.

This week’s toy: thinking about how choosing music has changed since the introduction of the iPod in 2001. Yes, some serious “old man shakes fist at cloud” stuff here, but building a mix tape used to involve more thought than prompting Spotify for workout jams (and yes, Spotify does a pretty good job at this now).

Edition 298 of this newsletter is here - it’s March 30, 2026.

Thanks for reading! Let me know if there’s a topic you’d like me to cover.

The Big Idea

A short long-form essay about data things

⚙️ Stop Designing Your Graphics. Start Compiling Them

Writers already do the hard part: turning messy thinking into a clear argument.

The frustrating part comes after. You finish a draft, you need a graphic that carries the point — not decorates it — and suddenly you are in Figma nudging text boxes.

Then you revise the draft. The headline changes. The framing shifts. And the graphic is wrong again.

This is the loop that kills publishing momentum. Not the writing. The maintenance.

I have been stuck in this loop for years. Every article I publish on FindDataOps includes graphics like comparisons, process flows, pull quotes. In the old world (before I wrote a package to do this), each one used to take longer to produce than the section it illustrated. I would finish a 1,500-word essay in an afternoon and spend the next two hours wrestling with visuals that were already out of date by the time I exported them.

So I built a tool to fix it. And the thing I learned building it changed how I think about visuals entirely.

The problem is not “making graphics”

The problem is that writing is iterative and publishing is unforgiving. You need graphics that hold their structure while your message changes. With prompt-to-pixels generation — the “make me an image of this” approach — the result drifts every time. Fonts shift. Spacing varies. Comparisons stop lining up.

You cannot tell whether a difference is your idea or just the renderer being inconsistent.

I tried the approach of building with StableDiffusion, ChatGPT, and Google’s Nanobanana. The process was almost always the same: describe what you want and get something that looked close but was never reusable. When you run the same prompt twice, you get two different layouts. The output was impressive and unreliable in exactly the wrong ratio.

This is an expected outcome with LLMs, because they are non-deterministic. If you want a repeatable process, you need to build something different.

What I actually needed was not an image generator. I needed a compiler.

What compiled graphics actually means

A compiler takes structured input and produces consistent output. Every time.

For graphics, that means separating what changes from what stays the same.

What changes:

• your headline

• your comparison points

• your pull quote

• The argument

What stays the same:

• typography

• spacing

• color scheme

• visual hierarchy

• the design system.

When you revise the draft, you update the argument fields and regenerate.

The design system holds. No Figma. No pixel-pushing. The graphic follows the writing.

This sounds obvious. It was not.

The first version of Modern Graphics shipped as a CLI tool. You would run a command, pass in your comparison text, and get a PNG. It worked. But nobody used it the way I expected.

The people who wanted graphics were writers working inside AI assistants — Claude, Cursor, tools where the writing was already happening. They did not want to switch to a terminal to construct a command. They wanted to stay in the conversation and say “make me a comparison for this section.”

This is a lesson that keeps showing up in developer tools: the best feature in the world loses to a mediocre feature that meets people where they already are.

Writers are not in the terminal. They are in the conversation, talking to bots.

Where the writing happens now

The current version runs as an MCP server — a protocol that lets AI assistants call external tools.

In practice, you describe what you need to the assistant: “I need a comparison showing the old workflow versus the new one.” The assistant picks the right layout, fills the fields from your writing, and exports the graphic.

This matters because the workflow becomes:

1. write the section

2. identify the beat that needs a visual

3. tell the assistant

4. get the graphic

5. When you revise, you regenerate with updated text and it takes seconds

I published the subscription pricing essay this way last week. Four graphics, zero time in Figma. The comparison of “The Browser” versus “The Buyer” was generated directly from the essay’s own language.

When I tightened the wording in the draft, I regenerated the graphic with the new copy and it matched immediately. The whole graphics pass for a 1,500-word essay took under ten minutes. That used to be a two-hour Figma session.

When graphics are cheap to produce, you produce more of them. When they are cheap to revise, you revise the writing more freely because you know the visuals will follow. The tool did not just save time on graphics. It made the writing better because it removed the penalty for changing your mind.

What I learned about consistency

The original version let you customize everything. Colors, fonts, spacing, density. People spent more time configuring the theme than writing the article. That is the Figma problem dressed up in different clothes.

Now templates enforce a visual system. You pick one that matches the tone — editorial, technical, warm, dark — and the template handles every design decision after that. Typography, color roles, whitespace density. You focus on the argument.

This is the same principle that makes Markdown work for writing. You do not choose font sizes in Markdown. You mark a heading as a heading and the renderer handles the rest. Compiled graphics work the same way. You mark a comparison as a comparison and the layout engine handles the visual structure.

The constraint is the feature. When you cannot fiddle with spacing, you stop fiddling with spacing and go back to the writing.

Why this matters beyond one tool

Most publishing workflows treat visuals as the final deliverable. You write, then you design, then you publish. Three phases, three tools, three sets of decisions.

Compiled graphics collapse the last two into the first. The visual is a function of the writing. Change the input, get updated output. The graphic has no independent existence — it is downstream of the argument.

This matters because the best writing gets revised. A lot. And every revision that does not update the graphics creates drift. The graphic says one thing, the text says another, and the reader notices the mismatch even if they cannot articulate why.

Kyle Poyar’s SaaS benchmarks reports includes dozens of charts. Each one maps directly to a data point in the text. If the data changed, the chart would update. Nobody would suggest manually redrawing them in Figma every quarter.

But that is exactly what most writers do with their article graphics. They treat every visual as a one-off craft project instead of a repeatable output. And then they stop revising because the cost of updating the graphics is too high. The design tool becomes a tax on iteration. The more graphics you have, the heavier the tax, and the less you revise.

When your graphics compile from your argument, your revision loop never breaks. The visuals stay current because they have no choice. They are downstream of the words.

The shift to compiled data stories

You are not editing a picture anymore. You are updating an argument and the picture follows.

That is a small sentence with a big implication for anyone who publishes regularly. It means your graphics never lag behind your thinking. It means revision does not create drift. It means you can be as iterative with your visuals as you already are with your prose.

What’s the takeaway? Treat your graphics like compiled code, not crafted art. Define the argument, let the layout engine handle the design, and when you change your mind, regenerate in seconds. The tool makes the writing better because it removes the penalty for changing your mind.

Links for Reading and Sharing

These are links that caught my 👀

1/ Put your agents to work - If you want your LLM Agents to do a good job, you also need to give them reasonable tasks that are well known. Agents are more creative (and effective) when you give them basic building blocks and ask them to combine them in novel ways.

2/ Stripe is building minions - Reading about how Stripe is building agents for their own work will help you see what’s possible. Focus on outcomes and guardrails, not on pure process.

3/ ETL might be dead - Or we might just be realizing that schema-on-demand is now possible, so making connections between different systems is a lot easier than it used to be. But don’t assume that because an LLM says that it can connect A to B that it knows how — this is where the logic of ETL hasn’t died yet.

What to do next

Subscribe now

Hit reply if you’ve got links to share, data stories, or want to say hello.

Hi, I’m Greg 👋! I write weekly product essays, including system “handshakes”, the expectations for workflow, and the jobs to be done for data. What is Data Operations? was the first post in the series.

This week’s toy: if you keep your grocery receipts for 25 years, you too can create a data visualization of the change in the price of eggs over time. (AI can read bad thermal paper receipts, apparently.)

Edition 297 of this newsletter is here - it’s March 26, 2026.

Thanks for reading! Let me know if there’s a topic you’d like me to cover.

The Big Idea

A short long-form essay about data things

⚙️ Subscriptions Attract Browsers. Single Purchase Attracts Buyers.

When you buy your next speaker, are you going to grab whatever Bluetooth is on sale at Best Buy? Or are you going to find the right great-sounding speaker that fits into your current system, like a Sonos Roam?

That question tells you more about pricing strategy than most business books.

The person grabbing the sale speaker is browsing. The Sonos buyer already has a system, already knows what good sounds like, and is completing a setup, not starting one. They are different people with different intent, and they respond to completely different signals.

I think about this a lot right now because the software market is in a weird place. Three forces are pulling buyers in different directions, and the default response from most founders — monthly subscription, free trial, pray for retention — is getting weaker by the quarter.

The subscription model trained buyers to leave

Everyone has a subscription they forgot to cancel.

You open your credit card statement and there it is. $14.99 for something you used twice in January. The pitch was “the price of two mochas a month.” That framing worked in 2018 when you had three subscriptions. It stops working when you have fifteen.

This is not anecdotal. Kyle Poyar’s 2025 SaaS Benchmarks report covering 800 companies found median net revenue retention of just 82% for B2B SaaS and 49% for B2C. More than half of consumer subscription revenue evaporates every year. Recurly’s benchmark data across 1,200+ subscription sites shows average monthly churn of 3.5 - 6.5% depending on industry.

The model itself trained people to keep one foot out the door.

When “cancel anytime” is the primary selling point, people cancel.

I ran a GTM ops team where we spent more time analyzing churn cohorts and building win-back sequences than we spent on the actual product experience. That felt like a miss.

The vibe-coding escape route

There is a second force reshaping how people think about buying software, and it has nothing to do with pricing pages.

AI changed the build-versus-buy math.

Two years ago, if you needed a tool to manage your client pipeline or track your content calendar, you had two real options:

1. find a SaaS product that was close enough,

2. or hire someone to build what you actually wanted.

Option one meant a subscription. Option two meant real money and real time.

Now there is a third option. Open a chat window, describe what you need, and start building. You can build your exact use case, your exact workflow, no monthly fee, no compromises.

The reality is a lot messier. I have several half-finished projects that do not quite solve the problem as well as the $12/month tool I was annoyed to pay for but that at least actually worked.

The cost of vibe coding is not tokens: it is the slow accumulation of unfinished things. Each time you feel really close to finishing, but the last 10-20% in software is really hard to make it complete enough for other people to rely on. You trade a $12 subscription for forty hours of tinkering and a prototype that breaks when you change one input.

This is build fatigue, resulting from having infinite capability and no finished product.

What single purchase actually does

I keep coming back to single purchase, because it provides a middle ground between subscriptions and vibe coding.

On one side: subscription noise. Fifteen tools, monthly charges, cancel-anytime anxiety, and the quiet guilt of paying for things you barely use.

On the other side: the vibe-coding wilderness. Infinite possibility, unknown time cost, and a growing pile of almost-done projects.

There is an opening for someone selling a finished thing at a clear price.

No recurring charge. No half-built prototype. No “price of two mochas” pitch. Just an exchange: money for a tool that works. You own it. Done.

This is not nostalgia for pre-SaaS software. It is a filtering mechanism.

Go back to the speakers. The person who grabs the $19 Bluetooth at Best Buy is not the same person who buys a Sonos Roam. The Sonos buyer already has a system. They are not browsing — they are completing something. Single purchase selects for that buyer.

The person who pays $99 once already knows what they need because they already understand the value.

That is not a smaller market. That is a better market.

The math, briefly

A $99 one-time purchase with a 3% conversion rate on a thousand visitors produces $2,970.

A $10/month subscription with a 1% conversion rate and four-month average retention produces $400 from the same traffic.

The subscription theoretically wins at scale with strong retention. But “strong retention” is doing a lot of heavy lifting in that sentence, and Poyar’s data shows most products never get there.

The more interesting difference is not revenue per visitor. It is who shows up.

Subscription attracts people who are willing to try. Single purchase attracts people who are ready to buy. Those produce fundamentally different businesses. One gives you a user base that churns. The other gives you a customer base that refers.

The contrary signal

In a market where every competitor races to $0 trials and $9/month plans, charging once and charging well sends a specific signal.

It says: this is finished. This is not a beta you are paying to test. This is not a feature set that will get paywalled next quarter. This is a tool, it works, and it is yours.

Free trials are invisible now. They are table stakes that stopped differentiating years ago. But “no subscription required” still stops people.

It creates a moment where the buyer pauses and thinks: wait, I just pay once?That pause is worth more than a thousand optimized onboarding flows. For a growing category of tools — the ones that do a specific thing well, that live locally, that solve a bounded problem — the contrary bet is worth making.

Charge enough that it means something. Let the price point filter for the customers who actually want what you built.

What’s the takeaway? In the land of vibe coding and subscription fatigue, the Sonos buyer is out there. They are tired of browsing. Build them something worth owning.

Links for Reading and Sharing

These are links that caught my 👀

1/ The agent thing is a big deal - When industry analysts remain impressed, you know that a tech trend is real. Ben Thompson is a skeptic, and believes in the power of AI agents. (ps, he’s right.)

2/ What’s up with the job market? - Wondering which way the job market will go with the advent of AI? Me too. Andrej Karpathy has created a data visualization of jobs most likely to be displaced or changed by AI.

3/ Money money … - The best way to sustain a business? Capture the nostalgia of a pop wave like ABBA. It will keep going long after they are gone.

What to do next

Subscribe now

Hit reply if you’ve got links to share, data stories, or want to say hello.

Hi, I’m Greg 👋! I write weekly product essays, including system “handshakes”, the expectations for workflow, and the jobs to be done for data. What is Data Operations? was the first post in the series.

This week’s toy: a functional LEGO keyboard brick that’s a computer. If you remember the single bricks that showed a '"computer” this is a scaled implementation of that idea: a real computer in the shape of a square LEGO brick with a slanted front. Edition 296 of this newsletter is here - it’s March 16, 2026.

Thanks for reading! Let me know if there’s a topic you’d like me to cover.

The Big Idea

A short long-form essay about data things

⚙️ You’re using AI wrong

I asked a friend this week what he was building with AI.

“I’m doing some pretty interesting things with ChatGPT,” he said.

I waited for the rest of the sentence, and there wasn’t anything else.

He meant he was searching. Asking questions, getting answers, maybe summarizing an article. He was using a large language model the same way he used Google in 2015, just with better grammar on the output side.

twiI am pretty sure most of the American public believes that “using AI” means typing questions into ChatGPT or Claude and getting slightly better search results. If they are really advanced, they have customized a chatbot to give domain-specific answers, or connected it to their email so it can surface calendar conflicts.

That is not using AI. That is using a chat window.

The local maximum

We’re all used to hearing a message: AI equals chatbot. A chatbot is an application focused on chatting.

So people chat. They ask questions. They get answers. They move on.

What they don’t realize is that behind that chat window sits a system that can help you create software, invent new document formats, build internal tools, generate curriculum for almost any skill, and co-author things that would have taken a team of specialists a year ago.

This is a failure of imagination, not intelligence. People are not dumb, they just don’t have good context for what is possible. When the only frame you have been given is a text box that answers questions, you ask questions.

You do not think to ask it to build you a personal CRM, design a reading tracker, or generate a custom invoice system for your freelance business. (And you should!)

So what do you do when you find a friend who wants to learn more about AI but does not know where to start?

You help them build one thing, while they drive the experience.

The problem is the blank page. My friend doesn’t know the unknown task of creating the software. And this is the gap that pauses most people.

They open ChatGPT, stare at the prompt box, and type “help me build an app.” The response they get is too generic to be useful and too long to be actionable. They close the tab.

What they need is not a better prompt. They need a first move.

LEGO bricks, not magic

The best builders I have worked with share one trait. They get really good at identifying what I call the LEGO bricks.

These are the key building blocks that every piece of software is made of:

• How you store it. Every application needs a place to keep data. A spreadsheet, a database, a JSON file. When your friend says “I want to track my reading list,” the first LEGO brick is: where does the list live?

• How you show it. Once data exists, you need a way to look at it. A web page, a dashboard, a simple table. This is the interface, the thing a person actually sees and touches.

• The glue. Something has to connect storage to display. When a user clicks “add book,” code runs that takes what they typed, saves it, and updates what they see. That is the glue.

A reading tracker and a billion-dollar SaaS product have the same bones. The complexity changes, but the structure doesn’t change all that much. (Yes, I know enterprise software is different, but this is a persuasive essay to convince people to build.)

When your friend understands these three building blocks, the blank page gets smaller. Instead of “build me an app,” they can say: “I need to store a list of books with title and rating, show them in a simple table, and let me add new ones.”

Controlled obsession is the fuel

But knowing the LEGO bricks is not enough. Your friend needs a reason to push through the friction.

I have written before about controlled obsession as the bottleneck for building — Ben Basche does it better. The idea is simple: if you are building something because you cannot stop thinking about it, you will find a way through the hard parts. If you are building because someone told you AI is important, you will quit at the first error message.

The friend who wants to learn AI does not need a tutorial. He needs a problem he personally cares about solving. Maybe it is tracking his kid’s soccer stats. Maybe it is organizing recipes his grandmother wrote on index cards. Maybe it is building a tool that helps him prep for client meetings faster.

It does not matter what your friend wants to build. It matters that he cares enough to sit with the discomfort of not knowing what he is doing for longer than twenty minutes.

AI can co-build a lot of things with you. That does not mean it will be easy. It means the hard part moved. The hard part is no longer writing code.

The hard part is knowing what you want and being willing to iterate until you get it.

The tools are not ready yet (and that is OK)

Here is the honest truth: the current tools are in a weird middle state.

Claude Cowork might be the bridge for someone who has never developed software. It tries to make building possible without requiring you to know what a function is or how a database works.

But Claude Cowork misses something important. It cannot do everything for you. You end up in a state that is not quite development and not quite a magic wizard. You still need to make decisions about structure, fix things when they break, and understand enough to know when the output is wrong.

Codex has the same gap from a different angle. It is powerful, but it assumes you already know how to think like a developer.

What is coming next, I think, is a layer of software that interviews you first. It asks what you are trying to build, why, for whom, and what constraints matter. Then it composes the interface you actually need to build the thing.

We’re describing software that builds the tool that builds your software. But it would cover the full spectrum of developers from noob to expert.

The real gap

You might be using the tool wrong, but only because no one showed you what it can do.

The gap is not intelligence, it is exposure. And exposure does not come from reading articles about AI (including this one). It comes from the moment you describe something you want, watch it appear on screen, and realize you can change it.

The fastest way to get there is to build one small thing that matters to you.

Pick something you actually care about. Describe it in terms of what you want to store, how you want to see it, and what should happen when you interact with it. Open Claude Code or Codex. Start.

When you get to the other side, you will not see a chat window anymore. You will see LEGO bricks everywhere.

What’s the takeaway? Putting AI to work for you is a process. Pick something you care about, describe how it works and build it badly all the way to done. Once you’ve built one ugly thing that works, you stop seeing a chat box and start seeing LEGO bricks everywhere.

Links for Reading and Sharing

These are links that caught my 👀

1/ You are here - If you look backward at an exponential curve, things look very steep. But if you look forward, that view is hard to see because it ascends so fast. Ethan Mollick writes on what it feels like to see our future. it looks a lot like cinematic video created by AI, not by humans.

2/ How do you use the everything machine? - “Building anything used to hit three walls: knowing how to do something, having the technical ability to do it, and having the time and manpower to see it through.” —Ben Basche on obsession for building

3/ The history of the Fn key - A delightful long read by Martin Wichary on the history of the Fn key on your keyboard. I guarantee you’ll learn something. And if it’s too long, give it to your AI bot to summarize for you or LLMNotebook to turn into a podcast.

What to do next

Subscribe now

Hit reply if you’ve got links to share, data stories, or want to say hello.

Hi, I’m Greg 👋! I write weekly product essays, including system “handshakes”, the expectations for workflow, and the jobs to be done for data. What is Data Operations? was the first post in the series.

This week’s toy: a new emoji for anyone who likes a fisheye face.

Emoji seem like a small thing, but the ones that stick make it to the keyboard of every mobile phone in the world, so the process is pretty interesting in itself. Too-strong zoom on a selfie must be a universally understood image now.

Edition 295 of this newsletter is here - it’s March 9, 2026.

Thanks for reading! Let me know if there’s a topic you’d like me to cover.

The Big Idea

A short long-form essay about data things

⚙️ Use your Exoskeleton

When I was a kid, I wanted laser eyes.

Not metaphorical laser eyes. Actual comic-book-origin-story laser eyes. I read too much X-Men, saw Scott Summers vaporize a problem, and thought: yes, that seems useful.

That same feeling is the closest description I have for what using AI well feels like right now. You can summarize a market in minutes. You can turn a rough product idea into a working prototype by lunch. You can ask a model questions that used to require interrupting an engineer, a designer, or a data person.

The power is real. The confusion is real too.

The mistake is thinking the new superpower is execution. It is not. The real shift is that execution got cheap enough that judgment became the bottleneck.

The bottleneck moved

Three years ago, I was building API calls into spreadsheets and thought I was discovering fire.

If I had an idea in 2022, one of the first questions was usually: who do I need to ask to make this real?

Now, if I have an idea that needs a scratch implementation, I can ask Claude, Cursor, or another coding agent to produce the first pass. I can get a UI, some glue code, a rough data model, and basic tests without opening the old queue of favors and dependencies.

That sounds like pure upside, and for a while, it feels like it. Then you live with it for a few weeks and realize you can generate more surface area than you can evaluate.

More screens. More branches. More speculative workflows. More “pretty close” solutions that still hide bad assumptions.

AI did not remove the need for product thinking. It increased the penalty for weak product thinking.

When output is expensive, bad ideas die early. When output is cheap, bad ideas multiply.

Why “Just Build It” stops working

The easiest trap with AI is treating it like an autopilot instead of an exoskeleton.

• Autopilot thinking says: give the tool a goal, let it run, hope the result is good.

• Exoskeleton thinking says: use the tool to amplify your strength, but keep your hands on direction, balance, and proof.

That distinction matters because AI is very good at extending motion. It is much less reliable at improving the quality of the plan.

If your framing is vague, the system will often produce a vague solution faster. If your acceptance criteria are weak, it will happily help you ship something that only looks complete.

The biggest shift for me this year has been realizing that the highest-leverage prompt in my workflow is not “build this.”

It is some variant of:

1. ask me clarifying questions,

2. then propose a plan,

3. then define the checks that would prove we succeeded.

Those are the magic words.

That is the difference between getting motion and getting traction.

A Concrete example in miniature

When I get a product idea, it’s usually something small enough to scratch quickly but important enough that I want to see it working. Maybe it’s a way to create graphics. Perhaps it’s a skill or a report that collapses three annoying steps into one.

Three years ago, the way I built this idea was to socialize the idea, wait for time, and hope it survived contact with the next sprint. I couldn’t build it myself, either because I needed help from a developer or I’d get stuck on some dumb syntax error before I made real progress.

Now I can sketch the flow in plain English in the morning and have a working branch by lunch. That part still feels a little absurd in the best way.

Here is the catch: if I stop there, I have a demo, not a decision.

I’m now starting to build features and recently I created a small change completely using vibe-coding. It looked right in the demo, and in the tests I thought I was running. When it made it to production, the feature didn’t work (syntax error, of course.) It was an easy fix but I missed it because I didn’t realize that my vibe-coding fix had created a mock test rather than testing with actual data in the API. I didn’t see what would happen because I hadn’t defined the success criteria with observable conditions.

A better loop looks like this:

1. Define the job to be done in one sentence.

2. Ask the model what assumptions are hidden in the request.

3. Set exit criteria before implementation starts.

4. Build the smallest version that can be tested.

5. Run checks against the criteria, not against vibes.

6. Decide whether to keep, revise, or kill the idea.

The AI accelerates steps 2 through 4. I still own steps 1, 5, and 6. Those are the parts that determine whether speed compounds or whether I just created more cleanup work for myself.

Work in Gates

The biggest improvement in my own workflow has not been “better writing prompts” or “better code generation.”

It has been treating AI work like an incremental delivery system with gates.

Every project starts with a plan, then becomes a series of stories. I build an example of the criteria for a story, then ask the agent to break the requirements into story-shaped chunks. But that doesn’t mean we’re ready to build. I imagine I’m working with a person, and keep working on each story until it sounds like the feature I want to build. Then I use tests, review checklists, and concrete acceptance criteria to verify the output before I move on.

That is basically the same kind of CI thinking that developers do but using it earlier in the process for the product development work. You create, edit, nudge, and build. The agent is not doing all of the work. Ideally, it is doing the next bounded piece while you hold the thread. (And doing the work that you hate the most, like fixing syntax.)

Instead of asking, “Can the model do the whole thing?” the better question is, “What proof do I need at each step before the next layer of complexity is allowed in?”

The same structure applies outside code. For strategy memos, research synthesis, or roadmap work, the gate questions look like this:

• What claim is being made?

• What evidence supports it?

• What assumption would break it?

• What decision changes if this is true?

Without that structure, AI gives you momentum without reliability. With it, AI becomes a serious leverage tool.

The new PM skill

The practical skill shift for PMs is straightforward: less energy spent translating ideas into tickets, more energy spent designing evaluation loops.

The old advantage was knowing how to get scarce builders pointed at the right problem.

The new advantage is knowing how to turn abundant generation into trustworthy progress.

The difference shows up in how you frame the work. The old version: “Can we add export to the onboarding flow?” The new version: “What would need to be true for export in onboarding to improve activation, and how would we know within two weeks?”

That means asking sharper questions. It means writing better acceptance criteria. It means spotting where a prototype created false confidence. It means knowing when a polished answer is still strategically wrong.

In other words, the PM job becomes more editorial and more operational at the same time. You are not just deciding what to build. You are designing the system that decides whether what got built deserves to survive.

Use the suit, don’t worship it

AI does feel like a superpower. That part is not hype.

But superpowers are only useful if you can aim them.

The right metaphor is not replacement. An exoskeleton can help you lift more, move faster, and cover ground that used to be out of reach. But it does not tell you where to go, what is safe to carry, or whether the structure you are building is worth keeping.

That judgment is still your job.

If AI is giving your team more output than ever, the relevant question is no longer “How do we use it more?”

It is “What decision gates do we need so that faster output becomes better work?”

What’s the takeaway? You’re not the bottleneck any more, but your decisions are stopping progress from happening. Set your criteria before you build, check against them after, and own the decision about whether what got built deserves to survive.

Links for Reading and Sharing

These are links that caught my 👀

1/ Service as a service - I love this article by Julian Bek about Service as a Software, because the concept’s been around for a decade or more (we were chasing this at Pro.com in 2013) and yet … the tools are finally there to tackle making agentic processes that deliver service concepts at scale. Almost every business that’s out there can be made better by agents, so pay attention to this article.

2/ The Lindy Effect - Mateus Lima makes a compelling case for building simpler software. That doesn’t necessarily mean simple software; it means making a conscious choice to use the tools that work when you’re building software even if it’s not a sexy new way of building. The Lindy effect suggests that the things that work now will still be in use for at least the amount of time they’ve been around now. (Who doesn’t use SQL?)

3/ 20 questions - How do you know if your LLM is lying to you? Aaron Tay counts the ways that you should be skeptical when you’re using AI search.

What to do next

Subscribe now

Hit reply if you’ve got links to share, data stories, or want to say hello.

Hi, I’m Greg 👋! I write weekly product essays, including system “handshakes”, the expectations for workflow, and the jobs to be done for data. What is Data Operations? was the first post in the series.

This week’s toy: imagining what interfaces might look like in the age of AI. Today, it looks like science fiction, but not too far in the future.

Edition 294 of this newsletter is here - it’s March 2, 2026.

Thanks for reading! Let me know if there’s a topic you’d like me to cover.

The Big Idea

A short long-form essay about data things

⚙️ Design Navigation from the Inside Out

In 2023, I wrote about building software from cow paths. The idea was simple: study how people actually work and design around those natural paths. Don’t invent workflows in a conference room and expect users to adapt. Watch behavior, then pave it.

That assumed a sequence: behavior happened first, and design followed.

AI changes that. We no longer need to observe workflows outside the product and encode them later. The product itself can now surface paths before navigation hardens. What once formed in the real world can form inside the system.

The old model: navigation first

Most products still design from the outside in. Teams define objects, group features, build a left rail, and assign ownership to vertical slices. Navigation becomes the skeleton of the product. Users learn to translate goals into routes.

This works when attention is abundant and friction is tolerable. It breaks down when attention shrinks and abandonment rises.

On mobile, navigation carries real cost. Small screens compress hierarchy. Deep stacks create context loss. Each additional step increases the chance the user leaves. Navigation directly affects retention.

The shift: outcome first

Conversational interfaces changed how users begin. Instead of asking where something lives, users ask how to get something done.

When someone writes, “Build a Q4 churn breakdown by segment and export it for finance,” they define the task in one move. They do not think about Reports, Filters, or Export tabs. They think about completion.

A composable system can assemble the pieces around that intent. It generates the query, renders the visualization, exposes filters, and offers export without forcing the user across multiple surfaces.

Because orchestration remains observable, teams can measure which actions cluster together and which compositions correlate with successful outcomes. Navigation becomes something derived from behavior rather than imposed upfront.

“Reports” versus inline insight

Consider a team debating whether to add a top-level “Reports” tab. Users ask for analytics and exports, so the team creates a Reports page with filters, saved views, and export controls.

Now consider the alternative. A user types, “Show me churn by segment for Q4 and highlight anything unusual.” The system generates the chart inline, highlights anomalies, exposes filters beneath it, and offers export in context. The user adjusts the date range. The chart updates in place.

The report never lived in a silo. It emerged around the task.

If the conversation persists, the chart and refinements stay attached to that thread. The user can return later without navigating a dedicated Reports surface.

Over time, patterns emerge. Users often start with churn, segment by tier, adjust dates, and export. At that point, the team can promote those recurring compositions into structured surfaces.

In the traditional model, you create Reports first and hope users find what they need. In the inside-out model, reports emerge in context. Structure follows evidence.

Repeated discovery

Creation is only half the problem. Users also need retrieval. Eventually someone asks, “How do I find that churn report from last month?”

Inside-out design does not eliminate structure. It delays commitment.

One solution uses intent-driven retrieval. The user asks for the churn report they exported last week, and the system searches persisted conversations and restores the visualization.

Another solution adds faceted filtering across conversations. Users can filter by reports, exports, segments, or shared artifacts. Navigation becomes metadata over work instead of a fixed set of routes.

Creation flows horizontally. Retrieval relies on search and filtering. If certain patterns dominate, a dedicated Reports surface may still emerge. It just won’t start there.

Mobile and desktop pressures

Mobile-first users complete tasks and move on. They operate in short bursts. If the path feels long, they abandon.

Composable conversational layers compress friction. They resolve bottlenecks inline and reduce the number of surfaces users must traverse. Because abandonment happens quickly, teams get rapid feedback on which compositions succeed.

Desktop users face a different problem. Mature products fragment into silos. Reporting, automation, and communication live in separate verticals. Navigation reflects ownership.

A horizontal composable layer cuts across those boundaries. The user expresses an outcome, and the system assembles capabilities across teams in a single flow.

Architecture and uncertainty

Teams must design discrete, callable actions, define clear state transitions, log orchestration patterns, and provide safe preview mechanisms. Without that foundation, conversation becomes a thin wrapper over static routes.

There is also an organizational question. Route-driven products often mirror team boundaries. Conway’s Law suggests systems tend to reflect the structures that build them. That relationship is common, though not deterministic.

Inside-out design cuts across those boundaries. Whether that reshapes organizations or settles back into silos remains unclear. What matters is that orchestration becomes measurable. Teams gain visibility into how value forms across functions.

This will challenge support

Support teams used to page-based troubleshooting will need to reason about compositions rather than routes. That shift can feel uncomfortable, but variability is not chaos if instrumentation exists.

Product evolution often precedes operational comfort. When architecture improves, teams adapt. The right move is not to preserve familiarity but to make new behavior observable and teach teams how to interpret it.

What’s the takeaway? If navigation slows users down, compress it. If composable intent layers reduce friction, ship them. Then measure what changes.Let the path form inside your product before you pave it.

Links for Reading and Sharing

These are links that caught my 👀

1/ In branding, have an opinion - “Different” is often more memorable than “better.” Review this branding masterclass.

2/ You can’t stop scrolling - Here are a few of the reasons why short form video content is so hard to put down.

3/ Time to get better at AI - Whether you like AI or not, it’s here to stay. Time to get better at it.

What to do next

Hit reply if you’ve got links to share, data stories, or want to say hello.

Subscribe now

Hi, I’m Greg 👋! I write weekly product essays, including system “handshakes”, the expectations for workflow, and the jobs to be done for data. What is Data Operations? was the first post in the series.

This week’s toy: a 1983 adventure game made “new” by Claude. Maybe old dogs can do new tricks!

Edition 293 of this newsletter is here - it’s February 23, 2026.

Thanks for reading! Let me know if there’s a topic you’d like me to cover.

The Big Idea

A short long-form essay about data things

⚙️ The Three Minute AI Skill Test

The first time I used a large language model, it felt like cheating.

I dropped in messy notes and got back a cleaner argument than I could have written in one pass. It surfaced connections I had not named yet. It made rough thinking look polished.

The second time I tried to reproduce that result, the magic disappeared.

Same tool. Similar prompt. Worse output.

That is where most teams get stuck. They mistake first-pass surprise for capability.

If you want AI work to compound, run a three-minute check before you open chat:

Outcome: What exact shape should the answer take?

Inputs: What specific material will I provide?

Constraints: What must it not assume, exceed, or invent?

That pause looks trivial. It is not.

It is the difference between a clever prompt and a repeatable skill.

The bottleneck already moved

Most teams still think the hard part is generating output. That used to be true.

Today, generation is cheap. You can create drafts, summaries, and analysis in seconds. The bottleneck is no longer typing speed. The bottleneck is specification quality.

When your specification is vague, AI fills gaps with plausible noise. When your specification is sharp, AI gives you structured leverage.

Cheap execution amplifies both.

This is why many teams report the same experience:

1. They get one strong result.

2. They cannot reproduce it next week.

3. They conclude the model is inconsistent.

In most cases, the inconsistency is upstream, and results from them not being specific (to be terrific, you must be specific!)

Novelty mode vs skill mode

In novelty mode, you paste content into a chat and see what happens. (Vibe coding ftw!) If the output sounds smart, you keep it. If not, you nudge wording and try again.

Novelty mode is useful for exploration, but it’s not good for building repeatable operations.

In skill mode, you define the result class first, then prompt.

You are not asking for “a summary.” You are asking for “five bullets: one risk, one tradeoff, one open dependency, one owner question, one decision recommendation.”

You are not asking for “feedback.” You are asking for “critique against these criteria, with evidence quoted from the source, no external assumptions.”

Skill mode creates bounded variation: output changes based on inputs, but stays in the same useful shape.

That is what teams can reuse.

A concrete micro-story

A product operations team I worked with had a weekly ticket triage ritual. Every Friday, one PM spent two hours reading support tickets and writing a Monday brief for engineering and CX.

Imagine this experience and how it would work today with AI. You might be able to vibe code this in an afternoon, and the outcome will look great. Celebrations all around!

Week two might not look the same as your initial success. Some summaries are long and fluffy, and others invent implied causes that were never in the ticket text. When you get the blank stare from your team members and can only respond, “I’ll have to look into why the robot did that,” it’s not a reply you can repeat often before you lose trust with the team.

Instead, what if your new process looks like this? Before the report, they use the three-minute test before each run:

• Outcome: “Return exactly eight bullets grouped by issue cluster, each with count and one user quote.”

• Inputs: “This CSV plus last week’s cluster labels.”

• Constraints: “No root-cause claims. No recommendations. Only evidence in provided text.”

Quality stabilizes immediately. Review time falls from two hours to twenty-five minutes. More importantly, outputs are comparable week to week.

This team is not discovering a better model. They are simply describing their problem consistently and building a scalable insight pipeline.

Outcome, Inputs, Constraints in practice

Why does this work, and where should you be skeptical of this method?

Each line in the test solves a specific failure mode.

1) Outcome prevents shape drift

Without an explicit outcome, a model chooses its own format, depth, and emphasis. That may look impressive once, then break downstream.

Define structure up front: length, sections, ordering, mandatory fields.

If another teammate can recognize the same output class in ten seconds, your outcome is clear enough.

2) Inputs prevent hidden scaffolding

Most bad outputs come from missing context the model guessed at.

Be literal about source boundaries:

• Which documents are in scope?

• Which are excluded?

• Which fields are authoritative?

This reduces hallucinated glue logic and keeps traceability intact.

3) Constraints prevent confident fiction

Constraints are not bureaucracy. They are portability.

Set explicit guardrails for assumptions, tone, evidence, and length. If you do not, models optimize for fluency over fidelity.

Good constraints make output safe to reuse across teammates and weeks.

From prompting to operating model

A prompt is a one-time instruction. A skill is a repeatable capability with boundaries that can be made for your local use (in Claude, ChatGPT, or Gemini), generalized for any problem you build in those tools, or made into a skill.md file that you can share with others.

When building a skill, use a compact six-step loop:

1. Name the recurring job: what repeats weekly or daily?

2. Lock output shape: what exact artifact is needed?

3. Lock input contract: what source set is always provided?

4. Lock constraints: what assumptions are forbidden?

5. Run and score: what failed against spec?

6. Version the pattern: what changed and why?

If the workflow survives the fifth use with a different teammate, you are building capability that goes beyond you!

If it only works when the original author babysits prompts, you are collecting tricks. (Which are sometimes still awesome, but less useful outside of a narrow use case.)

Light mechanics for agent-era teams

As teams add more automation, this gets even more important.

A skill can encode the expected output contract. A scoped subagent can run a bounded task in parallel. A lightweight PR gate can check whether output met the declared structure and constraints.

None of that replaces judgment. It operationalizes clarity.

You do not need a heavy platform to start. Even a markdown template with Outcome, Inputs, Constraints before each recurring AI task is enough to change behavior.

The capability challenge for PMs and leads

The uncomfortable truth is that execution acceleration raises the bar for decision quality.

When teams can generate many plausible options quickly, approving work becomes the high-leverage act.

Leaders who reward “more output” without stronger specification standards will get volume without compounding.

The better posture is simple:

• Ask teams to show the output contract before the prompt.

• Reject results that are eloquent but non-compliant with constraints.

• Track reproducibility, not just first-pass quality.

This is a learnable muscle, not a talent lottery.

What’s the takeaway? If you want to know whether your team is building AI capability or just collecting clever prompts, run the Three Minute AI Skill Test before the next recurring task. The leverage is not in typing faster. The leverage is in the pause that defines the work.

Links for Reading and Sharing

These are links that caught my 👀

1/ Making software to last? - creating durable software feels strange in a world where you can ask a bot to build things. Dan Hock posits a way through this is to focus on the benefit. (Classic advice.)

2/ how to avoid hallucinations - What to worry about when you’re searching with AI? I’d say you need to know how the system retrieves and validates information.

3/ a portrait of an artist - Claude draws a self-portrait with a plotter. If nothing else, this is a fascinating art project.

What to do next

Hit reply if you’ve got links to share, data stories, or want to say hello.

Subscribe now

The next big thing always starts out being dismissed as a “toy.” - Chris Dixon

Hi, I’m Greg 👋! I write weekly product essays, including system “handshakes”, the expectations for workflow, and the jobs to be done for data. What is Data Operations? was the first post in the series.

This week’s toy: Matt Webb has made a fun and shareable way to collaborate on Markdown files. (What Google Docs should be doing.)

Edition 292 of this newsletter is here - it’s February 17, 2026.

Thanks for reading! Let me know if there’s a topic you’d like me to cover.

The Big Idea

A short long-form essay about data things

⚙️ When Shipping Gets Easy, Choosing Gets Hard

Your team can ship 10x more, but your judgement still doesn’t scale.

“Why can’t we move faster?” is the question haunting product teams right now. The usual suspects: tech debt, decision debt, not enough hands. “Not enough resources” or “too many problems, pick one.”

One root cause is cycle time—the need to keep changes atomic, low-risk, and decoupled. Take a small front-end fix. You move through problem identification, investigation, implementation, review, testing, revision, release.

Multiply that by a backlog of “small improvements,” and most of the week disappears into mechanical work. In that world, execution was expensive. Prioritization mattered, but capacity was the visible constraint.

That assumption is breaking. With bounded agent workflows, I can run small implementation tasks in parallel using explicit “skills” and scoped “subagents.” These bots draft changes, generate tests, produce PR notes, and surface risks for review.

They are not magical “Sorcerer’s Apprentice” bots. They do what you tell them—and maybe a bit more. They make mistakes, but they are reliable enough that execution cost is dropping fast.

When execution becomes cheap, weak judgment gets exposed.

The bottleneck moved upstream

Software is not limited by typing speed, or even by agents filling in software Mad Libs on your behalf. Software is limited by decision quality and second-order effects.

• What should exist at all?

• What failure modes are we introducing?

• What complexity are we normalizing?

• What future roadmap options are we quietly closing?

When implementation is expensive, bad prioritization hides behind scarcity. You cannot approve everything.

When execution gets cheap, that buffer disappears.

If your team can generate ten viable changes by noon, the problem is no longer “Can we build this?” It is “Can we choose well enough to avoid compounding noise?”

That is a different operating environment. It rewards a different PM posture.

A concrete example of where teams drift

Here’s what I worry about in a world of agent-enabled teams, and what we need to guard against.

By Tuesday, there is a queue of fourteen plausible UI improvements:

• better inline validation copy

• cleaner error states

• accessibility upgrades in shared components

• minor performance fixes

• onboarding friction reducers

• small design consistency cleanup

Every item is reasonable. None is catastrophic. Most are easy to justify in isolation.

The PM approves ten because they’re low effort and execution is now cheap.

Two weeks later, the team has mixed outcomes:

• some local UX wins

• slightly lower support volume in one path

• higher review overhead because PR volume exploded

• more component divergence than before

• roadmap work slowed by integration and cleanup noise

No single decision was “bad,” but the aggregate customer experience didn’t get better. Failure now looks like fast accumulation of acceptable changes that dilute the product.

Cheap execution does not increase your weekly supply of high-quality decisions.

Why this is now a PM leverage question

When teams adopt agents, execution mechanics can be partially automated. Throughput coordination becomes less differentiating. Decision governance becomes more valuable.

That does not mean PMs need to become full-time engineers.

It means PMs need technical boundary fluency: enough to interrogate consequence before approving work from agent pipelines.

When I review agent output, I want clear answers to:

• What exact files and surfaces are touched?

• What is the rollback path if this creates regressions?

• What class of bug is most likely here?

• What coupling or complexity is being added?

• What signal will tell us this was actually worth shipping?

If those answers are vague, we are not exercising judgment. We are delegating judgment to momentum. Momentum does not protect system quality.

The operating model that actually works

The teams getting real leverage are not using unconstrained autonomy. They run constrained execution with explicit human decision gates.

In practice:

1. Constrain intake Each task gets a tight scope and explicit out-of-bounds rules.

2. Run specialized subagents Use targeted skills for bounded work units (e.g., UI validation pass, accessibility patch, test generation), not broad “fix everything” prompts.

3. Enforce an output contract Each subagent must return: diff summary, assumptions, risk notes, tests, and rollback plan.

4. Gate through PR review A PR is reviewable evidence, not automatic merge authority. PM + engineering review consequence, not just effort.

5. Validate post-ship signal Changes without observable success/failure criteria are parked or rejected.

The key principle: approval is tied to consequence, not implementation cost.

Here is the compact checklist I use before approving agent-generated work:

PM_DECISION_GATE
1) Scope check: Is this exactly in-bounds?
2) Impact check: Which objective does this move?
3) Risk check: What breaks, and how do we roll back?
4) Complexity check: Did we simplify or add surface area?
5) Evidence check: What metric/event confirms value?
6) Ownership check: Who owns outcome after merge?

If a change cannot pass this gate quickly, speed is the wrong goal.

A potential weekly cadence:

• Monday: define bounded agent tasks tied to one product objective

• Midweek: run subagent outputs through PR gates with explicit risk calls

• Friday: review shipped items against evidence criteria and mark regret decisions

The capability challenge is real, but learnable

PMs who stay at ticket choreography level will lose leverage in agentic teams.

That is not because they are less smart. The market is revaluing what PM work matters under execution abundance.

The upside: this capability is trainable faster than people think.

A practical path:

• sit in PR gates for agent-generated changes and ask one consequence question every time

• keep a monthly “decision regret” log of shipped work you would now reject

• require rollback + observability notes for every non-trivial change

• build deep fluency in one layer of the stack where your product risk is concentrated

You do not need to write production code daily. You need to reason clearly at decision boundaries.

PMs who can do that become force multipliers. They turn execution abundance into focused product progress instead of complexity debt.

The optimistic version of this shift

This is not a story about protecting PM territory from automation.

It is a chance to remove mechanical drag and reinvest attention into higher-order judgment:

• sharper sequencing

• cleaner product boundaries

• better tradeoff quality

• less accidental complexity

Engineers can spend more cycles on architecture and reliability. PMs can spend more cycles on decision quality and coherence. When execution is cheap, relevance is the discipline.

Where PMs usually get this wrong first

The first mistake is treating agent throughput as automatically strategic throughput. But more completed work can still mean less progress if the work is weakly connected to outcomes.

The second mistake is approving changes because review friction is lower. Low-friction approval often hides high downstream cost—more exceptions, more implicit coupling, more “tiny” one-off logic that future teams inherit.

The third mistake is lack of ownership when changes need to be committed and approved. If a PM approves, an engineer merges, and no one clearly owns post-ship consequence, quality will drift no matter how good the tools are.

These are process failures, not model failures.

If teams blame the agent for every bad outcome, they avoid the harder fix: raising decision standards, clarifying ownership, and making consequence visible at approval time.

The new default

In an agentic environment, “yes” is no longer a neutral choice.

Every approval changes the system. Every added branch increases future cost. Every local win competes with strategic focus.

The default needs to shift:

Approve less. Approve better.

• Keep autonomy bounded.

• Keep gates explicit.

• Keep decision rights close to consequence.

• Keep PM attention on what compounds.

Execution can now scale in parallel.

Judgment still scales one careful decision at a time. That is not a weakness in the system. It is the center of the PM job now.

If this resonates, the practical question is simple: where in your current workflow are you still rewarding motion over relevance?

What’s the takeaway? As a PM, you need to be pushing and approving the highest-leverage items. Be careful what you decide to build and approve. It can solve today’s apparent problem but create tomorrow’s backlog if you’re not careful.

Links for Reading and Sharing

These are links that caught my 👀

1/ Art in the age of machines - Dan Hockenmaier reminds us that in the age of machines, thinking like a human (and an artist or philosopher) helps you to stand out. Taste, judgement, and influence matter.

2/ The price of a TV - Why did TVs get so cheap? This is a fascinating deep dive on the market forces (and production enhancements) making TV prices drop like a rock.

3/ How do you pitch AI? - When anyone can build anything, how do you pitch in a compelling way? Here are a few examples that marketers of AI-forward software are using to improve positioning.

What to do next

Hit reply if you’ve got links to share, data stories, or want to say hello.

Subscribe now

The next big thing always starts out being dismissed as a “toy.” - Chris Dixon

Hi, I’m Greg 👋! I write weekly product essays, including system “handshakes”, the expectations for workflow, and the jobs to be done for data. What is Data Operations? was the first post in the series.

This week’s toy: Anthropic released the new Opus 4.6 Model - check it out! I look forward to testing it on Dad Jokes (see below)

Edition 291 of this newsletter is here - it’s February 9, 2026.

Thanks for reading! Let me know if there’s a topic you’d like me to cover.

The Big Idea

A short long-form essay about data things

⚙️ Start with a single page web site

The blank page seems bigger with LLMs when you invite them into your file explorer. How do you go from zero to one by starting with something interesting and then end up with an app? Most people start the same way they use Claude or ChatGPT in the browser: by asking questions.

That works to a point, until you want to build a more complicated application or process, because of context rot. After a certain period of time, the LLM runs out of space and you’re starting again from square one, explaining to a forgetful intern what you were working on.

When you try to move from “could this work” to “does this exist”, this aspect of chat becomes a liability. Every answer evaporates when the tb closes, except for the plan files that get created when you run Claude or Codex in plan mode.

Getting value out of these tools requires a simple but non-obvious shift. Instead of asking questions on a web chat, embded the chat experience inside your workspace.

The easiest way to do that is to begin with a one-page website.

Chat (alone) is the wrong default for builders

Chat is great for planning, and not as good for progress. They reward clever prompts, long explanations, and theoretical completeness. That’s useful for learning, but it doesn’t help you build. There’s no persistent artifact, no shared ground truth, and no natural pressure to refactor or decide.

You build consistency and by creating a system that supports building. Start with a plan and then create:

• files

• structure

• constraints

• tradeoffs you can point to later

When you isolate “chat with an LLM” inside a file-based IDE and give it concrete artifacts to operate on, the model behaves differently than it does when you use it on the web interface. You go into planning, evaluation, and thinking mode ... and then build.

The one-page website as a universal starting block

If you strip away tooling debates and framework preferences, most early projects fail for a simpler reason: they never become real enough to push back. A one-page website solves that immediately.

It forces an idea to cross a boundary — from imagined to instantiated — without demanding commitment to a backend, a framework, or a long-term architecture. You get something that runs, renders, and responds, while remaining cheap to abandon or reshape.

A single page collapses several early decisions into one artifact:

• what the product is, in plain language

• what a user can do, even if it’s trivial

• what feedback looks like, visually and interactively

From an LLM’s perspective, this is an ideal unit of work. The page is small enough to fit in context, concrete enough to reason about holistically, and visual enough that mistakes are obvious.

You’re no longer asking the model to design something abstract. You’re asking it to change a thing that already exists.

Start small by building a single card

Most “getting started” demos accidentally teach the wrong lesson.

They start with serious-looking software like charts, tiles, toggles, and settings. It looks like software, but it doesn’t feel like a single artifact to review.

A better metaphor is a collectible card. One joke. One card. One unit of work.

Using a dumb idea like a joke card is a solid constraint and a tight visual story. It also matches how people actually adopt tools. They want a small win that feels finished, not a scaffolding project that “will be great later.”

The card format forces the parts that matter:

• a title

• a clear body

• an image window (even if it’s a placeholder)

• a brand tag

• a number (“#4 of 36”)

• a few simple signals

That’s enough to feel like a product.

The dad joke card (API-only, no backend)

Let’s try this out with a smallish project: a one-page dad joke card. Not just because jokes are fun, but because the shape of the problem matches what we want to solve.

The page does almost nothing:

• fetches a random dad joke from an external API

• displays it on a collectible-style card

• shows a card number (“#4 of 36”) and a brand tag (“DadJoke”)

• lets the user choose:

  • 👍 like

  • 👎 dislike

  • ⏭ skip

• shows simple stats (liked / disliked / skipped)

• has a “next card” action

There’s no backend. No database. No server. Just a single page making an API call.

And yet, this already forces real product decisions:

• What does “skip” mean? Is it neutral or negative?

• What happens when the same joke appears twice?

• Do you treat “no response” as “unrated” instead of “dislike”?

• Where does state live (memory vs localStorage)?

• What is the smallest UI that still feels complete?

Those decisions live in the files, so when the chat fails, it has a clear way to recover.

Scope and story live outside the prompt

Here’s how to start. Before writing any code, create two small markdown files:

• scope.md: what this is and, more importantly, what it isn’t

• story.md: the user flow and what “done” looks like

When you ask the LLM to help you build, it’s not guessing your goals from a prompt. It’s extending a shared plan. The conversation becomes subordinate to the artifacts, which is exactly what you want.

Let constraints teach you architecture

As the page evolves, something predictable happens: the JavaScript starts to sprawl.

State handling, API calls, UI updates, edge cases—they all pile into one place. Somewhere around a few hundred lines, working on it stops being fun.

You don’t refactor because “best practices” say so. You refactor because the artifact demands it. Splitting logic into smaller files stops being academic advice and becomes relief.

This is how architecture should be learned: as a response to pressure, not as a prerequisite.

SPOILER ALERT: the LLM thrives here. With smaller, clearer files, it can reason locally.

Why stopping early is the point

This example intentionally stops at a one-page site plus an external API. That’s not because those things don’t matter. It’s because you don’t need them to learn how to build effectively with AI.

By the time this page works, you’ve already practiced the transferable skill:

• scoping work explicitly

• anchoring context in files

• iterating without resetting progress

• refactoring when complexity appears

The dad joke card isn’t a toy. It’s a complete learning loop with a clean exit.

If you’re getting started with AI coding tools and feeling stuck, the problem is rarely the model. It’s the environment you’ve put it in.

Chat is great for answers. Builders need artifacts. And DadJokes are fun!

What’s the takeaway? Start with something that runs. Keep it small enough to understand. Let constraints force decisions. And treat the model as a collaborator inside your workspace, not a voice in a tab.

Links for Reading and Sharing

These are links that caught my 👀

1/ Be careful when you make rules - you might end up with more rules, so be mindful about which ones you want to keep.

2/ The third revolution - we went from 4gl languages to Saas apps and now to … apps on demand. It’s a new golden age, thanks to AI.

3/ Company as code - organizational patterns follow the organizational rituals of the company. What happens when you try to define those rules in code?

What to do next

Hit reply if you’ve got links to share, data stories, or want to say hello.

Subscribe now

The next big thing always starts out being dismissed as a “toy.” - Chris Dixon

Hi, I’m Greg 👋! I write weekly product essays, including system “handshakes”, the expectations for workflow, and the jobs to be done for data. What is Data Operations? was the first post in the series.

This week’s toy: Agentic coding for iOS apps is increasing big time.

Edition 290 of this newsletter is here - it’s February 2, 2026.

Thanks for reading! Let me know if there’s a topic you’d like me to cover.

The Big Idea

A short long-form essay about data things

⚙️ From Tickets to Conversations

Most customer service communications systems aren’t explicitly broken. They’re still doing exactly what they were designed to do. But the way they are doing it is not longer what customers expect.

Take ticket help desks like Zendesk, Freshdesk, and JIRA Service Desk. These systems are a good example of “job well designed” because used well, they resolve issues correctly, enforce consistent rules, and scale predictably. For a long time, giving you a ticket ID and resolving your issue in a reasonable amsount of time was exactly the right thing to optimize for in a support situation.

The need for support didn’t change. What changed was the expectation to respond instantly.

When correctness stops being enough

The traditional help desk (ITIL) model assumes that work arrives as a declared request. A user identifies a problem, opens a ticket, enters a queue, and eventually receives a response. Fairness and order matter more than immediacy. Waiting is acceptable as long as the process feels legitimate.

That model still works! Tickets get resolved, and it’s possible to manage and adhere to service level agreements. (Yes, I know that lots of tickets still breach their commitments).

But now there is ChatGPT and Claude, so users expect an immediate acknowledgement and ideally an answer on the first response. Resolution might come later, but silence from the help team feels like failure, or at the very least “I don’t matter to you.”

Let’s acknowledge that in the world of GPTs, waiting feels unnecessary when the question is simple, contextual, or exploratory. Even when you need to go get some information to solve a question, you should at least be able to respond right now with what you know.

This is where organizations get stuck. The system is still right, but it’s no longer aligned.

The wrong explanation for chat usage

When chat volume increases, it’s tempting to explain it as user confusion. Customers don’t know what they want, and they’re bypassing the “proper” interface. That framing made sense when chat was slow, text-only, and disconnected from real action.

Jevons paradox suggests otherwise … when it’s easier and cheaper to communicate, people will do it more!

Modern chat can persist context, render UI, surface options, preview outcomes, and trigger workflows inline. Once conversations can stay stateful and take action without handoffs, chat stops being a fallback channel and becomes a legitimate interface.

Don’t forget another big shift that happened over the last few years. If you can’t interact with a company on your phone, that interaction might as well not exist. Once conversational interfaces became something you could access instantly, from anywhere, the acceptable delay collapsed. Users stopped thinking in terms of sessions and started thinking in terms of moments.

When you’re using your phone and have question, you don’t want to wait. Some of this is a UX slight of hand, because when you lack an immediate acknowledgement, it feels like friction.

Chat + mobile + always available network access means that every app with messaging needs to feel like a text conversation.

Chat as a dynamic control surface

By “control surface,” I don’t mean that chat should replace every interface. I mean a surface where intent can be clarified and action can be taken without forcing the user to leave context.

Here’s how it works.

A user asks a question. The system responds, but also offers two actions inline. One click resolves the issue. No ticket number. No queue. No escalation. The conversation continues.

That’s not just faster support. That’s control.

In a ticketing system, help and action are separate. You explain the problem, then wait for someone else to act.

In an inline chat model, those boundaries blur. The system can guide the user, suggest next steps, and sometimes complete the action directly. The chatbot isn’t replacing resolution. It’s replacing waiting.

Chat as a user-owned inbox

One way to understand this shift is to stop thinking about chat and tickets as different tools. They’re different ownership models for conversation.

Tickets are conversations optimized for organizational flow. Chat is a conversation optimized for user continuity.

Organizations initiate help desk tickets. They use internal structure like queues, priorities, and ownership to make work manageable. Basically, you’re adding the user to the organizations Inbox.

Chat flips that relationship. The user starts the conversation and stays in it. Routing, escalation, and logging can still happen, but they don’t need to be exposed as part of the experience.

Tickets didn’t disappear. They stopped needing to be visible.

Historically, visibility was how systems maintained control. Process transparency was how trust was earned. Systems were brittle enough that users had to participate in internal workflows.

Why exposing tickets now feels heavy

When ticket mechanics are exposed, users are forced to adapt to internal workflows. IDs, statuses, and queue positions interrupt flow. Process transparency becomes part of the experience whether the user wants it or not.

But most customers don’t want transparency for its own sake. They want acknowledgment, progress, and resolution.

If those can be delivered without exposing internal routing, hiding it becomes a feature, not a bug. This is why chat feels lighter even when the underlying system hasn’t changed.

Where resistance shows up

When organizations resist this shift, it’s rarely because chat doesn’t work. It’s because ticketing systems encode long-standing assumptions about boundaries.

Treating chat as just another intake mechanism preserves existing roles and separations. Letting chat guide or act challenges them.

So objections show up as principled arguments:

• “Support shouldn’t do product.”

• “That belongs in the UI.”

• “Chat should just answer questions.”

These sound like architectural concerns. Often, they’re defenses of familiar system design.

This isn’t an argument for novelty

Not all functionality belongs in chat. Not all users want guidance. Some domains still require formality, delay, and explicit handoffs.

This isn’t about chasing trends.

It’s about recognizing that systems age relative to expectations, not correctness. When expectations shift, correctness becomes an insufficient defense.

Treating chat as “just support” is no longer neutral. It’s a design choice—to preserve old boundaries even when customers no longer experience them that way.

What’s the takeaway? Users expect your system to work like a text conversation. If you started again and designed your support system today, what assumptions would it make about customer patience? I’d start by making sure you can answer more questions instantly and well, and setting expectations appropriately when your team needs more time to work.

Links for Reading and Sharing

These are links that caught my 👀

1/ Context is king - When you’re building applications (especially for AI), state is only the first thing you need to think about. Context is everything.

2/ A cookbook for agents - A wonderful compendium of patterns for AI agents. Check it out here and you’ll probably also check some of your assumptions.

3/ On estimating work - If you’ve ever been asked, “how long will it take?” and the answer that immediately popped into your head was “it depends…” you probably need to read this piece on estimating, written by a software engineer.

What to do next

Hit reply if you’ve got links to share, data stories, or want to say hello.

Subscribe now

The next big thing always starts out being dismissed as a “toy.” - Chris Dixon

Hi, I’m Greg 👋! I write weekly product essays, including system “handshakes”, the expectations for workflow, and the jobs to be done for data. What is Data Operations? was the first post in the series.

This week’s toy: game theory to assess which LLM lies most effectively. See if you can win! And then, think about how to validate and center the answers you get from LLMs when you’re using your favorite chatbot. Trust, but verify that the chatbot is telling you the right thing. You’ll be improving the model and your critical thinking ability at the same time.

Edition 289 of this newsletter is here - it’s January 26, 2026.

Thanks for reading! Let me know if there’s a topic you’d like me to cover.

The Big Idea

A short long-form essay about data things

⚙️ Why focusing on the customer journey fixes the ownership problem

Who owns the customer experience, really? When a problem happens, we typically point at the team that owns that feature in the product. But most ownership problems aren’t caused by unclear roles or missing accountability. They happen because no org chart maps cleanly to how customers actually experience a product.

Features, reliability, support, and recovery live in different teams, but the customer experiences them as a single, continuous journey. The customer doesn’t care if a problem happens due to team 1’s feature or team 2’s feature. They just know they have a problem. When teams focus on optimzing their slice of the system, no single owner can see, let alone fix, the full impact.

This is why ownership debates feel endless and unsatisfying. Everyone is partially right. Everyone is locally correct. And the customer still has a broken experience.

The ownership problem is structural, not managerial

Organizations often respond to fragmented ownership by tightening control. They assign a DRI. They escalate decisions to leadership. These moves concentrate accountability, but they don’t change how decisions are made in the moment. They treat ownership as a reporting problem instead of a systems problem.

The systems problem is that the org divides responsibility along internal boundaries, while the impact is felt end-to-end. A product team can ship a feature that works by design and is very different than a similar feature created by another team. A platform team can keep systems healthy without observability metrics that detail customer pain. The support can resolve tickets within a service level agreemnt while still disappointing the customer.

And the customer can still lose trust because the experience no longer makes sense from one step to the next.

Customer journey ownership fails when responsibility is evaluated locally and is disconnected from the global experience.

The customer journey is the only end-to-end system

No one team owns the entire customer journey. That path starts before the customer is ready to buy, continues through mid- and bottom- funnel actions, and begins again in an activation journey as a customer. When the back-end organization changes, the customer journey rarely changes along with it.

That makes the customer journey the only system that:

• every team touches,

• no team fully controls, and

• cannot be optimized locally without visible consequences.

Focusing on the customer journey fixes the problem from the outside in. You don’t need to re-org the team to create a shared reference teams can use even when they have fragmented responsibility.

When the customer has a problem and teams disagree about what to do, the customer journey delivers a more useful question than “who owns this?”:

Does this preserve the customer’s ability to predict what happens next?

Ownership fails at boundaries

Most customer harm happens at the seams:

• between feature and support,

• between automation and human fallback,

• between “working as designed” and “working as expected.”

These handoffs are invisible inside teams and obvious to customers.

When decisions are evaluated through internal lenses—velocity like uptime, ticket volume, and cost, teams rationally optimize their metrics and unintentionally degrade the journey. Each of these decisions makes sense in isolation. The failure appears when the customer gets surprised.

Focusing on the customer journey asks teams to reason end-to-end, even when they don’t share a manager, a roadmap, or incentives.

Failure classes are broken customer expectations

Using the customer journey as a frame gives you a clear way to classify failure. You can triage by which customer expectation was violated and carried forward.

For example:

• When the customer’s mental model breaks (and you see confusion), it doesn’t matter specifically whether it’s an API bug or a UX miss.

• When customers don’t tell you that they are having problems and your observability system doesn’t see it either, it’s a twin problem.

• When a reasonable customer mistake keeps happening and becomes an expectation of failure, it might be genuinely hard to reverse.

Once you anchor failure to the journey, debates about ownership become easier. Teams may still disagree on fixes, but they can agree on whether a decision preserves continuity or introduces surprise.

Why cross-training sometimes works

One way to solve this problem is to move people around within internal teams so that they see more (and different) types of problems. The intuition is sound: exposure builds empathy.

But it’s a flawed assumption. Someone who can’t identify root causes in their home team will usually just relabel symptoms elsewhere. They return with anecdotes, not insight.

Cross-training works much better when it forces people to confront the same class of customer harm under different constraints. The value isn’t context switching. It’s judgment calibration.

A product IC who has shipped features, been on-call for multiple teams, and debugged downstream fallout starts to recognize patterns that transcend teams. They don’t ask, “Who owns this?” They ask, “Where does the journey break if we do this?”

That’s not collaboration. That’s shared judgment.

Why rotations need sense-making to matter

If you want cross-training to strengthen ownership rather than dilute it, rotations must be designed around exposure to failure classes, not roles. You need to be able to identify decisions, not just execute tasks. And you bring it together to find results.

Every rotation should end with questions like:

• Which customer expectations failed repeatedly?

• Which tradeoffs looked rational locally but harmful globally?

• Where did the journey rely on assumptions that didn’t hold?

Without that synthesis, experience stays anecdotal.

The customer journey as a tie-breaker

The most practical benefit of journey-anchored thinking is how it resolves disagreement.

When two teams disagree, the deciding question isn’t who owns the fix, whose metric matters more, or who should escalate.

It’s answering this idea:

Which option preserves the customer’s ability to move forward without relearning the system?

Answering this question makes the tradeoffs explicit rather than hiding them. Teams still choose speed over polish, or automation over human review. But they do so knowing where the journey bends and what debt they’re incurring.

That’s a fundamentally different ownership model focused on the customer.

Where teams misuse the customer journey

This approach fails when the journey is treated as a documentation artifact, a CX diagram disconnected from decisions, or a rhetorical shield to block progress.

The journey isn’t a reason to stop shipping.

It’s a way to understand what you’re breaking when you do.

Designing for continuity, not consensus

Ownership problems disappear when teams share a way to evaluate impact that transcends org boundaries.

The customer journey works because it doesn’t belong to any team. It also works because it reflects the system customers actually experience, not the one we wish they did.

When teams don’t share a manager, the customer journey becomes the only system allowed to overrule local optimization. It’s the map to design organizations where good judgment scales without permission.

What’s the takeaway? Ownership problems aren’t about roles; they’re structural. The customer journey is the only system every team touches but no one controls. Make it the tie-breaker.

Links for Reading and Sharing

These are links that caught my 👀

1/ Ascii Art rendering - One of my fun tricks when workplace messaging first started was to copy ASCII art from very early BBS days and send it to baffled co-workers. (“Why is Star Wars presented only in text?” is a suitable statement.) Imagine my delight at finding this project that converts video to ASCII.

2/ Using the 5 Whys with an LLM - No, I’m not talking about “make me a one-page website” or “solve this equation for me.” Asking an LLM to explain its logic to you helps you to learn the concept, take it apart, and share with others. Ask your chatbot of choice to explain things to you, and have a conversation.

3/ A cow that uses tools - Who knew (moo!) that a cow can use tools like other primates.

What to do next

Hit reply if you’ve got links to share, data stories, or want to say hello.

Subscribe now

The next big thing always starts out being dismissed as a “toy.” - Chris Dixon

Hi, I’m Greg 👋! I write weekly product essays, including system “handshakes”, the expectations for workflow, and the jobs to be done for data. What is Data Operations? was the first post in the series.

This week’s toy: A microcontroller that runs code to display the next bus arriving nearby. Perhaps the next revolution of AI will be a breakthrough in physical 3d printing to enable us to build software+things. Want to build a switch for your desk to change the song or a toggle to start the dishwasher? (Or perhaps more practical things.)

Edition 288 of this newsletter is here - it’s January 19, 2026.

Thanks for reading! Let me know if there’s a topic you’d like me to cover.

The Big Idea

A short long-form essay about data things

⚙️ What do you build when you can build anything?

The most dangerous outcome of unlimited building capacity is that you can become very good at fixing symptoms without eliminating the root cause. The bottleneck moved from technical risk to judgment. You need to know when a fix teaches you something and when you are “kicking the can” and papering over a deeper flaw.

Before 2024, effectiveness was constrained by tooling. Even if you knew what you wanted to change, you had to determine how to get it done cheaply, safely, or quickly to earn a release. Scarcity of engineering resources forced prioritization. It also hid some bad judgment because you couldn’t just ask Claude “how do I fix that?”

That engineering constraint is gone, thanks to Agents and LLMs.

It’s possible to build tools, scripts, workflows, dashboards, and automations faster than organizations want or can even run a decision process to decide whether it’s a good idea. The result is uneven effectiveness. Some teams compound their gains, and others get very busy fixing the same problems faster.

The difference might be the question: “is this the right fix to solve the problem, every time it happens?”

The dashboard that didn’t deflect anything

Let’s take a familiar example. When support volume is rising, everyone agrees it’s a problem. So you build a dashboard that shows volume by category, deflection rate over time, and the top repeated questions.

Everyone loves the dashboard, and it initially focuses the team on solving some of the most important problems faced by customers. Hooray for progress!

Now fast forward to several weeks later, when support volume hasn’t meaningfully changed. The team has identified exactly where the problem is happening. But it’s still happening.

Trying to harden the system

The dashboard did its job: it surfaced the problem. The response is where things go wrong. The support dashboard exposes problems in the data. Perhaps category data is not normalized. Maybe there’s a double counting problem. It could be a legitimate schema change that wasn’t shared with the operational team.

So engineers respond rationally by normalizing data, introducing helper libraries for categorization, and other abstractions. They also ask AI for a good fix, and it’s great at this!

Each of these decisions is defensible. When they’re not aligned, they quietly raise the cost of change.

Now the dashboard works better, but contains a new library that no one has used before. Fewer engineers understand the pipeline end to end. Small changes take longer because the codebase has some new pathways. And the original problem remains: customers still ask the same questions.

The issue isn’t complexity itself. It’s structure introduced before the system has earned it. Those abstractions harden assumptions that haven’t been tested yet. And AI is a very good multiplier for this problem. In the hands of someone who’s not sure how to improve things, AI will attempt to complete the answer.

Teams that use AI and exhibit some caution when using it gain the benefits of fast iteration plus engineering discipline.

As an engineer, you want known systems:

• Favor primitives over patterns

• Boring code you can reason about six months later

• As little abstraction as possible

These simple solutions may take longer to build than a quick fix. Many teams fix symptoms because incentives quietly reward it. System-level fixes are slower, harder to attribute, and often invisible when they work. Over time, organizations train people to optimize for visible artifacts instead of reduced work.

PMs want to use bugs for learning, but might get optimistic

PMs approach the same situation and run into a different local maximum.

They look at the dashboard and see the top repeated questions. They respond rationally:

• Writing help center articles

• Adding tooltips

• Creating canned responses

• Occasionally fixing small bugs themselves

These fixes don’t solve the root cause of the problem and make the paper cuts less painful instead. The goal should be strategic, well-chosen small fixes. These are the kind that eliminate the cause.

Bug-fixing can be one of those mommnts when it’s used as discovery. For PMs, fixing a bug teaches things no roadmap ever will:

• Where assumptions break

• Which defaults confuse customers

• How data actually flows

• Why “simple requests” aren’t simple

But caution: If PMs fix symptoms without eliminating the cause, they become a patch layer. Instead, we want a reinforcing loop:

Fix → learn → redesign the system so the fix is no longer needed

Otherwise, we’ve fixed the symptom and not the problem.

Immediate relief vs long-term leverage

This argument assumes basic hygiene exists: ownership is clear, failures are observable, and changes can be shipped safely. If those foundations are missing, symptom-fixing isn’t a mistake, and is often the only way to regain control.

The danger starts once hygiene is in place and teams keep treating recurring problems as one-off fixes. Not all fixes are bad, and not all leverage is good.

Sometimes immediate relief is correct:

• A customer-visible issue

• A frequent, expensive failure

• A fix that is clearly bounded and reversible

Sometimes long-term leverage is required:

• When the same class of problem keeps reappearing

• When ownership or decision rights are unclear

• When every change requires explanation and coordination

Teams get into trouble when they confuse the two:

• Building “platforms” when customers need relief

• Shipping patches when the system needs redesign

The test is simple:

Does this reduce future friction, or just reduce noise today?

Speed is not the metric. Direction is.

Designing systems that can change

When capability is abundant, the goal is no longer to build correct systems. It’s to build systems that can change safely.

Effective systems:

• Favor incremental delivery over big rewrites

• Replace questions with defaults

• Make status observable instead of reported

• Encode judgment once, not repeatedly

• Fail in ways that are visible and recoverable

This is where engineers and PMs converge. Both are now constraint designers, and changeability is the real form of leverage.

Guardrails against fixing symptoms forever

Abundance – especially AI-assisted abundance – introduces entropy by default. Discipline matters more than ambition.

A few rules that scale:

• Reject solutions you can’t explain to a teammate

• Prefer existing tools over novel ones

• Treat AI output as a draft, not a decision

• Be suspicious of fixes that feel “too clean”

Clever systems age poorly. Boring systems evolve.

The final test of effectiveness isn’t how fast you ship, how much you automate, or how elegant the solution looks.

If your system requires increasingly skilled people to keep it running, you didn’t build leverage; you built a dependency.

What’s the takeaway? Building is abundant; judgment is scarce. When you make changes, ask: does this reduce future friction, or just noise today? Your goal should be building systems to change safely, not ones that require experts to always be on call.

Links for Reading and Sharing

These are links that caught my 👀

1/ “Ok, computer” - The next leap in creating software will probably start from a phone with a voice conversation. Agents doing the work remove the need for you to be in front of a keyboard, so what will be different? (And what need challenges and opportunities will arise?)

2/ How do you trust an agent? - For agents that deal with money, you define a set of rules for fiduciary responsibility. Next, an observability layer that helps consumers to know if the agents actually did what they were supposed to do (think star ratings for mutual funds conducted by an independent agency for a model here.) Yep. it’s early days.

3/ What does a skilled operator do now? - if you believe (like I do) that AI is a useful set of tools and that as skilled operators, we need to learn how to use them, what do you do if you’re feeling behind? The short answer: get started using the tools, and don’t worry if you’re doing it it right. AI may not take over your job, but you’ll be a lot better at your job if you can articulate how you can make it better (or not) using AI.

What to do next

Hit reply if you’ve got links to share, data stories, or want to say hello.

Subscribe now

The next big thing always starts out being dismissed as a “toy.” - Chris Dixon

Hi, I’m Greg 👋! I write weekly product essays, including system “handshakes”, the expectations for workflow, and the jobs to be done for data. What is Data Operations? was the first post in the series.

This week’s toy: a version of the “six degrees of Kevin Bacon” game where you get from one topic to another with help of an LLM. If nothing else, it’s a good way to practice your prompting instincts.

Edition 287 of this newsletter is here - it’s January 12, 2026.

Thanks for reading! Let me know if there’s a topic you’d like me to cover.

The Big Idea

A short long-form essay about data things

⚙️ A State Machine answers “when” and “why” for customer changes

Picture this: you run a query and find the count of active customers. Next week, you run the same query and get a different number. In the perfect data environment, you know why that number changed. It’s a combination of new customers, customers who left, and those who didn’t change.

Now here’s the hard part. You can’t easily see the rate or shape of the change with a single point of data on a record.

Most teams store subscription status as a field: status = "active". That works until you need to answer “when” or “why” questions. So you add more fields: billing_status, product_status, support_status. Now you have three statuses that might conflict, and you still can’t answer “when did they cancel?” or “what triggered the last change?”

The problem isn’t the number of fields. It’s that you’re storing snapshots when you need journeys.

When did they cancel? How long were they in trial? What triggered the last state change? A status field can’t answer these. It’s a snapshot, not a story.

The solution isn’t more fields. It’s a state machine. A state machine models how subscriptions move through states (trial → active → cancelled) and what triggers each transition. With state history, you can answer “when.” With events connected to transitions, you can answer “why.”

State machines capture the customer journey

Most teams model subscription status as a field because it’s simple to store a single value. But subscriptions move through states over time. A status field tells you where a subscription is now. A state machine tells you where it came from, where it can go, and what triggers each move.

The difference matters because the questions that matter aren’t “what is the status?” They’re “when did it change?” and “why did it change?” Those questions require history and events—the two things a status field can’t provide.

A state machine isn’t just a better way to store status. It’s a different way to think about data. Instead of asking “what is the current state?” you ask “what is the journey?” The shift from snapshot to story unlocks better questions that actually matter.

There are some questions status fields can’t answer

Here are five questions that status fields can’t answer without help from other tables:

Question 1: “When did they cancel?”

• Status field: Can’t answer. You only know they’re “cancelled” now.

• Why it matters: You can’t calculate time-to-churn or identify patterns in cancellation timing.

Question 2: “How long were they in trial?”

• Status field: Can’t answer. You only know they’re “active” now.

• Why it matters: You can’t optimize trial length or identify which trial durations convert best.

Question 3: “What triggered the last state change?”

• Status field: Can’t answer. You don’t know if it was a payment failure, user action, or time-based rule.

• Why it matters: You can’t debug issues or understand why subscriptions change states.

Question 4: “What’s our true MRR?”

• Status field: Ambiguous. Does “active” include paused subscriptions? Past-due subscriptions?

• Why it matters: You’re making financial decisions on unclear data.

Question 5: “Can we reactivate this subscription?”

• Status field: Can’t answer. You don’t know the transition history or business rules.

• Why it matters: You can’t automate reactivation or understand what’s allowed.

Status fields capture “what” but not “when” or “why.” For subscription lifecycles, you need the journey, not just the destination.

What is a State Machine?

A state machine modes how something moves through different conditions over time. For subscriptions, it defines three things:

States — The valid conditions a subscription can be in:

• trial (evaluating, not yet paying)

• active (paying and using)

• paused (temporarily stopped, may resume)

• past_due (payment failed, but not cancelled)

• cancelled (ended, but may have access until period ends)

• expired (fully ended, no access)

Transitions — How subscriptions move between states:

• trial → active (when payment succeeds)

• active → past_due (when payment fails)

• past_due → active (when payment succeeds)

• active → cancelled (when customer cancels)

• cancelled → expired (when grace period ends)

Rules — What transitions are allowed:

• Can a cancelled subscription become active again? (Depends on your business rules)

• Can a past_due subscription skip directly to expired? (Usually no—it goes through cancelled first)

• What can move to active? (trial, past_due, paused—but not expired)

A state machine isn’t just a list of states. It’s a system with rules. Those rules prevent invalid states (like a subscription that’s both “active” and “cancelled”) and make your data model reflect how your business actually works.

Unlike a status field, a state machine models the journey. It knows where a subscription came from, where it can go, and what triggers each move.

How do state machines answer “when” and “why”?

A status field stores current state. A state machine stores history in an event table.

What you need:

• Table: subscription_state_history

• Fields: subscription_id, state, started_at, ended_at

• This creates a timeline: trial (Jan 1-14) → active (Jan 15 - Mar 10) → cancelled (Mar 11 - Mar 31) → expired (Apr 1)

Now you can answer:

• “When did they cancel?” → Look at when cancelled state started

• “How long were they in trial?” → Calculate difference between trial start and end

• “What’s the average time from signup to first payment?” → Compare trial end to active start across all subscriptions

You’re not just asking “what is the status?” You’re asking “what happened and when?” Events are the key thing that trigger state changes.

What you need:

• Table: state_transitions

• Fields: subscription_id, from_state, to_state, triggered_by, occurred_at

• This connects events to state changes: payment_failed → active → past_due

Common triggers:

• Payment succeeded → past_due → active

• Payment failed → active → past_due

• User cancelled → active → cancelled

• Trial ended → trial → active (if payment) or expired (if no payment)

• Grace period ended → cancelled → expired

Now you can answer:

• “What triggered the cancellation?” → Look at the triggered_by field for the transition to cancelled

• “Why did this subscription go past_due?” → Find the payment_failed event

• “How many cancellations were triggered by payment failures?” → Query transitions where from_state = past_due and to_state = cancelled

You’re not just asking “what changed?” You’re asking “why did it change?”

What does this look like before and after?

Before: Status Field Approach

Table: subscriptions

• Fields: subscription_id, customer_id, plan, price, status

• Status values: “active”, “cancelled”, “trial”

Questions you can answer:

• “How many active subscriptions do we have?”

• “What’s the total revenue from active subscriptions?”

Questions you can’t answer:

• “When did subscription #123 cancel?”

• “How long was subscription #123 in trial?”

• “What triggered the cancellation?”

• “What’s our MRR excluding paused subscriptions?”

(You don’t even have a “paused” state)

After: State Machine Approach

Tables:

• subscriptions (subscription_id, customer_id, plan, price, current_state)

• subscription_state_history (subscription_id, state, started_at, ended_at)

• state_transitions (subscription_id, from_state, to_state, triggered_by, occurred_at)

Now you can answer:

• “When did subscription #123 cancel?” → Query state_history where state = ‘cancelled’

• “How long was subscription #123 in trial?” → Calculate from state_history

• “What triggered the cancellation?” → Query transitions where to_state = ‘cancelled’

• “What’s our MRR excluding paused subscriptions?” → Sum active subscriptions, exclude paused

The state machine doesn’t just store more data. It stores the right data—the data that answers “when” and “why” questions.

One concrete example:

• Status field: “Subscription #123 is cancelled.” That’s all you know.

• State machine: “Subscription #123 was in trial for 14 days, active for 45 days, then cancelled on March 11th when the customer clicked ‘cancel’ after a payment failure. The subscription expired on March 31st when the grace period ended.”

That’s the difference between a snapshot and a story.

A fluid view of status

A status field answers “what.” A state machine answers “when” and “why.” For subscription lifecycles, that’s the difference between a snapshot and a story.

But this isn’t just about subscriptions. The same pattern applies to any data that changes over time: customer journeys, order fulfillment, support ticket resolution, feature adoption. If you’re storing current state without history, you’re losing the ability to answer “when” and “why” questions.

Start with state machine thinking. Define your states. Map your transitions. Track the history. Connect events to changes. That’s how you answer questions that matter, and how you build a data model that reflects how your business actually works.

The paradox of subscription data is that more fields don’t solve the problem. The solution is a different model—one that captures journeys, not just moments.

What’s the takeaway? Don’t add more fields. Change the model instead. Remember that status fields capture moments, and state machines capture journeys. For time-series events like subscriptions, you need the journey.

Links for Reading and Sharing

These are links that caught my 👀

1/ Are you reading? - If you read more than two books last year, you’re above the median American reader in completed books. This is a good reason to go check out your local bookshop or library.

2/ Your LLM is reading more selectively - Cursor is changing the way their agents discover content. The reasoning? Agents perform better with better context, especially the kind of context created by Agents specifically designed to plan outcomes. By adding this flow to the Agent workflow (this is pretty similar to Claude’s “plan” mode), the system gives more relevant context to an agent.

3/ You need to manage that context - When AI coding environments are aggressively adding to their available context to get a “better” and “more comprehensive” answer, that means you need to be more deliberate about telling the Agent where to go. The balance? Tell it exact directions, it might get limited at a local maxima and not solve the right problem. Give it too much freedom, it might be … too creative.

What to do next

Hit reply if you’ve got links to share, data stories, or want to say hello.

Subscribe now

The next big thing always starts out being dismissed as a “toy.” - Chris Dixon

Hi, I’m Greg 👋! I write weekly product essays, including system “handshakes”, the expectations for workflow, and the jobs to be done for data. What is Data Operations? was the first post in the series.

This week’s toy: an archive of fictional brands. Some might say that learning about Cyberdyne Systems is not needed for cultural literacy, but this site will help you when you’re not sure if a brand is real or not and you don’t want to depend on your local AI bot.

Edition 286 of this newsletter is here - it’s January 6, 2026.

Thanks for reading! Let me know if there’s a topic you’d like me to cover.

The Big Idea

A short long-form essay about data things

⚙️ Critical questions ops leaders need to ask when building Agents

I just submitted my first PR for an Agent, and learned a lot in the process. The biggest change? My mental model for building Agents going forward.

My assumption going in was that I’d be able to write some code, specify some decision points, and end up with a production agent. Silly me, and the best way to enlighten yourself to that gap is to go build and write up your learnings after you’ve gone through the process.

Agents, like other code, often reach production carrying unexamined assumptions about authority, cost, failure, and trust. If your team is building agents, your job as an Ops Leader isn’t just to understand the “jobs to be done” or only to read the code if you’re a technical lead.

Your job is to ask the questions that surface operational risk in Agents before that risk shows up in an incident. The side benefit? You’re anticipating failure points before they happen.

What is this Agent’s job?

Begin with the end in mind. After this Agent wakes up and does its job, what should happen?

A good answer to this question looks a lot like a quality user story:

This code triggers [how often, on an event] and [does a series of specific actions], resulting in a decision to [action verb] a record with [data]. If [boundary condition], the Agent shuts down.

For example:

“This code checks every day for a record that has no value in a specific custom field and based on another field sets a classification value in that target field. If the result is inconclusive or the agent takes more than 30 seconds to run, the record is marked as “needs remediation” and the code is stopped.”

If your Agent has a clear remit, it’s a lot easier to confirm it got the job done.

Finding the safe high-leverage task to complete

Agents can do almost ... anything. So it’s a good idea to isolate them from high-tension interaction with the customer until you know the broad spectrum of outcomes.

Customer-facing triage and recommendation is a great place to start, because the actions are reversible and fixable.

Examples:

• classifying inbound support requests

• recommending escalations

• flagging account risk

• suggesting follow-ups

• normalizing messy customer inputs

These tasks work well because they share four properties:

1. High volume (real leverage)

2. Low blast radius per decision

3. Human override is natural

4. Outcomes are easy to observe

When you give these tasks to an agent, you’re succeeding when the tasks get doen without human interaction and your team can focus on higher value tasks.

A successful agent is one you would expect to get the job done more often and effectively than a human (that also proves it).

How do we isolate and control the authority of this agent?

What could possibly go wrong? That’s the question you need to be asking when you start using an Agent.

Start by identifying whether you are working with reversible or non-reversible changes. Flipping a bit on a record might not cause a problem. Deleting a record and causing a cascading delete of other records is a much bigger potential problem.

You can control a lot of what could go wrong by testing carefully and by quality checking your code. Adding unique credentials for that agent makes it possible to remove access and to see actions in a log.

What permissions does the agent need to finish its job? Don’t delegate more than necessary. If you can get the job done with read, you don’t need write.

What makes the agent start and stop?

If you don’t know what makes your agent start and stop, don’t deploy it. It’s tempting to read posts about autonomous agents that goal-seek and think that you don’t need to make the boundary. You absolutely need to set a boundary for starting and ending.

There needs to be a clear trigger for starting the agent. This could be schedule-based (wake up every 2 hours) or event-based (when you get a webhook that a value changed in a record), and tells us to get started.

You need the same precision for when to stop. Is it a time limit or some other limiter that stops the agent from acting? And what happens if your agent is in an intermediate state and fails to complete its action?

Retry logic is important infrastructure. Your request might have failed because the resource is unavailable, or something else weird might have happened. It helps to know how many times you’ll attmempt the action before logging failure.

What happens if this agent runs twice?

Allowing the agent to rum more than once opens up the possibility that it might run successfully more than once. So what happens? If you’re thinking about this ahead of time, you’re designing for idempotency. That’s a fancy word meaning if you run a task more than once, you get a consistent outcome.

In practice, this means building in a condition (a switch, a flag, whatever you want to call it) that gets set when you run the Agent the first time. When you run that Agent again for the same record, the outcome will be ... nothing. So idempotency protects you from making changes due to race conditions or subsequent re-runs.

Make repeat runs of an agent boring, not dangerous, because your system knows what “done” looks like.

There’s one more test you can run to confirm that your agent will take the right action given real data. That entails creating a mode where the agent does its normal job, then logs what it would do instead of completing the action.

Building a “safe mode” is a great way to find the edge cases in your environment using real data. At that point, you can simulate the outcomes using real data and find the errors faster.

How do we keep this from getting expensive, or drifting into incorrect answers?

There’s one more wrinkle to consider. Because you’re likely using finite resources with your agents, it’s important to know the cost of an agent run.

Your costs are likely either token usage (for LLM calls) or finite resources like API calls. In either case you need to know the cost of running your Agent 10 or 100 or 1000 times. Then, put some guardrails in place to monitor the outputs.

If you’re using an LLM as part of your code, you need to check the outputs programatically. Instead of relying on “it seems off lately,” default to a data measurement in an Eval that you can test with a true/false or an LLM judge.

What evidence would tell us this agent is degrading?

Early indicators might include:

• disagreement rates between humans and agent recommendations

• changes in escalation frequency

• confidence distribution drift

You don’t need to know how to build agents to lead teams building them. You need to know which questions prevent silent failure.

What’s the takeaway? As an ops leader, ensuring your agents get it right requires upfront testing and consideration. You wouldn’t launch a human process without testing, so make sure you do the same with agents.

Links for Reading and Sharing

These are links that caught my 👀

1/ The state of LLMs in 2026 - Andrej Karpathy has encyclopedic knowledge about how LLMs and chatbots function, so when he writes his year-end “what happened”, you should pay attention. Two things that stood out about this quote: “LLMs are emerging as a new kind of intelligence, simultaneously a lot smarter than I expected and a lot dumber than I expected.” First, we’re underestimating what these tools can do. Second, a whole new set of application layers is emerging.

2/ What visualizations did people use last year? - The team at Datawrapper shared a list of the most popular visualizations created by their users last year.

SPOILER: Tables and line charts are the winners!

3/ But before you build that line chart… - Check out this series of suggestions to make your line charts more effective. This is a great tutorial to give you specific steps (mostly removing info, adding specifics) for improving your visualizations.

What to do next

Hit reply if you’ve got links to share, data stories, or want to say hello.

Subscribe now

The next big thing always starts out being dismissed as a “toy.” - Chris Dixon

Hi, I’m Greg 👋! I write weekly product essays, including system “handshakes”, the expectations for workflow, and the jobs to be done for data. What is Data Operations? was the first post in the series.

Today’s bonus newsletter is a look back at some of the essays that year that represent recurring themes.

Edition 285 of this newsletter is here - it’s December 31, 2025.

Thanks for reading! Let me know if there’s a topic you’d like me to cover.

The Big Idea

A short long-form essay about data things

⚙️ Farewell to 2025, welcome to 2026

If there’s a single theme to take away from writing 52 essays in 2025, it’s that shipping it is a good model.

Starting with the blank page is never fun, but finding a process and sticking to it helps with writing.

The product lesson? Build systems you want to keep using that remove less interesting tasks from your plate. Focus on the highest value activity for your time, and better things will follow.

With that in mind, here are 5 takeaways from 2025, ordered around the 5 most popular essays I wrote this year.

Idea 1: LLMs and Chatbots are a necessary tool in your toolbelt

If you got stuck this year thinking “how do I use a chatbot to get stuff done”, you might be thinking too much about Claude or ChatGPT the consumer product. In 2025, Anthropic, OpenAI, Cursor and a million other companies made it a lot easier for you to use these tools for … anything you want.

I’d recommend starting with: “what can it do for me while I’m sleeping” or “what can it do that saves me time.”

Idea 2: Internal product delivers internal leverage

Building products inside your company is not the same problem as building for an external audience. If you swing too far toward a consumer mindset, it takes too long to get anything done. If you build only for internal power users, no one will use your product.

Balancing that contradiction is a theme from 2025, especially when it comes to using “wake up and do stuff” agents that fill important gaps without requiring you to build an entire interface.

Idea 3: LLMs are great at finding needles in haystacks

If you know what you’re looking for, LLMs are amazing at finding needles in haystacks. The trick, of course, is defining your search criteria, testing the result with evals, and delivering a deterministic result from a non-deterministic source.

One of my favorite themes from this year is automated search, where you define a target, sift results, and visualize the results. It’s a lot easier to build a market map than it was last year.

Idea 4: Building answers to business problems is valuable

2025 turned anyone who wanted to become an engineer into an engineer. With command line tools like OpenAI Codex and Claude Code and Cursor Agent, it’s now possible to make a branch, fix production bugs, and push code like an engineer, even if it takes you more tries at the PR than some of the other team members.

The point is that engineering expertise is now a requirement in more areas of the business, so we all need to get comfortable with how to create, push, test (and maybe rollback) changes. When we combine regular tools and Saas tools, that requires more creativity.

Idea 5: “Automagical” visual creation delivers dividends

If there’s one theme that kept surfacing for me in 2025, it’s product thoughts about graphical stories that build themselves. Whether it’s building a graphics library that does this or thinking about improvements for dataviz through products, this topic kept coming up.

It’s a great goal in product to automate things that you don’t want to do while getting them done at high quality, then switching to a new bottleneck.

What’s the takeaway for 2026? Keep on shipping it!  

What to do next

Hit reply if you’ve got links to share, data stories, or want to say hello.

Subscribe now

The next big thing always starts out being dismissed as a “toy.” - Chris Dixon

Hi, I’m Greg 👋! I write weekly product essays, including system “handshakes”, the expectations for workflow, and the jobs to be done for data. What is Data Operations? was the first post in the series.

This week’s toy: robots are now installing solar panels, and doing a pretty good job at it. When industrial robots are doing things outside the factory, this sets a pretty interesting precedent for the future of work.

Edition 284 of this newsletter is here - it’s December 29, 2025.

Thanks for reading! Let me know if there’s a topic you’d like me to cover.

The Big Idea

A short long-form essay about data things

⚙️ 5 Customer Journey Axioms Teams Actually Use

Product-led teams often talk about their customer journey as the measure for delivering the customer promise. When they spend more time building a journey map in Figma than translating it to clear principles for the engineering team, that journey doesn’t always transfer.

Want to know if your customer journey is working?

Look at your top support tickets and see if they change month over month. If the same issue shows up week over week and month over month, you don’t have a support problem. You have a product decision problem that is failing to solve a key product need your customers keep hitting.

Now comes decision time. Does the customer behavior happen because you have the wrong customers, or because they don’t know what to do? Most teams want to keep their customers, so they need to get better at telling customers (and internal teams) the intended customer behavior.

Your customer journey isn’t defined by your intentions, but the tradeoffs you make under pressure.

You need a small set of customer axioms to guide the teams in the moments whern the product team is not in the room.

Poster principles don’t give enough detail

Most companies already have “values” that sound like customer axioms:

• “Be customer-first.”

• “Delight users.”

• “Make it easy.”

• “Build trust.”

These are great principles, but they’re hard to operationalize.

These statements don’t tell you what to do when you can either ship a feature or clean up the confusing workflow that generates 200 tickets a month. They don’t tell you what to do when a product change will improve margins but create a new class of “what happened?” support threads because enablement lagged the release.

Customer journey axioms – shorthand observations or rules that teams can follow in a process or procedure – give the team clear steps when they are under pressure and need a next step.

What’s in a customer journey axiom?

A customer journey axiom has four parts:

1. Claim (memorable)

2. Tradeoff rule (what wins when priorities collide)

3. Forced behavior (what it requires in the product)

4. Proof hook (how you’ll know it’s working)

If you can’t attach proof, your axiom loses credibility. If you can’t name the tradeoff, no one will trust that they can use it effectively.

Five example axioms that build confidence

The ideas are written to improve the whole customer journey with support acting as the early-warning radar for the business.

Axiom 1: The customer should always know what happens next

Tradeoff rule: When speed conflicts with orientation, choose orientation.
Forces in the product: clear states, next steps, progress indicators, ownership (“who is doing what”), and visible completion criteria.
Proof hook: fewer “what now?” tickets, fewer follow-up pings, fewer duplicate submissions.

If users can’t tell what’s happening, they start doing the worst possible behavior: guessing. Guessing creates retries. Retries create duplicates. Duplicates create irreversible messes. Messes create escalations. Escalations create churn stories.

This is why “what happens next?” is not a UX nice-to-have.

Axiom 2: Every meaningful action creates a receipt

Tradeoff rule: If an action changes money, data, access, or commitments, it must be confirmable and recoverable.
Forces in the product: confirmations, status pages, “view details,” audit trails, undo/retry, and durable reference IDs.
Proof hook: fewer “did it go through?” tickets and fewer “I did it twice because nothing happened.”

A receipt is not a toaster notification. It’s evidence.

A customer should never have to open a ticket to answer:

• Did my payment succeed?

• Did my invite send?

• Did my integration connect?

• Did my request get queued?

• Did my change actually apply?

If they have to ask support, your product shipped the work of reassurance to humans.

Axiom 3: No silent failure, no hidden work

Tradeoff rule: If something fails, it must fail loudly and informatively for the customer (not just for logs).
Forces in the product: explicit error states, human-readable causes, constraints communicated early, and graceful recovery paths.
Proof hook: fewer “it just didn’t work” mysteries, lower time-to-diagnosis, fewer multi-touch tickets.

Teams will instrument the backend beautifully, then leave the customer with the equivalent of a blank screen and a prayer.

Silent failures don’t just create tickets. They create doubt. Doubt doesn’t stay in support; it contaminates retention and referrals.

Axiom 4: Trust beats speed in money/data/access moments

Tradeoff rule: When a change risks surprise in billing, permissions, or data correctness, trust wins — even if it takes longer.
Forces in the product: previews, confirmations before irreversible actions, clear permissions language, transparent billing changes, reversible flows where possible.
Proof hook: fewer escalations, fewer billing disputes, fewer “you changed my access” panic threads.

People forget a slow feature. They don’t forget a billing surprise. They don’t forget “we lost your data.” They don’t forget “my account got locked and no one can tell me why.”

Trust is a product surface. Treat it like one.

Axiom 5: Repeated confusion is a product bug

Tradeoff rule: If the same confusion repeats, the fix belongs on the roadmap ahead of “nice-to-have” features.
Forces in the product: root cause analysis, simplified flows, guardrails, better defaults, and deprecation of confusing paths.
Proof hook: top ticket drivers trend down month over month; re-open rate drops.

If your support team can predict tomorrow’s tickets, your product team can too. And if you can predict it, you can prevent it.

The goal isn’t “fewer tickets.” The goal is less repeat pain.

Support’s real role is early-warning radar

Support is where the journey shows you its weather.

Tickets, chat logs, re-opens, and “any update?” pings are radar returns. These are weak signals that something upstream is getting unstable. The product team won’t see it in the roadmap. Sales won’t see it until deals slow down. Leadership won’t see it until it’s counted and shows up in a report.

That’s why the goal isn’t “close tickets faster.” The goal is to treat support as a signal system that protects the customer journey from repeat turbulence:

• A spike in “what happens next?” is an orientation failure (Axiom 1).

• A spike in “did it go through?” is a receipt failure (Axiom 2).

• A spike in “it just didn’t work” is a silent-failure failure (Axiom 3).

• A spike in billing/access panic is a trust failure (Axiom 4).

• A stable top driver month after month is product debt (Axiom 5).

If you can’t translate support signals into the axiom they’re violating, you don’t have customer journey governance.

You have customer journey weather reports you ignore.

Introducing these practices in your company

Like any other “big idea”, these practices don’t stick until teams try them, make tweaks to adopt them as their own, and do them the second (or fifth, or thirtieth time).

If they are not simple enough to add “just one thing,” they might be too much change at one time. Here are a few ideas to get started:

Put axioms in the PRD template

Add one mandatory line:

“Which axiom does this advance, and which axiom does it risk?”

If someone can’t answer, you’re about to ship a feature that feels “useful” but quietly rots the journey.

Run a weekly Radar Sweep

Take fifteen minutes each week to review progress, using the following agenda once you’ve instrumented some reports:

1. Top 5 signals (volume and severity)

2. Which axiom is being violated?

3. Is the response: product fix, guardrail, communication, or instrumentation?

4. What threshold triggers escalation next time?

Radar is only useful if it changes behavior before the storm hits.

Keep it simple

Choose one proof metric per axiom (and one guardrail):

• Axiom 2 metric: “did it go through?” ticket rate

• Guardrail: successful completion rate

You’re trying to reduce confusion without creating friction.

Objections (and the point)

You’re going to hear some objections to this approach. They might sound like some of these statements:

“Axioms oversimplify.”
Good. The alternative is debate theater, inconsistent experiences, and a journey that changes depending on who you talk to.

“Axioms will conflict.”
Also good. That’s why they’re a constitution: when they conflict, you surface the real tradeoff instead of pretending everything is “customer-first.”

“We already have values.”
Values are identity. Axioms are operating constraints. Your customers don’t churn because your values are unclear. They churn because outcomes are unpredictable.

Meeting the challenge

Pick one part of your journey you’re secretly ashamed of — the place where customers get stuck, surprised, or forced to ask a human for reassurance.

Write the axiom that would have prevented it.

If it doesn’t change next week’s roadmap conversation, rewrite it until it does.

That’s how you know the customer journey is real: not when it’s mapped — when it’s enforced.

What’s the takeaway? Support is early-warning radar. Building product axioms to define when we’re breaking the customer journey helps you to know how to separate a garden-variety bug from a critical product issue.

Links for Reading and Sharing

These are links that caught my 👀

1/ A🍕 team might beat a 🍕🍕 team - the main reason a small team can beat a bigger team? Less cross-team communication needed. The coordination tax is real.

2/ Touch that dial, not that screen - car makers are finally realizing that touchscreen controls provide the same level of disorientation as driving while impaired. It’s time to bring back the dial.

3/ Behold, the robot olympics - one of my key indicators for robot performance is the ability to do real-world tasks like laundry-folding, dishwashing, and other household tasks. How are we doing on that so far? Not as far away as you might think.

What to do next

Hit reply if you’ve got links to share, data stories, or want to say hello.

Subscribe now

The next big thing always starts out being dismissed as a “toy.” - Chris Dixon

Hi, I’m Greg 👋! I write weekly product essays, including system “handshakes”, the expectations for workflow, and the jobs to be done for data. What is Data Operations? was the first post in the series.

This week’s toy: a short feature on the Parallel Parking Championship that happens each year in Pittsburgh, PA. If you’re wondering, you get extra points for piloting a giant SUV.

Edition 282 of this newsletter is here - it’s December 22, 2025.

Thanks for reading! Let me know if there’s a topic you’d like me to cover.

The Big Idea

A short long-form essay about data things

⚙️ Ship story-first graphics on demand with this modern graphics library

Whether you write consistently or not, you need to compelling visuals to get attention. I’ve noticed the most effective illustrations are simple, well-produced graphics that look like hand-crafted slide deck graphics. These are (up to this point) best built in a vector graphics tool like Figma or Excalidraw.

AI tools don’t do a good job creating informative graphics with relevant text, yet. With the advent of models like Nano Banana, we might have new ways to do this soon.

But for now, if you want to have deterministic outputs that get created from your non-deterministic prompts, one way to do that is to build your own graphics library.

Custom graphics improve your writing

When you’re creating content, it helps to have an anchoring graphic that feels professionally designed, consistent, and grounded in real data.

In Stop Building Slides and Start Building Stories, we talked about the importance of making a graphics pipeline to speed up your information visual work.

What better way to practice this than make a library to build the graphics in this style?

I created Modern Graphics, a Python and OpenAI-based package to build graphics and slides to illustrate articles.

This library packages the design system, prompts, and guardrails that let you ask, “Show me how revenue shifted from Q2 to Q4 and why it matters,” and get back a polished visual in seconds.

Why build a library to create images when you can use a Chatbot to do it for you?

As a curious developer and product person, I think the best way to learn about the limitations of technologies is to practice building them. The newest generation of presentation tools (NotebookLM, Pitch, Gamma, and whatever ships next week) can spit out decks faster than we can outline them.

That’s exciting, and also makes you miss the fine details you need to build a data visualization consistently, even if you have varying inputs.

The real questions to build every visual around are deceptively simple:

• What changed?

• Over what time period?

• What does it mean?

That trio gives every figure a narrative arc and keeps even auto-generated slides rooted in reality. Start there, and your templates become a delivery mechanism for insight instead of a factory for AI slop.

Said another way, how can you build graphics with a clear visual style while using AI tools to accelerate your output?

Here’s what you get when you ask Gemini and Nano Banana to illustrate this article:

And this is what you get from ChatGPT’s image generator.

Compared to what we saw a few years (or maybe even months) ago, these are pretty impressive graphics. But they also scream “AI generated.”

If you’re building bespoke graphics, you don’t want a generic outcome.

Use templates for a shorter path to great visuals

Think of templates as a kind of visual Eval (“evaluation” for those not familiar with AI development). Instead of trusting the AI output to be perfect, we create true/false tests to measure the difference between the expected AI output and what we received. Templates limit the creativity and the hallucinations of an AI implementation by constraining the output to a known set of fonts, colors, and shapes.

Evaluating how close the generated output is to a “good” image lets you know which model performs the best. We don’t (yet) have a good way to apply an LLM-based judge to a visual output from a model without building a series of evals, e.g. “tell me whether this is an effective graphic.”

I’m sure that’s going to be available widely in the next year or two. At that point the “visual template” you create is going to be a conbimination of a prompt and visual styling rules.

With a graphics agent in your back pocket, you can add a step to your workflow that’s simply “create some appropriate graphics for this article” and start the pipeline.

Here’s a sneak peek at what the Modern Graphics generator can whip up for you:

• Data Cards: Perfect for those moments when you need to highlight key figures or achievements in a crisp format.

• Infographics: Ideal for when you want to break down complex data into a compelling, easy-to-digest visual narrative.

• Story-Driven Slides: When you have a story to tell, these slides help you narrate the journey clearly and compellingly.

• Transformation Cards: Great for showcasing before-and-after stories, be it a process overhaul or a dramatic turnaround story.

Think of it as your answer to those “can’t you just tweak the deck?” asks that always pop up ten minutes before the meeting. Instead of forking a Figma file and praying you remember every revision, you regenerate the graphic with updated data.

How do you move from prompts to slides?

The whole point of the modern graphics generator is that you shouldn’t have to touch code to get a deck-ready asset.

The workflow is intentionally short:

1. Write the story beat: one sentence answering what changed, over what window, and why it matters.

2. Name the template: data-card, story-slide, transformation-card, etc.

3. Paste the prompt into your assistant (NotebookLM, custom GPT, terminal helper) and drop in the numbers.

4. Receive the PNG/SVG that already matches your modern theme.

Here’s the exact prompt we use for a story slide:

You are the Modern Graphics Generator. Render a story-slide using the modern palette.

What changed: Revenue model shifted from upfront licenses to subscriptions

Time period: Q2-Q4 2025

What it means: Predictable revenue and 20% higher retention

Call to action: Double down on usage-based tiers
Include metric callouts for ARR ($2.4M, +24% QoQ) and churn (4%, -3pts QoQ).

Return the image and a one-sentence alt text.

Drop that into the agent, and you get back a slide with a bold title, the modern gradient background, two stat cards, and a CTA footer, with no timeline spent nudging boxes in Figma.

Behind the scenes, the workflow works because every template is really a schema.

Even the simplest “data card” needs a title, subtitle, metric, delta, and a plain-language interpretation.

Adapting graphics to match your style

How do you make this auto-generated graphic feel like your own? Create templates for your prompt. Adjusting colors, fonts, and layouts lets you dial in your brand identity, ensuring each graphic feels ready to publish.

Iteration also means testing the story, not just the pixels. Ask the “what changed / when / so what” questions for every draft image. If you can’t answer them in a sentence, the graphic probably needs another pass.

Before you run the Agent, write a single sentence that answers the story questions. Drop that sentence next to the command you’re running; it becomes both a test and an instruction for the template.

With a handy graphics generator and a sprinkle of template magic, you’re all set to produce engaging, brand-aligned visuals that elevate your content from good to unforgettable.

That graphic we were looking for from ChatGPT and Gemini? here’s how it turned out with this system.

What’s the takeaway? This is the practical follow-up to Stop building slides: now you can actually prompt a deck-quality slide that keeps the story at the center. The robots will keep getting better at spitting out decks, but it’s on us to orchestrate the story.

Links for Reading and Sharing

These are links that caught my 👀

1/ On the importance of speed - Ironically, the author of this article on speeding up took six years to finish it. The advice still holds: ship before you’re ready and improve iteratively.

2/ A clever drag and drop ui - Check out this drag and drop treatment with a twist: the background scrolls.

3/ The origins of the digital camera - Kodak was first, you won’t be surprised to hear. But they didn’t commercialize the technology best - a classic innovator’s dilemma.

What to do next

Hit reply if you’ve got links to share, data stories, or want to say hello.

Subscribe now

The next big thing always starts out being dismissed as a “toy.” - Chris Dixon

Hi, I’m Greg 👋! I write weekly product essays, including system “handshakes”, the expectations for workflow, and the jobs to be done for data. What is Data Operations? was the first post in the series.

This week’s toy: A new way to visualize Mermaid diagrams and make them dynamic. The core of this is simple: how do you get people to want to look at a flow chart and also update it quickly? I’ve written about these diagrams before and think we’re still waiting for our “iPhone” moment to make creating, editing, and viewing data-driven presentations effortless.

Edition 281 of this newsletter is here - it’s December 15, 2025.

Thanks for reading! Let me know if there’s a topic you’d like me to cover.

The Big Idea

A short long-form essay about data things

⚙️ Stop building slides and start building stories

For a good portion of my career, I’ve been waiting for a robot to build me slides in a slide presentation. Not just any slides, but the kind of infographics that a leader asks for to tell a data-driven story at a meeting.

The kicker is almost always that the underlying data that drives the slides produces a boring story, so the team tries to spice things up and tell the most interesting version of the data possible given the time and design constraints of the problem. Through heroic effort, they make an amazing presentation. And then, slightly after (or slightly before) presentation time, a leader asks for a small change, not knowing how easy or hard it is to make the slide better.

At this point, you have a choice

In the perfect outcome, you’d have a magical robot that could take the data behind your slides, update and edit the presentation content, and produce a new slide.

Want to pivot that data table to a new dimension and tell a different part of the story? No Problem!

Want to create a sensitivity table showing a what-if analysis and do it in the same graphical style, but make it something we can edit in Figma? No Problem!

You can choose to fork your design and build what the customer is asking for, knowing that future versions of your graphic and data story will need to be updated by hand, or you can create an automated visualization that has the correct data, and ... just doesn’t look all that exciting.

Typically, we make a choice between “it looks great with the final_final version the data” or “it looks a little bit weird, but it updates instantly.”

We’re getting close to the point where the slide portion of your presentation is going to be the output of your story and your creative direction, rather than a manual paste-together mark up of fonts, shapes, and colors.

We’ve moved from simple data cards to infographics

About 18 months ago, I wrote about Data-Driven Stories and defined the idea this way: “A data-driven story shows a change (or lack of change) in a process over time and identifies the next action needed based on the semantic goals of the business.”

Infographics, we thought, were data cards that moved beyond just the number on the card and started to tell a story that delivered insight beyond the basics of today’s number.

Zoom out and consider the impact of time on your graphics and your slides. If you truly explore a problem interactively, it will be possible to build your infographic outcomes in real time based on the questions the audience asks. There’s a small problem interwoven here: the outcome won’t be deterministic.

So on the good side, we’ll be able to build anything we want, and soon. The fidelity will continue to improve and you will be able to change your formatting and rebuild the presentation immediately. But it won’t be pixel perfect, yet.

NotebookLM and the auto-generated slide deck

If you’ve been watching the presentation space you may have seen tools like Stick (Acquired by Google), Gamma, Pitch, and others. These presentation tools promise to create visually consistent decks powered by generative AI. Some are more cautious (Pitch) while others lean into the generation (Gamma) and aim for “good enough and improving.”

Google introduced NotebookLM in May 2023. The intention was to combine a number of resources to synthesize knowledge and reframe it with a variety of tools. You’d add a PDF, a website, and then ask a bot to explain it to you. The next big leap was in September 2024, when a podcast-like feature was added that explained the content as if on a radio play.

And now NotebookLM makes slides. Here are some examples it created from the text of this post.

It’s pretty good. I’m not going to give in and say that it’s better than a person in expressing these ideas but it’s quite effective for a zero-shot prompt.

Using stories to sell ideas

We use slide decks to pitch ideas because a picture or a visual presentation is worth the proverbial thousand words. No one wants to read a multi page PRD when they can view the prototype. No one wants to read the whole report when they can see an infographic of the highlights and the TL;dr. But they do want all the graphics to use real numbers. They do want the ideas to be consistent. And they do want the strategy to foot and produce results.

Here’s what NotebookLM called out as an important note:

What if the real innovation of data driven stories (or infographics) created by generative AI lets us relax from the idea of a pixel-perfect slide?

I’m not suggesting that we support incorrect information or hallucinations. I’m asking the question: what do we use these artifacts to create?

I believe the point of a slide deck is to share ideas, gain consensus, and achieve an outcome on an idea or a decision. The best way to do that is with a great story. And it’s easier to tell a story with great visuals.

A new way of building presentations

If the presentation tools of the near future are non-deterministic, how do we improve the way that they create value? By borrowing the techniques from software engineering and dynamically created content in other forms.

At the core, we need a data schema to define the slide itself. A very simple version would include the title, subtitle, main content, and footer. You might have a slideType that would tell you like in Google Slides or Powerpoint what kind of layout you need. For each slideType, you have a prompt that defines the slide and how it renders, and you need a method of testing the output with Evals so that you can test for stylistic and other errors.

Then, each slideType might have individual components that understand how to ingest data, calculate, and render an outcome. Perhaps you have a storyBlock, a barChart, a comboBlock, or a CTA button. (If this is starting to sound like building a modern, responsive, React application you’re probably not far off).

What makes this possible for wide use? The editing. It’s a product challenge to take the core of this presentation engine and infuse it with enough creativity to build prompts on prompts on prompts and also not have it devolve into AI Slop. When users need to edit content, you also need to make it clear what sorts of edits are possible.

Editing a label might be very different than the implication of editing underlying data series that flow through the whole presentation. This implies that you need a “design editor” agent to tell you whether your presentation is good or meh.

The story at the center

However we’re building presentations in the future (or the present), the story needs to be at the center of each slide. Don’t think of the challenge as “how do I build slides” -- the answer needs to be “how do I convey this idea effectively”, or “how do I inspire wonder and creativity?”

Generative tools make many different outputs possible, and they also cheapen some of the hard work that goes into directing the parts of the orchestra to deliver a great outcome. As you are thinking about data-driven stories, don’t miss the point.

“What changed, over what time period, and what does it mean?”

This is the basic insight you’re building when you tell a story about data.

What’s the takeaway? Tools like Google’s NotebookLM make it possible for you to build sophisticated slide presentations with data-driven graphics. But are audiences going to tune out? You need to focus on the story you’re trying to deliver so that you get your point across. Generative AI is going to continue to improve, but you need to orchestrate it well to persuade your peers.

Links for Reading and Sharing

These are links that caught my 👀

1/ Make some lists - Jeff Huang uses one single list file to keep track of his todos. He’s been doing this for years. This should remind you that keeping a consistent schema over a period of time gives you an interesting first party data set.

2/ AI will not bring us faster horses - Andy Jones, a researcher at Anthropic, writes that the changes AI will bring to the economy will happen faster than we think.

3/ Anthropic & Apple - Daniel Miessler has a more positive outlook, believing the “iPhone moment” for AI is upon us, and it’s driven by the product vision at Anthropic.

What to do next

Hit reply if you’ve got links to share, data stories, or want to say hello.

Subscribe now

The next big thing always starts out being dismissed as a “toy.” - Chris Dixon

Hi, I’m Greg 👋! I write weekly product essays, including system “handshakes”, the expectations for workflow, and the jobs to be done for data. What is Data Operations? was the first post in the series.

This week’s toy: cartographers who hid illustrations in official swiss maps… for decades. Those are some impressive doodles.

Edition 280 of this newsletter is here - it’s December 8, 2025.

Thanks for reading! Let me know if there’s a topic you’d like me to cover.

The Big Idea

A short long-form essay about data things

⚙️ If your AI seems wrong, check your knowledge base

Answering customer questions with AI is a hot topic these days.

Set the context of your company, ingest some content from a knowledge base or documentation site, and you should be good to go almost immediately (if you believe the marketing hype).

Next, test your question-answering bot by asking it questions like a customer.

Pretty soon you’ll realize a few things:

• wow, this tech really works! It produces reasonable answers to a lot of surface questions really quickly and accurately

• this tech helped me find an inaccurate piece of information in my knowledge base that no one has pointed out for quite some time

• some of our content between our knowledge base and our documentation is mismatched

AI chatbots are effective vacuums of information, made to “blenderize” your content into embeddings that show the nearest concept to the item you’re searching.

If your content is well-organized and contains a strong information architecture, the answers will flow naturally and it will feel like “talking with the documentation”. If the information is inconsistent, that question-asking and answering activity will also feel disjointed.

Having worked on this problem, I have some ideas on how to improve the information journey for customer with a few tactics learned from vibe-coding with LLMs and also in designing hundreds of help centers a decade ago.

These tactics mirror the same work you’d do in designing other kinds of help experiences, with the additional wrinkle that you know your reader is going to build a mind map or information graph automatically.

1. Set the context for an uninformed reader

2. Make the content atomic

3. Provide bread-crumbs and links based on the skill or topic

Assume the reader is visiting for the first time

Right now, check out a documentation site that you really admire. (You might not have one in mind, but let’s check out Stripe, a developer tool that helps businesses take payment on the internet).

Start by going to Stripe’s page that helps you set up no-code payment links.

What do you notice the minute you land here?

A really strong title, anchored by a verb (”Create Payment Links”) and a subtitle that tells you exactly why you’re here: “[q]uickly accept payments for goods, services, subscriptions, tips, or donations.”

If you didn’t know what Stripe does and you landed here, you have at least one very clear use case that tells you how to proceed.

For the sequence-oriented, Stripe adds a few ordered lists telling you how to get started. They also switch modalities by explaining capabilities in short, active sentences.

This is one of the key items you need to establish when writing for LLMS: the context of the situation. Summarize this page and you’ll know almost immediately that you have content for a business to business software tool that facilitates payments on the Internet.

A first time user knows at least one way to proceed, so this is an ideal place to start for AI to make sense of this page.

But the content on the page is also arranged in smaller content units ideal for embeddings. This is the format LLMs use to take content, break it apart into smaller concepts, and build an information graph to link items.

Building atomic content

The concept of “atomic” content means that when you write something for LLMs in a Help Center, you need that content to stand alone as an example that makes sense by itself without much other explanation.

In our payment introduction, reviewing the option to Share Payment Links gives you a quick list of the places you can use and review payment links. A reader (or a bot) quickly summarizes that you can take payment via QR code, link, or button; and that that these links can be served by any of the payment methods (like Google Pay and Apple Pay).

The basic content on the page is reinforced by the building blocks of the service (button, link, account, payment intent, subscription, one-time payment). That information graph is already evident in the way the documentation page is constructed.

AI can read this and avoid hallucinations because the base context -- providing payments to b2b customers -- is easily linked to domain expertise (how you provide payments) and individual questions (where do you pay and how do you know a payment has completed).

You need to build this core knowledge architecture into your docs to deliver great documentation answer with an AI chatbot.

Create wayfinding points in every content object

The solution? The equivalent of the “claude.md” file for a human - the ability to get context when you have no memory. In knowledge base articles this is the “bread-crumb” of links from question > topic > domain letting you know know that “how do I complete a payment” is part of “Sending and receiving payment” and is part of “Merchant Payment Services” as a domain.

Each article in your knowledge base typically has tags - topic words that group like articles - and a section or concept to arrange those articles. Your topics might look like “Getting Started” or “Payment topics” if you’re Stripe. For other businesses, the topics might look different.

But the point here is that at the starting point of waking up and reviewing an article or article fragment, both a person and an AI would have a basic idea of the current step and what the next step might be in a process. Reading the article gives you context, direction, and velocity. It helps you know whether you are at the start, middle, or ending of a task.

And if you don’t know where you are, it’s tough to know where you’re going.

What do you do if you get a weird answer from AI?

The next logical question here is to wonder what to do when AI “hallucinates”. We’re defaulting to calling it that when we get unexpected answers to a question because the answer content is related to some other content. To AI, this is nearest and best content. To a human, it might appear to be quite odd.

In either case, a hallucinated or incorrect answer is much more often the result of mismatched, overlapping, or incorrect help content than it is hallucinating AI. If you’re talking to an AI model directly, you are closer to the actual source of the text generation. When you are sending and receiving messages with an AI chatbot, there are a lot of application layers between the input and the base model.

The likelihood of you encountering a hallucination is much lower than the likelihood of finding incorrect content. Articles describing a feature that existed three months ago that doesn’t exist now. Two articles using the same word to describe an identical concept. Maybe even content that you didn’t realize was public in your knowledge base.

The AI chatbot is the best quality control you’ve ever had for your knowledge base, but not in the way you expected.

How do you optimize the knowledge base for AI?

So how do you create a solid customer experience when answering questions using a chatbot? Focus on the same experience you would for a reader:

1. Articles need to be focused on a problem the user needs to solve (”How do I? ....)

2. Topic pages should collate like intents (”I’m trying to ...”)

3. The content needs to be atomic, letting you know all that you need to know to solve a problem; and when there’s a related problem, letting you know other related articles

Said differently, a person with a question needs to be able to ask the knowledge base that question in a search and receive a reasonable answer in the first few results. Reading that result, that person can perform the action and succeed to a high level of accuracy. Reading multiple articles in the same section, that person needs to find consistent terms and defintions linking the current article to other like articles.

Wait a minute. Instead of talking about how to build your knowledge base for AI, we’re talking about information architecture in general. That’s right - the priniciples for building content haven’t changed. The thing that changed is the process or pipeline for retrieving that information from a taxonomy and reframing it or stating it in an easily digestible format.

When you think about it that way, LLM search is another form of the same indexing we have done in the past for search. By adding context to that search in metadata and embeddings, we improve the similarity score for an answer. The main difference now is that answer appears as a multimodal output rather than an URL of the highest scoring thing.

What’s the takeaway? Building your knowledge base for AI is a revised version of the process you should have already been doing. Finding missed searches, identifying the best answer in the shortest number of clicks, and composing great content is a great recipe. What’s different in the age of AI is that we’re finding gaps based on the questions people ask and the answers that are composed rather than just having missed search counts.

Links for Reading and Sharing

These are links that caught my 👀

1/ Tech debt compounds - Dave Baines nicely summarizes the problem of “kicking the can” in software development and writes about tech debt here. In the article, he shares this excellent infographic from Martin Fowler displaying how past decision debt weighs down future progress.

2/ On writing - I loved this essay on blogging, even if I’m being lazy by using the phrase “I loved.”

3/ Naming your drives - If you’ve had a Windows machine, you might wonder how drive letters are set. You might also wonder if you can name those drives something other than letters A to Z….

What to do next

Hit reply if you’ve got links to share, data stories, or want to say hello.

Subscribe now

The next big thing always starts out being dismissed as a “toy.” - Chris Dixon