A field guide for the BA in product
A visual, jargon-light guide for anyone stepping into a business analyst seat on a product team.
You got the title before you got the map. This is the map. A working picture of what a business analyst does on a product team, drawn so you can read it on a train and still follow the arrows.
What a BA actually owns
On day one the useful question is not what a BA is. It is which decisions land on your desk and which do not. Get that clear early and you save yourself a month of guessing.
You own
- The real problem behind a request
- Clear, testable requirements
- Shared understanding across the team
- Tracing a delivered feature back to its need
You partner on
- Priority calls, led by the product owner
- Design of the solution, with designers
- Estimates and feasibility, with engineers
- Acceptance, with QA
You stay out of
- Writing the production code
- The final go or no-go budget call
- Line-managing the delivery team
The loop you run all week
The five buckets repeat. Most of your week is somewhere on this ring.
From a vague request to something buildable
Requests arrive half-formed. Someone says "add a reset button." Your job is to walk that request down a short pipeline until it is specific enough that an engineer could build it and QA could test it without asking you what you meant.
The iceberg: what they said vs what they need
Stated requests sit above the waterline. The reason they matter sits below it. A BA who only builds the stated request ships buttons nobody needed. Look down.
Same request, read at four depths. The button is the tip.
Map how it works now, then how it should work
Before you design anything, draw the current path and the proposed one side by side. The gap between them is the actual scope of your change, and it is usually smaller and clearer than the conversation made it sound.
As-is
- User cannot log in
- User emails support
- Support waits, then replies
- Agent resets the password by hand
- User waits for the all-clear
To-be
- User cannot log in
- User clicks "Forgot password"
- System emails a secure reset link
- User sets a new password
- User is back in, no agent needed
Deciding what is worth doing first
You will not own the final priority call, but you will be asked to frame it. The fastest honest frame is value against effort. Put candidate work in the grid and the quick wins pick themselves out.
Where you sit among the people
A product gets built by three groups pulling in the same direction: the people who own the what, the people who shape how it looks and feels, and the people who make it real. You thread through all three, keeping the story straight as it moves between them.
The bridge you hold up
Needs come from the left in plain words. They cross to the right as buildable specs. You keep the meaning intact in both directions.
Inside a sprint, done right
Here is the model most people arrive with and get wrong: they picture a sprint as small waterfall phases, where you design, then build, then test in sequence. That is not how it runs. A sprint is a short, repeating loop where building and testing happen together, and refinement feeds the next round while the current one is still live.
Backlog refinement ›
Sprint planning ›
Daily standup ›
Build and test ›
Sprint review ›
Retrospective ›
Proving the change worked
Shipping is not the finish line. You close the loop by checking the numbers moved in the direction you promised. For the reset work, that means support tickets down and more users getting back in on their own. Read a dashboard as a set of claims you can confirm.
Read the funnel for the drop
Illustrative numbers. The biggest drop is email to click, so that step is where you dig next.
Your first two weeks
You do not need to understand the whole product to be useful. You need to understand the people and the process. Work this list and you will be contributing before the month is out. Tap to tick them off.
Where to go next
Six books, no filler. The blue-tagged ones are the ones I would open first.
Glossary
Every term defined once, in one place, in plain words.
One last thing. Nobody expects you to know the product on day one. They expect you to ask the question everyone else stopped asking, which is "what are we actually solving here." Hold onto that habit. It is the whole job, and you already have it.
I first built a version of this for a friend moving into a business analyst seat on a product team. He had the title before he had the map, which is the usual way it goes. I cleaned it up and published it so anyone in that spot can use it.
The diagrams do the heavy lifting here. Every term is defined inline the first time it appears and gathered again in a glossary at the end, so you can read it straight through or jump around. The sprint section fixes the mental model most people arrive with on day one, and one worked example (a broken password reset) runs through the middle so the abstract parts land on something concrete.
It is for new BAs, for product managers who sit next to a BA and want a shared vocabulary, and for teams onboarding someone into the role. Read it on your phone if you like. It was built to hold up there.