Product1 publisher3 min readPublished
Product managers still deliver stories, argues a former LinkedIn PM writing for a16z
An ex-LinkedIn product manager writing for a16z demotes the 120-page spec the author once wrote and names the story as a PM's most important output. AI changes how teams code, the author writes, but the story still has to survive being retold without the PM in the room.
The Product Desk · Product desk
What happened
- An a16z essay by a product leader who came up at LinkedIn argues that product management is still all about telling stories.
- At LinkedIn the author wrote a 120-page spec for a jobs platform built inside a social network, defining the whole experience and its requirements.
- The author now says that spec was not the most important artifact of the job, and that the story about the people using the product is.
- On AI, the author writes that it is changing how teams write code and how fast they can move forward from an idea.
- Ten years ago the author defined the job in one sentence: a product manager helps their team and company ship the right product to their users.
Compiled by The Product DeskSomething wrong?How this is made
Why it matters
- decision Teams that grade product managers by the documents they file are grading the part of the job the author ranks second; the essay's standard is whether colleagues can act on the plan.
- cost A plan that only works when its PM presents it makes that PM a scheduling dependency for every team that has to act on it.
- constraint With one career as evidence and the AI argument unfinished, the essay can shape how a team judges its planning documents but cannot tell it which PM tasks to hand to AI tools.
The meeting that started this argument happened at RealNetworks. The author had gone from engineer to running the product and engineering team for RealPlayer, which had hundreds of millions of users at the time [2][3]. Colleagues on the business side would suggest ideas such as, "We should show an ad every time the player starts" [4]. The author knew it was wrong but "had no way to argue with their Excel spreadsheets showing how much money we'd make" [4].
Anyone who has lost a roadmap review to a revenue model will recognise the position.
The author's first remedy was a better document. After starting business school at Berkeley, the author interviewed at LinkedIn with Reid Hoffman [5]. "So, you want to be a product manager. What is the artifact that a product manager produces?" Hoffman asked [6]. Engineers have code, he explained, and business development has signed contracts [7]. The author answered with the spec, the document that "unlocks every team to go build from there," got the job and left business school [8]. "Because I gave the wrong answer," the author wrote years later [9].
The essay's distinction is exact enough to use. A spec describes a system: what it must do, and which boxes must be checked before it is done [12]. A story is about the people who will use the product and why it will matter in their lives [12]. It has to be understood immediately by whoever hears it. It also has to be repeatable: "people need to be able to pass it around faithfully, without you being in the room" [13].
The author's interview answer assumed that someone writes it all down and every team builds from the document [8]. The essay says a plan instead has to survive colleagues retelling it to each other with the PM absent [13]. The essay also demotes the product manager. "You're not the leader," the author wrote, summarising a talk from ten years ago; the PM is "the person who helps make the thing happen" [15]. People still send the author that talk, "which is either flattering, or a sign that the field hasn't moved" [16].
The AI part of the argument is the thinnest. The author opens it with "Obviously something has changed, a few things actually," and the available text ends mid-sentence, before reaching what AI does to the story [17]. So the evidence covers the building side, plus a title asserting the story still comes first [1][17]. I'd expect faster building to raise the value of the story. A team that can build the wrong thing in days needs to know who it is for before it starts.
A planning document, whether a person wrote it or a tool generated it, can be placed on two axes. The first is whether it names a user and why the product matters in that user's life, or covers only what the system must do. The second is whether someone who was not in the room can repeat it accurately. A document that does both is a story. Naming the user but working only when its author presents it makes it a pitch, and it needs rewriting until a colleague can retell it. Requirements that travel well are a spec, good for building and no help deciding whether to build. Requirements that need the author present do not work without the author. The quickest way to place a document is to ask an engineer who missed the review who the feature is for and why that person would care. If the answer is a list of requirements, the team has a spec.
What to watch
- Whether the full essay says what AI does to the story itself, beyond coding and speed from idea, and whether it gives any part of that work to AI tools.
- Any measured evidence, beyond one career's account, that teams with a retellable product story ship the right product more often than teams working from specs.