Product Management in the AI Era: Why Storytelling and Judgment Outweigh Feature Specs

Product Management in the AI Era: Why Storytelling and Judgment Outweigh Feature Specs Former LinkedIn and Twitter product leader argues that despite AI drastically lowering the cost of prototyping and building software, the foundational role of product management remains unchanged: crafting a repeatable narrative, exercising product judgment, and guiding users toward core value. The primary artifact of a product manager is not a specification document, but a repeatable story that aligns the team and defines why a product matters to users. AI dramatically reduces the cost of building and prototyping, flipping the traditional software development loop from 'spec-and-scope' to 'build-and-play'. Lower development friction risks producing 'AI slop' if teams substitute speed for judgment, as closing the gap between a demo and a working product still requires curation and impact debates. True user engagement must be measured by core actions aligned with the product's fundamental purpose and cycle frequency, rather than vanity metrics. Onboarding serves as the most critical storytelling touchpoint, where multi-step, discrete explanations convert curious, middle-ground users more effectively than blank input boxes. The True Artifact of Product Management Reflecting on an early career interview with LinkedIn's Reid Hoffman and writing a 120-page specification during the waterfall era, the author concludes that specs merely outline system mechanics. The actual job is establishing a shared, easily communicable story explaining who the users are, the role the product plays in their lives, and why it matters. A product manager functions not as an authoritative commander, but as a facilitator who helps the team and company deliver the right product to users. Inverting the Development Loop with AI Historically, engineering constraints necessitated elaborate upfront scoping, drafting of specs, and internal debates to protect scarce developer bandwidth. With AI code generation, the loop has inverted: teams can now rapidly instantiate an idea, interact directly with a working prototype, and then formulate the UX and engineering design. While this eliminates the deliverable status of lengthy specs, it introduces the danger of cramming excessive, uncurated features into products, demanding heightened product taste and discernment over mere schedule management. Measuring Real Usage Beyond Vanity Metrics Product vision breaks down into three components: purpose, core actions, and cycle frequency. Rather than relying on aggregate figures like downloads, DAU/MAU ratios, or token counts, product managers must track whether users independently arrive via direct traffic and perform core tasks. For example, LinkedIn focused on profile maintenance even if interaction occurred only once or twice a year, acknowledging that regular usage aligns with the specific purpose of the platform rather than forced daily engagement. Onboarding as the Primary Narrative Vehicle Because users will never grant as much attention again, onboarding is the decisive moment to establish product understanding. While eager users navigate friction naturally and uninterested visitors churn immediately, onboarding design must convert the curious middle segment. Instead of overwhelming users with minimalist open prompts or blank AI input boxes, testing reveals that structured, simple, sequential steps explaining key concepts one by one yield superior long-term retention, as demonstrated by Twitter's historical transition to its concept-focused 'Learn Flow'.

产品经理的核心依然是讲故事：AI 时代的产品管理与判断力 作者结合在 RealPlayer、LinkedIn 及 Twitter 的经历指出，AI 极大降低了工程实现与原型制作成本，但产品经理的核心产出并非规格说明书，而是向用户传达清晰的故事，并在丰富选择中保持判断力与产品把控。 产品经理最重要的产出不是规格说明书（spec），而是清晰、可复述的产品故事与共同理解。 AI 将传统研发流程从“先写文档再开发”倒置为“先低成本生成原型再设计”，但原型距离可用产品仍有差距。 衡量产品成功的标准不是表面数据，而是用户是否在合理周期内真正执行了核心操作（Core Actions）。 新用户引导（Onboarding）是讲好故事的最关键阶段，通过细分、清晰的步骤引导中间层用户比极简空白界面更有效。 产品经理的核心交付物是“故事”而非规格文档 作者回顾向 Reid Hoffman 面试时将“规格说明书（spec）”视为产品经理产出物的经历，指出这一认知并不准确。规格书仅定义了系统与要求，而产品管理的本质是讲述使用者为何需要该产品、它如何改变生活的故事，并让团队与外界达成可复述的共识。 AI 颠覆研发循环：从先写文档到先做原型 以往为了保护昂贵的工程时间，团队需要前期严密的论证与规格设计。AI 使得构建原型的边际成本大幅下降，研发流程变为先快速做出原型体验、再展开设计并交付。然而，演示原型不等于可用产品，功能堆砌容易带来“产品垃圾（product slop）”，决定“不做什么”的业务判断力反而更加关键。 以“核心操作”与生命周期衡量真实使用 注册量和活跃比率等浅层指标不能代表用户真的在用产品。作者提出“目标、核心操作、频次周期”框架，例如早期 LinkedIn 用户可能一年仅被检索一两次，但只要完成核心操作即算成功。对于 AI 产品，团队更应直接审阅用户的输入记录以发现断点，而非全权交由算法总结。 新用户引导是转化中间层用户的关键时刻 用户群体中存在少数高度积极者与浅尝辄止者，大量处在中间地带的潜在核心用户需要被引导。AI 常见的空白输入框往往让用户无所适从。作者以 Twitter 早期重构“学习流程（Learn Flow）”为例，通过逐步展示推文、关注与时间线概念，证明更多单一步骤教学能显著提升次日留存与核心行为。

[America](https://www.a16z.news/t/america) | [Tech](https://www.a16z.news/t/technology) | [Opinion](https://www.a16z.news/t/opinion) | [Culture](https://www.a16z.news/t/culture) | [Charts](https://www.a16z.news/t/charts) Product management is all about telling stories. So let me share how *I* think about product management, and how AI has changed it, by telling you one. I started my career as an engineer at RealNetworks, and in a few years I was responsible for the product and engineering team for RealPlayer. It was a pretty meaningful consumer product at the time - it had hundreds of millions of users, and helped bring audio and video to the early internet. I’d sit in meetings with people over on the business side, who’d suggest ideas like, “We should show an ad every time the player starts.” I knew this wasn’t the right thing to do, but I had no way to argue with their Excel spreadsheets showing how much money we’d make. I wanted to become a *real* product manager, and concluded I should probably go to business school. I started business school at Berkeley, and soon after arriving I saw on my former college email list that LinkedIn was hiring. I applied, and found myself in an interview with Reid Hoffman. He sat down and asked me an interview question I’ll never forget: “So, you want to be a product manager. What is the artifact that a product manager produces?” He elaborated. Engineers have an artifact: code. Business development has an artifact: signed contracts. Designers make the visual look and the graphics. The CEO has the org chart, the funding plan, and the vision that keeps everyone together. What about a product manager? I told him that I wasn’t sure product managers really had “artifacts” like that, but that the fundamental thing we do is gather up everything that’s going on and write it down in a *spec*. The spec is the blueprint. It’s where we define the requirements, and everything we’re going to do, and it becomes one of the most important documents in the company because it unlocks every team to go build from there. I was clearly nervous. I think he noticed, because he reassured me that it was a fine answer. I ended up getting the job, dropped out of business school to join LinkedIn, and I’ve been thinking about that question ever since. Because I *gave the wrong answer*. This was still the Waterfall Era of building software. At LinkedIn we were trying to reimagine a jobs platform within a social platform - where hiring managers could see job applications in the context of mutual connections, candidates could see job listings and find ways through their network to get to the front door. During this discovery process, I wrote a 120-page spec defining the entire experience, and what the requirements were. I’ve thought a lot about it in the years since. Because that spec, obviously, is not the most important artifact. The *story* is. The spec describes a system, what it must do, and what boxes must be checked off before it is done. *That is not the art of product management.* Product management is about telling the story of people who are going to use the product, and why it will matter in their lives. It has to be immediately understandable, by whoever you’re talking to. And it has to be *repeatable* - people need to be able to pass it around faithfully, without you being in the room. That is a completely different document, and a completely different job. Ten years ago I gave a talk about product management, and people *still* send it to me; which is either flattering, or a sign that the field hasn’t moved. I’ll consider both possibilities. Anyway, the whole talk came down to one sentence: “**A product manager helps their team (and company) ship the right product to their users.”** I spent most of the talk breaking down that sentence, word by word. *Helps their team.* You’re not the leader. A lot of people think the product manager is the leader. You’re the person who *helps* make the thing happen. Which means you must … Understand your *team* and your *company.* Your team is your domain: you have to understand it! And you have to understand how it sits inside the bigger picture, so you can serve the company’s goals and not just yours. *Ship*. We can talk all we want, but at the end of the day, all that matters is putting the product in front of customers. *The right product for your users*. We’ve finally arrived at the job: honing in on what “right” actually means. How much of that changes in a world of AI? Obviously *something* has changed, a few things actually. On the one hand, it’s changing how we code, and how fast we can get from an idea to something running. On the other hand, it’s changing what users expect a product to *be*. I think we’ve barely tapped this, especially in consumer. Being able to describe what you need and have the product deliver it, maybe with agents running in the background, without you having to learn and interface. There’s no question that the cost of *making stuff* has collapsed. It’s no longer all that difficult to scope something out and try it; that gives you enormous flexibility. But the cost of *judgment* hasn’t changed at all. Figuring out what to build is more important now than ever. Product development is a loop. It used to be that someone had an idea - and it doesn’t have to be you; in a good company it can come from anywhere. You try it. You write a spec, or a product brief, or whatever your name for that document is. There’s some up front cost to it: scoping, designing, arguing - everything that must happen before you spend precious engineering time. These are all rituals that we invented in order to protect engineering time from bad decisions. Because you only got six or eight turns around that loop a year. Then making things became *absurdly* cheap. Not somewhat cheaper; a different order of magnitude. And what has happened is really interesting. That old loop is still very much there - just rearranged into a new order. The old loop went: idea, spec, costing, scoping, everything else, *then* building. *Now:* First, take the idea and you build it quickly with AI, just to see how it works and how it feels. You get to play with it, and figure out how it feels and fits into the overall picture. Prototypes beat “what-ifs”, every time. *Then* you design it. Now that you’ve played with it, you know what it *is*, and you can actually talk about what it’ll take for this to be more than a prototype. I mean design here in both senses: visual and UX design, and also engineering design. Then you ship and learn. It completely inverts: from spec-and-scope, to build-and-play. **I think that changes product management more than anything else happening right now.** This finally means that **the spec is no longer the deliverable; for real.** You don’t have to start by writing a long document and getting everything right on paper. This used to be true in an aspirational sense, but now it’s just obviously true, in a literal sense. But I want to be careful, because there’s an equal and opposite mistake you can make. Demos are almost free now. **Working products are not.** I keep seeing the flip side of this new approach: “That’s great, just ship it.” That’s still not how it works. We all still have to respect that *the distance from a prototype to something real still takes time to cross.* There’s a bit of a trope about product managers, that their job is mostly about asking, “Does it fit in the schedule?” Throw that idea away entirely. The most important question is: *Does it fit in the product?* We all have great ideas, and now we all have agents that can code for us. Deciding what to build is officially not a resourcing debate. It is an *impact* debate. “This or that”, not “this or nothing.” Taste and curation matter a lot here, when you have a vision and you really know what you’re trying to do for the world. But the system you build still has to feel complete. My biggest worry about AI is that it lets us go faster, and therefore just cram everything in. We talk about “AI slop” in content; this is what AI slop means for product. I’ve seen it happen in a few places already, and I think we’re all a bit worried about it. When anyone can build anything, *deciding what to build is the whole job.* And that’s a story problem. What story do you want to tell? What story do you want your customers to understand? What story do you want living in their heads? Your job as a PM is not to write a spec of what the product will do. It is about creating a shared *understanding* - a shared picture of what we’re doing and why. Why is the user here? What do they feel at each step, and why does that matter? Where is it impressive, and where is it boring? It’s okay for a product to be boring occasionally, as long as you know where. But if you can’t write a good script, the product is going to be dull. The gift that AI gives you is now you can find this out for free, right up front. You can build it quickly, get a feel for it, play with it, and figure out that one sentence: **what does this product do for somebody in their life?** Because if you can answer that, you can answer my question: “Are people actually using it?” Because now you’ve said what it does, and you’re asking whether they do it. What does it mean to have a “vision” for your product? When I say vision, I don’t mean a mission statement. Those matter, but they are not a vision. A vision is the end-to-end **reason for the product to exist for users**. I have a simple framework for this: Purpose. Why is someone picking up your product and putting it in their life? Core actions. When they pick it up, what are they actually doing? There can be more than one thing, you have to understand them all. Cycle. What is the expected frequency of each of those core actions? My whole career, as I’ve met with founders and other product people, I ask them: ***are people using your product?*** And they almost always jump straight to user data. “We have a 50% DAU/MAU ratio. We crossed 10,000 signups. We’ve got a million people on the waitlist. Our ARR is a million. We’re doing four billion tokens a day. We hit #3 on the App Store.” Are any of those an answer to the question I asked? Sometimes I ask the question again, but I add one more word: **are people really using your product?** And then, sometimes, they clue into what I’m asking about. LinkedIn’s purpose was to *find* and *be found*. Maybe the core action, for some people, was just responding when somebody reached out. For most people that’s not a daily thing; it might be once or twice a year. Look at that cycle - once or twice a *year*. Understanding this was critical to LinkedIn working, because the network needed a very large number of people willing to be found, and at least some people doing the finding. LinkedIn was a social network, after all, so you might be tempted to prod users into taking actions every day. We didn’t do that. Instead, we spent enormous time in the early days on making sure people kept their profiles accurate. It was completely fine if you were only found once or twice a year, as long as when it *did* happen, you clicked through and understood, “someone’s reaching out to me, that’s great.” When you’re measuring whether your product is working, those core actions are what matters. Focus on direct traffic: find the people who *literally came to you*. They have the app installed and hit the icon, or they typed your domain in by hand; they went *to you,* of their own volition. That’s the traffic that matters, as opposed to all of the other ways you can get somebody back in the moment. And then only really count the people who perform the core actions. Not “briefly opened the app”, but actually engaged with it. On Discord it would be, “got into a live session. Actually read and sent messages.” If you can’t define what those core actions are, then *you do not have a product*, because you don’t have something that you understand. Now, one thing that’s new, and that I love, is that in AI products where the user is talking to the product, or prompting it in some way, you now have a literal transcript of your user journey. You can see what people are saying in their own words. You can see the exact moment someone gave up and rephrased. You can see what they expected the product to do that it didn’t. READ THESE! AI is great for surfacing things you wouldn’t have seen before, but you can’t have it summarize everything, and you can’t have it form your opinion for you. Forming your opinion - figuring out what the story actually is - is the job and the art of product management. Onboarding is the single most important moment you have to tell your story to a customer. They’ve discovered your product - maybe through an ad, a viral invite, an article, whatever. They know you exist; they’re curious and want to try it. **You will never get this much attention from them ever again.** You have to remember, at this point, that not everyone shows up to your product with the same motivation. There are the **eagers**. They want in *so badly*. They’re ready to go. And, just so we’re clear, if you work at the company, you live in eager-land. Everyone internal to your company should be treated like an eager; they’re already steeped in the product every day. When they onboard to the product they think, “I know what I’m doing, this is boring, why is this step here?” On the other hand there are the **fly-bys.** They’re just not that into you. They heard about it, checked it out, but the message didn’t land, and they’re going to bail. Those two kinds of users are the edges of the distribution. In between is a big fuzzy middle. These are people who showed up for a reason: they’re curious! They want to learn more! And you genuinely can convert them into core users of your product. These are the people you need to build around. You’ll get the eagers anyway. The middle is who you need to understand. Assume your users are motivated and curious. Take the time to introduce the product, step by step. **More simple steps beat fewer complex ones.** I’ve proven this in A/B tests at multiple companies over the years. If every step is discrete and simple, and it’s clear what you’re asking and what you’re teaching, that beats single large screens, or complex choices to keep the number of steps low. Every time. So how do you actually build that? Start by repeating the core message: **Here’s what this is for.** State the context, inside the product. It’s fine to ask for the basics - email, password, phone. For everything else, explain why you’re asking, and how it relates. Then break your product down into its key concepts, each with a clear action for the user to take. **AI products have made this harder, not easier.** You get the blank prompt box. In some ways it’s the worst onboarding screen ever designed. It’s a magic box. It can do anything. So… what do you want to do? A lot of products nowadays start with, “Hi, I’m here to help, ask me anything!” Speaking for myself, I am not the most articulate or creative person, in that moment. You have to teach capabilities concept by concept. “If you ask something like this, I can do it.” And then let the product do it. Get the user to at least one valuable use case quickly, ideally with their own data, so it’s actually valuable to them. People ask me sometimes: with a longer flow, won’t more people drop off? *Yes!* But the ones who get through are far, far more likely to actually use your product. If you’re A/B testing two different onboarding flows, do NOT look at how many people made it to the end of the flow. Look at how many people come back the next day, or the next week, and how many took a core action. If you ask them, at that moment, “What is this product?” they should give you more or less the right answer. Your retention data, from this point forward, is your report card. I’m going to wrap all of this together by telling you a story from Twitter. I joined Twitter in late 2009. We had a growth problem - except it wasn’t really a growth problem. Twitter was in the news constantly. People were blogging about it, the media was talking about it, and plenty of people were asking: “What is this Twitter thing? I need to go figure it out and sign up.” And then millions of them did. But they never came back. **The problem was that no one could tell you what Twitter was.** I can actually prove this: *Caption: “we eventually got to number one.”* The way we were doing onboarding was, people would sign up, and see options to “Find your friends” or “Follow 20 random people”. Most people skipped it, and then landed on a page that looked like this: This is pretty terrible! It’s a big empty box. People would look at it and think, “...I don’t have anything to say.” And then they’d leave. If you asked them at that moment, “What is Twitter?” they’d say, “I think it’s about saying something to the world? Or finding my friends? I don’t know.” So we rebuilt onboarding over a couple of years, and found the thing that worked, which was the Learn Flow. We taught them Twitter, one concept at a time, as a story. And it moved retention more than anything else we shipped that year. First, the new home page: “Welcome to Twitter.” We didn’t try to put content there, just: “Find out what’s happening right now with the people and organizations you care about.” That’s a pretty good description of Twitter, honestly. Then: This is a tweet. It’s a short message, up to 140 characters, and it can contain links. Now you know that tweets are the unit of this thing. Next you have to build your timeline. So we showed you a timeline. We made you click “follow” on people on the left. And when they click follow, their tweets appeared on the right. So you get the whole idea, in one motion: *I click follow, tweets show up, that’s my timeline.* Which is the actual concept of Twitter - tweets, following, and a timeline. And then, finally, your timeline. You’d recognize every account on it, because you had actually followed them yourself. Onboarding is your story. Your job as a product manager is to help your team and your company ship the right product to your users. In a world of AI, the shipping is less of the problem than it used to be. Figuring out the *right* product, and who your users are, is just as important as it has ever been. If not more. Always ask whether people are really using your product. Understand what that means. Think about the purpose, the core actions, the cycle. Spend more time on onboarding than feels reasonable. It’s where you convert the fuzzy middle, and it’s where you actually tell the story of your product. Use AI to go faster on the prototypes — but don’t speed up your judgment. Don’t give up your judgment. Don’t just say, “Well, let’s test it and see.” That’s how you end up with a sloppy product. Keep your judgment everywhere. The hardest part of the job is still balancing all of our creativity as product managers against all the data we now have access to. Good luck! *This newsletter is provided for informational purposes only, and should not be relied upon as legal, business, investment, or tax advice. Furthermore, this content is not investment advice, nor is it intended for use by any investors or prospective investors in any a16z funds. This newsletter may link to other websites or contain other information obtained from third-party sources - a16z has not independently verified nor makes any representations about the current or enduring accuracy of such information. If this content includes third-party advertisements, a16z has not reviewed such advertisements and does not endorse any advertising content or related companies contained therein. Any investments or portfolio companies mentioned, referred to, or described are not representative of all investments in vehicles managed by a16z; visit [https://a16z.com/investment-list/](https://a16z.com/investment-list/) for a full list of investments. Other important information can be found at [a16z.com/disclosures](http://a16z.com/disclosures). You’re receiving this newsletter since you opted in earlier; if you would like to opt out of future newsletters you may unsubscribe immediately.*