10%, or 10×
AI made your week faster. It did not make your team larger. Saving time has a ceiling. Multiplying a team does not.
I asked Dan Olsen, author of The Lean Product Playbook, a question I already knew the answer to.
If I had told you a year ago that I vibe coded something, what would you have thought I built?
A prototype, he said. HTML, CSS, and JavaScript. Something clickable you could put in front of a customer to find out whether the idea survived contact with them.
Then the harder version.
If someone tells you today that they were using Claude Code for their work, do you know what they are doing?
That answer took longer. Production code. Automated workflows. Agents. A lot more pull requests. For the teams that have gone furthest, sophisticated loops with their CI/CD…
Similar tool question, 12 months apart. A year ago it named 1 artifact. Today it stretches from a mockup to managing finances, to production work, and the person saying it might be a designer who has never opened a terminal or a staff engineer who lives in one.
Knowing which tool you use stopped carrying information. Which matters, because tool choice is no longer what separates one team from another.
Every team got faster this year. Almost none of them got stronger. The difference is not the tools, and by now everyone has the same ones.
It's the operating model. The rest of this piece is about the difference between buying a faster week and buying a team that can attempt work it could never have staffed.
What a year of prototyping bought
Dan has been redrawing 1 slide for 20 years. On it is what he calls the design gap: you have your words, a PRD or a spec or a user story, and what you do not have is an experience. "There are words," he said, "and we need to bridge the gap from words to code, which is the user experience."
The old bridge was a clickable Figma prototype. Test it, iterate until customers like it, hand engineering something validated. Everyone agreed with that process. Most teams could not run it, and Dan is blunt about why: "they don't have the time, they don't have the bandwidth, they don't have a design resource."
So they skipped the test and built anyway. Not from carelessness. The queue for the one person who could make the prototype was longer than the deadline.
AI prototyping removed the queue. A real win, it arrived fast, and it is now finished. A product manager can now go from words to something interactive without asking anyone. Designers did not lose that work so much as inherit a harder part of it, since a generated screen still has to obey a design system before it ships.
Every one of those wins landed on an individual. 1 PM got faster. 1 designer got leverage. Multiply that across a team and you do not get a faster team. You get 8 people moving quickly in 8 directions, each with their own folder of context, each getting a different answer to the same question.
The interesting year starts there.
The moment it stops being personal
Dan described something he has watched happen repeatedly over the last few months, as enterprise accounts landed and whole teams got these tools at once.
Someone builds a skill for writing PRDs. Someone else mentions they built one too. Then the obvious question arrives: should we not just have one skill for the whole team?
A personal setup has become an operating problem. And the question that follows decides whether the shared version survives more than a month, which is the one I put to him in the room: who keeps it up to date?
What most teams have once everyone gets an agent. It works, and it is different on every laptop.
Design systems are getting solved. Shared context for a team is not.
What teams build next
We have now talked with more than 300 product companies putting these tools to work. Nobody calls it the same thing, but the shapes repeat enough to name. I call the whole apparatus a harness: everything you build around the model so that the model does useful work on your product rather than generic work on a prompt.
The curve has 6 marks. In practice they cluster into 3 places most teams recognize.
Personal and scattered. Chat prompts, shared Gems or Projects that go stale, then Claude Code or Codex on every laptop. Output climbs. So does divergence: the same question returns a different answer depending on who asked. This is where most teams are today, and where most of them stall.
Shared, but kept alive by hand. One place holding product, brand, and engineering context, with starter packs so people begin from the same state. It works until whoever maintains it gets busy. Then it decays.
Built to multiply, then to evolve. The team's own CLIs, plugins, and checks; enough DevOps that a product manager can push a branch and get a working URL back; then the rare step where new information is processed on arrival and the harness improves its own rules against what happened last time.
These are not maturity levels and I would not use them to grade anyone. Teams sit in several at once, one per workflow. The useful question is narrower: which workflow are you still running by hand, and what would it take to stop.
One design decision comes up in every one of these conversations, so it is worth settling early. Someone always asks how this works when product managers never touch code. The answer is that they should not have to. Give the agent the product manager is using read access to the repository instead. Feasibility questions then get answered without interrupting an engineer: can this work at all, what happens when this data arrives, where does this break. Reading a codebase is not the same as writing to it, and the two deserve different conversations about access.
What it costs, which is the part that gets skipped
Every harness conversation I have been in skips the bill. Here is mine.
Giving agents more reach moves capability and risk in the same direction. If everyone can connect to everything, someone can also write a script that deletes production data. Withholding the tools costs more than it saves, so the guardrails become engineering work, and somebody has to do that work and keep doing it.
A small example from our own stack. We drive the Google Workspace API from the command line (gws cli). As shipped, an agent holding those credentials can send email. We did not want that, and the permission we wanted did not exist, so we forked it and put our own permission layer on top. Our agents draft. They do not send. And now we can trust the agent.
The same picture once someone owns it. The two rows worth arguing about are the last ones: what runs on a schedule, and where the human boundary sits.
The bill gets steeper at the top of the range. A harness that keeps itself current needs DevOps and full-stack skill, and then it needs evaluation work to tell whether the changes it makes to itself are improvements or overfitting to last week. Call that AI engineering, and price the talent accordingly, because the market has.
Which is why the honest advice is not to build the whole curve at once. Build the one that covers the workflow you run most often, give it an owner and a maintenance budget, and treat it the way you treat your product. It will rot faster than your product does.
Where a harness alone stops paying
Teams who do all of this well tend to arrive at the same wall, and it is worth knowing it is coming.
They set up a weekly job that pulls every call transcript into local storage. It works. Now there is a folder holding tens of thousands of markdown files, fully searchable.
Then somebody asks a normal product question. In the area we are working on this quarter, what are customers telling us that we have not acted on?
The answer may well be in 3 of those 10,000 files. Finding it by search means already knowing the words those 3 customers used, which are not the words you would think to type. More context does not fix this. Nothing has been processed, so nothing can be found by meaning.
Notice what has gone missing. Not the data. The reason. Somewhere between the call where a customer said the thing and the branch where an engineer built something, the why came unattached from the what, and no folder of transcripts puts it back.
Closing that gap is what we build, so read the next paragraph as interested rather than neutral. We process signals as they arrive, attach them to the ideas they support, and hold the line intact from a customer sentence to the decision to the pull request that shipped. We call it a loop rather than a pipeline because what you learn after shipping returns to the same place the evidence came from.
The most useful proof I can offer is an admission. During the session I opened our own workspace and went to the idea I am least comfortable about: new users land in Zentrik and see too much at once. Several people on that call had told me exactly that. It sits in our system with 16 signals from real calls attached, ranked against everything else we could do. Dan then did what a good product person does with a live idea, which was to refuse the vague success metric and make me name the 1 workflow a new user has to finish on their first visit.
10%, or 10×
The arithmetic below should decide where you spend the next quarter.
If what you are buying is saved time, your ceiling is 100%. A task that took 1 hour goes to 30 minutes, then to 5, then to nothing. When it reaches nothing, the work is gone, and so is the reason to have had someone doing it. The grey curve at the top of this page. Real, and it runs out.
Capacity has no such ceiling, because it is not the same quantity. Saving time makes the work you already have cheaper. Multiplying capacity changes what the team is willing to attempt, and that number has nowhere to stop.
The teams furthest along this are not running 10% faster. They are shipping work they could not have staffed. A single person now carries what used to need a small team around them, not because anyone types faster, but because the context that used to be rebuilt before every decision is already there. I am describing what I see in our own work and in the companies we talk with, not a benchmark anyone has audited. The gap is not subtle either. You can tell within 1 conversation which side of it a team sits on.
Our own number, offered as illustration rather than proof: between May 1 and July 12, our 2-person development team shipped 113 tagged releases in 72 days. None of that came from typing faster.
So the question to put to your own team is not how much time the tools save. Ask whether any workflow has crossed over from cheaper to larger, and if none has, which one is closest.
One move for this week. Pick a decision your team makes over and over. Name who owns it. Attach one real customer source to it. Smaller than a harness, and the same instinct: refusing to let the reason for the work get separated from the work.
If you are building one of these
I have spent the past year building harnesses and comparing notes with teams doing the same, and the failure modes repeat far more reliably than the wins do. If that is the work in front of you, 3 things you can take:
- The curve above, as a reference to hold your own team against. Find the cluster you are on, then the next move.
- A working session, if you want help with the 1 move rather than the whole climb. 25 minutes, 1 customer source, 1 decision, and you leave with it running. Ask for one here.
- What this looks like when a system runs it instead of a person, which is what we mean by a loop.
I write about this as I go. Follow along on LinkedIn if you want the next one, and tell me which rung you are on. The answers are the most useful thing I get.
