The business analyst is usually the first role to get cut on a lean team. It looks like overhead. The PM does requirements, right? The engineers can ask questions. Why pay for a layer in between?
Then six months later you're wondering why estimates are always wrong, why every ticket has three follow-up Slack threads, and why the team keeps shipping features that don't quite match what the stakeholders thought they were getting.
The cost of cutting the BA isn't on the headcount line. It's distributed across every other function, and it adds up to more than the role you eliminated.
What a BA actually does
The job is poorly named. "Business analyst" sounds like someone who makes spreadsheets. The work is something else: turning ambiguous business intent into specific, testable, buildable requirements that an engineering team can execute against without follow-up.
That's a craft. The good ones spot edge cases the PM missed. They ask the question that exposes the assumption nobody knew they were making. They write tickets that an engineer can pick up cold and build correctly. They keep the gap between "what we said we wanted" and "what got built" small.
It's not work that disappears when you remove the role. It just doesn't get done as well, and the cost gets paid by the engineers, the PM, and the stakeholders — all in their less-good versions of doing it.
What goes wrong when the role is cut
Three patterns show up almost every time:
Tickets stop being buildable from. The PM writes a description, the engineers ask three clarifying questions, the PM answers, the engineers find another edge case, and so on. Each ticket has a long Slack tail before any code gets written. That tail is the BA work happening — just spread across the team and slower.
Estimates get worse. Engineers estimate against what they think a ticket means. When tickets are ambiguous, the estimate carries the ambiguity — which usually shows up as the work taking 2–3x longer than the estimate. The team gets blamed for missing dates that were always going to slip because the spec wasn't clear enough to estimate against.
Features ship that don't match the brief. The PM and the stakeholder had a conversation. The PM wrote a ticket. The engineers built what the ticket said. The result is technically correct and miles from what the stakeholder thought they were getting. That gap is usually a missing translation step — the BA's job — that nobody picked up.
When you can get away without one
There are real cases where the role isn't needed.
The team is genuinely small. Three engineers, one PM, one designer, all in the same room every day, working on a tightly-scoped problem. The conversation overhead is low. The shared context is high. A formal BA layer adds friction without adding clarity.
The PM has the BA skill. Some PMs do — they're the ones who write requirements engineers don't have to follow up on, who think in acceptance criteria, who proactively map out edge cases. If your PM is that kind, you don't need a separate BA. You need to recognise that and protect their time for it.
The product surface is small and stable. If the team is iterating on a known surface — a search results page, a settings panel — the requirement work compresses. Most asks are small variations on understood patterns. The BA layer adds proportionally less.
If none of these are true, you need someone doing the BA work. The only question is whether they have the title or whether the cost is being absorbed elsewhere.
What to do if you've already cut the role
A few moves that close most of the gap without restoring the line item.
Make tickets a craft. Build a template that forces the questions a good BA would ask: what's the user trying to do, what's success look like, what are the edge cases, what's explicitly out of scope. Refuse to start work on tickets that don't fill these in. The forcing function does most of the BA work for you.
Pair the PM with engineers on requirements. Not "PM writes spec, engineer builds". A 30-minute conversation per major feature where the PM and a senior engineer co-write the acceptance criteria. The engineer catches what the PM missed. The PM catches what the engineer assumed. The ticket that comes out is the ticket the team can actually build from.
Promote the senior engineer who's good at this. Some engineers love the requirements work and are excellent at it. Officially making it part of their role — and giving them the time for it — is cheaper than hiring a BA and almost as effective.
The shift
The BA role is invisible work. When it's done well, you don't notice it. When it's removed, you don't notice it for a while either — until the slow-burn costs start showing up everywhere except the headcount line.
Cutting the BA isn't free. It just moves the cost. If you're going to remove the role, do it deliberately, with a plan for who picks up which parts of the work. Don't let it disappear into the cracks.
If you're trying to ship faster, the answer isn't usually more people — it's clearer requirements. And if your tickets aren't buildable from, that's where most of the slowdown is coming from.