There's a kind of work that happens before anything gets made. It's the work of sitting with a decision long enough to actually believe in it. Product teams do this constantly, often without naming it. You have a sense of what to build, and then you test that sense against reality. By the time something ships, the team has built up real conviction that this is the right thing in the right form. That conviction-building is the product development process.
I've been thinking about this a lot as I use more of the new generation of AI design tools. Figma Make, Replit, Claude Design, and others are getting really good at producing visual output very quickly. You can go from a rough idea to something that looks close to real in minutes. These tools are going to change how product teams work, and a lot of that change is good.
But something has been bothering me about how these tools are positioned.
Conviction
A good product process moves conviction through three stages.
In the product thinking phase, the team builds conviction that they are solving the right problem for the right people. This is the requirements work, the research, the customer insights, the framing of what matters and why.
In the design phase, that conviction gets hardened into form. Designers take the product thinking and stress test it against how people will actually experience it. This is where a lot of the unexpected discoveries happen. You find out that the thing the PRD assumed was simple is actually three different problems, or that the flow you pictured doesn't hold up when you try to lay it out, or that a small visual decision reshapes what the feature should even be. Good design work helps to transform and harden the product thinking.
In the engineering phase, conviction gets committed to. This is the most expensive part of the process, and that expense is the reason conviction matters. You don't want to spend weeks or months building something the team isn't sure about.
Each stage pressure tests the one before it. The artifact you carry from stage to stage is useful, but the artifact is not the point. The point is that the team's shared understanding of what they are building has gotten stronger at every step.
References
This is also why a design system matters. A design system isn't just a library of components. It's the record of every design decision the team has already made and hardened. When you use a button from the system, you're not just grabbing a visual element. You're inheriting a decision the team already argued through like how a button should behave in your product. That decision came out of conversation, iteration, and the thinking that happened the first time the pattern got solved.
This is the part of the current AI design tools that sticks out most to me. They treat your design system as an aesthetic reference. They pull in tokens and colors and maybe some component shapes, then generate fresh versions of things you've already figured out. They take the surface and leave the substance. If you already have a managed design system living in one place, the tools should use it, not recreate it.
Speed
The tools are very good at getting ideas out faster. They're good at helping people who don't have years of design experience produce something with decent hierarchy, sensible color, and a workable structure. There's a version of this story where designers help more of their teammates think visually, and that's good for product teams.
What the tools are not good at, and what I'm not sure they can be good at, is what I'd call the "sitting with" phase of design. The nuance of trade offs. The conversation that happens inside a designer's head before they even open the tool. The question of whether this is really the right thing, or whether there's a version of it that would be better, or whether the thing the PRD asked for is actually the thing the user needs. That work is slow because it has to be slow. It's the work of building conviction, and conviction cannot be generated with one or two well thought out prompts and chained together tools.
The risk I keep coming back to is that these tools produce artifacts without authors. The tool has no stake in the outcome. It doesn't know your users. It hasn't done any of the sitting with. It generates something plausible and hands it to you, and because the output looks finished, it can create the illusion that the thinking is finished too. A PM generating a flow in Cowork, a designer refining it in Claude Design, an engineer picking it up in Claude Code. The handoff chain is real and exciting, but if nobody along the way has actually done the sitting with, what gets handed off is a nicely rendered guess.
Obligations
The useful reframe, especially for product teams figuring out how to work with these tools, is that the tools change the speed of output but not the obligation of each role. Product thinking still has to build conviction that the problem is the right one. Design still has to build conviction that the form is the right one, and still has to use the process of making to uncover what the product thinking missed. Engineering still has to build conviction that this is worth committing to. The tools can help at every stage, but the sitting with is not something any of us can hand off.
None of this is a critique of the tools themselves. I use them everyday. Claude Code tells me I've used multiple times the amount of tokens as great works of literature (whatever that means). The tools are going to keep getting better, and the version of the product process that includes them is going to be better than the one we have today. But it matters that we stay honest about what they are. They are very good at producing visual output. They are not, at least not yet, a substitute for the process that produces good design decisions. Speed of output is not depth of conviction, and I'd rather ship slower with conviction than faster without it.