What Business Analysis Actually Looks Like on a Real Project
Most people think a BA writes documents. The real job is figuring out what the problem actually is before anyone writes a line of code.
When I tell people I spent eight years as a business analyst, the first response is usually some version of: "So you write requirements documents?"
Sometimes. But that's not what the job is.
The real job
Business analysis is fundamentally about one thing: making sure the right problem gets solved. Not the problem that got described in the first meeting. Not the problem that's easiest to build a solution for. The actual problem.
In practice, this means:
Asking why five times before touching a spec. A client says "we need a mobile app." Why? "Our customers keep calling to ask where their orders are." Why don't they check the website? "There's no tracking on the website." So the problem is missing order tracking — not the absence of a mobile app.
Separating symptoms from causes. Low conversion rates on a checkout page might be a UX problem, a trust problem, a pricing problem, or a product-market fit problem. Building a prettier checkout fixes none of the last three.
Getting specific about success. "We want more sales" is not a success criterion. "We want to reduce checkout drop-off from 68% to under 40% within three months" is one you can actually design and build toward.
Where most projects go wrong
I've worked on projects at agencies and with direct clients. The failure mode is almost always the same: building starts before understanding is complete.
This happens because:
- Clients want to see progress (and progress looks like screens, not discovery sessions)
- Developers want to start building (it's more interesting than requirements)
- PMs want to hit milestones
- Everyone assumes someone else has already figured out the actual problem
The cost of this is enormous. Rework is expensive. Rebuilding something that was built wrong is more expensive. The sunk cost of a solution that doesn't solve the problem is most expensive of all.
What good looks like
Good BA work is almost invisible. The project runs smoothly. The developers know exactly what to build. The client recognises the solution when they see it. No major surprises at demo time.
When I work with a founder or an agency, the goal is always the same: make sure the right thing gets built the first time. Not because we're perfect, but because we spent enough time asking the right questions before anyone wrote a line of code.
That's not glamorous. But it's the difference between software that ships and software that works.