Auto PM

Study guide

Product management and business analysis, end to end

Ten stages, in the order the work actually happens, taught through one worked example: Rota Relief, helping coffee-shop managers fill last-minute shift gaps. Each stage tells you what it is, what to produce, what the example looked like, what newcomers get wrong, and where in Auto PM you do it. Read it once end to end, then keep it open beside your first project.

01

Research and discovery

PM leads · BA runs the interviews

Whose problem is this, and how do we know?

Before anything is built, you collect first-hand material: customer interviews, support tickets, sales-call notes, usage data, complaints. The goal is not ideas — it is evidence. An idea is an opinion until a real person has said or done something that backs it.

How to do it

  • Book 5–8 conversations with people who actually live the problem. Five is usually enough to hear the same thing three times.
  • Ask about the last time it happened, never about the future. "Tell me about the last shift you couldn't fill" beats "Would you use an app that…".
  • Write down quotes verbatim. Your own paraphrase quietly deletes the inconvenient half.
  • Pull the boring sources too: support tickets, cancellation reasons, the sales team's lost-deal notes.
  • Tag every piece with who said it and when, so you can trace any later decision back to it.

What you produce

  • An evidence log: one row per quote or observation, with source, segment and date.

The example: Rota Relief

  • Our worked example is Rota Relief — helping coffee-shop managers fill last-minute shift gaps.
  • Eight managers interviewed. Four said they spend the first hour of every shift phoning staff one by one. Two said they open understaffed roughly once a fortnight. One said: "I text twelve people and the first yes is usually someone who isn't trained on the machine."
  • Support tickets showed 31 messages in three months containing the word "cover".

What newcomers get wrong

  • Asking leading questions and calling the agreement validation.
  • Talking only to friendly customers, who never churn and never complain.
  • Skipping straight to solutions in the interview — you get design feedback instead of problem evidence.

In Auto PM: Evidence tab

02

Synthesis and insights

BA leads

What is the pattern underneath all this raw material?

Raw quotes are unusable on their own. Synthesis is the act of grouping them into themes, then writing a one-sentence insight per theme — a statement about behaviour, not a feature request. Each insight must point back at the quotes that produced it.

How to do it

  • Put every quote on its own card and group cards that share a cause, not a keyword.
  • Name each group in the customer's words, not yours.
  • Write the insight as: [who] [does what] [because] [and it costs them what].
  • Count the mentions. Three managers saying it is a theme; one saying it loudly is an anecdote.
  • Keep the disagreements. The segments that behave differently are usually the real finding.

What you produce

  • Themes with mention counts, and one written insight per theme.

The example: Rota Relief

  • Theme: "Phoning round" — 6 of 8 managers, ~40 minutes per gap.
  • Insight: Managers contact staff one at a time because they have no list of who is trained, free and willing, so the fastest yes is often the wrong person.
  • Second theme: "Nobody wants to say no" — staff ignore the message rather than decline, so managers never know who to skip next time.

What newcomers get wrong

  • Jumping from one interview to a roadmap item.
  • Grouping by feature ("notifications") rather than by cause ("no view of who is eligible").

In Auto PM: Insights tab

03

Opportunity framing

PM and BA together

Which problems are worth solving, stated as problems?

An opportunity is a problem worth money or time, written before any solution exists. Framing it properly keeps you from falling in love with a feature. Each opportunity names the segment, the current behaviour, the pain and the measure that would move if you solved it.

How to do it

  • Write it as a problem: "Managers cannot see who is eligible for a gap", not "Build an eligibility filter".
  • Name the segment narrowly. "Single-site coffee shop managers" beats "users".
  • Record what they do today, including the workaround — the workaround is your competition.
  • Attach the candidate metric: what number proves this got better?
  • Link it to the evidence count. An opportunity with one quote behind it is a guess, and should say so.

What you produce

  • An opportunity per problem, each with segment, current behaviour, candidate metric and evidence count.

The example: Rota Relief

  • Opportunity: single-site managers lose ~40 minutes per gap because eligibility lives in their head. Today they phone down a mental list. Candidate metric: median minutes from gap opened to gap filled.
  • Opportunity: managers cannot tell a "no" from a "not read". Candidate metric: share of outreach that gets an explicit answer.

What newcomers get wrong

  • Smuggling the solution into the problem statement.
  • Writing a metric you cannot actually measure with the data you have.

In Auto PM: Opportunities tab

04

Prioritisation

PM decides · BA supplies the evidence

What do we do first, and can I defend that in a room?

Prioritisation is not a spreadsheet trick; it is a way of making your reasoning visible so others can argue with the reasoning instead of with you. The common frames are RICE and MoSCoW. Both are wrong in the details and useful in the ranking.

How to do it

  • RICE = (Reach × Impact × Confidence) ÷ Effort. Reach = people affected per period. Impact = 0.25 to 3. Confidence = how sure you are, as a percentage. Effort = person-weeks.
  • Score relatively, not absolutely. You only need the order to be right.
  • Write one line of reasoning per score. In six weeks nobody remembers why impact was 2.
  • Use MoSCoW (Must, Should, Could, Won't) for a release scope conversation; use RICE for a ranking conversation.
  • Say out loud what you are deliberately not doing. A prioritisation without a "Won't" is a wish list.

What you produce

  • A ranked list with a visible score and a one-line rationale per item.

The example: Rota Relief

  • Eligibility list: reach 400 gaps/quarter, impact 2, confidence 80%, effort 4 weeks → 160.
  • Explicit decline: reach 400, impact 1, confidence 70%, effort 1 week → 280. It ranks higher because it is cheap, and it unlocks the data the eligibility list needs.

What newcomers get wrong

  • Pretending the numbers are measurements. They are arguments with decimal points.
  • Scoring alone. The value is the conversation with engineering and design.

In Auto PM: Opportunities and Roadmap tabs (RICE scoring)

05

The PRD

PM writes · BA supplies the detail

What are we building, for whom, and how will we know it worked?

A product requirements document is the single place a newcomer can read to understand the decision. Good PRDs are short, specific and honest about what is unknown. They cover the problem, goals, users, scope, requirements, metrics, risks and open questions.

How to do it

  • Open with the problem and the evidence, not the feature.
  • State goals as outcomes with numbers, and write the non-goals underneath.
  • Describe the users and the journey in their language.
  • Write requirements as testable statements: "The manager can see, for one gap, every employee who is trained, available and opted in."
  • List the metrics: one primary, two or three supporting, and a guardrail that must not get worse.
  • Keep an open-questions section and date every answer. Unknowns you name are manageable; unknowns you hide are not.

What you produce

  • A PRD of roughly 8 sections, reviewed by engineering, design and one sceptic.

The example: Rota Relief

  • Rota Relief PRD — primary metric: median time to fill a gap, from 41 minutes to under 15. Guardrail: no increase in shifts filled by untrained staff.
  • Non-goal: full rota scheduling. We are solving the gap, not replacing the roster.

What newcomers get wrong

  • Writing 40 pages nobody reads. Anything longer than a coffee break gets skimmed.
  • Specifying the screen instead of the requirement, which quietly removes design from the process.

In Auto PM: PRD tab (with shareable review links)

06

Business analysis in depth

BA leads

How does the work actually happen today, and what exactly must change?

This is the BA's core craft and the part most new starters skip. You document the current process, design the target process, name the gap between them, and turn that gap into numbered requirements that a developer and a tester can both read without asking you a question.

How to do it

  • Draw the as-is process: every step, every decision, every handoff, including the spreadsheet nobody admits to.
  • Draw the to-be process next to it, and write the gap as a sentence per difference.
  • Write personas and use cases: actor, preconditions, main flow, alternate flows, what happens when it fails.
  • Number every requirement and give each a priority. Numbers are what make traceability possible.
  • Build a data dictionary for the new fields: name, type, allowed values, who owns it.
  • Prepare elicitation question packs before each workshop, grouped by who you are asking.
  • Keep a stakeholder register with RACI — who is Responsible, Accountable, Consulted and Informed for each decision.

What you produce

  • As-is/to-be flows, numbered requirements, use cases, personas, a data dictionary, a stakeholder RACI register and a change log.

The example: Rota Relief

  • As-is: gap appears → manager recalls who might be free → phones down the list → verbal yes → writes it on the paper rota.
  • To-be: gap appears → system lists eligible, available, opted-in staff → offer sent to all of them → first accept wins → rota updated and both parties notified.
  • Requirement R-07: an employee may only be offered a shift they are qualified for at that store. Priority: Must.

What newcomers get wrong

  • Documenting the process managers describe rather than the one they perform. Watch, don't only ask.
  • Requirements that cannot be tested: "the system should be fast".

In Auto PM: Business analysis tab

07

Backlog and acceptance criteria

PM and BA together with the team

What is the smallest next slice a team can build and a tester can verify?

The backlog turns requirements into work. An epic is a chunk of value; a story is a slice of it that a user can feel. Acceptance criteria say precisely when a story is done — the single most valuable thing a new BA can learn to write well.

How to do it

  • Write stories as: As a [role], I want [capability], so that [outcome].
  • Keep them vertical — each story should deliver something a user can see, not "build the database table".
  • Write acceptance criteria in Given / When / Then form, one per rule, including the unhappy paths.
  • Estimate relatively with the team (points or t-shirt sizes); never estimate on their behalf.
  • Refine little and often. An hour a week beats a four-hour marathon.

What you produce

  • Epics, stories with acceptance criteria and estimates, refined and ready for a sprint.

The example: Rota Relief

  • Story: As a manager, I want to see only staff trained for this store, so that I never offer a shift to someone who cannot work it.
  • Given an open gap at Store A, When I open the eligible list, Then only employees with an active Store A qualification and no clashing shift appear.
  • Given an employee has opted out of notifications, When offers are sent, Then they receive nothing and are shown as opted out.

What newcomers get wrong

  • Acceptance criteria written as a to-do list for developers instead of observable behaviour.
  • Stories sliced by layer (backend / frontend), which means nothing ships until everything ships.

In Auto PM: Backlog tab (with Jira two-way sync)

08

Roadmap and delivery

PM owns the sequence · BA owns the detail flowing in

In what order, by when, and what could stop us?

A roadmap communicates sequence and intent, not promises to the day. Alongside it you keep dependencies and risks: what must happen first, what might go wrong, how likely and how bad, and who is watching it.

How to do it

  • Sequence by dependency and learning, not by who shouted loudest.
  • Use now / next / later with any team that has never hit a date; use dates only where a real deadline exists.
  • List dependencies explicitly, including on other teams and on legal or procurement.
  • For each risk record severity, likelihood, mitigation and an owner. A risk with no owner is a wish.
  • Attend stand-up, but manage by unblocking, not by asking for status.

What you produce

  • A sequenced roadmap, a dependency list and a live risk register.

The example: Rota Relief

  • Explicit decline ships first (1 week) because eligibility scoring needs the decline data.
  • Risk: employee qualification data is maintained by hand and may be stale. Likelihood high, severity high. Mitigation: show the last-updated date next to every name and ask managers to confirm before sending.

What newcomers get wrong

  • Turning the roadmap into a Gantt chart of promises, then spending your year explaining slippage.
  • Tracking risks in your head.

In Auto PM: Roadmap, Analysis roadmap and Risks tabs

09

Testing, UAT and launch

BA leads UAT · PM owns the launch

Does it do what we said, and is the business ready to use it?

User acceptance testing is the business confirming the built thing matches the agreed requirement — separate from the engineers' own testing. Launch is everything around the software: training, comms, support notes, the rollback plan.

How to do it

  • Write UAT cases straight from the acceptance criteria: preconditions, test data, numbered steps, expected result.
  • Have a real user run them, not you. You know too much.
  • Record pass / fail / blocked with a note; a failed test must become a defect with a number.
  • Roll out gradually — a few sites first, then the rest — and agree in advance what would make you stop.
  • Write the support and training notes before launch day, not after the first complaint.

What you produce

  • A UAT pack with results, a launch checklist, release notes and a rollback plan.

The example: Rota Relief

  • UAT-03: Given a gap at Store A and two trained staff, when the manager sends offers and both accept within a minute, then exactly one is confirmed and the other sees "already filled".
  • Launch: four pilot stores for two weeks. Stop condition: any shift filled by an unqualified employee.

What newcomers get wrong

  • Treating UAT as a formality signed off the day before release.
  • Launching without telling support what changed.

In Auto PM: UAT tests and Documents tabs

10

Metrics and learning

PM leads · BA verifies the numbers

Did it work, and what do we do with the answer?

Shipping is the middle of the job, not the end. You measure against the number you wrote in the PRD, tell people honestly what happened, and feed the surprises back into the evidence log so the next cycle starts better informed.

How to do it

  • Measure the metric you committed to, including the guardrail, over a fair window.
  • Compare against the baseline you captured before launch — capture it before, or you never can.
  • Interview a few users again; the number tells you what changed, they tell you why.
  • Write a short outcome note: what we expected, what happened, what we now believe, what we will do next.
  • Publish the misses as clearly as the wins. Your credibility comes from this, not from the wins.

What you produce

  • An outcome review, updated beliefs, and new evidence for the next cycle.

The example: Rota Relief

  • Median fill time moved 41 → 18 minutes; target was 15. Guardrail held: zero unqualified fills.
  • Surprise: a third of accepted offers came from staff at a nearby store, which nobody had designed for. That became the next opportunity.

What newcomers get wrong

  • Declaring success at launch, because the feature exists.
  • Losing the baseline and arguing about whether things improved.

In Auto PM: Documents and Ask Auto PM tabs

Product manager or business analyst — who does what

In a small company one person does both. In a larger one the split below is the usual shape, though every team draws the line slightly differently — ask on day one where yours sits. The short version: the PM owns why and what for; the BA owns exactly what and how we prove it.

Decides what gets built and whyProduct manager
Decides what "built" precisely meansBusiness analyst
Owns the outcome and the metricProduct manager
Owns the requirements and their traceabilityBusiness analyst
Runs the prioritisation conversationProduct manager
Runs elicitation workshops and process mappingBusiness analyst
Writes the PRDProduct manager (with BA detail)
Writes acceptance criteria and UAT casesBusiness analyst
Talks to executives about trade-offsProduct manager
Talks to operations about how the work really happensBusiness analyst

Your first week, day by day

Day 1

Get access to everything: the backlog, the analytics, the support inbox, the team's chat. Read the last three months of release notes. Meet your engineering lead and your designer.

Day 2

Read every existing document about your area, and write down every term you don't understand. Ask someone to explain them — nobody expects you to know the acronyms in week one, and everyone notices if you pretend.

Day 3

Sit with the people who use the product, or listen to five support calls. Write down verbatim quotes. This is your first evidence.

Day 4

Draw the as-is process for one workflow and show it to the team. Being wrong in public on a whiteboard is the fastest way to learn a domain.

Day 5

Pick the smallest real thing: write acceptance criteria for one story in the backlog, and have the engineer and tester review them. Ship something small in week two.

Case studies — four situations you will meet

Each one is a shape of problem rather than a company name: the reframe, the solution handed to you as a request, the artefact that missed its context, and the release that grew quietly. Read the situation, decide what you would do, then read what was done.

Rota Relief — the worked example

A coffee chain losing an hour a morning to phone calls

Twelve stores. When someone calls in sick at 6am the manager phones down a mental list of who might be free. Cover is often confirmed after opening, sometimes not at all. Nobody above store level knows it happened until the sales look wrong the next day.

What they did

  • Interviewed five people across three roles — store managers, hourly staff and an area manager — and pulled three months of support tickets mentioning 'cover'.
  • Found two distinct problems, not one: managers cannot reach everyone at once, and they cannot tell a refusal from an unread message.
  • Framed the opportunity as a measurable outcome — minutes from a shift being dropped to cover being confirmed — rather than as 'build a shift app'.
  • Wrote an explicit out-of-scope list: no payroll, no contracts, no anything a manager does not do at 6am.
  • Sequenced the roadmap so broadcast and one-tap accept shipped first and reporting shipped last, because reporting on no data is theatre.

What happened: The backlog reduced to 6 epics and 24 stories, every one traceable to a quote. The overtime risk surfaced in analysis, not in the first payroll run.

The lesson: The value came from the reframe, not the build. 'Cover is confirmed late' can be measured and argued about; 'we need a shift app' cannot.

The onboarding form that nobody finished

When the requirement was right and the problem was elsewhere

A lender's new-customer form was abandoned by more than half the people who started it. The business asked for a shorter form — a solved-sounding request with a named solution attached.

What they did

  • The analyst refused to start from the solution and pulled the drop-off point per field from the data first.
  • Nearly all abandonment happened on one screen asking for an employer reference number most applicants did not have to hand.
  • Five short interviews confirmed it: people left to find the number and never came back.
  • The requirement became 'let an applicant save and resume', not 'remove fields'.

What happened: A far smaller change than the one requested, delivered in one sprint, addressing the actual cause.

The lesson: When a stakeholder hands you a solution, your first job is to find the problem behind it — politely, with data, before anybody has committed publicly.

The dashboard nobody opened

Shipping the artefact instead of the outcome

An operations team asked for a dashboard showing warehouse throughput. It was built, demoed well, and after three weeks had four unique users out of forty.

What they did

  • A retrospective walked the as-is process and found supervisors were on the floor, not at a desk, during the hours the numbers mattered.
  • The real need was to be told when throughput fell below a line, not to go and look.
  • The replacement was a threshold alert to the handheld devices they already carried.

What happened: The dashboard stayed for the weekly review; the alert did the daily work. Usage stopped being the measure — response time became it.

The lesson: Ask where the person will be standing when they use it. A requirement that ignores the context of use is a requirement that will be ignored.

The release that grew in the dark

Why 'out of scope' is the most valuable page in a PRD

A four-week payments change ran fourteen weeks. No single decision caused it; eleven small additions did, each one reasonable, each agreed in a corridor.

What they did

  • The team started writing every addition in a change log with who asked and what it displaced.
  • The PRD got an explicit out-of-scope section, and anything moving into scope had to name what moved out.
  • The roadmap bars were re-cut publicly each time, so the cost was visible at the moment of the decision instead of at the deadline.

What happened: The next release of similar size landed within a week of its estimate — with five requests logged and declined, in writing.

The lesson: Scope does not creep, it is added. Make each addition visible and priced, and most of them withdraw themselves.

PM vs BA quiz — ten questions

Judgement questions, not trivia. Answer all ten, then check — every answer explains itself, and the explanations are the point. Eight or more and you can hold a planning meeting on day one.

01A stakeholder says “we need a filter on the shift list”. What do you do first?

02Who normally owns the decision about which problem the team solves next?

03Which of these is an insight rather than a feature request?

04You have five interviews and everybody said something different. What does that mean?

05What belongs in the acceptance criteria for a story?

06Which is an outcome metric rather than an output metric?

07Traceability mostly protects you from which question?

08UAT has been drafted straight from acceptance criteria. What is still missing?

09A senior stakeholder asks for a date in a meeting and you do not have one. Best answer?

10Which is a legitimate reason to write 'out of scope' in a PRD?

Practice run — Rota Relief, end to end

Reading this teaches you the vocabulary. Running one full chain teaches you the job. Rota Relief already has evidence, a PRD and a backlog in it — work the ten steps below inside that project, doing each piece yourself first and only then comparing with what the app drafts. That comparison is where the learning is.

  1. 01Open the project. Open Rota Relief from your dashboard and read the Overview. Note what already exists before you touch anything — that habit alone separates a confident first week from a chaotic one.
  2. 02Read the evidence. Go to the Evidence tab and read all twelve items without judging them. Write down, on paper, the three phrases that repeat across different people.
  3. 03Find the patterns yourself. Before pressing anything in the Insights tab, write your own two or three insights in the format [who] [does what] [because] [and it costs them what]. Then draft the insights and compare. Where you differ, decide who is right — usually you, because you read the quotes.
  4. 04Frame the problems. In Opportunities, turn your themes into problems with a segment and a candidate metric. Refuse any wording that names a solution. Score them with reach, impact, confidence and effort, and write one line justifying each confidence score.
  5. 05Write the decision. In the PRD tab, tick your top opportunities and draft. Then read it as an engineer: every spot you would have to ask a question is a gap. Fix those yourself before running the critic.
  6. 06Break it into work. Generate the backlog, then hand-write acceptance criteria for two stories before letting the app draft the rest. Comparing your version with the drafted one is the fastest acceptance-criteria training there is.
  7. 07Do the analysis. In Business analysis: draft personas, use cases and requirements, then the stakeholder register, then the interview scripts for each person on it. Run the gap analysis and process flows and check the to-be actually closes the as-is.
  8. 08Sequence it. On the Roadmap, put the broadcast and accept work first. Then open Analysis roadmap and make sure each requirement is analysed before the epic that needs it starts.
  9. 09Prove it. Draft the UAT pack, then add three unhappy paths yourself: two people accepting at once, a phone with no signal, someone accepting then withdrawing.
  10. 10Close the loop. Open the Traceability grid and chase every amber row until each story can be followed back to a quote. Then write the exec brief in Documents and read it as if you were the director receiving it.

Then do it again on a problem of your own

The second run is the one that makes you employable, because nothing is pre-filled and the evidence has to be real.

  1. 01Create a project from a problem you actually have — a club rota, a small shop, a course group.
  2. 02Add five real pieces of evidence: things people genuinely said to you. No invented quotes; the whole method collapses on invented input.
  3. 03Turn them into insights, then into two or three opportunities written as problems.
  4. 04Score the opportunities with RICE and write the one-line reason for each score.
  5. 05Draft the PRD, then read it as if you were an engineer being asked to build it. Every place you'd have to ask a question is a gap.
  6. 06Generate the backlog, then hand-write the acceptance criteria for two stories yourself before comparing with the drafted ones.
  7. 07Draw the as-is and to-be flows in the Business analysis tab and see whether your requirements actually close the gap.
  8. 08Write the UAT pack and get a friend to run it against your own description. They will find the hole.
  9. 09Share the PRD link with someone and ask for a change request. Handling feedback is half the job.
Start a projectSee a finished example

Glossary — the words people will use around you

Acceptance criteria
The conditions a story must meet to be accepted, usually written Given / When / Then.
Backlog
The ordered list of work not yet done.
BRD / FRD
Business and functional requirements documents — heavier, older cousins of the PRD, still standard in enterprises and consultancies.
Definition of done
The team's shared checklist applied to every story: tested, documented, deployed.
Elicitation
The BA word for getting requirements out of people: interviews, workshops, observation, document analysis.
Epic
A large chunk of value, delivered as several stories.
Gap analysis
The written difference between how work happens today (as-is) and how it should happen (to-be).
Guardrail metric
A number that must not get worse while you improve the main one.
MoSCoW
Must, Should, Could, Won't — a scope-setting frame for a release.
MVP
The smallest version that tests the belief, not the cheapest version of the full idea.
North star metric
The one number that best represents delivered customer value.
Persona
A named, evidence-based description of a user type and what they are trying to do.
PRD
Product requirements document — the shared description of the problem, scope and success measures.
RACI
Responsible, Accountable, Consulted, Informed — who plays which part in a decision.
Refinement / grooming
The recurring session where the team clarifies and estimates upcoming stories.
RICE
Reach, Impact, Confidence, Effort — a scoring frame for ranking.
Stakeholder
Anyone affected by the change or able to block it.
Traceability
The chain from a piece of evidence to an opportunity, a requirement, a story, a ticket and a test.
UAT
User acceptance testing — the business confirming the build matches the agreed requirement.
User story
As a [role], I want [capability], so that [outcome].