When AI Can Write Code and Build Products on Its Own, What Is Left for Product Managers?

With the widespread adoption of large models and AI-assisted programming tools, the barrier to developing software prototypes has plummeted. Engineers can use natural language to rapidly generate runnable interfaces and logic, leading many to wonder: if code generation has become so cheap, is the traditional product manager (PM) losing their reason to exist?

Josh Elman of a16z offers the exact opposite view. His core observation is crystal clear: the cost of building code has indeed fallen drastically, but the cost of making the right product judgment has not decreased by a single cent.

This is not an abstract assessment. Early in his career at RealNetworks, when Josh led the product and engineering teams for RealPlayer, the business team suggested displaying an advertisement every time the player launched, presenting an Excel spreadsheet showing how much money it could make. He knew this would hurt the product, yet he couldn't articulate how to counter financial projections with product judgment.

Later, during an interview at LinkedIn, Reid Hoffman asked him: "What is the artifact of a product manager?" At the time, Josh answered that it was the product specification (spec). After joining LinkedIn, he even wrote a 120-page spec for "a recruiting platform inside a social network," exhaustively defining experiences and requirements.

Yet a spec can only describe what a system is supposed to do and which checkboxes to tick when it is done. Years later, Josh realized that a PM's true artifact is a "story": who is using the product, and why it impacts their lives. This story is not marketing copy, but a shared mental picture across the team; anyone should be able to understand it immediately and retell it accurately when the PM is not in the room. It must also answer why users come, how they feel at every step, where they should be delighted, and where things can intentionally remain understated.

This brings us to the author's core definition of a product manager: helping the team (and the company) ship the right product to users. A PM is not a leader standing above the team; rather, they must understand their team and its place within the company's broader goals, assist the team in actually shipping the product, and continuously judge what is truly "right" for users.

When building things becomes extraordinarily easy, the greatest danger a team faces is no longer the inability to build features, but churning out mediocre features at blistering speed—features nobody needs, whose logic is broken, and which users abandon immediately. Exploring product work in the AI era hinges on understanding the inversion of the development cycle and learning how to establish a decision-making framework genuinely centered on user value.

The Inversion of the Development Cycle: From Lengthy Deduction to Prototype-First

In traditional software development, engineering time was extremely expensive. To avoid committing costly engineering resources in the wrong direction, teams had to invest heavy effort upfront into writing feature specifications (specs), estimating costs (costing), scoping requirements (scoping), and completing designs (design) before writing any real code. Under this rigorous upfront deduction, a team could typically run only six to eight complete development cycles a year.

With the introduction of AI coding tools, this development cycle has undergone a fundamental inversion: from paper-based deductions to Idea → Build with AI first → Play with it → Visual/UX & engineering design → Ship → Learn.

A working, interactive prototype makes intuitive judgment far easier than verbal or documented what-if hypotheses ever could. You can experience it firsthand, feel the friction in interactions, and validate early on whether an idea holds up.

On the other side of this inverted development cycle, AI is also shifting user expectations around product paradigms: users are beginning to expect that simply describing what they need will yield results—or even that background agents will do the work—without having to learn complex interfaces first. Yet this does not mean all products have already achieved this form.

However, one must clearly recognize the boundary of reality: a demo being virtually free does not mean a working product is free. Piecing together a prototype in minutes with tools is worlds apart from polishing it into a stable, secure, and scalable real product—a gap that still requires rigorous engineering and substantial time and effort.

Verifying Real Usage: The Vision Framework and Conversation Logs

Once the friction of prototyping is removed, product managers need all the more clarity in judging: are users truly using the product? The author introduces a clear Vision framework. Here, Vision is not a slogan-like mission statement, but the product's end-to-end raison d'être for users. This framework comprises three core dimensions:

• Purpose: Why the product exists in the first place, and what core problem it solves. For example, LinkedIn's fundamental purpose is to "find and be found."
• Core actions: What users actually do within the product. Taking LinkedIn as an example, some users merely respond to incoming inquiries; instead of forcing every user to interact daily, the team invested heavily in ensuring profiles remained accurate. Even if someone is found only once or twice a year, as long as the value holds at that moment, the product is still working—and that still qualifies as real usage.
• Cycle: The expected cadence or frequency with which each core action occurs.

The author underscores that "whether users are truly using it" can never be substituted with surface metrics like registered users, waitlist numbers, ARR, tokens consumed, or App Store rankings. Treating a user briefly opening an app as usage is meaningless; what the team must observe is whether people who intentionally arrive at the product actually carry out the core actions all the way through.

In AI products, the window for verifying this real usage has become far more direct: conversation logs between users and the product serve directly as a verbatim transcript of the user journey. Rather than an abstract statistical report, they faithfully capture:

• What users spontaneously say when unprompted: What needs they first attempt to express without any guidance;
• Where users give up and try rephrasing: Where they hit friction and how they restate their needs;
• What users expect the product to do that it fails to deliver: Which unmet expectations expose the gap between product capabilities and user expectations.

Only by understanding the essence of real usage and the user journey can a team accurately diagnose where a product has detached from users' real lives when anomalies appear in data.

Twitter's Retention Crisis: Throwing Users into an Empty Room Tells No Story

How can correcting a product narrative rescue core metrics? An authentic crisis experienced by early Twitter during a period of explosive growth provides a compelling case study.

Before diving into the specific case, however, one must first clarify whom onboarding is truly meant to serve. At opposite ends of the user spectrum lie two extreme cohorts: on one end are the "eagers," who arrive with intense intent and will figure out how to use the product no matter how clunky the onboarding or how difficult the interface; on the other end are the "fly-bys," who drop in purely by accident and are unlikely to stick around regardless of guidance. What onboarding can actually convert is the middle group—those who arrive with curiosity to explore value. A fatal blind spot is that company employees all live in "eager-land"—they are already intimately familiar with the product's core value and internal logic, and therefore can never represent the real perspective of a new user.

For these curious users, how should onboarding actually be designed? The author points out that onboarding is the moment of peak user attention for storytelling: the user already knows the product exists and is willing to give it a shot—a level of focused attention hard to regain later. Therefore, if you ask users for anything beyond baseline information like email, password, or phone number, the team should explicitly explain why you are asking and how it relates to the value they will receive. Building on this, drawing on his experience running A/B tests across multiple companies, the author presents an empirical assertion (the source material does not provide specific experimental data; this is the author's experiential conclusion): compared to fewer screens packed with dense, complex UI, using more numerous, simple, discrete steps—each with an unmistakably clear goal—often yields better onboarding outcomes. While a longer flow inevitably causes more drop-offs midway through, teams should never judge success by completion rate alone. The true measure of efficacy is how many users voluntarily return the next day or the next week to complete the core actions, and whether they can accurately explain to others what the product actually is.

This insight is especially poignant for today's AI products. Many AI applications are accustomed to presenting a blank prompt box upon first entry, accompanied by "Ask me anything"—which essentially abdicates the responsibility of explaining product capabilities entirely to the user. Faced with an empty input box, curious new users often fall into confusion and analysis paralysis. Effective onboarding should teach specific capabilities one by one, guiding users to personally complete at least one valuable use case—ideally grounded in their own real data—so they can tangibly feel the boundaries of capability and the value delivered.

This was precisely the retention predicament Josh Elman faced when joining Twitter in late 2009. At the time, massive mainstream media coverage and celebrity endorsements brought in millions of sign-ups, but many new users never returned. The crux of the problem was fundamental: people couldn't explain what Twitter actually was.

In Google's search auto-suggestions at the time, typing "i don't get..." would bring up "i don't get twitter." This historical screenshot vividly documents the public's comprehension gap, demonstrating that users could not articulate what the product was, rather than being a search interface seen after registration.

In the legacy onboarding flow, after registering, the system offered options like "Find your friends" or "Follow 20 random people." Many new users simply skipped them, only to land on an entirely blank home feed. Confronted with a "What's happening?" prompt box, seeing zero updates, and not knowing what to say themselves, they left bewildered.

To straighten out the product narrative, the team rebuilt the onboarding experience into what was called the "Learn Flow," guiding users to understand the product step-by-step through a natural cognitive progression:

Step 1: Clarify the product promise. The welcome screen stated upfront: "Find out what's happening right now with the people and organizations you care about," calibrating expectations on the very first screen and clarifying the product's fundamental value.

Step 2: Understand the product's basic unit. The screen broke down what a tweet was, clearly explaining that it is a short update of up to 140 characters that can contain links, helping new users intuitively grasp the fundamental unit of content.

Step 3: Complete the timeline mechanism with a single action. The onboarding screen displayed a two-column timeline interface: when a user clicked Follow on an account on the left, that account's tweets appeared instantly on the right in real time. Through this single coherent action, the user understood on the spot the core logic: "Follow an account → that account's tweets appear → they aggregate into my timeline." When onboarding concluded, the home feed the user entered was no longer an empty, unfinished room, but a timeline already populated by the people they had just followed.

The author explicitly notes that this Learn Flow improved user retention more than any other project shipped at Twitter that year. It focused squarely on aligning user mental models: through a sequence of steps with clear goals, it helped curious users understand the product promise, grasp basic concepts, and personally complete a value loop with their own hands.

Reading Users' Verbatim Words Yourself: AI Spots Patterns, but Judgment Cannot Be Outsourced

As noted earlier in the discussion of real usage, one of the greatest differences between AI products and traditional software is that the interaction logs between users and the system directly constitute a verbatim transcript of the user journey (just as in the conversation transcription framework cited earlier). Every single word a user says to the product during an interaction directly reflects their unvarnished, authentic intent.

Across these verbatim records, the team can directly observe three critical facets: what needs users spontaneously express first when unguided, at which points they hit obstacles and choose to give up and rephrase, and where the gap lies between what users eagerly expect the product to do and what the system fails to satisfy. The prerequisite for understanding these genuine experiences is that the product manager and the team must personally read the users' original words, rather than observing them only through the veil of highly abstracted data metrics.

In this process, AI can help the team surface phenomena they hadn't noticed before. But the team must never outsource all conversations to AI-generated summaries, let alone allow AI to form opinions on behalf of the product manager.

Personally reading these raw expressions, forming one's own judgment, and deciding what story truly lies behind the product remains the indispensable craft and responsibility of product management.

Trade-Offs for Impact: Guarding the Whole Product in an Era of Code Abundance

When everyone has great ideas and everyone has code-writing agents at their side, the center of gravity in discussing "what to build" shifts fundamentally: it is no longer primarily a dispute over engineering resources and scheduling, but an impact trade-off of priorities—the nature of decision-making shifts from "this or nothing" in an era of resource scarcity to "this or that." Teams must abandon the reflex of asking "can we fit it into the schedule?" and instead ask first, "does this belong in this product?"

When the barrier to building features drops to near zero, the greatest risk facing a product is degenerating into AI slop: cramming every conceivable feature, interface, and interaction into the product simply because it is technically easy and code is readily available, resulting in a bloated, fragmented overall experience. Amid an oversupply of features, product taste, rigorous curation of functionality, and a holistic grasp of a clean, cohesive, and complete product become more critical than ever before.

This demands that product teams stay clear-headed in their operating rhythm: we can use AI to dramatically accelerate prototyping, but we must never accelerate past judgment, let alone abandon judgment altogether.

When facing divergence in direction, product managers cannot simply say "let's test it and see" and abdicate the responsibility of decision-making to experimental data. Product managers must still maintain a balance between creativity and data, and form their own judgment on trade-offs.

While AI has drastically lowered the friction of building prototypes, this by no means suggests it has eliminated all engineering labor; taking a demo and turning it into a truly working product still takes time, engineering investment, and product refinement.

As Josh Elman emphasizes, the core mission of the product manager has never wavered: helping the team (and the company) ship the genuinely right product to users. As writing code becomes increasingly cheap, the judgment to resist the temptation of building everything, to make clear trade-offs amidst endless possibilities, and to guard the right story for the team is the single most scarce asset that determines whether a product lives or dies.