Legal work is one of the closest matches to business analysis of any non-technical background, and almost nobody says so, because the two professions never meet.

The overlap is not “attention to detail”. It is that both jobs are fundamentally about removing ambiguity from language before it causes an expensive problem.

What the job actually is

Somebody describes a problem and usually a solution they have already decided on. You work out what the real problem is, which is often not what they said, and then write it down so precisely that a developer who has never met them can build the right thing.

The writing is the job. Not summaries. Specifications where every sentence has to survive being read by a stranger who will implement it literally.

No code required.

What actually transfers

  • Drafting. You have written documents where an ambiguous clause has real consequences, and had every one reviewed by somebody more senior looking for exactly that. Acceptance criteria are the same discipline in a different template. Most business analysts write them badly. You will not.
  • Caseload management. Forty concurrent matters, each with its own deadlines, dependencies and documents. That is portfolio management, and you did it without a tool that helped.
  • Disclosure and bundling. You have coordinated document production across counsel, clients and third parties against a court date that could not move. That is dependency management where the deadline genuinely is fixed, which is rarer in software than people pretend.
  • Client updates. You have told somebody nothing has moved, in a way that kept them calm, repeatedly. That is status reporting and it is a skill.
  • Precedent and template work. You know why a standard clause exists, which is the same instinct as knowing why a requirement has an edge case attached.
  • Reading for what is missing. This is the one to lead with. A paralegal reads a document and notices the thing that is not there. That is exactly what separates a good business analyst from somebody who writes down what they were told.

What does not transfer

Two things.

Precision has a different cost. In law, ambiguity is a liability and you eliminate it. In delivery, over-specifying early is also a failure, because the requirement will change and you will have spent a week on a document nobody reads. Learning when good enough is correct takes a while, and it feels wrong at first.

The other is hierarchy. Legal practice is steep and everybody knows where they sit. Delivery teams are flat, sometimes performatively so, and a junior engineer will tell a director their idea is wrong in an open channel. That is normal and not a crisis.

Where legal experience is worth money

Legal technology, compliance software, regtech, insurance claims platforms, and anything touching contracts or case management.

Those products are built by teams who mostly do not understand the domain, and a business analyst who has actually done disclosure is unusually valuable. That is a concrete reason to hire you over a generic candidate with two years of experience, and it is worth putting in your covering letter rather than hoping somebody notices.

The gap

Vocabulary and artefacts. You can do the thinking. You have never written a user story, run a sprint, or used Jira, and the interview will ask about all three.

Build one delivery project. Twelve stories with proper acceptance criteria including the unhappy paths, three sprints, one thing that went wrong for a boring reason.

Say it is a practice project, every time, in one sentence. You of all people will understand why that sentence matters.

How to write the CV

  • “Managed a caseload” becomes “Managed a caseload of up to 40 concurrent matters, each with its own deadlines, dependencies and documentation requirements”
  • “Assisted with disclosure” becomes “Coordinated document production across counsel, clients and third parties against court deadlines that could not move”
  • “Drafted documents” becomes “Drafted documents to a defined standard where ambiguity carried real consequence, and had every one reviewed”
  • “Client care” becomes “Kept clients informed on matters where the honest answer was often that nothing had moved yet”

Translate the verb. Never touch the evidence.

Certification

For business analysis, the BCS Foundation in Business Analysis or the IIBA ECBA. Not a scrum certification, which signals you are applying across roles rather than for this one.

After the project, not before.

Is it worth it

If you liked the part of legal work where you took a mess of facts and made something precise out of it, and you disliked the billing, the hierarchy and the hours, this is a reasonable trade.

If what you liked was the law itself, it is not, and legal tech will only partly scratch it.


The gap is not knowledge

It is that every interview question assumes you have a project to answer from. The Portfolio Project Kit is a complete agile delivery project you import into your own Jira in one click, with full acceptance criteria, three sprints and one documented impediment. It is a practice project and you say so every time you present it. See the Portfolio Project Kit, $49


Not sure which of the four you are aiming at?

The Role Fit Diagnostic is sixteen statements. You tick the ones that are true of you now, count your ticks by letter, and read the page for whichever role you already work like. Ten pages, printable, free, about six minutes.

Take the Role Fit Diagnostic