The BA-in-Product Field Guide
A field guide for business analysts moving into product roles.
So you're the BA in the room now.
A friendly, plain-language walkthrough of the role, built straight from the job description you were handed. Read it once top to bottom, then keep it around as a reference when a term or a ceremony trips you up.
The loop you'll live in
The five areas in your job description aren't a checklist you finish. Four of them feed each other in a loop, over and over, for every feature or fix you touch. The fifth, stakeholders, isn't a stop on the loop. It surrounds the whole thing, all the time.
This guide describes the full world of product thinking, because you'll be standing inside it every day. Your specific seat is Business Analyst inside a product team, so on day one you'll go deep on some of it and stay light on the rest.
You own heavily: gathering and documenting requirements, mapping how things work today versus how they should work, producing clear artefacts (diagrams, specs, user stories), supporting testing, and being the trusted go-between for business and tech.
You support, you don't solely own: the product roadmap, the vision, and the final call on what ships. Those sit with the product manager. You make their decisions sharper by handing them clean, well-analysed inputs.
So when a section below sounds huge, relax. You grow into the width of it. Your core job is to make ambiguity disappear so the people building can build.
Requirements & discovery
This is the foundation of everything. Requirements are all the things you need to gather before you can build a sensible solution, whether that solution is a new feature, a bug fix, or an improvement. And those requirements have to line up across every stakeholder who touches the thing: marketing, growth, finance, operations, and the users themselves.
The work you do before committing to build anything, to reduce the risk that you build the wrong thing. It's the deliberate act of learning whether a problem is real, whether people actually want the solution, and whether it's worth doing at all. Good discovery kills bad ideas early and cheaply, so engineering time goes only to things that matter.
A1Elicit, analyse, and document requirements
You have three main ways to pull requirements out of people and reality. Use whichever fits the moment, and often you'll combine them.
Direct questioning to understand a need. This ranges from a written survey, to a one-to-one call, to a one-to-many session where you interview several people at once. You're after the "why" behind what people do.
A scheduled, structured session where you get the right people in one room to brainstorm and align on a requirement together. The value is that decisions get made live, with everyone hearing the same thing at the same time.
Watching a real user actually use the product or run their process, without steering them. You learn what people do, which is often different from what they say they do. This is where you catch the workarounds, the confusion, and the friction that no interview surfaces.
A2Translate needs into stories, criteria, and specs
Once you understand what people need, you have a requirement in your head. Your job is to translate that into documentation that engineering and design can act on with zero guesswork. Design turns it into the UI and UX. Engineering turns it into working code. That documentation has three core building blocks.
A short, plain-language description of a need written from the user's point of view. The classic shape is: As a [type of user], I want [something], so that [benefit]. It keeps the team focused on the human and the outcome, rather than jumping straight to a solution.
The specific, testable conditions that must be true for a story to count as "done." They remove arguments later, because everyone agreed up front what finished looks like.
The fuller detail around a story: business rules, edge cases, data involved, and how it connects to other parts of the system. Where the story says what and why, the spec fills in the precise how and the boundaries.
A3Challenge assumptions, constructively
Here's a truth about the role: you handle a lot of stakeholders, and not every idea they bring is a good one. That's normal. Most people are tunnel-visioned toward what they personally know and want, so they miss how their request ripples out to other features, other users, other teams, and the data underneath.
Your value is that you zoom out. You take the bird's-eye view, spot the downstream impact, and then make the harder call about who to prioritise: the business goal, or user satisfaction, and by how much. Think of it as risk management. You're weighing which trade-off does the least damage while moving things forward.
The single most useful habit here: separate the stated request from the underlying need. People ask for a specific solution. Your job is to dig down to the real problem they're trying to solve, because there's often a better, cheaper, or safer way to solve it once you see the whole iceberg.
Process & solution analysis
If section A was about hearing needs, this is about understanding the machine those needs live inside, and then finding the smartest way to change it.
B1Map current state and target state
You need to understand the whole lifecycle of the product, at least the parts in your domain. And here's a mindset point worth internalising early: a good product person knows a little about everything. Even if you focus on one section of the product, you have an obligation to care about what everyone else is building, because your judgment is only as good as your view of the whole. Know everything enough to make a clear call. You don't need to know everything deeply. That balance is the skill.
So you start by mapping the as-is: what the product is genuinely good at, where the gaps are, what users hate, where the back end is fragile or slow, where the redundancy lives. Only once you can see the good and the bad clearly can you design the to-be: what to improve, what to automate, what tedious five-step process can collapse into two.
B2Produce clear artefacts
These are the deliverables that make your analysis legible to everyone else. Here's what each one is.
A step-by-step diagram of how a process moves from start to finish, including decision points. The as-is and to-be maps above are process flows.
A map of how data moves through a system: where it enters, where it's stored, what transforms it, and where it goes out. It answers "where does this piece of information live and travel?"
A description of how a user and the system interact to achieve a goal, step by step, including what happens when things go wrong.
Notes layered onto a low-fidelity screen sketch (a wireframe) that explain what each element does, what data it shows, and how it behaves. It's how you hand design intent to the team without ambiguity.
A table that links each requirement to its design, its build, and its test, so nothing gets lost. You can look at any requirement and prove it was designed, built, and verified.
B3Evaluate options and articulate trade-offs
A big part of product work is optimisation, doing the best possible thing for that specific moment. Sometimes you want to build heavily. Sometimes you can't afford to. Your job is to weigh the levers honestly and pick the least painful poison. There are three trade-offs you'll reach for constantly.
- Build vs configure — write custom code, or set up an existing tool to do the job?
- Scope vs timeline — go deep and wide, or ship something smaller to hit the date? A tight timeline forces a shallower scope, and that's fine when you name it out loud.
- Cost vs value — how much money and effort goes in, against the return you expect to get out?
A simple tool for prioritising a list of ideas is the value-versus-effort view. Plot each option, then let the picture make the argument for you.
Delivery support
Now the thing gets built. You don't disappear once the spec is written. You stay in the room, clarifying and unblocking, all the way through delivery.
C1Partner with the product trio
Product work runs on a tight three-way partnership.
The close working unit of Product (that's your side, owning the problem and the requirements), Design (owning UI and UX), and Engineering (owning the build). The three sit together and solve problems together. When the trio is tight and trusts each other, delivery is smooth. When it isn't, everything drags.
C2Support the sprint
Software gets built in short, repeating cycles called sprints. You support the ceremonies that keep each cycle honest. Here's the full loop, in the right order.
- Product backlog. The running, prioritised list of everything the team might build. The source of all work.
- Backlog refinement (ongoing). The continuous grooming of that list: clarifying items, adding detail, re-ordering by priority. This used to be called "grooming"; it's the same activity, now officially named refinement.
- Sprint planning. At the start of each sprint, the team picks which refined items it will commit to for this cycle.
- The sprint. The fixed time-box, usually one to four weeks, where the committed work actually gets built.
- Daily standup. A short daily sync inside the sprint. Each person shares what they did, what's next, and what's blocking them. Fast, not a status meeting.
- Sprint review. At the end of the sprint, the team demos the working product to stakeholders and gathers feedback. This is about the product.
- Retrospective. Right after the review, the team reflects on how they worked and how to improve next time. This is about the process, not the product.
C3Contribute to UAT
The final check before something goes live, where real users (or people standing in for them) confirm the software does what it was supposed to do in real conditions. You help by planning what to test, writing the test cases, and validating that what got delivered actually meets the acceptance criteria you wrote back in section A. This is where those criteria pay off: they become your test checklist.
Data & reporting
Opinions start arguments. Data ends them. This part of the role is about using real numbers to find problems, size them, and prove whether what you shipped actually worked.
D1Analyse operational and product data
When you build a feature or a product, data tells you the truth about it. You'll work with product analytics tools such as Mixpanel, PostHog, or Firebase to understand what users actually do. You dig into the data for a few reasons: to see what's working and what isn't, to understand user behaviour in general, and to follow conversion all the way through to the final action you care about. Here are the four core concepts you'll hear constantly.
A single recorded action a user takes, like "signed up", "started lesson", or "tapped subscribe". Events are the raw material of all product analytics. If it isn't tracked as an event, you can't measure it.
A sequence of steps you expect users to move through, showing how many make it from one step to the next. Funnels reveal exactly where people drop off, which is usually where your biggest problem, and your biggest opportunity, is hiding.
A group of users defined by something they share, like "everyone who signed up in June" or "teachers on the free plan". Cohorts let you compare groups fairly and spot which types of user behave differently.
The measure of how many users keep coming back over time. High retention is usually the strongest signal that a product is genuinely valuable, because people return to things that help them.
Tools like Mixpanel are powerful because they let you explore data freely. That freedom is also the trap: if you don't know what you're looking for, the blank canvas is paralysing. The fix is D2. Decide your metrics before you go exploring.
D2Define reporting and dashboard requirements
Before you get lost in free exploration, define the specific metrics your dashboard needs to show. The habit that separates good product people from the rest: decide, from the very beginning of building a feature, which metrics you'll track to judge whether it worked. When you know your metrics up front, it becomes easy to justify how you build things and why. Depending on your product, your dashboard might lean toward learning and operational metrics (course completion, active classes, support load) as much as pure subscription numbers. Here's what a simple dashboard could look like:
Typical metrics to define: daily, weekly, and monthly active users (DAU / WAU / MAU); onboarding conversion and drop-off rate; and conversion on key calls-to-action like the subscribe page. Name them before you build, and the whole team knows what success looks like.
Stakeholder management
There's a saying in the product community: good product managers bring donuts. It's only half a joke. Relationships are the job. You are the trusted line between the people who run the business and the people who build the technology.
E1Be the reliable point of contact
Technical people tend to speak in a precise, structured, straightforward way. The business units, education delivery, operations, commercial, tend to be more creative, flexible, and dynamic. You sit in the middle as the translator and the mediator. You run the requirement-gathering conversations, help the group decide where to move next, and turn insight into something both sides understand. When you're a reliable point of contact, both sides stop talking past each other and start moving together.
E2Communicate progress, risks, and decisions
The other half of stakeholder work is keeping everyone informed clearly. For any piece of work, people want to know: the current state, what's being built, the obstacles you're hitting, what you're doing about them, and a realistic ETA. Alongside that, you communicate risk (what could go wrong and how likely) and the decisions being made and why. And you do all of this in language that lands for both a technical audience and a non-technical one. Same message, two translations. That skill, more than any tool, is what makes people trust you.
Here's a simple structure you can copy straight into your first weekly update email or Slack post. Fill in the blanks and you'll already look more organised than most.
Status: on track / at risk / blocked
Built this week: what got done, in one or two plain lines
Blockers: what's in the way, and who or what unblocks it
Next: what happens in the coming week
ETA: realistic date, updated honestly if it moved
Risks: what could go wrong + how likely + what we're doing about it
Decisions needed: anything you need from the reader, stated plainly
copy this · fill the blanks · send it every week without fail
Your first two weeks
Everything above is the map. This is what to actually do on Monday. Work through these in roughly this order and you'll build context faster than anyone expects from a new joiner.
- Shadow one real user, end to end.Watch someone actually use the product or run the process. Say nothing, take notes. This is your first observation session (A1) and it will teach you more than any deck.
- Read the last three sprint boards.Open the team's board (Jira, ClickUp, whatever they use) and read the last three sprints' worth of tickets. You'll absorb the vocabulary, the pace, and what "done" looks like here.
- Book one coffee per business unit.One person each from education delivery, operations, and commercial. Ask them two things: what the tech team does well, and what frustrates them. You've just started your stakeholder map (E1). Bonus points for donuts.
- Find the existing dashboards.Ask where the team already looks at numbers (Mixpanel, PostHog, internal reports). Learn which metrics they watch. Don't build anything yet, just learn what "normal" looks like (D2).
- Read the two most recent specs.Find the last couple of user stories or specs the team shipped from. Notice their format, their level of detail, their acceptance criteria style. Your first documents should look native, not foreign (A2).
- Sit in every ceremony once, silently.Attend a standup, a refinement session, a planning session, and a retro before you try to run or contribute heavily to any of them. Learn the room first (C2).
- Sketch one as-is process map.Pick any small process you've now seen and draw it, boxes and arrows, nothing fancy. Show it to someone and ask "did I get this right?" That question makes friends and builds your reputation at the same time (B1).
Six books worth your time
You don't need these on day one, but they'll compound fast. The first three come straight from my own shelf. The last three I'm adding because they're the most useful for the analysis side of your role specifically.
One last thing, from me to you.
All of this looks complicated laid out on a page, and honestly, it is a lot at first. But here's the real secret: every product person has their own way of approaching the work. There's no single correct style, so don't push too hard on yourself to have it all figured out right now.
You will get better. That's not a maybe, it's just how this role works. You'll pick up new skills, unlock new little superpowers, and gain knowledge you don't have yet, and one day you'll realise the terms in this guide have become second nature. Not knowing something yet is completely normal. The only move is to keep learning and keep improving, and you already do that.
Product management looks hard from the outside. From the inside, it's genuinely one of the most fun roles there is. You get to solve real problems for real people, every single week. Enjoy it.
Glossary index
Every term in one place. Tap any term to jump back to its full explanation and example.
- Discovery
- Work done before building, to reduce the risk of building the wrong thing.
- Interviews
- Direct questioning (survey, one-to-one, one-to-many) to understand a need.
- Workshops
- A scheduled group session to brainstorm and align on requirements live.
- Observation
- Watching real users to learn what they actually do, not what they say.
- User story
- A need from the user's view: as a [user], I want [x], so that [benefit].
- Acceptance criteria
- The testable conditions that define when a story is done.
- Specification
- The detailed rules, edge cases, and data behind a story.
- Process flow
- A step-by-step diagram of how a process runs, with decision points.
- Data flow diagram
- A map of how data enters, moves, transforms, and exits a system.
- Use case
- How a user and system interact to reach a goal, including failure paths.
- Wireframe annotation
- Notes on a screen sketch explaining what each element does.
- Traceability matrix
- A table linking each requirement to its design, build, and test.
- Product trio
- The tight unit of Product, Design, and Engineering.
- Backlog
- The prioritised list of everything the team might build.
- Refinement
- Ongoing grooming of the backlog; clarifying and re-ordering items.
- Sprint planning
- Choosing which items to commit to for the coming sprint.
- Sprint
- A fixed time-box (1–4 weeks) where committed work gets built.
- Daily standup
- A short daily sync on progress, next steps, and blockers.
- Sprint review
- End-of-sprint demo of working product to stakeholders.
- Retrospective
- Team reflection on how to work better next sprint.
- UAT
- User Acceptance Testing: final real-user check before go-live.
- Event
- A single recorded user action, the raw unit of analytics.
- Funnel
- A sequence of steps showing where users drop off.
- Cohort
- A group of users defined by something they share.
- Retention
- How many users keep coming back over time.
- DAU / WAU / MAU
- Daily, weekly, and monthly active users.
Made as a handoff for a friend stepping into product. Keep it close, outgrow it fast.
This guide collects what I learned moving between BA and product work.
It covers the mindset shift, the artifacts that transfer, and the ones you have to unlearn. Published here as a pipeline verification artifact.