There’s something I’ve noticed about my best learning periods. They tend to happen between projects, not during them. Between one job and the next, I finally had time to think wider — not about the current product — to read articles, explore AI tools, take courses. I’d been meaning to do these things for months. But while I was deep in delivery, there was never a slot for it.

I assumed this was mostly a time problem. Then I came across the concept of working memory — and I wanted to add it to my list of excuses, but it didn’t work: working memory is about what the brain holds right now, not across months.

But it is directly connected to something that kept me curious for a long time: why user stories don’t get read.

I tried to fix this for years. Plain language, visual formatting, color highlights, bold text, inline screenshots, emoji. My stories always had visual references, because we all process images faster than text (everyone likes books with illustrations:). And still, whether the story got read depended mostly on how accountable the specific reader was.

Then the working memory concept gave me a better explanation.

Our brain has a tab limit

Working memory — the cognitive system that holds and processes information in real time — has a hard capacity. George Miller’s original research put it at 7±2 “chunks.” More recent work by Nelson Cowan narrowed it to 4±1. The key word is chunk: not characters or bullet points, but units of meaning.

This limit refers to what the brain holds simultaneously at a given moment. For an experienced developer reading a user story, one chunk might be an entire flow. For someone newer to the product, it might be a single field on a form.

When you write a user story, you are competing for space in a system that holds roughly four things at once. Everything else gets dropped, skimmed, or mentally filed under “I’ll come back to this.”

The stories that went unread

I’ve written hundreds of user stories — detailed ones. Happy paths, edge cases, acceptance criteria for every scenario I could anticipate. I’d spend hours on them, pre-answering developer questions, covering QA concerns before they came up.

And then I’d watch them go unread.

Sounds familiar? Developers built something slightly off. QA missed an edge case you’d explicitly documented. Someone asked in a standup: “What should happen when the user is logged out and tries to do this?” And you thought:  It’s in the story. I wrote it. It’s right there.

Then I started reading Steven Pressfield’s Nobody Wants to Read Your Sh*t — I found it in a Medium article on PM reading. His central point: no one is waiting eagerly to read what you’ve written. They’re busy. They have a thousand other things competing for their attention. By default, they want to skip it — not because they’re lazy, but because attention is finite.

“Why? Because they might have to actually read it.”

That line hit differently after years of comprehensive documentation that wasn’t being read.

Pressfield reframes writing as an exchange. The reader gives you their limited attention. In return, you owe them something worth that investment. A developer reading your user story is giving you maybe three minutes of focused attention. What are they getting back?

I had a sharp reminder of this when I joined a new project and opened tickets from the previous PO during onboarding — trying to understand why the product felt so unclear. When I opened the first ticket, I understood immediately. Each one had 15–30 sentences starting with “User must…” No structure, no priority, no signal about what actually mattered.

The problem was never the reader. The problem was the writing.

I asked an AI assistant to review one of my early stories from that period. The feedback was direct: solid structural instincts, correct behavior-driven style — and cognitive load that was brutal. It was an epic, not a story. Four pages, inline screenshots, nested conditionals. A developer would struggle to hold any of it in working memory at once.

Thoroughness and readability are not the same thing. Coverage and clarity are not the same thing. A story that documents everything in one place — seven flow stages, three roles, page layout, and notification logic — covers a lot, but unfortunately communicates nothing about what matters most.

What a good story actually looks like

In practice, a good user story, as I understand,  does a few specific things:

It treats acceptance criteria as a prioritized list, not an exhaustive one. The top three criteria are the ones that define correctness. Everything else is context.

It distinguishes what’s ambiguous from what’s obvious. If the behavior is standard and the team has built it a dozen times before, say so and move on. Reserve detail for what’s genuinely unclear or easy to misread.

It’s written for a specific reader, not a future audit. The question is not “could someone prove from this document that requirements were covered?” The question is “will the developer who picks this up tomorrow build the right thing?”

Pressfield’s lesson from advertising still holds  (he heard  “Nobody wants to read your shit” for the first time when he worked at the advertising agency). The transaction has to work for the reader, not for the writer. 

Every line you include is a request for a reader’s limited attention. If it doesn’t earn that attention, it shouldn’t be there.

To summarise it, I would  say that the job of a PM or PO is to make the right things impossible to miss.

What’s your experience — are your user stories actually getting read?