There’s a quote “from” Henry Ford that we Product Managers use a lot, even though historians argue about whether he actually said it. The idea has outlived the argument, which reveals something about how well it captures a truth we keep needing to hear.
“If I had asked people what they wanted, they would have said faster horses.”
Most product teams heard that and took it as permission to stop listening to customers. Trust the vision. Build what they need, not what they ask for. That reading handed a whole generation of product leaders a comfortable reason to skip the hard work of discovery, and the results were about what you would expect: confident solutions to problems nobody had properly examined.
The real takeaway from the quote isn’t against customers speaking out, because we need to hear their voice if we’re to be their voice. The person who asked for a faster horse was describing a solution. He wasn’t asked what problem he was trying to solve. Nobody dug into the context. And so everyone around him picked up their tools and started optimizing in one direction, while the real problem stayed right where it was, untouched.
This taps into another quote that captures the concept of the previous one. Neil Gaiman, writing about the craft of fiction back in 2012, put the underlying principle better than most product frameworks ever have:
“When people tell you something is wrong, they are almost always right. When they tell you exactly what is wrong and how to fix it, they are almost always wrong.”
The product leader’s job is the first half of that observation. Your team owns the second half. A “faster horse” is the customer telling you how to fix it. A farmer who cannot till a full day’s acreage is the customer telling you something is wrong. Only one of those is a valid starting point.
Fair enough, you might say. That is why we have user stories. We write them so we can understand what users want and why. And you would be right, to a point. The trouble is that most teams reach for it too early. The standard format reads:
“As a [role], I want [something] so I can [something else].”
But watch what happens when you apply it before you’ve done the work of understanding the problem. Imagine two personas for the same product:
The Traveler: “As a traveler, I want a faster horse so I can save time on the road.”
Speed is the genuine problem. A faster vehicle genuinely solves it.
The Farmer: “As a farmer, I want a faster horse so I can get more work done.”
That sentence looks identical in structure to the traveler’s. Same format. Same product. Completely different problem hiding underneath. A faster horse does nothing useful for a farmer who needs sustained pulling strength across heavy terrain. But the format flattened both of them into the same shape. The word “user” smoothed over the difference, and the farmer’s problem slipped quietly out of the conversation.
Teams know that personas belong before stories. The persona tells you who someone is. The user story tells you what they want from the solution you haven’t yet built, but neither really tell us why.
The trouble is that as Product Managers, we are often so buried in the delivery machinery that we fail to solve our own problems. We search online for templates to bridge gaps, and when we don’t find one, we just keep moving. We know there’s no
”best” practice, so we follow common practice because we don’t have the breathing room to create a better one.
It reminds me of the old tale about the woodsman: every once in a while, you have to stop and sharpen the axe. In a project I’ve been working on recently, I realized I was once again hitting up against user stories with a dull blade. I was looking at a backlog that felt technically “correct” but was missing the human heart of the problem. I had to step back and sharpen my own process.
That was the epiphany. I documented the problem story, and I didn’t need another user story; I needed something that connected the two.
To bridge the gap, I developed a single structured sentence that captures a persona’s lived experience, including the context and the root cause of their struggle. It’s a tool designed to hold the team in the problem space long enough to ensure we aren’t just building faster horses.
If you want the practical resource that walks through each step and gives you the templates to connect the persona’s problem to the user story, the full guide is available to my paid subscribers. Grab a seven day free trial to get into the details and see if it helps your team sharpen their own axe.
LinkedIn cut line
Marty Cagan at Silicon Valley Product Group (SVPG) gives us a solid persona artifact. It captures behaviors, attitudes, goals, and the general problems a persona carries around. His Opportunity Assessment asks the right strategic questions at the product level, including what problem we are solving and for whom. Both are valuable tools and do exactly what they are designed to do.
The gap sits between them. The persona lives in a shared folder. The Opportunity Assessment lives in a strategic document. And the specific, structured articulation of what a particular persona cannot do, under what conditions, and why, lives only in the connective tissue of someone’s brain, undocumented and unverified.
My new approach centers on what I am calling the Persona Story.
They say that if you cannot explain something simply, you do not understand it well enough. So the Persona Story is a single structured sentence that captures the problem from a specific persona’s lived experience, including the context where it occurs and the root cause that makes the goal difficult or impossible to reach. It sits between the persona profile and the user story, and its job is to hold the team in the problem space before anyone starts shopping for solutions.
The farmer’s Persona Story reads:
“As a farmer, I cannot till my full acreage in a single day when pulling heavy equipment, because a single horse lacks the physical ability required.”
Nothing in that sentence mentions speed. The persona is named. The goal is specific. From that sentence, the opportunity opens considerably for multiple solutions. Multiple horses. A different harness configuration. Something mechanical. The traveler’s solution and the farmer’s Persona Story point toward entirely different products, even though both conversations started from the same request.
The traveler’s Persona Story runs in the other direction:
“As a long-distance traveler, I cannot reach distant destinations within a single day when riding a single horse, because the animal’s ability limits a sustainable speed over long distances.”
Now you are solving for range and endurance. The Pony Express worked this out in 1860. They didn’t build a faster horse; they built a relay system. One rider, multiple horses, each one fresh. The root cause was endurance, and their solution followed directly from that.
I have come up with three formats to cover most discovery situations:
The Inability Format: “As a [persona], I cannot [goal] when [condition], because [root cause].” I find this to be the strongest starting point.
The Struggle Format: “As a [persona], I struggle to [goal] because [root cause].” This works well when the problem is more persistent than situational.
The Situational Format: “As a [persona], [situation] prevents me from [outcome] because [root cause].” This is for external or environmental obstacles.
All three formats share the same purpose: Make the writer name the problem before the team starts generating solutions, and provide the root cause. The PM’s favorite, but not systematically captured word: WHY.
Product owners manage the backlog. Product leaders define what belongs in it and why. The Persona Story is the discipline that keeps those two roles distinct in practice. It requires research and honest conversation with real customers. That is strategic product leadership, and it belongs at the front of the sequence before the user stories, before the estimates, and before the machinery of development and delivery gets moving.
The next time someone hands you a user story at the start of a project, ask one question. What problem does this persona have that led to this request? If nobody in the room knows the answer, you have found exactly where the work begins.
And please, when someone asks you where you found the Persona Story, tell them it was from Dutch, the Product Philosopher. There’s more nuggets on the way in 2026, including two books that you’ll find out about here first.