If the Designer is the Product: Re-reading Inspired in the Age of AI

I finally got around to reading Marty Cagan’s Inspired. Yes, I know, I’m a bit late to the party.

Reading a product book from 2018 today is a weird experience. A lot has happened since then. The rigid processes, like weeks of discovery and the strict handoffs between UX, UI, and engineering, feel like ancient history, or at least like they’re on their way out, now that AI agents can do so much of this at the same time.

But the core principles? They might matter more now than ever. This is an attempt to work out which parts of the book have aged and which parts have become sharper, and what that means for those of us who design for a living.

What still holds

Cagan says every product idea carries four risks: will people value it, can they use it, can we build it, and does it work for the business? His whole argument is that strong teams address these risks before they build, not after.

AI has nearly wiped out one of the four. “Can we build it?” is almost always yes now, and it is yes quickly. The other three remain, and they are the human ones. Nobody has automated the question of whether a thing is worth making.

That makes the book’s central warning louder rather than quieter. When AI lets us build the wrong thing in an afternoon, a rigorous filter for “why are we building this at all?” is your only defense against shipping garbage at the speed of light. Cagan wrote that at least half of our ideas won’t work. That hasn’t changed. What’s changed is how quickly we can ship the bad half.

From discovery as a phase to discovery as a habit

Here’s where the book shows its age. Inspired still describes discovery as something that happens before delivery, a stretch of work that comes ahead of the build. That model made sense when building was slow. If you were going to spend three months in engineering, you had better spend a few weeks making sure you were building the right thing.

The books that came after already moved past this. Teresa Torres’ Continuous Discovery Habits takes Cagan’s product trio of product manager, designer, and engineer and asks it to talk to customers every single week, mapping opportunities and testing assumptions as a routine rather than a project. Melissa Perri’s Escaping the Build Trap makes the same shift from a different angle: teams get stuck measuring output, features shipped, instead of outcomes, meaning the change in customer behavior those features were supposed to cause. Jeff Gothelf and Josh Seiden argued in Lean UX that design should stop being a deliverable and become a shared team activity, with the whole trio sketching and testing together.

Read these together and a pattern shows up. Every one of them pushes discovery closer to the work, more continuous, more collaborative, and less like a handoff.

AI finishes that trend. When a prototype takes an afternoon instead of a sprint, there’s no reason for discovery and delivery to be separate phases at all. The tools have caught up with the philosophy.

When building stops being the bottleneck, discovery becomes the bottleneck. That’s a good place for designers to be standing.

The crossroads

So what does this mean for designers specifically? It depends a lot on how your company organizes design work, and I think the two most common set-ups are being pulled in different directions.

In a company that works in product trios, there is one designer per team. That designer sits with a product manager and an engineer, joins the customer interviews, sketches, prototypes, and specs the whole experience. This is the generalist by definition. The trio model was always a bet that one broad designer close to the problem beats a chain of specialists further away from it.

In a company with a design department, the roles are split. There’s a UX designer, a UI designer, a researcher, a content designer, maybe a service designer, each with their own craft and their own queue. Work moves between them as handoffs. This is the specialist model, and it’s still how a lot of larger organizations run.

For a long time, we were told the “T-shaped” designer was the answer for both: broad enough to work in a trio, deep enough to hold your own in a department. But I keep wondering if that’s actually the future. If an AI can generate decent UI, parse research, and write copy, then the “general stuff” is something anyone can do. AI has basically commoditized the generalist.

It feels like we’re standing at a crossroads.

Path one: the AI-powered trio designer. Maybe the T-shape is the future, but on steroids. The trio designer doesn’t need the department behind them anymore because they have AI as their engine. They become orchestrators. They set up the workflows and the rules for the agents to do the UI, the copy, and the first pass at research synthesis. They design fast, test fast, fail fast, and succeed fast. The trio designer becomes close to a one-person product team, steering the AI to build.

Path two: the hyper-specialist. But what if the specialized roles in the department are actually the future? If anyone in a trio can prompt an AI to create a decent layout, the floor has been raised. Human value now lives at the absolute ceiling. We might need hyper-specialists who work in spaces AI can’t reach: accessibility, complex domains like healthcare or finance, research methods, the hard interaction problems where “decent” isn’t good enough.

What this does to each role

The more I sit with this, the less I think it’s a real fork. But the two set-ups don’t arrive at the same place by the same route, so it’s worth taking them one at a time.

In the trio, the designer’s role gets wider and moves earlier. Continuous discovery already asked the trio designer to be in the customer interviews every week. With agents producing the UI and the copy, the hours that used to go to pixel work are freed up, and the obvious place to spend them is discovery: framing the opportunity, testing assumptions, arguing with the PM about value. The trio designer becomes the person who holds the problem, not just the person who draws the solution. The trap is the designer who uses agents only to produce more output faster. Ten prototypes in an afternoon are worthless if you can’t tell which of the ten solves the actual problem. That still takes depth.

In the department, the handoffs are what AI removes. When a trio can generate a layout, a first draft of copy, and a research synthesis before lunch, the queue to the UI team or the content team stops making sense. I don’t think that means the specialists disappear. I think they move. Either they get embedded in the trios, closer to the problem and further from the queue, or they move up to become the ceiling: a research lead who sets the methods and reviews what the trios’ agents synthesize, a content designer who owns the voice and the rules the agents write within, a UI specialist who owns the design system the agents build from. In both cases the specialist’s output stops being the artifact and becomes the standard and the judgment behind it. What doesn’t survive is the specialist whose value was the handoff itself, producing a deliverable that other people waited for.

Either way, the specialist only stays valuable if their depth is in something the agents can’t reach. Depth in a tool, a framework, or a visual style is exactly the kind of depth being commoditized. Depth in a domain, in a user group, in accessibility, in how people understand and act on interfaces, is not.

So the T doesn’t disappear. It gets redrawn, and it gets redrawn the same way in both set-ups. The wide part of the T is now everything the agents can help us reach, which is a lot. The deep part is what it always should have been: understanding people and problems well enough to know what’s worth building. Torres would call this the opportunity space. Cagan would call it addressing value risk. I’d call it the job.

How the trio actually works with agents

It’s one thing to say the trio designer moves earlier and the specialists move up. It’s another to describe what a Tuesday looks like. Here is how I think the collaboration changes in practice.

The shared context becomes the shared asset. In the old model, the trio’s shared understanding lived in people’s heads and in a scattered set of documents: interview notes, a PRD, some mocks. With agents, that context is what they work from, so it has to be written down and kept current. I think of it as one living folder that the whole trio and every agent reads from, in four layers:

• The problem: who the users are, the outcome we’re chasing, the opportunity map, the assumptions we’re testing right now, and what we’ve already learned. This layer changes every week.
• The evidence: interview notes, synthesis, usage data, support themes. Raw enough that an agent can pull a real quote, structured enough that it doesn’t have to reread everything.
• The rules: design system, voice and tone, accessibility standard, research protocol, technical constraints. This layer changes slowly, and it’s the one the department’s specialists own.
• The decisions: what we chose, what we rejected, and why. Without this, the agents, and new trio members, keep re-proposing things we killed three weeks ago.

Each of us tends the part closest to our own risk. The PM keeps the outcome and the business constraints current. The designer keeps the problem framing, the interviews, and the interaction principles. The engineer keeps the technical constraints and the conventions of the codebase. Ownership matters more than format, because a context nobody tends goes stale in a fortnight, and stale context is worse than none: the agents trust it. It also has to stay small. If a person can’t read it in twenty minutes, an agent can’t use it well either.

Whoever keeps that context alive keeps the trio aligned. In practice that is often the designer, because it is the same material discovery already produces.

The spec matters more, not less. It’s tempting to think agents make specs obsolete: why write it down when you can just generate and look? But uncertainty doesn’t disappear when you hand work to an agent. It gets paid for in tokens, in iterations, in ten versions of the wrong thing. A vague brief produces plausible output that answers a question nobody asked. So the most valuable document the trio writes is no longer a feature spec describing the solution. It’s a short, sharp statement of the problem and the outcome we’re after: who this is for, what they’re trying to do, what should be different for them afterwards, and how we’ll know. Cagan’s four risks and Perri’s outcomes turn out to be the best prompt there is. The clearer the outcome, the less the agents guess, and the less time we spend watching them guess.

The prototype becomes the conversation. The old sequence was PM writes, designer draws, engineer estimates, and the debate happened in review meetings about documents. Now the three of us can sit in the same room, describe an idea, and have three or four working versions of it in front of us within the hour. The argument happens over something real, on the spot. This is what Gothelf and Seiden meant by design as a team activity, and the agents make it the default rather than a workshop format we bring out twice a year.

Each of us judges our own risk. The trio’s accountabilities don’t change; what changes is that we spend our time judging rather than producing. The PM looks at the prototypes and asks whether users will value this and whether it works for the business. The designer asks whether people will understand it, whether the interaction holds up, whether it respects what we heard in the interviews. The engineer asks whether what the agent built is sound and whether it fits the system we already have. The agents generate. The trio decides. Nobody is off the hook because the agent did the work.

The cycle shortens to a week or less. Torres’ habit of a weekly customer touchpoint was ambitious when a prototype took a sprint. Now the loop can be: interviews on Monday, a handful of prototypes testing our riskiest assumption by Wednesday, real users on Thursday, a decision on Friday about what to keep and what to kill. The habit Torres describes stops being a weekly touchpoint and becomes the way the whole team works.

The specialists set the rules the agents follow. This is where the department connects back to the trio. The design system, the voice, the research protocol, the accessibility standard: these are no longer things a trio waits in a queue for. They are configured into the agents. A content designer who owns the voice guidelines is now shaping every draft every trio generates. A researcher who sets the interview and synthesis method is shaping every insight. Their reach goes up as their hands-on output goes down.

The failure mode is generating alone. The easiest mistake here is for the PM, the designer, and the engineer to each go off and prompt their own version of the solution, then meet to compare three divergent prototypes with three private mental models behind them. That is the old handoff problem with faster tooling. The point of the trio was always shared understanding. Generate together, or at least from the same context, and treat the prototypes as questions to put to users rather than answers to defend.

So what is our actual advantage?

All of this puts a lot of weight on judgment. So it’s worth asking where that judgment comes from, and why it is still ours.

It’s our brains, our bodies, and our creativity.

AI can generate a UI, but it doesn’t experience the world. It hasn’t stood in a hospital corridor watching a nurse try to log a medication on a tablet with gloves on. It hasn’t sat in a kitchen while someone tries to pay a bill with a toddler on their lap. Discovery, in Torres’ sense, is built on this kind of contact, and it can’t be prompted into existence.

We also solve problems best when we get to focus on them at the right level of detail, and that usually means stepping away from our screens. We need to go back to solving complex problems the way our minds actually work. I’m talking about sketching, discovering, and discussing. It’s the messy, human process of bouncing an idea back and forth. It’s the ability to debate the outcome we want to achieve, rather than just staring at the output on a monitor.

This is the part of the work that generating together protects. The value of design was always the shared understanding a team builds, not the artifact. The artifact was a by-product. Now the by-product arrives in minutes, which makes the process behind it the thing worth guarding.

The interface itself is changing

There’s one more reason to move our attention up a level. Interaction in everyday apps is going to look very different soon.

When an agent can complete a task on the user’s behalf, the screen stops being the product. The interface might be a conversation, a notification, a confirmation, or nothing at all. Someone still has to decide when the system should ask and when it should act. What should the user feel in control of? How do they notice a mistake, and how do they undo it? How much should the system explain about what it did on your behalf?

These are design questions, and they are among the hardest we’ve had. They just aren’t pixel questions. Our understanding of interaction principles, feedback, affordance, trust, and recovery, is what carries over. Our fluency in a particular design tool doesn’t.

If the designer is the product

Cagan, both in Inspired and later in Empowered, describes the product trio as three people with distinct accountabilities: the product manager for value and viability, the designer for usability, the engineer for feasibility. The design was to split the four risks across three humans who argue productively.

In the age of AI, those lines are blurring. Feasibility is largely handled. The designer who does continuous discovery is already carrying a chunk of value risk, and in a trio that works the way I described above, all three of us spend our time judging rather than producing. Take the PM and the engineer out of the room, which is what happens in a lot of smaller companies and in a lot of design departments, and a designer who can frame the problem, talk to users weekly, prototype in an afternoon, and direct the agents is doing most of what the trio used to do, alone.

That’s an opportunity, and it comes with a cost. If the designer is becoming the product team, the product is only as good as the designer’s judgment. There’s no longer a slow engineering phase to catch a bad idea, and without the trio there’s no PM to push back on value. The filter that used to be a process, or a team, is now a person.

So the craft going forward is our mental models, our grasp of interaction principles, and our ability to understand complex human problems. That means investing in the discovery habits Torres describes, the outcome thinking Perri describes, and the risk framing Cagan describes, and treating them as daily practice rather than as things we read about once.

It also means being honest about where the T needs to be deep. Not in the tool. Not in the layout. In the people we design for and the problems they actually have.

Cagan wrote Inspired for a world where building was the slow part, and a good process was how you avoided wasting that time. We now live in a world where building is fast and judgment is the slow part. The process didn’t go away. It moved inside the designer.

Let the agents worry about the output. Our job is the outcome.

I’d like to hear how this plays out where you work: in a trio, in a department, or somewhere in between.