Transcription
We are moving to a new operating surface at work. It is not just a function of chat GPT5. I know I've talked a lot about chat GPT5 the last few days. That's because 700 million, 800 million people have it, and we all use it. Now, I want to go beyond that.
I want to talk about the idea that we have a new operating surface at work that, yes, is exemplified by chat GPT5, but is also going to be exemplified by Claude, by Gemini, and others over the next few months. The stakes are really high. The real drag in modern companies is not creativity, where AI has been attacking over the last two years. It is so easy now to get a hundred ideas, a thousand ideas. The real bottleneck is the cost of proving a decision. We do that in docs. We do that in spreadsheets. We do that in slides. And you know what's happening over and over now? Chats become docs. Chats become spreadsheets. Chats become slides. And the challenge is that we are still bolting on our old decision-making to this new way of working.
I want to suggest to you that with chat GPT5, we crossed a Rubicon. We now have, for the first time, an incredibly easy way for anyone who is not a coder to create interactive artifacts that collapse that chain. Interactive artifacts that make decisions executable, auditable, and fast. My thesis is very simple: the unit of work is shifting from static deliverables to instruments of work. Front-end artifacts that you can open and tweak and run. An instrument will couple some small typed inputs, a little UI, maybe some tests or an audit in very clean ways to look at the results. A good instrument will replace several meetings and a deck with one surface and a very quick decision.
Why is this happening now? What makes this possible today? Number one, distribution. It is easy now to have single file canvases that can travel as easily as slides across internal tools. You can share that chat GPT5 canvas so easily. Claude does this too. You can share the Claude canvas really easily. There's no infrastructure to run that. Cost is also so cheap. If you have all of your employees on a chat plan anyway, and the canvas comes with it, it's essentially free. Governance is also easy because tests and approvals live in the instrument. You can actually capture what you did and then, if you really want to lock it, just stick a screenshot of that UI and stick it somewhere. It's easy to log your decisions. The nice thing is you can also compound and remix. So these artifacts are not dead, they're living. You can remix a weekly business review artifact and make it better next time. You can reuse it.
Now, I will add a caveat here. As someone who worked on weekly business reviews at Amazon, I am not trying to pretend that one artifact produced by one person in chat GPT replaces a weekly business review instrument that has been honed by business analysts over years for a team at Amazon scale. What I am saying is that most teams don't operate at that scale, and most decision-making doesn't require that formula review process. There's a whole class of practical work done decisions that are right now being made very slowly with documents, with artifacts. They don't need to be, and that is the new class of work that I'm talking about when I talk about this motion from static deliverables to instruments.
So what is an instrument? It has an input, a very explicit schema, and sample fixtures. It has logic functions that you can read and test. The code is visible. Edge cases are declared. It has a UI, a display-first scoreboard that has a few knobs you can touch and dial. It has tests, so gates are at the top, and if it doesn't work, it doesn't run. It has an audit encoded in it, and ideally, it will have an export. The key is making sure that you take those instrument components seriously. For example, if you have inputs, logic, and UI, but you have no audit trail, you can't really see what changed when people started to mess with your dashboard. And in the course of a meeting, there can be a lot of changes and adjustments.
So I want to suggest to you that the strategic impact of getting this work done is really understated because we haven't really lived it yet. The real challenge here is actually moving from a world where we have high latency and high friction and low trust for a lot of work, even among good functioning teams, because people can't remember the slack and they've been trained over and over again not to just trust the meeting, but to get stuff into a doc. Get to a world where you have more leverage, where trust increases because you can actually see it in the interactive artifact, where you can just generate free evidence by just running the artifact again with new data points. You want to get to a point where you have a portfolio of artifacts that replaces your portfolio of PowerPoint decks, something that lets you run the business with artifacts.
Now, this is not going to work for everybody. Again, I've said it before. This doesn't replace BAs at scale. This doesn't replace excellent SaaS tools for scaled-up companies, but it does allow you to get a lot of practical work done. I've created a dozen instruments to get you started, and they're designed to work together as a coherent operating system for small-scale teams and something that gives large-scale teams ideas about how to run fast for those in-between the cracks where the real work gets done stuff. Let me lay them out for you briefly, and then you'll get like full prompts for them in the Substack.
Run the business: You get a WBR scorecard and you get a data quality sentinel, something that like helps you obsess over your data quality and check your data quality where it matters. For shipping decisions, I've got an experiment decision pad and I've got a launch gate for you. For reliability, I've got an incident commander dash and I've got so radar. Again, these are very configurable, right? You can adjust the prompts the way you want. You don't like my WBR? Don't use my WBR. Use the prompt and make it yours. That's the whole point.
Revenue and risk: You have deals. You have contract risk triage. These are things you can actually put into on the sales side. Customers: You have customer health triage. You have a pricing and mix simulator. For your people side, you can get a hiring and funnel health one. You can get an access review runner. And this is just the beginning. These are designed to form an ops operating system from the get-go and a loop you can put in anywhere. But this is just the beginning of getting your head around the idea that you have instruments now and not static artifacts.
I want to suggest to you that there are real challenges with rolling this out that are not technical. In fact, the technical piece is mostly done. It is relatively easy to get these to start to work. Instead, the risks show up in culture terms. People overtrust these, right? Like sometimes they will have shallow data in here, and they will not show their thresholds, and they will not pay too much attention to the artifact because they're not used to it, and they will allow a lot of sprawl. They'll remix the artifacts in 50 different versions. This requires discipline, just like having a document standard requires discipline. It's not like it's a free ticket and you don't have to administrate the artifact. The power lies in the fact that it collapses a bunch of other work into one clean, interactive artifact that makes decision-making faster. So the work really changes as a result, and you have to be ready to impose that on the culture as a leader.
So meetings can run inside the artifact. You can record them, use Granola, use Otter, use whatever your recording AI is of choice, and then you have the record of the meeting. You have the artifact itself, and you're done. That's the whole thing. You need to get to a point where you are encouraging people to test artifacts, version them, and make sure that people are using artifacts appropriately in appropriate context and not just overusing them in ways that aren't helpful. You don't want 16 different versions of the same meetings artifact running around because then people will not trust it. And so there's a certain level of experimentation you want to encourage when you're trying to get an artifact to gel. And then you need to converge and actually pick the winner and anoint that and standardize it and discourage further experimentation while you focus on other parts of the workflow you want to align out.
Part of how you do that is by challenging the operators, the runners of the business, to own the outcomes associated with these artifacts. If you have someone in sales who is running the meeting that the artifact is associated with, they own the artifact. If you have someone in legal, they own the artifact for the legal review. You get the idea. The key here is that you have artifacts that tie to consistent organizational patterns, to product launches, to incidents, to pricing, to access, to hiring, to weekly business reviews. And you keep them as consistent and versioned as possible. And yes, for bigger teams, for bigger orgs, of course, you're going to have like, you know, the weekly business review version for this team versus that team because they're like 50-person teams, and they have different business units, and they have different metrics. I get that. That's why prompts are easy to mix together. The point, though, is that you want to manage that cadence of evolution. You want to manage who owns it. You want to assign ownership, just like you do with other good culture changes. And you want to map the instruments to the meeting cadence in a way that gives everyone predictability. That's what builds trust. That's what builds trust.
I would suggest if you want to move this way, that you stand up an instrument studio, a place to maintain schemas, tests, export standards, what counts as good. That you assign a bar raiser to review the prompts that are used for any new version so that people maintain those standards and you get better over time. And I want you to challenge people and change the incentive to reward decisioning that ships through gates, not through decks or through docs. You want people to start to think in terms of how they can accelerate decisioning and how they can leverage instruments instead of flat docs to do so. So change your incentives. Maybe change how you do performance reviews. This could get as far as looking at promotion readiness, is looking at whether someone can articulate and define a new artifact in a way that's useful for their team. Just giving you an example there.
I want to close with one other piece. We've talked a lot about how this changes things for business runners, right? People who run the business, operators. What happens for tool builders, people who build Word, Docs, Notion, Sheets, people who are essentially building the static docs of the past? I want to suggest to you that Notion's already aware of this, and others are too, because they know the product is no longer a document editor. It's an execution surface. That's why Notion's homepage is "What do you want to make today?" There's going to be a ton of competition for this space. And as a builder of a business, you are going to be spoiled for riches in how you actually convert your team over to instruments.
If you're in the tool-building business and you're used to static docs, one of the really interesting ways you can involve here is choose to ship primitives for instruments. Ship inputs as blocks, logic blocks, tests and gates, stable exports, things that people need to compose instruments for various workflows. I think that's a really interesting opportunity I haven't seen anybody fully grasp yet. You want to be in a place where you can have somewhat opinionated building blocks if you're in the document creation space, because if you just have free text, people will abuse that. Whereas if you have inputs with regular schemas and people can choose those, you're going to get much more useful downstream blocks. Give people helpful limitations to help them build composable instruments. And so part of what I'm doing when I suggest the prompts down in the Substack is I'm trying to hold to and key to an opinionated schema, a schema you can stick with over time, because you need that consistency to build useful artifacts.
One of the interesting implications of all of this is that we are moving to a world where policy is code. So a business rule is literally encoded in TypeScript somewhere, or a business rule is encoded in an artifact somewhere. Approvals happen on the surface. We don't really have this yet, but we want to get to a world where we have lightweight e-signatures and not just a button-click go/no-go. Right now, it's just going to be a button-click go/no-go that's encoded in the artifact, and you screenshot it. That's fine for getting started, getting into the instrument world. I want to see a world where we actually have artifacts that start to evolve into those mini-applications. And I expect to see that over the next 6 months to a year.
One of the keys is making sure that these are everywhere. You can link them if it's Claude, Claude and the artifacts, or if it's chat GPT and the canvas, you can link them anywhere. They're public-facing links. So, link them in the invites. Link them in the chat. Link them in the issue. Make sure that these are interoperable and everyone sees them. And make sure, and I'm just going to advise this because I've seen this happen, make sure that you do have those screenshots because people can go in, click on them, and change things afterward, right now, and remix the artifacts, which is great if you're chat GPT and you're trying to encourage innovation, but it's perfect hell if you want to make sure you have a steady state. And so until these artifacts evolve with a little bit more mini-app internal checkpoints, you be the one that takes those screenshots and encodes "this is what we talked about, this is what we decided." So you can always go back to that state relatively easily. In fact, at this point, honestly, you cannot just encode the screenshot. You can frankly grab a code snippet, and it becomes an even more immutable record of what happened.
I want to suggest to you that there are some business model shifts here. First, we are moving to a world where AI needs to be visible and governed, from AI being in the shadows. That means models need to have authors for these artifacts. They need to have run summaries and audits. You need to be able to generate tests from the code that show what you did. We are at the beginning of this. You can use some fancy prompt work, and you can get something like this going in GPT5 with canvas. There's going to be more.
I also want to suggest to you that value is starting to accrue at runtime, not author time. That's a very profound shift. So think about it for a second. It's not the authoring of the artifact that matters the way authoring the PRD mattered when I came up as a product person. It is the way value occurs at the time you run the artifact and have the conversation. And so the value is in the active instrument itself. And there's sort of a profound implication there if you're building in the product space.
One of the things that I want to suggest is that you lean into adoption of these instruments if you're doubtful but want to try, and be willing to make the first step trivial and imperfect. Hey, let's replace the deck this week. It might not be perfect, but let's see how it goes and have the conversation. That's a two-way door. We can do that. See if you can start to measure the share of meetings that run on an instrument versus the share of meetings that run on something flat. See if you can start to optimize to support instruments being used more and more as you have internal AI teams that want to support you. This is so much more interesting work than just building the chatbot to talk with the HR policy manual, which for whatever reason seems to be the default thing that people who greenlight AI teams internally always do first. No, do something interesting like this that actually accelerates the business. Think about AI as an outcome driver directly, not just a chatbot. Move the center of gravity from defining a narrative into execution. That's what these instruments do.
Instruments don't actually kill documents. They just demote them, right? Docs will capture the narrative, the context, the story. You're going to turn the meeting minutes automatically into a document and a story. Instruments are what give you the decision and capture the record, and then you can move on. Instruments are what let you go faster. And we've never really had that before. So my challenge to you is figure out how you can ship higher quality decisions and prove that they're better quality. And that's exactly what I focused on with these 12 prompts to build these 12 instruments. Better quality decisioning, fewer slide decks. Welcome to a world where we have a new way of working. We're all going to learn about it.