The product team after AI

For most of software history, the way product teams worked together was shaped by a simple constraint: making software was expensive.

Turning an idea into a product required different kinds of expertise, so the work moved through specialists. Product decided what should be built, design translated that into an experience, engineering turned it into software, and QA made sure it worked. The handoffs between those roles became the operating system of the team.

Most of the artifacts we still use come from that model. Specs, tickets, wireframes, Figma files and pull requests are all ways of carrying intent from one person to the next. A ticket is not inherently the best unit of product work, just as a static mockup is not inherently the best way to communicate an interaction. They became useful interfaces between specialists.

The boundaries between product, design and engineering were blurring well before generative AI, and new titles like design engineer and product engineer name it. Marcelo Chaman describes design engineering as a spectrum rather than a single new role: people sit at different points between design and engineering, with different depth on each side. AI makes it easier to move along that spectrum because it lowers the cost of operating outside your strongest discipline.

Nobody’s job goes away. Everyone’s range gets wider.

A designer shows up to the review with something you can click instead of a Figma file. A product person brings a working version of the idea rather than a document describing it. An engineer tries several interface directions before asking the designer which one deserves their time.

The designer is still the designer. Being able to build something is not the same as being able to judge it or maintain it, so deep expertise gets more valuable: there is far more to evaluate.

Specialists stop being mandatory steps that every piece of work has to cross. They become the people you pull in at the moments where their judgment matters most.

When the cost of producing software falls, the number of possibilities you can explore goes up. I can try five implementations instead of committing to the first one.

I think this is where the line between vibe coding and professional work sits. Vibe coding stops at the first thing that works. A professional builds the alternatives, compares them, and finds out which one is better before committing.

The other half is what you do with the results. The lazy version is to drop all five options on a teammate and ask them to figure it out. That moves the cost from you to them. At Shopify, Tobi Lütke says, they call these slop grenades.

So if you are using AI, you should take on a new responsibility: absorb the exploration yourself. Send the agents out to scout, compare what they bring back, discard the weak options, form a recommendation, and only then bring in someone else’s judgment where it is useful.

How you bring it in matters too. A prototype that looks finished tends to close the conversation, so it should arrive as a question.

Someone still has to decide which direction is better, which trade-off is worth making, whether the thing solves the right problem and whether it fits the rest of the product. That part did not get cheaper.

An agent cannot always make that call. Agents are very good at math, pattern matching and coding, which is why producing the options got cheap. Choosing between them is a different skill. My friend Hugo explains part of why: the agent sees only what is in its session.

What it misses is the untidy knowledge a team carries around: the tech debt discussed three months ago, the user who complained about exactly the thing you are touching, the taste that comes from years of shipping. Keeping that bigger picture in mind is still your job.

That gives a clear division of labor. Agents explore, build and prepare the decision. A person who knows the product, and who answers for the result, makes it.

So the scarce part moves upstream, from producing the work to judging it with the full picture in mind.

Many decisions no longer need anyone else. With AI I can settle them on my own, without interrupting a colleague, and that is where much of the speed comes from. The ones that still need another person are where collaboration now happens.

This changes what I think the basic object of collaboration should be. If execution becomes cheap, perhaps the decision itself becomes the real unit of collaboration.

If the decision is what travels, the artifacts around it have one job: make it fast to understand.

Andrej Karpathy recently made this point about model outputs: go beyond prose to diagrams, interactive webpages and bespoke explainer videos. We can now choose the medium by how well it communicates, not by how expensive it is to produce.

A prototype no longer needs to be a step toward shipping. It can exist for half an hour, help three people understand a trade-off, lead to a decision and then be thrown away. That makes software itself a communication medium.

It also changes who pays for communication. Most of it today is optimized for the sender, and the receiver inherits the cost of understanding. AI makes it cheap to invert this: the same idea can reach a founder as a short summary, a designer as a visual comparison and an engineer as a list of edge cases.

The goal becomes minimizing time-to-understanding rather than time-to-send.

Our tools hold the work, not the decision behind it. A Linear ticket describes a task, a Figma file contains a design, a pull request contains a code change. Whoever reviews them has to reconstruct the more important thing underneath: what decision is being made, what alternatives were considered, and where their judgment is needed.

GitHub is a remarkably good collaboration system for a product world in which code is the primary artifact.

But a product decision now comes with a prototype, user research, screenshots, generated experiments and an implementation. The people reviewing it include engineers, designers, product managers, founders, domain experts and AI agents. Most of the humans here will never open a diff to read the code.

If the decision is the unit of collaboration, the tool should be built around it. Call it a decision request (DR). A pull request asks whether a change is correct. A decision request asks whether it is the right thing to build. A person or an agent brings the question, the alternatives already explored, the evidence, a recommendation, and whatever artifacts make the decision easiest to understand.

Imagine a team deciding whether new users should create an account before or after they first try the product. The decision request states the question in one sentence. It links three working variants anyone can click through. It says which one is recommended and why the other two lost. It asks the designer about the flow and the engineer about what deferred signup does to the data model. It lists the assumptions it depends on, and sets a date to check whether the choice was right.

This can sound like a request for comments (RFC) or a decision record with a new name. Teams have written decisions down for a long time. I think two things are different.

The alternatives are built, not described. An RFC argues for an option in prose because building three versions was too expensive. Now the reviewer can try them.

The author can be an agent. Agents do more of the work between one meaningful choice and the next, and they need a way to stop and ask for judgment in a form a human can absorb quickly.

If GitHub were designed today for the entire product team rather than around code, I suspect it would move in this direction. Less a place where developers review diffs, more a place where the whole team decides what gets built.