Did Reading Fiction Make You Better at Product Work?

The designer says, “I’m not sure a new user will understand this.”

The engineer says, “But it’s obvious.”

The founder says, “But this is how the market works.”

The product manager says, “But users asked for this.”

And often, everybody is right from inside their own model of the world. The engineer understands the system. The founder understands the strategy. The PM understands the roadmap. The designer is trying to hold the experience of the person arriving cold, with none of that context, none of that history, none of that internal language, and usually very little patience.

I have a slightly half-formed theory that reading fiction as a child may make you better at this sort of work.

Not just design, although design is the obvious place to start. Product management too. Founding especially. Any role where you have to understand how different people see the same situation, then make something that works across those different models of reality.

A lot of non-fiction asks you to follow an argument. The author has a position. They gather evidence, build a case, and try to persuade you that this is the right way to see the world. At its best, this is brilliant. It can sharpen your thinking, give you language for things you half understood, or help you reason from better evidence.

But it is still usually one mind making a case.

Fiction does something different. Fiction rarely gives you one clean version of reality. It asks you to sit inside other people’s heads for a while. Often several of them. You see the same event through different characters’ eyes. One person sees danger. Another sees opportunity. Someone else misses the point entirely. They are not simply “right” or “wrong.” They are acting from their own fears, loyalties, histories, desires and blind spots.

Sometimes the narrator isn’t even reliable.

That may be one of the more useful lessons fiction teaches you: nobody is seeing the whole picture. Everybody is moving through the world with a partial model of reality, including you.

That feels very close to good product work.

Discovery only seems like a waste of time if you already believe you have the right model of the situation. If the problem is obvious, the user is obvious, the buyer is obvious, the solution is obvious, then talking to more people can look like delay dressed up as process.

But if you believe different people are seeing different parts of the truth, discovery starts to look very different.

It becomes a way of building a fuller picture.

You talk to users, buyers, support teams, salespeople, domain experts, sceptics, beginners and edge cases because each of them is holding a different fragment of reality. None of them has the whole answer. But neither do you.

This is where designers can be irritating in product discussions. They keep refusing to accept the organisation’s view of the domain as the only legitimate one. They keep saying things like, “I know that’s how we describe it internally, but would a customer use that word?” or “I understand why the flow works like this, but would somebody coming to this fresh know what to do next?”

To the rest of the team, this can sound like fussiness. Another round of naming debates. Another objection to the sensible, logical, efficient thing.

But often the designer is doing something more specific. They are trying to step outside the expert model and reconstruct the beginner’s model.

This is essentially what a cognitive walkthrough is for. You take a product you already understand and ask, step by step, whether someone else would reasonably know what to do. Not an expert. Not a teammate. Not the person who sat through three months of roadmap meetings. Someone with a goal, a bit of context, a few assumptions, and no interest in your internal taxonomy.

You’re not asking, “Can I use this?”

You’re asking, “Would someone coming to this fresh, with limited information, understand what this means, notice the right thing, and believe it will move them closer to their goal?”

That distinction sounds small, but it is often the entire job.

Teams regularly mistake their own fluency for clarity. They have spent so long inside the product that the product’s logic feels natural. They know what the button does. They know why the form has six steps. They know why the pricing page uses that language. They know what the feature is called in the database, what the sales team calls it, and why the original name was politically impossible to change.

A new user knows none of that.

They arrive with their own vocabulary, their own expectations, their own anxieties, and their own sense of what should happen next. If the product asks them to think like the company before it helps them get what they came for, the product is probably worse than the team thinks it is.

You see this in usability testing all the time. The first person struggles and someone in the room quietly blames the participant. The second person struggles and maybe the task gets blamed. By the fifth or sixth person, when the same pattern keeps appearing, the room changes. People stop laughing. The problem is no longer with the user. The problem is that the interface was designed around the team’s mental model, then mistaken for reality.

Good designers are often quicker to believe the confusion.

They are more willing to ask, “What did this person think was happening?” rather than “Why didn’t they get it?” That is a very different question. It treats user behaviour not as a failure of intelligence, but as evidence of a different model of the situation.

This is where the link to fiction feels interesting to me.

When you read a lot of fiction, you get repeated practice in seeing behaviour from the inside. Characters make choices that might seem irrational from the outside, but once you understand what they know, what they fear, what they want, and what they have misunderstood, their actions start to make sense. You learn to ask, “What would make this behaviour reasonable from their point of view?”

That is very close to abductive reasoning.

Deductive reasoning starts with rules and works out what must be true. Inductive reasoning looks at patterns and works out what is probably true. Abductive reasoning looks at a messy situation and asks what explanation would make the most sense of it.

Designers do this constantly. So do good PMs and founders.

A user ignores the obvious button. A buyer says they love the product but never converts. A customer churns after telling you the product was exactly what they needed. A founder hears ten different versions of the same problem and has to work out what is really going on underneath.

The lazy answer is to take behaviour at face value.

The better answer is to ask what model of the world would make that behaviour make sense.

Maybe the user did not understand the label. Maybe the buyer was being polite. Maybe the customer liked the product but could not persuade their boss. Maybe the market is not rejecting the product, but rejecting the way the company is framing the problem.

This is the work. Not simply collecting opinions, but reconstructing the different realities people are operating inside.

Of course, plenty of people who read fiction as children become terrible designers. Plenty of people who never cared for novels become brilliant founders, researchers, PMs or engineers. I’m not claiming some neat causal link where Jane Austen turns you into a better product thinker and business books make you worse.

But I do think fiction gives some people early practice in a skill product teams badly need: the ability to suspend your own certainty long enough to inhabit someone else’s.

That skill is harder than it sounds.

Especially in companies, where certainty is often rewarded. The person with the strongest point of view sounds decisive. The person asking for more perspectives can sound slow, vague or difficult. But certainty too early is often just a polished form of blindness. It feels efficient because it removes friction. It also removes the chance to discover that your model of the world is missing something important.

Maybe that is why designers, at their best, are such useful troublemakers.

They keep dragging other realities into the room. The confused user. The sceptical buyer. The support agent dealing with the fallout. The beginner who doesn’t know your acronyms. The customer who sees your category differently. The person for whom the “obvious” thing is not obvious at all.

That can be annoying.

It can also be the difference between building a product that makes sense to the company and one that makes sense to the people it is meant to serve.

So yes, I wonder if reading fiction as a kid makes you a better designer, product manager or founder. Not because it makes you nicer. Not because it gives you some vague empathy halo. But because it teaches you, early and repeatedly, that people do not move through the world as generic users. They move through it as particular people, with partial information, private motivations, unreliable stories and very different ideas about what is going on.

And if you can’t imagine that, you’ll keep designing for the one person whose perspective already dominates the room.