Stop optimising the story. Start understanding the problem.
Notes for working business analysts, product owners, and product managers who suspect there is more to the craft than cleaner Jira tickets. The argument here is simple: problem-understanding first, story-writing second. Most BA content gets that order backwards.
Three things you will find: writing on the analytical work itself, on using AI without losing the thinking, and unsentimental reviews of the tools BAs actually use.
Featured
-
The requirements document is dead. Long live the requirements document.
The death of the BRD has been declared a hundred times. Agile killed it. Jira killed it. AI is about to kill it again. The truth is that documents didn't die. BAs stopped writing good ones, then blamed the format.
-
What changed about being a BA between 2020 and 2025 (and what didn't)
Five years of change in the BA role: AI tools, async work, the rise of product ownership inside services firms. But the underlying craft barely moved. The BAs treating surface changes as the actual work are setting themselves up for a career problem.
-
BA vs PO vs PM: the difference nobody writes about honestly
Every article on this compares the three roles by their textbook definitions. None of them admit the truth: the boundaries are drawn by org politics and budget, not by any clean division of work. Here's how it actually plays out.
-
INVEST and SPIDR both miss the point
INVEST is older. SPIDR is newer. The endless debate about which is better misses a structural flaw both share. They tell you whether a story is well-formed. They don't tell you whether it's worth building.
-
Most stakeholder conflicts are authority disputes, not requirements disputes
When a stakeholder refuses to discuss a request, the standard advice is "ask better questions". This is almost always wrong. The problem is rarely communication. It's that nobody has agreed who gets to decide what, and the stakeholder is defending territory they're not sure they own.
-
How I use Claude to interrogate my own requirements before showing them to engineering
I write the requirement. Claude tears it apart. I rewrite. The version that goes to engineering is roughly the fifth draft, and they ask half the questions they used to.
-
Why "as a user, I want to..." is the worst thing that happened to user stories
The "as a user, I want X so that Y" template was a useful crutch in 2001. Twenty-five years later, it's a substitute for thinking. Here's what to write instead.
-
The question most BAs forget to ask before opening Jira
Most requirements work starts with "what do they want?" That's the wrong first question. Here's the one that saves projects.
-
Writing better user stories is the wrong goal. Here's what to optimise for instead.
There's a quiet epidemic in IT services teams. Business analysts and product owners are getting better at writing user stories. The stories are well-structured. They follow the template. They have crisp acceptance criteria. They pass every review. And the projects are still failing.
Recent Posts
-
Acceptance criteria that actually prevent bugs (with 12 worked examples)
Most acceptance criteria are written to look thorough, not to prevent bugs. Here's what the criteria that actually catch defects look like, with twelve real examples annotated.