I think about AI product design in terms of degrees of freedom. There are several different kinds of freedom. There is the freedom the user has to express what they want. There is the freedom the user has to configure the product. There is the freedom the model has to decide how to solve the problem. There is the freedom an agent has to use tools and take actions. And then there is the amount of variation an organization can manage between one person’s setup and another’s.

So, the question any good product designer asks is, “Is this the right degree of freedom for this specific context?”

Now, these freedoms are not the same thing. A one-button product can give the user almost no visible choice while giving the model an enormous amount of hidden discretion. And an empty chat box can give the user theoretically unlimited freedom while giving them almost no help in deciding what to do.

By a degree of freedom, then, I mean an independent and consequential choice that either the user has to make or the system is allowed to make.

A blank prompt box is not necessarily a simple interface. It may just be an interface that transfers the work of product design to the user. Every time you open it, you have to specify what the product should become for that particular task.

People see that an agent can now turn a wish into an app, and then they make the much larger leap that the app no longer matters — that eventually there will be no products, only services assembled around whatever we happen to ask for.

But a wish is not a concrete and detailed specification. Nor is it a stable-in-time abstraction.

Even if an agent can generate a music player for me from a sentence, I will still want to open that player tomorrow and press play. I will not want to reconstruct the application through conversation every time I want to hear a song.

Agents will obviously make much more bespoke software possible. But do people want every interaction with software to begin again at the level of intent? In most contexts, they do not.

So, a product is, in some sense, a stored answer to thousands of those questions. It houses intent that has already been elicited, argued over, tested against edge cases, made legible to other people, and stabilized into behavior. It is complexity that has already been digested for you, so every user does not have to re-articulate and renegotiate that intent on every use. Spotify is a very particular theory of what listening to music on a screen should be. But I appreciate this particular set of constraints it imposes because they absorb complexity for me. 

Software as an abstraction exists because people do not want to be the product manager of every ordinary interaction in their lives.

“Make a wish, get an app” is useful when I'm underconstrained. I can quickly whip up a tool tool, discover what I need, and throw the rest away. 

But once other people, data, or workflows begin depending on that tool, it has to acquire a more stable shape. The fact that an agent produced an app does not by itself make the app a dependable shared product.

AI does not magically eliminate human psychology, organizational structure, institutional knowledge, existing habits, established ways of working, or everything people are unwilling to unlearn. These constraints have little to do with what the model is technically capable of. And the model cannot simply wish them away.

So the claim that there will be no products, only services, mistakes intelligence for settled intent. A service can interpret what I am asking for now. A product remembers what has already been learned about the thing I keep trying to do. The product is where I stop having to articulate the same intent again.

Another way to think about this is asking yourself,

One answer is that they provide structure along many axes at once.

They constrain time: you know this will be done in a certain number of months or years.

They also constrain the curriculum: everyone is going to study this list of things, in roughly this order, and become competent at some defined body of knowledge.

And they give you feedback, peers, deadlines, standards, and a point at which you are allowed to say that you are finished.

So the student is borrowing the institution’s judgment about what to learn, in what order, at what pace, and what competence should look like.

The institution also gives you pedigree. Pedigree is a standardized signal you receive by accepting the institution’s constraints. It compresses a complicated educational history into something another university, employer, or system already knows how to read.

You may be a self-learner who is several times better than a Harvard graduate. But you may still be illegible to the system. The system does not know how to evaluate you because you did not come through a path it recognizes.

Its defaults, sequence, vocabulary, workflows, and stopping conditions contain judgments that the user does not have to reconstruct from scratch. The product is a useful and welcome constraint on the user. It lends them a way of approaching the problem that has already survived contact with many other users and many earlier mistakes.

If you replace all of that with an empty agent interface, the freedom may look generous, but the meta-work has quietly returned to the user. Now they have to decide not only what they want to accomplish, but how the system should be organized, which objects should exist, what a finished state looks like, and which failure modes matter.

In many contexts, that is not useful. You're making your users do unpaid product design.

If several companies that look like mine already trust the same product with the same kind of work, that may not necessarily prove the product is the best I can get. But it does make the choice legible to procurement, security, leadership, and everybody else who has to share the risk. I am buying capability and the confidence that a lot of the general complexity and feature requirements have already been absorbed.

When many other comparable companies use the same product, I know that

- It has survived security and procurement reviews.

- Its failure modes are relatively well known.

- People can be hired who already understand it.

- Integrations and implementation partners exist.

- Employees moving between companies recognize it.

- The vendor has an observable roadmap and installed base.

- The buyer can tell the board that similar enterprises already depend on it.

ServiceNow advertises roughly 8,400 customers, adoption by more than 85% of the Fortune 500, and a 97% renewal rate. Those numbers make it extraordinarily legible as a purchasing decision.

In contrast, anything ambiguous, with a very high number of degrees of freedom, is difficult to evaluate because evaluating it requires a lot of taste and judgment. You need someone capable of understanding the space of possibilities and judging why this particular path through it was good.

Agents are one of those things. Most people cannot yet wrap their heads around what an agent is, what it will do, or how it will behave. An agent has an unusually large possibility space. And you cannot constrain it in exactly the same ways that an organization constrains a human.

A human employee sits inside a hierarchy, a team structure, a promotion system, a set of social norms, and a network of incentives. But there is also a much larger invisible social layer around them: reputation, embarrassment, managerial judgment, tacit knowledge, precedent, and an enduring stake in remaining part of the organization. Agents do not participate in that layer in the same way.

You can absolutely constrain agents in other ways. In fact, you have to. And that is what the harness is: the institution around the agent.

But what you cannot have is every person in the same organization designing an entirely different harness and an entirely different set of constraints for their agents. That gets chaotic very fast.

In general, the more powerful and general the underlying capability becomes, the more important it is to decide which freedoms should be exposed, which should be hidden, which should be personal, and which should be standardized across the institution.

And in this sense, constraining an agent is less a technical problem and more of an organizational and product-design problem.

So a services motion and a team of brilliant forward-deployed engineers can be extremely useful for discovering the shape of a product. They can sit with the customer, uncover intent, find all the tacit exceptions, reconcile people who want incompatible things, and crystallize this into a workflow. Intelligence makes that process faster.

Such enterprise software is also a context-specific compression with shared objects that give many people a common language. A bespoke app may describe one person’s needs more faithfully, while a shared product gives the organization something it can coordinate around.

Constraining degrees of freedom is often the thing that makes collective action possible. If every person’s agent invents a richer but different representation of the same customer, project, or decision, the individual interfaces may all be intelligent while the organization becomes incoherent.

You can make something extremely complex and extremely good, but if it does not make itself legible to the end user, that complexity is useless to them.

Generally, no. They want maximum differentiation with minimum unique machinery. The enterprise has to ask which processes are valuable enough to justify deviating from proven software. Because custom software creates obligations! Someone must test it. Someone must secure and audit it. Document it. Understand it after its original builders leave. Ensure that it continues working after every surrounding system changes. Explain why this organization operates differently from everyone else.

It's simply not feasible for an enterprise with an ‘IT Department.’

Agents may reduce the cost of producing code, but code production is only one part of the lifecycle. They do not automatically eliminate everything else.

An enterprise isn't one organism with one clearly recoverable intent. It is a coalition of departments and people with incompatible preferences. Standard software here acts as an external settlement. It imposes a constraint that prevents every workflow from becoming an internal constitutional debate. An agent can implement a decision faster, but it cannot determine whose preference ought to win.

Standardized software interfaces absorb all these costs.

This is also why old software can be so difficult to replace.

There's no denying that many legacy vendors absolutely rent-seek. They exploit switching costs, neglect the product, and charge customers for the fact that leaving is painful. But I think of rent-seeking as a byproduct of a system that was able to tame some significant organisational entropy. It's a signal that part of the institution has slowly grown around the software, creating a moat from the inside out, if you will.

A young AI startup does not replace SAP in the same way that an individual replaces a note-taking app. No, no. It has to earn the right first, by providing undeniably effective point solutions. Because the system you're trying to replace is entangled with approval paths, roles, reporting, data definitions, integrations, training, and the way thousands of people believe their jobs are supposed to work. The last bit is also the hardest.

So replacing the old product means changing the software and the organization at the same time. The new system can be objectively better and still be a terrible proposition if adopting it makes the buyer feel as if the ground will disappear underneath them.

Which means AI product design has to think about change management from the beginning and find a way to deliver something effective that can be tried without warranting a lot of change or “transformation”. It has to preserve enough familiar objects, workflows, and assurances that the new capability feels adoptable and low-risk.

It is a change-management problem, a legibility problem, and a constraint-design problem at the same time.

You have to decide how to constrain the degrees of freedom without putting the user in a straitjacket. You have to decide when and how to open new degrees of freedom without overwhelming the user or degrading the product experience. And it is terribly easy to degrade a product by allowing people to do anything they want.

A lot of experienced and senior folks today have lost sight of this. You can have nuance, judgment, taste, and handle an insane degree of freedom. But if the users you're serving do not operate on that plane, you are just talking to yourself and people will not understand what the fuck you are going on about. The lay professional's ability to hold complexity is different. Their appetite for configuration is different. And you cannot decide how much freedom a product should expose by asking only how much freedom you are comfortable with, or how much complexity you can wrap your head around.

The model can absorb some of the complexity behind the interface. But the product still has to decide where that complexity goes and who has to metabolize it.

Every additional degree of freedom has a cost. It creates another decision, another state, another way to get lost, and another behavior that may need resolution and maintenance.

And if you want to increase the user’s degrees of freedom, that requires an insane amount of thought. It is not enough to expose the model’s underlying capability and assume the user will figure it out. Banking on users to “get it” has always been a bad model for product design. If you need FDEs and a full do-it-for-you service motion just for the users to be able to get value out of your software, you're selling IT services, not software.

So, people designing applied AI products need clarity of purpose that helps them build tools that encode taste others can borrow.

You can have a hammer and use it with extraordinary craft and skill. That is one kind of mastery. But designing a hammer that naturally allows another person to borrow some of your craft — by virtue of the way the product itself is shaped — is something else entirely. 

A good product gives the user access to some of the designer’s judgment. With AI that offers an almost unlimited possibility space, this judgment is more critical than ever. Because the product cannot simply dump that possibility space onto the user. It has to decide which possibilities become visible, which actor gets to exercise them, at what moment, and inside what boundary.

And if you get that right, you get a user that's now a lot faster and more capable.

AI will certainly create a glut of personal software and tooling that continuously reshapes itself. But these will be a far cry from enterprise software, because no enterprise wants to make every wish from scratch.