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

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 pair of sneakers that let you play classic NES games. Slightly awkward to have to take your shoes off to play some games, but amazing to have a portable game system with you to do it.

Edition 279 of this newsletter is here - it’s December 1, 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

⚙️ Avoiding the Telephone Game

Note takers - even the robot notetakers we are using these days to capture meetings - are prone to the telephone game. By this, I mean the tendency for the meaning of a meeting to drift over time.

Do you really know what happened after a meeting, and how you’re going to take action after the meeting?

At the very least, you need the three-line handoff:

1. What you must receive

2. What you must validate

3. What to do next

What’s a great example of this technique? That old telephone message pad that you’ve probably never seen if you’re younger than 40. I needed to use AI to visualize what this looked like because we don’t use this artifact anymore.

Why did it work? It was a simple workflow tool indicating WHO called, WHEN they called, and WHAT they wanted.

Depending upon the skill of the notetaker, it also indicated how to close the loop. The assumption of this tool? That whoever reads it has enough context to use this message to determine what’s missing.

It was somewhat of a leap of faith. If your sibling filled out this information on a pad next to the (probably wired) phone, they probably didn’t do more than write down the name of the person who called and their phone number.

Good luck on knowing the time of the call or gaining a deeper understanding of why the phone call happened.

This didn’t work 100% of the time when people answered their phones or when you counted on someone to answer your phone for you.

So why are we confident that AI notetakers can do a better job?

It’s easy to assume that they got everything. They are confident, produce a tidy summary, and are really good a jogging your memory to identify what happened in the few hours after a meeting.

But beyond that point, they are not as useful as that summary promises to be.

Where work falls apart

The reason that AI-driven summary doesn’t always work the way we expected stems from the same root as other misunderstandings. None of the individual steps are wrong, but something about it doesn’t hang together.

Here’s the analog in a process you might see every day:

• Support escalates something to Product

• Product forwards it to Engineering

• Engineering hands off to QA

• The team loops in Compliance

• Compliance sends something back to Support

Where’s the error? No single step is broken, but the expectations and boundaries are not consistent across teams.

Every transition introduces:

• slightly different interpretations

• mismatched assumptions

• format changes

• “we thought you meant…” moments

By the end of the journey, you’ve played the Telephone game, and you might end up working on disjoined projects.

Handoffs are not specific enough

It’s too easy to turn a “one pager” into a “too many pages, I didn’t read it” using AI. That’s the first response to extra requirements. Think of that effect as documentation scope creep. The problem with this output is that you get more surface area for interpretation.

Instead of a crisp set of instructions, you end up with an 80% solution that gets misinterpreted.

The solution to this is the three-line handoff. Every handoff — human-to-human, human-to-AI, or AI-to-human — should contain exactly three things:

1. What you MUST receive - the minimum valid inputs required to begin the next step.

2. What you MUST validate - Simple, zero-interpretation checks. (Not judgment. Not context reconstruction.)

3. What you MUST do next - A single explicit action that advances the work.

This gives you a low-effort, high value map to improve handoffs.

Creating a concrete handoff example

Let’s take a common hand off instance between support and product. You’re probably used to seeing a ticket with a wall of text, a screen shot, and a comment: “this feels like a bug.”

This could be better with a three-line handoff added.

1. MUST receive:

• Impact statement (1–2 sentences)

• Reproduction steps

• Expected vs actual behavior

• Ticket link

2. MUST validate:

• Repro steps actually reproduce

• Impact statement is understandable outside Support

3. MUST do next:
Assign to Product inbox → set status: Ready for Triage

This is the difference between a telephone-message-style note and a boundary designed to prevent drift.

Clarity matters more when AI is in the loop

The “telephone game” works a lot of the time because humans are pretty good at inferring intent from lossy, incomplete information. When we read the AI-created summary from the meeting we had yesterday, it’s easy to pick out an additional thing that adds context based on what you remember.

AI can’t add this context because it’s not present in the artifact. When messages are ambiguous:

• AI fills the gaps and rewrites the context

• AI smooths over inconsistencies and makes it sound polished

• Occasionally, AI manufactures the wrong detail

The message recorder is not doing this on purpose, but summarizing according to its prompt. With a perfect transcript, it can probably do a pretty great job of identifying action items, summarizing the outcomes of the meeting, and setting reminders. But most transcripts are not linear or perfect.

How can we do better?

Pick one workflow boundary, and then ask the two teams involved:

1. What do you think the other team needs?

2. What do you actually need?

3. What’s always missing?

4. What usually creates rework?

5. What would allow you to start immediately, without clarification?

The output of this exercise is your three-line handoff. Practice using this and collaborate so that everyone who needs to know this new handoff does it well. Then, move on to the next bottleneck.

Closing back to the image

The telephone message pad was designed for a world where you could call someone back and clarify.

Without that world, you need a heuristic so that your teams and your AI systems don’t play the Telephone Game every time work touches a boundary. A Three-Line Handoff makes sure the meaning doesn’t drift, no matter who (or what) is passing the message along.

What’s the takeaway? It’s worth it to create a brief summary that helps the other person to get context, especially when you know you might not be there to explain it. Then, if they need to call you back, you both know why you need to talk.

Links for Reading and Sharing

These are links that caught my 👀

1/ Why are some engineers stuck when trying AI? - The answer might be that they are not adapting their approach to this technology, and trying too hard to be deterministic. There’s a fine line here, because you want the end product to be correct (and to fit into a deterministic box), even if the means is different than traditional coding methods. Instead of trying ahead of time to eliminate errors, work at finding and resolving them as fast as possible (evals).

2/ Microsoft makes a classic open source - Zork is now officially open-sourced. If that sentence didn’t make any sense, go play it and enjoy a great game at the origins of today’s gaming culture (and really, the Internet).

3/ Don’t mess with a classic - I never thought I’d see the day when my childhood Cheese streak favorite would make the Michelin guide, but here we are.

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 robot that does your dishes. Unlike some other robot examples, this one is not tele-operated. It learned from “smart gloves” worn by humans who completed over 10 million tasks. Would you have one in your home?

Edition 278 of this newsletter is here - it’s November 24, 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

⚙️ Build a dashboard from a single data file

Effective dashboards mean answering a small set of questions exceptionally well.

You can have a beautiful design that progressively reveals information and elegantly filters records, but people will remember whether they were able to solve their most important questions in a few clicks.

You’ll earn double points if the design of that dashboard lends itself to follow-on questions that are related to the same data set and appear to emerge easily when you use that dataset.

How do you increase your chances of getting this outcome?

1. Start with the questions

2. Understand what the data represents

3. Choose the minimal visuals that answer those questions

4. Keep everything on a single page

5. Make the limits obvious

When dashboards fail, it’s often because teams invert this order by starting with the tool, designing the dashboard first and thinking later about the questions they wanted users to answer.

One way to practice this is to start with almost any CSV file of data, review the data fields, and think about the kinds of questions that could be answered.

Getting started by finding a dataset

Weather data is simple and everyone’s used to reading it on a daily or weekly basis. Starting with data fields like temperature, rain, and wind in a time series, you have everything you need to build a dataset.

You might want to know:

• Trends: temperatures over time

• Comparisons: city vs. city

• Distributions: variability of highs

• Extremes: hottest or wettest days

• Relationships: wind vs. precipitation

Reasonable questions might look like this:

Weather is the “hello world” dataset for dashboard literacy. Nothing about this workflow is weather-specific, and you can apply the ideas of time-series data to other kinds of datasets that you’ll see in the workplace.

If you have a CSV with:

• a time column

• a category column

• and numeric metrics

…the same method applies.

Why use an LLM to get started?

When you collaborate with an LLM to take a CSV and shape it into a dashboard, you’ll also feel ok throwing it away and refactoring as you get different design ideas.

You’re speed-running a workflow that you’re going to use repeatedly:

• restate your schema

• generate real questions

• identify limitations

• build visuals

• produce a one-page dashboard

Weather is training wheels. The skill is universal.

Don’t just ask “build me a dashboard”

LLMs need need to be grounded them in the data and the questions, or they will hallucinate. Don’t expect the bot to refuse; expect it to happily provide an answer that’s incorrect.

With vague instructions, the model will:

• invent relationships

• infer meaning from column names

• fabricate categories

• pick arbitrary “interesting” questions

• generate charts that look right but answer nothing real

A prompt like:

“Here’s a CSV — build a dashboard.”

is not specific enough to build a usable output.

The only reliable fix is structure:

1. Tell the model what the data represents

2. Have it generate and refine questions first

3. Force every chart to map to a specific question

Practicing your dashboard skills

To test this, let’s build an example data dashboard using weather data.

Let’s get started! For this example, I used OpenAI’s codex model, and you could use Claude or Cursor Agent or Gemini and I’d expect slightly different outputs.

First, download two csv files of weather data.

• Go to meteostat.net and search for a weather station and time frame.

• Download daily weather data for two cities (I picked 30 day files for Seattle, WA and Bellingham, WA). For each link, click export and select the CSV option.

• Save the files in a directory using the names “seattle.csv” and “bellingham.csv”

Meteostat gives you consistent fields:

date, tavg, tmin, tmax, prcp, wdir, wspd, wpgt, pres, tsun

We’ll use:

• date

• tmin

• tmax

• prcp

• wspd

The LLM will add a city column automatically based on the filename.

Understanding the data by talking to an LLM

To orient the bot, you’re going to give it both a general idea of what to do, and a specific dataset. A more advanced vibe-coding version of this dashboard might support arbitrary CSV file loading, but let’s skip that for now and keep it simple.

Here’s the prompt we’re using to help the bot get started:

You are a data analyst.

Each CSV is daily weather data from Meteostat.
Each row represents one city on one date.

Columns include:
date, tavg, tmin, tmax, prcp, wdir, wspd, wpgt, pres, tsun

Here are the files:

--- FILE: seattle.csv ---
[PASTE seattle.csv CONTENTS HERE]
--- END FILE ---

--- FILE: bellingham.csv ---
[PASTE bellingham.csv CONTENTS HERE]
--- END FILE ---

Please restate what this dataset represents:
- the grain (what one row means)
- what the important columns represent
- what questions this dataset can support

Generate the questions your dashboard should answer

Now, use that starting point to create a series of data-driven questions:

Using this dataset, generate 15 questions a curious person might ask.

Group them into:
- Trends
- Comparisons
- Distributions
- Extremes
- Relationships

For each question:
- explain why it matters
- list which columns it requires

Then select the 6–8 most important questions that fit on a single-page dashboard, and suggest possible visualizations. 

Now, build the dashboard

Finally, use the combination of data and questions and tell the bot what kind of dashboard you’d like to build.

You are a front-end engineer.

I downloaded two daily weather CSVs from Meteostat.
Both have the same columns:

date, tavg, tmin, tmax, prcp, wdir, wspd, wpgt, pres, tsun

I saved each file using the city name:

- seattle.csv
- bellingham.csv

Below are the full CSV contents.

--- FILE: seattle.csv ---
[PASTE seattle.csv data HERE]
--- END FILE ---

--- FILE: bellingham.csv ---
[PASTE bellingham.csv data HERE]
--- END FILE ---

----------------------------------------
YOUR TASKS
----------------------------------------

1) Parse & merge the data
- Read each CSV.
- Add a `city` field using the filename (capitalized).
- Keep only: `date`, `city`, `tmax`, `tmin`, `prcp`, `wspd`.
- Combine into:

```js
const weatherData = [ ... ];

Create a modern “Two-City Weather Dashboard” using Tailwind (CDN) + Chart.js (with date adapter, no extra fetches). Embed the provided weatherData array directly.

Layout

Gradient hero with title/description.

Three KPI cards (avg high gap, wettest city, peak wind) each with an icon, headline, detail line, and a trend/delta line.

Filter panel (glass card) containing:
   - City checkboxes
   - Validated date pickers (show full date)
   - Temperature & wind sliders with live min/max labels
   - Filter summary chip, Reset button, “Need tips?” accordion
   - Preset buttons (“Calm Days”, “Storm Week”, “Warm Stretch”) that change multiple filters
   - Active-filter chips (clickable to reset individual filters)

Auto “Story” panel listing three bullet insights based on current filters.

Chart grid (1 col mobile, 2 col desktop) with five cards: high-temp trend, low-temp trend, precipitation trend (filled), average-high comparison bar, wind vs precipitation scatter. 

Each card needs: question-style <h2>, info bubble describing the viz, fade animation on redraw, and an overlay that appears when no data matches (with Reset button).

Behavior

Filters re-render all charts, KPI cards, info bubbles, story bullets, and the filter summary with smooth fades.

Hero deltas compare early vs late portions of the filtered data (show “↑ +0.8°C” style text with contextual coloring).

Preset buttons and filter chips update state instantly.

Entire page is self-contained (no fetch requests).

This yields a modern, interactive, single-run dashboard.

Note: it might need a few turns to get right where you ask the LLM for a plan, and then iteratively improve that plan. You can use a prompt like this one to get better results:

Review the file and propose a step-by-step plan to modernize and enhance the dashboard’s visuals, interactivity, and storytelling. 

I want a concise list of improvements grouped by theme (layout, filters, charts, narrative, responsiveness).

Evaluate what the dashboard can’t answer

An LLM will not be able to know what makes a good result, so you need to give it some feedback. This prompt will help you to check if your dashboard answers the initial questions.

For each of our 6–8 key questions:

1. Can the dashboard answer this? (Yes / Partly / No)

2. If yes, which chart answers it?

3. If no, what additional data or chart would be required?

Return the results in a table.

After this exercise, you’ll have a better idea of what your data supports.

Quality checking the output

Your dashboard wouldn’t be any good if it didn’t answer the questions well. You can see clearly over this date span that we had a pretty rainy weekend in Bellingham, WA on November 6, and it wasn’t quite as rainy in Seattle, WA (about 80 miles away).

Designing dashboards is much more than selecting a visualization to answer some questions. You also need to consider:

• schema (what fields are available, and how do they relate to each other)

• grain (what’s the lowest common demoninator available for this data - is it hourly, daily, weekly, or other?)

• question relevance (what are the questions we could possibly answer?)

• visual mappings (what’s possible to see in the report?)

Turning CSV data into a trustworthy dashboard is a great pattern for data operations in general. You create information that’s grounded in the data, answers questions, and is honest about constraints.

The best part? It’s easy to map this exercise to other datasets you might create. Weather is the scaffolding, and this works for any data.

What’s the takeaway? Creating a dashboard in a low-stakes environment is a great place to practice using LLMs to analyze data. Clarify the problem you’re solving, and create a system of repeatable insight delivery.

Links for Reading and Sharing

These are links that caught my 👀

1/ SIFT for AI - If you’re not already thinking about how to ask critical questions when you get chatbot results, you need to read Mike Caulfield’s explanation of SIFT. It’s a prompt and a strategy to give you more information about AI-generated results.

2/ Teach an LLMbot new tricks - you can now define “skills” or reusable component blocks for Claude. Simon Willison explains why this is a big deal, and a gateway to building more complete applications in small steps.

3/ AI eats the world - Benedict Evans has released his newest presentation, AI Eats the World.

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