AI is making product, engineering, and UX roles overlap, so people need clarity about the value they bring.
2
Great AI products start with a single user outcome, earn trust by delivering it reliably, and expose the model's limits.
3
Restraint and judgment matter more than adding every available model capability to a product.
Summary
Raiza Martin argues that AI products are being built during an awkward transition. Existing software feels clumsy beside tools such as ChatGPT, Cursor, and Claude, which creates an opportunity to rebuild familiar experiences. She says good products begin with personal clarity about the vision, purpose, and taste behind the work. Teams should start with the user's job rather than interface details, then focus on one outcome the product must deliver. Her NotebookLM example shows how auto-summary helped users understand a new interaction model, while early failures at summarization showed how quickly trust disappears. Delight comes after trust and should give users agency rather than feeling like a trick. Martin is candid about her own Huxe product becoming a kitchen sink of capabilities. Her final advice is to use judgment and restraint, respecting users' time, data, and agency.
AI is blending product, engineering, and UX work together
Martin opens by saying people now do much more than the job title on their business card suggests. ChatGPT can write SQL queries, and AI makes it easier to access or simulate expertise, so old boundaries between roles are weakening. Teams also have invisible AI participants behind their documents, slides, and decisions. A five-person team may effectively work with five ChatGPT instances as well. Martin says this creates uncertainty about what product work means, but it also gives teams new abilities. Her advice is to understand where you are coming from and what value you bring, because access to AI does not remove the need for personal judgment.
The current awkwardness of AI products creates room to rebuild
Martin says the products people use today are the ugliest they will ever be because most were designed before AI. Their fixed buttons and narrow interaction patterns feel strange beside systems that can respond to intent. She describes a growing gap between intuitive AI products such as ChatGPT, Cursor, and Claude and the rest of the software world, which often feels janky by comparison. She expects a period in which many products are rebuilt. That work will be chaotic because roles, teams, and products are all changing at once. Martin frames the product builder's job as finding an opportunity and expanding it into something real.
Personal clarity gives a team the force to build a product
Martin says meaningful products have to be forced into existence, and that requires clarity carried by one person before it spreads through a team or organization. The clarity has three parts: vision, purpose, and taste. She uses the first version of NotebookLM, called Tailwind, as an example. Many people told her it was stupid, but she had a clear reason for wanting a tool that could accept many documents and let her interact with them. She was working full-time while returning to college, so the problem felt concrete to her. That conviction gave her the energy to keep pushing the idea with users, teammates, and stakeholders.
Martin says product teams should start with the job rather than the pixels. Taste is about the outcome a product delivers, not only how it looks. The team should be able to name the single outcome the product must deliver for every user, because that purpose helps distinguish a useful feature from baggage. It also protects against what she calls AI demo disease, in which a capability makes a compelling demo or social video without becoming a real product. Users do not care that something is AI by itself. They care about having an intent and getting the result in a way that feels inevitable.
Trust comes from delivering the promise and showing the edges
Martin describes a product as a promise about what it can do. Users have limited patience, so a failed first attempt can end the relationship. In early NotebookLM, users often uploaded sources and asked for a summary. Summarization was a common first query, but smaller context windows made it difficult, and failures caused people to leave. Martin says teams should expose the edges of the model instead of pretending it is smarter than it is. They should also handle failure in a human way and nail deterministic parts before adding probabilistic delights. A product has to keep its basic promise before users will spend time exploring its more unusual capabilities.
Once a product has earned trust, it can surprise users. Martin describes NotebookLM's podcast feature as playful because people knew which documents they had uploaded but did not know exactly what the generated podcast would say. She says delight sits between technical capability and user expectation. The product can move one step beyond what feels familiar, but going too far can make it feel spooky. Delight should come through agency rather than trickery. Users should feel that they are steering the experience and that the result comes partly from their direction and partly from the machine. Teams also need to live with their product and become its users so they can sense where people are ready to go.
Restraint is product judgment, and kitchen sinks lose focus
Martin warns against shipping a collection of model capabilities with a thin product opinion attached. She calls this a kitchen sink, where a product can chat, make podcasts, read news, and generate images or video, yet users do not know what they would actually use it for. She gives Huxe as her own example. It looked beautiful and initially felt like her dream product, but daily use showed that she relied on only one part of it. Several hundred users behaved similarly. Martin says the barrier to shipping is now judgment rather than raw capability. Teams should ask whether a product respects user time, data, and agency, then focus on doing one thing exceptionally well.
"The barrier to shipping, especially nowadays, it is not about the capability, it is about judgment."21:33
Who should watch
You are building an AI product that has many impressive capabilities but users are not returning to a clear core workflow.
Your team is debating interface polish before agreeing on the user outcome the product must deliver.
You need a practical way to think about trust, model limitations, first-use failures, and when a surprising feature is actually useful.
