The tech industry tends to glorify the extremes of the stack. On one end, engineering — raw building capability, increasingly accelerated by AI tools that let one developer do what once required a team. On the other, product management and its proximity to strategy, roadmaps, and the metrics that attract investment. The work that sits between those two ends — the grueling, unglamorous effort of making sure they're pointing at the same target — gets treated as administrative overhead.
That middle is where the Business Analyst lives. And the consistent failure to value it properly is costing organisations far more than they realise.
The Problem Isn't Speed. It's Direction.
The pressure to ship has never been higher. AI-assisted development compresses delivery cycles that once took quarters into weeks. Teams are smaller, faster, and more technically capable than they were five years ago. And yet the volume of post-launch regret — features no one uses, integrations that don't match how users actually work, systems that solve problems elegantly on paper and badly in practice — hasn't decreased. If anything, it's accelerating alongside velocity.
This is the pattern that the Business Analyst role was literally invented to address. The position emerged in enterprise technology in the late 1970s and 1980s as a direct response to a specific failure mode: software developers, building increasingly capable systems, had no reliable mechanism for understanding what users actually needed. The BA was the bridge. Decades later, the failure mode is identical, amplified by modern tooling, and organisations are still undervaluing the function designed to address it.
The Invisible Work
When someone describes a BA as a "note-taker" or a "JIRA manager," they're describing what the surface of the role looks like from the outside — or what it looks like when it's done poorly. The visible output is documentation. The actual work is something different.
A good BA maps the distance between what a stakeholder says they want and what they actually need. They surface the dependency that two teams didn't know they shared. They identify the contradiction between what the business owner wants, what the compliance team will approve, and what the engineering team can deliver in the given timeframe — and they hold that tension until something coherent emerges. None of that work produces a tangible artifact. It produces the absence of a very expensive problem.
I've watched this dynamic play out in enterprise technology environments. In sales-side work, I saw implementations fail not because the technical team built the wrong thing technically, but because no one had mapped the difference between how the client said they operated and how they actually did. In consulting engagements, a significant portion of the early work was discovering that the existing requirements didn't match the system everyone was actually using — meaning the root problem was several layers above where the team was looking.
When projects land well, that prevention work disappears into the outcome. When they land badly, it's almost always traceable to a failure in exactly this domain — not in engineering execution or product vision, but in the translation layer between them.
The AI Argument Gets It Backwards
The most common objection to investing in business analysis right now is that AI makes it unnecessary. Large language models can draft user stories, generate acceptance criteria, summarise interview transcripts, and produce requirements documents faster than any human. If documentation is the output, why employ someone to produce it?
This argument mistakes the output for the work.
AI is genuinely good at synthesising what stakeholders say. It is not equipped to decode what they mean, navigate the political dynamics of a discovery session where two department heads disagree without either saying so directly, or push back against an executive demanding a feature that will create three downstream problems no one has modelled. More fundamentally: AI answers the questions you give it. Business analysis is largely concerned with determining whether you're asking the right questions at all. That judgment depends on a model of the organisation — its history, its contradictions, its real operating reality — that no document fully captures.
What AI actually does to the BA role is compress the administrative portion of it. Documentation, transcription, template-filling — these tasks shrink. What remains is the harder work: the alignment, the critical thinking, the structured negotiation. AI raises the floor on what junior practitioners can produce. It raises the ceiling on what senior ones can accomplish. That isn't obsolescence; it's leverage.
What the Role Actually Touches
A good Business Analyst is one of the only roles in a technology organisation that operates across the full span of a product's life. Before scope is defined, they're qualifying whether the problem is worth solving and whether the proposed solution addresses the actual root cause. During delivery, they're the reference point for what the system was supposed to do when implementation diverges — and it always does. After launch, they're the ones who can answer honestly whether the thing that shipped matches the thing that was needed.
This cross-lifecycle visibility is unusual. Most technical roles are scoped to a phase. The BA is scoped to the outcome — which means they accumulate context that no one else on the team has, and they lose it when they're treated as a phase-specific resource and cycled off a project before anything ships. That's a surprisingly common mistake, and the consequences usually surface six months later when no one can explain why a particular decision was made.
The role also spans vertically in a way few others do. A BA operating well is simultaneously validating that a small tactical change at the team level connects to a broader enterprise goal, and that the result, once shipped, will actually be measurable. That double check — does this serve the strategy, and will we know if it did — is work that product management does at a higher altitude and engineering doesn't do at all. Someone has to do it at the level where the actual code meets the actual process.
The Measure That's Missing
The reason the BA role is persistently undervalued is structural. Organisations optimise for what they can measure. Lines of code, sprints completed, test coverage, deployment frequency — these are clean, attributable, and legible to leadership. The work of preventing a three-month misalignment from becoming a six-figure rebuild has none of those properties. It is invisible by design: if it succeeds, nothing happens, and nothing is hard to count.
But technical excellence built on top of a misunderstood problem is an expensive mistake. As delivery cycles shorten and the marginal cost of building falls, the cost of not knowing what to build becomes proportionally larger. Speed amplifies direction errors; it doesn't correct them.
The Business Analyst is not administrative overhead or a project management convenience. They are what connects technical velocity to actual business outcomes. The organisations that treat the role as a luxury tend to discover — usually at cost, and usually after the fact — that it wasn't.
