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.
The interview question I’ll never forget
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.
The evolution from spec to story
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?
What is changing
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 isn’t changing
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
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.
A story from Twitter
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:
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.
The Learn Flow, screen by screen
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.
The right product for your users
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!
