The Spec Is Dead. The Story Isn't.
Notes from Josh Elman's essay on product management in the AI era — on why the job was never about the document
I've been thinking about what a product manager actually produces.
Not what they're responsible for. Not what they're blamed for when a launch slips. What they make — the artifact, the thing you could hold in your hand and say "this is the output of that role."
Engineers have code. Designers have the visual. Biz dev has signed contracts. The CEO has the org chart and the funding plan.
A PM has... a spec? A roadmap? A Jira board?
I read Josh Elman's essay this week and it reframed the whole question. Elman was early at LinkedIn, Twitter, and Robinhood. He's seen the job from the inside at three companies that shaped how we use the internet. And his answer to "what does a PM produce" has changed completely — twice.
Here's what I took from it.
The interview question that started it
Reid Hoffman asked Elman this in a LinkedIn interview, years ago:
"You want to be a product manager. What is the artifact that a product manager produces?"
Elman's answer: the spec. The blueprint. The document that defines requirements and unlocks every team to build.
He was wrong.
Not wrong in the sense that specs don't exist. Wrong in the sense that the spec was never the point. It was a ritual — a way to protect engineering time from bad decisions when you only got six or eight turns around the loop per year. Waterfall-era thinking. Necessary at the time. Not the actual output.
The actual output is the story.
"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's a completely different document. And it changes what the job is.
What AI actually changed
Everyone talks about how AI collapses the cost of building. Elman agrees — the cost of making stuff has dropped by an order of magnitude. What hasn't changed:
"The cost of judgment hasn't changed at all. Figuring out what to build is more important now than ever."
The loop used to go: idea → spec → scoping → costing → build. Now it goes: idea → build quickly with AI → play with it → then design → ship and learn.
Build-and-play replaced spec-and-scope.
Which means the spec is no longer the deliverable. For real this time. Not aspirational. Literal.
But here's the trap Elman names that I haven't seen articulated this cleanly elsewhere:
"Demos are almost free now. Working products are not." "The distance from a prototype to something real still takes time to cross."
And the bigger risk — AI slop for products. When anyone can build anything, the temptation is to just cram everything in. Add features because you can, not because they serve the story.
"When anyone can build anything, deciding what to build is the whole job. And that's a story problem."
The question underneath the question
Elman has a question he asks every founder and PM he meets:
"Are people really using your product?"
And the responses he gets are almost always metrics. DAU/MAU ratio. Signups. Waitlist size. ARR. Tokens per day. App Store rank.
None of those answer the question.
What he's actually asking about is the vision — not the mission statement, but the reason the product exists for users. He breaks it into three parts:
- 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?
- Cycle. What's the expected frequency of each of those actions?
LinkedIn's purpose was find and be found. The core action, for most people, was responding when someone reached out. Cycle: once or twice a year.
That frequency understanding was load-bearing. LinkedIn is a social network — the instinct would be to drive daily engagement. Instead they spent enormous effort keeping profiles accurate, because the value was in the once-a-year moment when someone did reach out, and it needed to land.
"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."
Onboarding is the whole game
This is the section I keep returning to.
Elman's framing: onboarding is the single most important moment you have to tell your story. You will never get this much attention from the user again.
And the mistake most teams make is designing for the wrong user. There are three groups:
- The eagers. They want in badly. They'll figure it out. If you work at the company, you live in eager-land — you're steeped in the product and every onboarding step feels obvious and boring.
- The fly-bys. Not that into you. Heard about it, checked it out, the message didn't land, they're gone.
- The fuzzy middle. Showed up for a reason. Curious. Convertible.
You get the eagers anyway. The fly-bys were never going to convert. The middle is who you build for.
And the counterintuitive finding from A/B tests across multiple companies:
"More simple steps beat fewer complex ones. Every time."
Discrete, clear steps — each teaching one concept, each with a clear action — beat single large screens or complex choices made to minimize step count.
AI products have made this harder, not easier. The blank prompt box is, in Elman's words, "the worst onboarding screen ever designed." It's a magic box that can do anything. So... what do you want to do?
The fix is teaching capabilities concept by concept. "If you ask something like this, I can do it." Then let the product do it. Get to one valuable use case fast, ideally with the user's own data.
And when you test onboarding flows: don't measure how many people finish the flow. Measure how many come back the next day. Measure core actions. Ask them at the end, "What is this product?" — they should give you roughly the right answer.
"Your retention data, from this point forward, is your report card."
The Twitter story
The whole essay lands with this, and it's worth sitting with.
Twitter in 2009 had a growth problem that wasn't a growth problem. Millions of people were signing up. Almost none came back.
The reason: nobody could tell you what Twitter was.
The onboarding was: "Find your friends" or "Follow 20 random people." Most people skipped it and landed on a big empty text box. They'd stare at it, think "I don't have anything to say," and leave.
If you asked them what Twitter was at that moment, they'd say something vague about "saying something to the world" or "finding my friends." They didn't know.
So Twitter rebuilt onboarding into the Learn Flow — one concept at a time, as a story:
- Welcome to Twitter. "Find out what's happening right now with the people and organizations you care about."
- This is a tweet. Short message, up to 140 characters, can contain links.
- Build your timeline. Show people on the left. Make the user click follow. Their tweets appear on the right. One motion teaches the whole concept: I click follow, tweets show up, that's my timeline.
- Your timeline. Every account is one you chose.
That flow moved retention more than anything else Twitter shipped that year.
"Onboarding is your story."
What I'm taking from this
1. The artifact was never the spec.
It's the shared understanding. The thing that travels without you in the room. AI makes it easier to build, not easier to decide. Judgment is the job.
2. "Are people really using your product?" is the only question that matters.
Not DAU/MAU. Not ARR. Not tokens. Purpose, core actions, cycle. If you can't answer those three, you don't have a product.
3. Onboarding deserves more time than feels reasonable.
It's where the fuzzy middle converts. More simple steps beat fewer complex ones. Retention is the report card, not flow completion.
4. AI makes slop easier. Taste is the defense.
Demos are free. Working products aren't. When anyone can build anything, the constraint moves from can we to should we. That's a story problem, and it's the whole job now.
The line that stuck with me longest:
"Use AI to go faster on the prototypes — but don't speed up your judgment. Don't give up your judgment."
That's the tension. Speed on one axis, patience on the other. The teams that figure out how to hold both will win.
Source: Product Management Is Still All About the Story — Josh Elman, a16z.
If you're thinking about the spec vs. story shift in your own work, I'd like to talk. Let's connect.