Day in the life
A day in the life of a Business Analyst
Business Analysts bridge the gap between what the business needs and what the tech team builds. The work spans stakeholder interviews, requirements writing, process mapping, and data — often all in the same day.
Hour-by-hour breakdown
Standup with the product team — status on a requirements doc
Quick sync with PMs, devs, and designers. You give a status update on the requirements doc you've been writing: what's done, what's still open, and whether any decisions are blocked waiting on stakeholder sign-off. Short meeting, dense information.
Stakeholder interview with the sales team — capturing CRM feature requirements
An hour with two sales reps to understand what they actually need from the new CRM feature. You come in with a structured question list, but good interviews never go in a straight line. You listen for the pain behind the request, document verbatim quotes, and push back gently when requirements conflict or are too vague to build from.
Writing user stories and acceptance criteria in Jira
Back at your desk, you turn interview notes into structured stories: As a [sales rep], I want to [see pipeline stage changes in real time] so that [I can prioritise follow-ups without switching tools]. Each story gets explicit acceptance criteria — the 'done' conditions a developer and a QA tester can agree on. No ambiguity allowed.
Process mapping session — current state vs future state in Lucidchart
You facilitate a session with the ops team to diagram how a workflow actually runs today versus how it should run after the project ships. Current-state maps expose the workarounds and handoff gaps that nobody wrote down because everyone just knows them. Future-state maps are where the real decisions happen.
Lunch
Step away from the screen. The afternoon has two back-to-back meetings; you need the break.
Data analysis in Excel — pulling together KPIs for an exec report
You've been asked to pull together key performance metrics for an executive summary. You work through the spreadsheet: vlookups, pivot tables, cleaning inconsistent date formats from three different source exports. The data tells a story once it's clean; getting it clean is the unsexy prerequisite.
Requirements review meeting with the dev team
Walk the engineering team through the user stories you wrote this morning. Developers ask good clarifying questions — they're the ones who will find every edge case you didn't think of. You answer what you can, flag what needs to go back to the stakeholder, and update the stories in real time to capture the decisions made in the room.
Writing a gap analysis — current state vs desired state
Translate the process mapping session into a written gap analysis: what exists, what's missing, what needs to change in people, process, or technology to get from here to there. This document becomes the input for scoping and prioritisation — it has to be precise enough that someone who wasn't in the room can act on it.
Updating the requirements traceability matrix
The RTM links every requirement to the business objective it serves, the user story that captures it, and the test case that will verify it. You update it with today's new stories and note which ones are approved, pending review, or still open. It's administrative work, but it's the thing that prevents scope creep and keeps audits painless.
Tools Business Analysts use daily
You don't need to master all of these before your first job — but you'll encounter every one of them within your first few months.
Things that surprise new Business Analysts
What nobody tells you before you start.
BAs are translators, not just documenters
The job isn't to write down what people ask for — it's to figure out what they actually need. Business stakeholders describe symptoms; your job is to diagnose the underlying requirement and communicate it in terms engineers can build from.
60% of the job is gathering, clarifying, and documenting requirements
Interviews, workshops, review meetings, rewrites. Requirements rarely arrive clean. Most of your time is spent pulling the real need out of vague requests and making it precise enough to be actionable.
Soft skills matter more than technical skills for most BA roles
The ability to run a productive stakeholder interview, mediate conflicting priorities, and write clearly for a mixed audience is more valuable day-to-day than SQL or process modelling tools. The tools are learnable; the communication instincts take time.
Traits that thrive in this role
Technical skills get you in the door. These are what make you good.
Organised
You're managing requirements from multiple stakeholders across multiple workstreams simultaneously. Without rigorous organisation, things fall through the gaps and the wrong thing gets built.
Inquisitive
Stakeholders rarely tell you everything they know. Great BAs ask follow-up questions, challenge assumptions, and dig past the first answer to find the real requirement underneath.
Strong writer
Requirements docs, gap analyses, user stories, meeting notes — almost everything you produce is written. Precision and clarity in writing directly determines whether the right thing gets built.
Diplomatic
You'll regularly sit between stakeholders who want conflicting things. Navigating competing priorities without alienating people — or letting ambiguity slide into the spec — is one of the hardest parts of the role.
Sees the big picture
Individual requirements live inside a larger system. Good BAs understand the business context well enough to flag when a requested feature conflicts with a business goal, even if nobody else in the room has noticed.
Career progression
Ready to start?
Ready to become a Business Analyst?
Structured lessons, real tools, and a learning path built around how Business Analysts actually work. Free to start.
Start the Business Analyst track