Everything is ugly, so go build something that isn't

What does product work mean when product managers, engineers, and designers can increasingly do one another’s jobs? Raiza Martin opens with a show of hands across those disciplines, then describes product as a multilayer cake whose first layer is how builders understand themselves. A PM who could write SQL once had a recognizable technical distinction. With ChatGPT able to generate the query, the more consequential skill becomes knowing which question to ask. That does not make every person an expert; it makes expertise easier to access or simulate, and makes a job title less sufficient as an account of someone’s contribution.

The next layer is the team. Documents and slides now arrive with invisible contributors: ChatGPT, Claude, or Gemini may have helped produce them. Even after reading something herself, Martin gives it to ChatGPT, compares its takeaways with hers, and asks what she missed. Her illustrative five-person team therefore has five additional ChatGPT collaborators. The organizational consequences are still uncertain, but the practical question has already changed: what will people do with this additional capacity?

The third layer is the product itself: an idea drawn out of a person and translated into technology. Martin sees existing products as occupying an awkward transitional period. Interfaces designed before AI reflect the interactions their builders could imagine and implement at the time. Her deliberately ordinary examples are pressing a key to make a J appear and operating a microwave. Once richer interactions become possible, even these familiar mechanisms start to look constrained. Her description of products as the ugliest they will ever be expresses an expectation that the available interaction vocabulary is about to expand.

The user completes the layers. ChatGPT, Cursor, and Claude teach people that they can state an intent and receive something useful. Returning to products that require much more translation between intent and action then feels frustrating. Martin calls that gap consumer unrest: expectations rise across the entire product landscape, not only inside AI applications. It creates an opening to rebuild familiar tools around newly possible interactions.

That opening also has a personal cost. Changing roles and teams bring uncertainty about future work for PMs, engineers, and designers. Martin’s response is to define product people by their responsibility rather than their title: anyone supplying the force behind a product can find a small opportunity and expand it, like a popcorn kernel. An organization can share that responsibility across its members. The useful question becomes how to turn that opportunity into a product worth using; the answer here is a set of building principles, not an implementation recipe.

Making a product occupy a meaningful place in someone’s life takes sustained force. Martin initially wanted to describe the experience as violent; her team persuaded her to use forceful instead. The distinction she cares about is between making something as a hobby and pushing it into existence as a product people depend on. That second task requires conviction strong enough to survive resistance.

Personal clarity precedes organizational alignment. Before a team can agree on what it is building, someone needs a clear account of what matters and why. Martin treats technology choices, hiring, and organizational effort as expressions of energy supplied by people. Knowing the what and the why provides the energy to keep working with teammates, stakeholders, and users. She divides that clarity into vision, purpose, and taste.

The early NotebookLM, introduced as Project Tailwind at Google I/O in 2023, gives that principle a concrete origin. Martin recalls substantial skepticism about the idea, enough to make her question it herself. But she had returned to college full time after dropping out, while also working full time at Google building NotebookLM. Her need was immediate: put documents and slides in one place, then converse with them to accomplish useful work. This was the intended workflow, not the original format-support list: the initial NotebookLM rollout supported Google Docs, with Slides support arriving later.

She wanted to build that experience from the ground up, rather than attach it to another product. When users, stakeholders, or teammates did not understand its value, her own circumstances supplied a reason to continue. Personal clarity did not remove disagreement; it made the work of carrying an unfamiliar idea through disagreement possible.

Clarity becomes actionable when it names an outcome. Taste, in this account, concerns more than aesthetics: what is the single outcome the product must deliver reliably for every user? That purpose provides a criterion for deciding whether a feature adds value or becomes baggage. Without it, an impressive demo or a compelling social video can masquerade as a product. Martin calls this AI demo disease.

Purpose makes it possible to reject novelty when novelty dilutes the core job. Martin’s point is that the AI label is not the benefit users came for. They have an intent; the product should fulfill it in a way that feels natural and inevitable. That standard is harder to meet than making a model capability visible in an interface.

For NotebookLM, her target was to put 50 items into the tool and do useful work across them. Summarization was an entry point: if the product could make a body of material understandable, it could open the way to other operations across that material. Both the interface and the generation of a useful summary were difficult. Once implemented, however, the automatic summary served two purposes at once. It gave people useful information immediately, and it taught them what this unfamiliar collection-of-sources interaction was for. The 50 files describe the target workflow here, not a summary-quality result.

The feature looked basic from the outside. Its significance was that it acted as a tutorial through useful output, rather than requiring users to understand the product before receiving value. Martin connects that decision to sustained attention to the outcome: the apparently small feature emerged from repeatedly asking what the user needed to accomplish.

A product makes a promise about what it can do, and a user spends time and attention testing that promise. Martin describes trust as oxygen, with many products starting on something like negative credit: people may not want to try them at all, and those who do have little patience for anything unrelated to their task. One way to earn trust is to expose the model’s limits instead of concealing them. Users need a coherent experience at the point where the model stops being useful.

A product also exposes its builders’ workflow and assumptions. When it fails, the response should account for the person experiencing that failure. Designing and instrumenting only the best case leaves the worst case without a considered human experience. Get deterministic behavior right before adding delightful probabilistic behavior. An AI application still has to function as a good application; the model does not excuse unreliable basics.

In early NotebookLM, users uploaded sources and asked for summaries. Their requests often included a strict scope: summarize this document and only this document, or summarize only this concept. Smaller context windows made these requests particularly difficult. The older interface shown here has source cards, an empty Notes area, and a summary request being entered; it shows the starting workflow, not a generated result or an error.

Martin reports that roughly 90% of users’ first queries in early NotebookLM were summarization queries. She does not specify the cohort, observation period, or measurement method. The important behavioral interpretation is that summarization was a test: a user had heard about the tool, visited the website, uploaded material, and then asked it to perform an apparently straightforward task on that material.

If the summary failed, all of that effort ended in a broken promise. Martin describes users leaving and not returning, which made summarization a prolonged priority for her. The engineering importance of a feature therefore cannot be inferred from how exciting it looks in a demo. A basic first action can carry the burden of proving that the entire product deserves another interaction.

The user experiences this progression quickly. Martin describes the initial opportunity to earn trust as a matter of seconds, perhaps a minute, emphasizing how little patience a new product receives. Once it has earned that trust, it has room to delight. NotebookLM’s podcast-like Audio Overviews illustrate the change: users upload documents and receive a conversation whose phrasing and exchanges can be unexpected, funny, or goofy. The surprise introduces playfulness into working with familiar material.

Delight occupies a boundary between technical capability and user expectation. A trusted product can move one step beyond what feels familiar. Move too far and unfamiliarity becomes discomfort; Martin uses people’s unease around robots as an analogy. That makes the design task more specific than maximizing novelty: introduce something surprising that the user is ready to accept.

Delight should come through agency, not trickery. In NotebookLM, the user knows which document they supplied and chooses to transform it. The result can be unpredictable while the activity remains self-directed. That is different from pressing an unexplained random button: the user has contributed something meaningful and can recognize their role in the outcome. Martin describes the balance as feeling “equal parts me and the machine.”

Too many features make it harder to create that experience. Martin draws a sharp distinction between shipping model capabilities and shipping new outcomes. A team needs answers to four connected questions:

• Outcome: What is the product optimizing for?
• Path: How is the user supposed to reach it?
• Obstacles: What prevents the user from getting there?
• Discovery: How does the product show the user what is possible?

These questions tie capability selection to an actual experience rather than a feature inventory.

Answering them requires sustained use. Martin distinguishes testing a product from living with it: the latter exposes whether its capabilities matter inside a real routine. If the builder is not the intended user, the work includes inhabiting that user’s circumstances. This is how a team develops judgment about the boundary between what the technology can do and what people are prepared to adopt.

Delight demonstrates what a product can do. Judgment determines what it should do. Martin admits repeatedly making the kitchen-sink mistake herself: collecting model capabilities, adding some visual personality, and mistaking the collection for a point of view. Research previews can usefully reveal new capabilities. But a user looking at another broad capability bundle may reasonably prefer to use ChatGPT. Adding everything to see what sticks does not establish a distinct reason for the product to exist.

Her decision criterion is whether the product respects the user’s time, data, and agency. Restraint becomes an innovation multiplier because it concentrates effort on an outcome that can become excellent. When someone asks how such a simple product can compete, focus is the answer: do one thing sufficiently well that users begin to experience the difference. Working deeply on that one thing also improves the team’s intuition about where useful surprise becomes possible.

Consider trying a new product that does 30 things without making clear when you would use it. The number of capabilities does not resolve the uncertainty; it can create it. Martin traces that lack of focus back through the layers: unclear personal intent leads to unclear product direction, which makes it difficult to choose useful model capabilities. She encountered this in her own work on Huxe, whose early prototype combined chat, podcasts, news, image generation, and video generation. She initially found it beautiful and exciting—her dream product.

Daily use changed her assessment. She found herself using only one thing. Martin reports that several hundred people tried Huxe and likewise used only one thing in the product. Her account does not identify that feature or specify the observation period. The lesson is the gap between the breadth that excited the builder and the narrow role the product occupied in use.

Her comparison is Spotify: it may offer many capabilities, but her reason to open it is to play music. Huxe even had deliberately goofy chat to distinguish its tone from ChatGPT, yet that personality did not resolve the lack of focus. The three-screen montage shows content cards, messaging, and audio playback, including a player titled Fighting Pests With Sterile Flies. Looking back at the broad interface, Martin recognized her own version of AI demo disease: something that looked impressive without giving people a sufficiently clear reason to love it.

The principles form a dependency chain. Clarity supplies the energy for difficult work. Purpose directs that energy toward a specific outcome. Delivering on that purpose earns trust and user belief; belief creates permission to introduce delight, which reveals further potential. The kitchen-sink check keeps the chain honest by asking whether each capability still serves those commitments. Building something that is not ugly, in this sense, means making the product’s intent, behavior, and place in the user’s life fit together.