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
-
Business requirements vs functional requirements: the difference that actually matters
Business requirements vs functional requirements, explained with examples. Most definitions get the distinction technically right and practically useless. Here is the difference that actually changes how you work.
-
What separates BAs who compound from BAs who plateau
How to grow a business analyst career: what separates BAs who advance from those who plateau. Not talent or luck, but a specific, repeatable practice of calibration.
-
What to write up after the discovery conversation
How to document requirements after a discovery conversation: capture the findings, not just the notes. The format that survives, and three things you should never write down.
-
How to actually run a stakeholder discovery conversation
How to run a stakeholder discovery conversation: the structure, not just the questions. The opening minute, the middle pivot, the close, and five mistakes that kill elicitation.
-
The AI-assisted requirements workflow that actually works
Using AI for requirements gathering: the workflow that works. Most AI requirements work just generates acceptance criteria faster, producing faster bad requirements. Three stages.
-
The weekly written artifact rhythm
The weekly writing habit that separates business analysts who advance from those who plateau. Predictions, patterns, revisions, and why most BAs cannot sustain it.
-
When the one-page artifact is the wrong tool
The one-page push-back artifact is a tool. Like every tool, it has cases where it makes things worse. Three situations where reaching for it signals you have misread the room, and what to do instead.
-
The one-page artifact that earns the right to push back
Most BA templates organise content. The one-pager that lets you push back on a senior stakeholder organises judgement. Here is the exact format, the order of sections, and the moves that make it land instead of feel adversarial.
-
Pushing back on people who outrank you
How to push back on senior stakeholders who outrank you, without ending your career. The pre-meeting move, escalating risk not disagreement, and the calibration that earns trust.
-
When stakeholders won't answer your questions
How to handle difficult stakeholders who resist your questions. Four types of resistance, five tactics, and why pushback usually means you asked the right question.
-
The five questions, applied: three worked examples
The five-question template only earns its keep when you watch it work on real requests. Here it is applied to three requests every BA has seen: a customer health score dashboard, a loyalty program, and an AI chatbot for the support site.
-
The requirements document is dead. Long live the requirements document.
Is the requirements document dead? Agile, Jira, and AI each declared it. The truth: documents didn't die, BAs stopped writing good ones and blamed the format.
-
What changed about being a BA between 2020 and 2025 (and what didn't)
What changed about being a business analyst from 2020 to 2025, and what AI didn't change. The surface shifted; the craft barely moved. Why that gap is a career risk.
-
BA vs PO vs PM: the difference nobody writes about honestly
The real difference between a business analyst, product owner, and product manager, and who actually owns the outcome. Not another comparison table.
-
INVEST and SPIDR both miss the point
INVEST vs SPIDR for user stories, and why both miss the point. They tell you whether a story is well-formed, not whether it is worth building. The structural flaw both share.
-
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
The requirements gathering question most BAs forget before opening Jira. "What do they want?" is the wrong first question. The one that actually validates a requirement.
-
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)
How to write acceptance criteria that prevent bugs, with examples. Most criteria verify the feature works, not that it solves the problem. Here's the difference.