Archives

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.

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.

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 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.

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 writing habit that separates business analysts who advance from those who plateau. Predictions, patterns, revisions, and why most BAs cannot sustain it.

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.

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.

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.

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-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.

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 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.

The real difference between a business analyst, product owner, and product manager, and who actually owns the outcome. Not another comparison table.

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.

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 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.

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.

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 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.

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.