Before I became a product manager, I wrote about music for a living.
For several years, I reviewed albums and profiled artists for the NME and a handful of independent music magazines. I loved every minute of it. I still follow new music obsessively. But it turns out you can't pay a mortgage with free CDs and guestlist passes, so here we are.
What I carried into product management, and have never been able to unlearn, is this: the most important thing about a story is never the thing itself. It's why the reader should care.
Journalists don't start with the subject. They start with the angle, the lens that makes you lean in. A new album isn't interesting because it has twelve tracks. It's interesting because it marks a reinvention, or a return to form, or a confrontation with grief. The craft is finding what matters and putting it front and centre.
I've been a product manager for long enough now to know that most product teams get this backwards.
Features are forgettable – feelings aren't
The default product thinking habit is to start with what you're building: the feature set, the functionality, the capabilities. Story gets treated as something marketing bolts on later, once the thing is ready to ship.
But the story isn't a layer of polish you apply at the end. It's the foundation you build on. It shapes what you build, how you align your organisation around it, and whether anyone outside your team ends up caring. Get the story wrong (or worse, never find it) and you'll ship technically solid products that land in silence.
The uncomfortable truth is that nobody cares about your features. What they care about is the difference your product makes to them. Features describe the what. Story is the why and the so what. And the gap between those two things is where many products go to die.
Writing the story before you build it
The instinct to clarify story early isn't new. Amazon has practiced it for years with its ‘Working Backwards’ approach: before a line of production code is written, the team writes the press release. Not a specification. Not a roadmap. The announcement you'd want to make when this is done, written as if the product already exists.
It sounds like a creative exercise, but it's actually a brutal prioritisation tool. If you can't write a press release that would make someone care, you haven't understood what you're building yet. The clarity the exercise demands forces you to answer the question many teams skip: why should anyone want this?
Steve Jobs understood this intuitively. Watch any of the classic Apple keynotes and you'll notice he barely talks about specs. He talks about what the technology enables: what it feels like to have a thousand songs in your pocket, what it means to hold the internet in your hand. The product experience was designed to prove the story true. Everything in the presentation connected back to the same emotional thread.
The product story stack
Over the years I've developed a framework I use to build and pressure-test the story around any product – I call it the ‘Product Story Stack’. It's an inverted pyramid that works from belief down to mechanics, the opposite of how most product teams think.
Layer 1 – Belief: Why should this exist?
This is the foundation. Not a mission statement, but a genuine worldview, an ideological position about the way things should be. Airbnb believes travel should feel human. Lovable believes anyone with a good idea should be able to launch a software business. These aren't marketing slogans. They're the beliefs that make product decisions coherent and that make teams actually want to show up.
Layer 2 – Enemy: What are we fighting against?
Strong stories have tension. Every powerful brand has an implicit enemy. Not a competitor, but a condition they're working to end. It might be complexity, gatekeeping, corporate inertia, or technical elitism. Apple's historic enemy was the cold inaccessibility of corporate technology. Linear’s enemy is bloated project management software that slows engineers down. Without an enemy, you have utility. With one, you have momentum. This layer is missing from most product thinking, and its absence is why so many products feel flat.
Layer 3 – Aspiration: Who does this help someone become?
This is where Jobs-To-Be-Done (JTBD) theory goes somewhere more interesting than "hire a product to do a task”. Identity-driven thinking asks: what version of themselves is the customer aspiring to? Notion customers become organised and intellectually sharp. Figma customers become collaborative and creative. Peloton customers become the kind of person who trains. The product isn't the mushroom Mario eats. It's Super Mario after the transformation. Identity is stickier than utility, and it's where the most durable products live.
Layer 4 – Transformation: What changes in their world?
This is where aspiration becomes concrete. "Empowers teams to work more efficiently" is wallpaper. A sharp transformation statement like "turns first-time founders into confident product builders" tells you exactly what you're optimising for. It's also the layer where your roadmap, onboarding, and customer success need to connect. If they don't, the story fragments before it reaches anyone.
Layer 5 – Proof: Why should people believe us?
A story without evidence is theatre. Proof lives in the user experience, the onboarding flow, the outcomes your customers actually achieve, the community that forms around your product. It's the part of the stack that product, design, engineering, and commercial teams all share responsibility for. When Jobs walked through a demo, he wasn't showing off. He was proving the story true in real time.
Layer 6 – Mechanics: What does the product actually do?
Features, capabilities, integrations, infrastructure: the execution layer. Most product teams start here. In the stack, it's last – the implementation that delivers on everything above it. In an era when AI makes execution increasingly cheap, this layer is commoditising fast. What isn't commoditising is meaning.
The stakes are higher now
We're in a moment where anyone can build anything at near-zero cost. Prototypes take minutes. Shipping doesn't take much longer. The technical barriers that once distinguished products from each other are collapsing. That makes your product’s story the last genuine differentiator.
The battleground for product managers has shifted. It's no longer features versus features or UX versus UX. It's meaning versus mush. The teams who understand that story shapes what they create, not just how they talk about it, are the ones building the products people actually believe in.
My journalism career taught me that the angle is everything. The same facts, the same subject, the same raw material, told with the right frame, can make you care about something you'd never heard of five minutes ago.
Product managers are storytellers – we decide what matters, what it means, and how to make someone else believe it too. We always have been. We just haven’t always acted like it.
Before I became a product manager, I wrote about music for a living.
For several years, I reviewed albums and profiled artists for the NME and a handful of independent music magazines. I loved every minute of it. I still follow new music obsessively. But it turns out you can't pay a mortgage with free CDs and guestlist passes, so here we are.
What I carried into product management, and have never been able to unlearn, is this: the most important thing about a story is never the thing itself. It's why the reader should care.
Journalists don't start with the subject. They start with the angle, the lens that makes you lean in. A new album isn't interesting because it has twelve tracks. It's interesting because it marks a reinvention, or a return to form, or a confrontation with grief. The craft is finding what matters and putting it front and centre.
I've been a product manager for long enough now to know that most product teams get this backwards.
Features are forgettable – feelings aren't
The default product thinking habit is to start with what you're building: the feature set, the functionality, the capabilities. Story gets treated as something marketing bolts on later, once the thing is ready to ship.
But the story isn't a layer of polish you apply at the end. It's the foundation you build on. It shapes what you build, how you align your organisation around it, and whether anyone outside your team ends up caring. Get the story wrong (or worse, never find it) and you'll ship technically solid products that land in silence.
The uncomfortable truth is that nobody cares about your features. What they care about is the difference your product makes to them. Features describe the what. Story is the why and the so what. And the gap between those two things is where many products go to die.
Writing the story before you build it
The instinct to clarify story early isn't new. Amazon has practiced it for years with its ‘Working Backwards’ approach: before a line of production code is written, the team writes the press release. Not a specification. Not a roadmap. The announcement you'd want to make when this is done, written as if the product already exists.
It sounds like a creative exercise, but it's actually a brutal prioritisation tool. If you can't write a press release that would make someone care, you haven't understood what you're building yet. The clarity the exercise demands forces you to answer the question many teams skip: why should anyone want this?
Steve Jobs understood this intuitively. Watch any of the classic Apple keynotes and you'll notice he barely talks about specs. He talks about what the technology enables: what it feels like to have a thousand songs in your pocket, what it means to hold the internet in your hand. The product experience was designed to prove the story true. Everything in the presentation connected back to the same emotional thread.
The product story stack
Over the years I've developed a framework I use to build and pressure-test the story around any product – I call it the ‘Product Story Stack’. It's an inverted pyramid that works from belief down to mechanics, the opposite of how most product teams think.
Layer 1 – Belief: Why should this exist?
This is the foundation. Not a mission statement, but a genuine worldview, an ideological position about the way things should be. Airbnb believes travel should feel human. Lovable believes anyone with a good idea should be able to launch a software business. These aren't marketing slogans. They're the beliefs that make product decisions coherent and that make teams actually want to show up.
Layer 2 – Enemy: What are we fighting against?
Strong stories have tension. Every powerful brand has an implicit enemy. Not a competitor, but a condition they're working to end. It might be complexity, gatekeeping, corporate inertia, or technical elitism. Apple's historic enemy was the cold inaccessibility of corporate technology. Linear’s enemy is bloated project management software that slows engineers down. Without an enemy, you have utility. With one, you have momentum. This layer is missing from most product thinking, and its absence is why so many products feel flat.
Layer 3 – Aspiration: Who does this help someone become?
This is where Jobs-To-Be-Done (JTBD) theory goes somewhere more interesting than "hire a product to do a task”. Identity-driven thinking asks: what version of themselves is the customer aspiring to? Notion customers become organised and intellectually sharp. Figma customers become collaborative and creative. Peloton customers become the kind of person who trains. The product isn't the mushroom Mario eats. It's Super Mario after the transformation. Identity is stickier than utility, and it's where the most durable products live.
Layer 4 – Transformation: What changes in their world?
This is where aspiration becomes concrete. "Empowers teams to work more efficiently" is wallpaper. A sharp transformation statement like "turns first-time founders into confident product builders" tells you exactly what you're optimising for. It's also the layer where your roadmap, onboarding, and customer success need to connect. If they don't, the story fragments before it reaches anyone.
Layer 5 – Proof: Why should people believe us?
A story without evidence is theatre. Proof lives in the user experience, the onboarding flow, the outcomes your customers actually achieve, the community that forms around your product. It's the part of the stack that product, design, engineering, and commercial teams all share responsibility for. When Jobs walked through a demo, he wasn't showing off. He was proving the story true in real time.
Layer 6 – Mechanics: What does the product actually do?
Features, capabilities, integrations, infrastructure: the execution layer. Most product teams start here. In the stack, it's last – the implementation that delivers on everything above it. In an era when AI makes execution increasingly cheap, this layer is commoditising fast. What isn't commoditising is meaning.
The stakes are higher now
We're in a moment where anyone can build anything at near-zero cost. Prototypes take minutes. Shipping doesn't take much longer. The technical barriers that once distinguished products from each other are collapsing. That makes your product’s story the last genuine differentiator.
The battleground for product managers has shifted. It's no longer features versus features or UX versus UX. It's meaning versus mush. The teams who understand that story shapes what they create, not just how they talk about it, are the ones building the products people actually believe in.
My journalism career taught me that the angle is everything. The same facts, the same subject, the same raw material, told with the right frame, can make you care about something you'd never heard of five minutes ago.
Product managers are storytellers – we decide what matters, what it means, and how to make someone else believe it too. We always have been. We just haven’t always acted like it.
