The mid-level BA reference

What an NFR actually is

Functional requirements describe what the system does. Non-functional requirements describe how it does it — performance, availability, security, scalability, accessibility, observability, compliance. Mid-level BAs are expected to surface them deliberately; most projects fail because NFRs were treated as "engineering will sort that out".

The seven NFR categories you'll meet

How to write a good NFR

Who surfaces NFRs in a conversation

• Tech leads raise performance, availability, scalability — they live with the consequences when these break.
• Compliance and security teams raise security, GDPR, audit, accessibility — usually with phrases like "we have to demonstrate" or "the regulator expects".
• Operations / support teams raise observability — they want logs they can troubleshoot from at 2am.
• Sponsors rarely raise NFRs directly but will react strongly when an outage or breach happens. Anticipate.

SOAP, REST, wrappers — what a BA actually needs to understand

Integration is where waterfall specs break and agile sprints stall. Most BAs aren't expected to architect the integration — but a mid-level Software BA is expected to understand it well enough to write requirements against it, to challenge a tech lead's assumptions, and to translate the limits of a legacy system into business-language risk.

Two things at the centre: SOAP and REST

When a tech lead says "we'll integrate via the API", the unspoken question is which kind. The two you'll meet on real projects are SOAP and REST. They are not the same and the difference matters to a BA because it changes what's possible, what's reliable, and what's affordable.

What a wrapper is — and why it matters

A "wrapper" is a thin layer of code that sits in front of a legacy system and presents a modern API. The legacy system underneath stays as it was; the wrapper translates modern requests (often REST or SOAP) into the legacy system's native commands. Wrappers are common because the cost of replacing a legacy core is usually 10−100× the cost of putting a wrapper on it.

The catch: wrappers inherit the limits of the system they wrap. If the legacy system can only handle 3 transactions per second, the shiniest REST wrapper on top still only handles 3 transactions per second. That number is what an integration tech lead is really telling you when they say "the wrapper has a transaction-rate ceiling".

Legacy integration patterns — the four you'll meet

• Direct integration. Your new system talks to the legacy system natively (often through a database connection or a vendor SDK). Cheapest to build, brittlest in production — a change to the legacy system can break your system without warning.
• Wrapper / facade. A thin translation layer in front of the legacy system. Adds a layer of safety: the legacy system can change underneath without breaking the consumers, as long as the wrapper contract stays stable.
• Middleware / ESB (Enterprise Service Bus). A central piece of software that routes requests between many systems. Useful when you have lots of legacy systems that need to talk to each other. Heavy, expensive, slow to change — but predictable.
• API gateway + cache layer. Modern variant of the wrapper pattern. A gateway sits in front of one or more upstream systems, handles authentication, throttling, and caching. The cache layer is often what saves you when the upstream system can't sustain the load.

What a BA captures about an integration (the requirement checklist)

When you're writing a requirement against an integration point, these are the things your spec or your story needs to cover. Miss any of them and you'll be re-opening it in week 4.

The questions to ask your tech lead in the integration conversation

• "Walk me through the integration paths." Get the architecture in their words, not the documentation's.
• "What's the transaction-rate ceiling on the wrapper / upstream?" The number you get back drives FR-INT-* and your NFR-SCALE-* requirement.
• "What breaks first — latency, throughput, or correctness — if we go above the ceiling?" Tells you which fallback to design first.
• "If the wrapper is unavailable for 10 minutes, what's the fallback?" Surfaces resilience requirements you'd otherwise miss.
• "Is the upstream's data the master, or are we?" Determines whether you cache, mirror, or always read live.
• "If we wanted to replace the wrapper, what would it cost?" Useful for the three-options business case. Often the wrapper is the cheapest piece to upgrade.
• "What changed in the upstream in the last 12 months?" Legacy systems quietly change. Recent changes predict recent incidents.

Translating the tech detail into BA-language risk

The decision framework every software BA needs

"Build it ourselves" feels right because you're in control. It rarely is. Most internal projects underestimate build effort by 2-3x and overestimate the value of customisation. A mid-level BA's job is to force the comparison with the same rigour for all three options.

The seven questions to test each option against

When to integrate (often the right answer, often missed)

Integrate = use an existing system (often a buy) but write the glue yourself. You get the speed of buy + flexibility of build for the specific bits that matter. Most "build vs buy" debates ignore this third option even though it's usually the right one.

The conversation to have with each role

• Sponsor: what would change your mind between build and buy? (Most say "cost" — that gives you the test.)
• Product Manager: if we buy, what gets sacrificed on roadmap flexibility? If we build, what gets sacrificed on speed?
• Tech Lead: what are the integration paths for buy? Is there a build-vs-buy decision hidden in there (e.g. middleware)?
• Finance: how do they prefer to fund it — capex (favours build), opex (favours buy)?

Minimum Viable Product — and what it isn't

An MVP isn't "the rubbish version we'd be embarrassed by". It's the smallest thing that delivers measurable value AND that you can learn from. If it doesn't deliver value OR doesn't teach you something, it's not an MVP — it's just unfinished work.

The two tests

1. Does it deliver real value on its own? If yes, you've earned the right to ship. If no, you're shipping something that creates risk without payoff.
2. Will it tell you something you didn't know? An MVP exists partly to disprove assumptions. If you'd ship the same v2 regardless of v1 feedback, your MVP is wrong.

The Tom Hewitt MVP — a worked example

Why this is a brilliant MVP:

• Real value: 30% reduction in duplicates from week 8 onwards.
• Real learning: tells you whether seeing existing cases is enough — or whether you really do need automatic merging too. That's a £100k design decision answered for free.
• Right scope: excludes the hard parts (case-merging logic, customer-ID matching) for v2 when you've validated the easier hypothesis.

Writing user stories that don't dissolve in a sprint

Most user stories die in refinement because they're vague, too big, or written from the BA's perspective rather than the user's. The format isn't the hard part — "As a / I want / so that" is fine. The hard part is the discipline behind each clause.

The INVEST principle

From conversation to story

Splitting stories that are too big

• By workflow step: "view cases" / "merge cases" / "close merged cases" — three smaller stories instead of one big one.
• By data type: "show phone cases" first, then add email, then web. Each shippable.
• By user role: "view as agent" first, then "view as supervisor with extra data".
• By happy path vs edge case: happy path first, exception handling as separate stories.

Functional requirements that survive sign-off

A waterfall functional requirement is a single, testable sentence that tells the development team what the system must do — written so that, six months later, you can take it to a tester and they can write a test against it. Most reqs fail not because the BA didn't understand the need, but because they didn't write it down with the right discipline.

The anatomy of a "shall" statement

Every waterfall functional requirement has four parts. If any part is missing, the requirement isn't done.

MoSCoW prioritisation — what it actually means

MoSCoW (Must / Should / Could / Won't) is the discipline you use to keep a spec from becoming a wish-list. Each priority has a precise meaning — not a feeling.

Source attribution — every requirement names its origin

A functional requirement without a named source is a requirement nobody owns. The "Source" column on Aurora's requirements table is not decoration — it's how you defend the requirement in a change-control meeting six months in.

• Name the stakeholder. "Maya Okafor (Sponsor)" beats "Operations". Specific people defend specific decisions; departments don't show up to meetings.
• Cite the artefact. "Agent workshop, 12 Feb" beats "agent input". You can show the notes; you can show the photo of the whiteboard.
• Name the regulation. "FCA Consumer Duty — PRIN 12" beats "compliance". Regulation has clauses; cite them.
• Combine where the requirement has multiple parents. "Maya Okafor + agent workshops" is fine. "Compliance" is not.

Traceability — the chain you can pull

Each functional requirement should be traceable in two directions:

• Backwards to a business need: which business outcome does this requirement enable? On Aurora, Maya's "70% reduction in duplicates" links to FR-DD-01, FR-DD-02, FR-DD-03 — if the dedup requirements ship, the outcome is measurable.
• Forwards to a test: at UAT, every Must requirement gets at least one acceptance test. If a requirement has no test, either it isn't a requirement (delete it) or you forgot to write the test (add it). The test scenarios template lives at Test scenarios template.

Change control — the discipline that keeps the spec honest

The biggest waterfall failure mode is the spec becoming a contract instead of a conversation. Once signed, no one wants to admit any line in it was wrong — so the team ships the documented system rather than the right one.

The countermeasure is to build a Change Request (CR) process from day one and use it without shame:

1. Anyone can raise a CR — stakeholder, developer, BA.
2. The BA writes up the CR using the change request template: what's changing, why, impact on cost / time / scope / risk.
3. The Change Control Board (CCB) decides: yes (rebaseline the spec), no (record the decision and move on), or defer (capture as Won't this time).
4. If yes: version up the spec and name the change request in the version history, so every change stays traceable to the decision that approved it.

The same Aurora need, expressed both ways

Most teaching about "waterfall vs agile" stays at the level of the methodology. What changes day-to-day for a BA is the shape of the requirement — how it's written, how it's signed off, how it's allowed to change. Here's the same Aurora need expressed both ways, with the BA's job called out on each side.

The same need, two forms

Ben Carlisle (senior customer service agent, 12 years) said this in discovery:

Same need. Two ways to write it down:

What changes between them — for the BA

When each is the right answer

Both shapes are professional artefacts — the question is which fits the context.

Aurora specifically — which way to lean

Aurora's methodology decision sits in Project Aurora. The defaults the rest of the platform assumes:

• Waterfall route — you produce Aurora spec (this site's main waterfall artefact) and use the six-phase journey in the waterfall section.
• Agile route — you produce Aurora user stories (user stories board), live the refinement cadence in Aurora refinement, and show progress in Aurora sprint review.
• Hybrid route — you produce both. Many real Northcape-style projects in financial services run hybrid: a defensible spec for the FCA, plus story-level delivery for the team. Doing both is more work but is the realistic answer for a Consumer-Duty-bound project.

Why every business case shows three options

A business case with only one option is a sales pitch. Sponsors who matter have been around the block — they will reject a one-option case on principle, because they know they're being railroaded. Show three: Do Nothing, a lighter alternative, your recommendation. Then your case has integrity.

The pattern

The credibility test

For each option, you need three numbers: cost, benefit, time to value. If you can't fill those in honestly for the alternative options, you haven't actually considered them.

Consumer Duty — what it actually means for the system you're building

The FCA's Consumer Duty (in force since 2023) requires regulated firms to demonstrate they're delivering good outcomes for customers — not just following processes. For BAs in financial services this changes requirements work: every system needs to evidence outcome quality, not just transaction completeness.

The four outcomes you need to evidence

What BAs in the Aurora-style project need to capture

• Vulnerability flags on the customer/case record (financial difficulty, bereavement, low capability, disability) — visible to every agent without re-asking the customer.
• Outcome categorisation per case: resolved, partially resolved, unresolved, escalated. Reportable to the FCA on request.
• Repeated-contact tracking: same customer contacting multiple times for the same issue is a red flag. The Aurora project literally exists because of this signal.
• Time-to-acknowledge vs time-to-resolve as separate metrics: regulators care about both.
• Audit trail immutable for at least 6 years after the policy lapses. ICOBS requires this; FOS will ask for it.

The conversation to have with compliance

Compliance officers are usually brought in too late on projects. Ask:

• Which Consumer Duty outcome does this project most affect?
• What would you need the system to evidence for an FCA thematic review?
• Are there vulnerability indicators we should automatically flag, or is that a manual judgement?
• What's the worst-case scenario — and what's the smallest thing the system could do to prevent it?

How to get the most out of a tech-lead conversation

Tech leads will give you more value per minute than any other stakeholder — IF you ask the right questions. They'll also bury a project with risks unless you frame those risks as solvable problems. Mid-level technique: separate the technical surfacing from the risk-management response.

The four questions to always ask a tech lead

1. "Walk me through the integration risk." The honest answer tells you whether build/buy/integrate decisions are real or fake.
2. "What NFRs would you set, in your perfect world?" They'll usually overscope — but you'll learn what they actually care about, which becomes your minimum.
3. "What are you assuming that might not hold?" Tech leads have more assumptions than anyone. Capture every one for the assumptions log.
4. "If the wrapper / integration / system breaks at 2am, what's the fallback?" Surfaces resilience requirements you'd otherwise miss.

How to frame what you hear back to the sponsor

Tech leads talk about risks; sponsors hear "this project might fail". Translate:

Making compliance a partner rather than an obstacle

Compliance officers get involved late because BAs treat them as a box-tick at the end. Mid-level technique: bring them in during discovery, not at sign-off. They'll surface requirements that save you weeks of rework — and they're more accommodating than their reputation suggests when treated as colleagues.

Three questions that change the relationship

1. "What would a thematic review of this area look for?" Tells you what evidence the system needs to produce.
2. "What's the worst-case compliance scenario and what's the smallest mitigation?" Forces the conversation onto risk-proportionate design instead of belt-and-braces over-engineering.
3. "Where have similar projects in this firm got compliance wrong before?" Institutional memory you'd otherwise miss.

The phrases to listen for

• "We have to demonstrate" — there's a regulatory test you'll need to evidence.
• "The regulator will ask" — a real ask, not a theoretical one. Capture verbatim.
• "It's a six-week process" — a hard dependency on your timeline. Put it on the critical path now.
• "We've done it before" — there's an existing pattern. Get the documents.

Working with a Product Owner and Scrum Master

Most software BAs don't work alone — they work alongside a Product Owner and a Scrum Master in an agile team. Knowing where each role starts and stops is the difference between adding value and getting in the way. Mid-level BAs are expected to navigate these boundaries instinctively.

The three roles in one sentence each

The BA / PO boundary — where it gets blurry

The Business Analyst and Product Owner often overlap on story shaping. The right split:

Ceremonies — what you attend, what you skip

How to make a good first impression with the engineers

• Sit in on refinement before bringing any requirements. Learn how they think before you ask them to think differently.
• Ask the engineers what makes their job harder. They'll tell you everything you need to know about the product, the stakeholders, and the team in 30 minutes.
• Don't pretend to understand tech you don't. "I don't fully understand — explain it to me" earns respect. Bluffing loses it.
• Never say "can't you just…" — those three words destroy a BA's credibility faster than any other. There's always a reason it's harder than you think.
• Show up to demos with working software, not slides. Always.

Four mistakes new BAs in agile teams most often make

1. Writing big documents nobody reads. Replace the 20-page requirements doc with a refined backlog and a sequence of conversations.
2. Trying to do refinement alone. Refinement is a team sport — BA + PO + 2-3 engineers + QA. Solo refinement produces stories that fall apart.
3. Coming to demos with slides instead of working software. The team's done the hard part — let it speak for itself.
4. Believing "the requirements are signed off" means anything. In agile, requirements get refined every two weeks. Plan for that, don't fight it.

The question that separates senior BAs

When a sponsor introduces a project, they name the people they think about every day — their team, their peers, the people whose desks they walk past. The people they don't name are the ones who'll derail the project at month four. Mid-level BAs ask "who's not in the room?" deliberately, in every kick-off, every workshop, every steering meeting. It's the single highest-leverage question in the discipline.

The four groups sponsors usually forget

• The end customer. You're designing for them and they're never in the room. Complaints data, customer panels, journey-mapping research, NPS verbatim — they have to feed in somehow or the design is guesswork.
• IT Operations / run-the-business teams. Not the build team — the people who'll get paged at 2am when production breaks. They almost never sit in early discovery sessions and they will block go-live if they've been ignored. Find them in week one and bring them in.
• Compliance · Risk · Legal · Audit. Sometimes only one of these is named; the others get a token tick at the end. In regulated industries (finance, health, gov) they need to be in shaping the requirements, not signing off the finished thing.
• People who lost the last fight. If a previous project was rejected, replaced, or quietly abandoned, the people who built it usually have institutional memory of why. They're often deliberately excluded because "we tried that already". They're the cheapest source of insight you have.

How to ask it without sounding accusatory

Sponsors don't react well to "you missed someone". Reframe it as a check on yourself:

• "I want to make sure I've got the picture right — who haven't you mentioned that I should still be aware of?"
• "If we got to month four and someone said 'why didn't you talk to X?', who is X most likely to be?"
• "Who's the person who, if we don't include them, this project quietly dies?"
• "Who runs the system in production once we hand it over?"
• "Where's the customer voice coming from on this?"

What to do once you've found them

Add them to the stakeholder grid (power × interest) within 48 hours. Put them on the comms plan with a cadence. Get the introduction email from the sponsor while it's fresh — sponsors forget within a week. Capture the conversation in HubNote and tag the theme (stakeholder management).

Waterfall · Agile · Hybrid — and how to pick

Methodology isn't a religion — it's a delivery decision. The same project run waterfall, agile, or hybrid will produce very different artefacts, conversations, and risks. Mid-level BAs are expected to recognise which approach the project actually fits, even when the org has a default.

The three approaches at a glance

Which artefact does each methodology produce?

Your requirements documentation pattern is a function of your methodology — not the other way around. Picking the wrong artefact for the methodology is one of the most common BA mistakes.

Six-question decision framework

Ask yourself these about the project in front of you. The pattern of answers points to the right approach.

If you score 4+ "waterfall signals" your project is genuinely waterfall — don't fake-agile it. If 4+ "agile signals", commit to agile properly. If you're 3-3, you're a hybrid project; name it honestly.

Waterfall — done well, not as a punchline

Waterfall has a bad reputation it doesn't entirely deserve. When the domain is well-understood and the cost of change is genuinely high, sequential delivery with up-front requirements is the right answer. The reputation comes from waterfall being misapplied to software product work where it's the wrong fit.

The phases (and what the BA does in each)

The Specification Document — what's in it

The BRD or SRS is the central artefact. A well-structured spec includes:

• 1. Executive summary — what the system does, why, for whom.
• 2. Context & scope — in-scope and explicitly out-of-scope.
• 3. Stakeholders — full list with roles, sign-off responsibilities, RACI.
• 4. Business requirements — what the business needs the system to enable.
• 5. Functional requirements — what the system must do, in numbered list. Often with use cases.
• 6. Non-functional requirements — performance, security, availability, etc.
• 7. Data requirements — entities, attributes, retention, governance.
• 8. Constraints — regulatory, technical, organisational, contractual.
• 9. Assumptions & dependencies — what must be true / what else has to happen.
• 10. Acceptance criteria / sign-off — how we know it's done.
• 11. Glossary — for the love of all that's holy.
• Appendices — use cases, process maps, mockups, data flows.

The conversations that matter most in waterfall

• Workshops — multi-stakeholder, longer sessions, lots of upfront elicitation. The BA leads, captures everything.
• Stakeholder interviews — 1-1, deep dives. Used for nuance the workshop missed.
• Sign-off meetings — chase, chase, chase. A signed BRD that no one read is worse than no sign-off.
• Change Control Board (CCB) — when scope changes, this group decides. The BA brings the change request, the CCB decides yes / no / defer.

Aurora as a worked example — the six phases in practice

Here is the same six-phase waterfall journey, but walked through Aurora — what the BA does in each phase, which Aurora artefact (or reusable template) you produce, and where the platform has no tool because the work happens in real-life rooms.

Agile — the principles, not just the ceremonies

Agile isn't a process — it's a set of principles about how to handle uncertainty. The Manifesto for Agile Software Development (2001) sets out four values. Most of what people call "agile" is a particular framework (Scrum, Kanban, SAFe) that puts those values into practice.

The four agile values (from the Manifesto)

• Individuals and interactions over processes and tools — people make software, not Jira tickets.
• Working software over comprehensive documentation — a thing that runs is worth more than a doc that describes a thing.
• Customer collaboration over contract negotiation — the customer is in the room, not at the end of a fax line.
• Responding to change over following a plan — the plan was your best guess at the start, not a contract.

The crucial line in the Manifesto: "While there is value in the items on the right, we value the items on the left more." It doesn't say documentation is bad — it says working software matters more than the documentation.

What changes about the BA's job in agile

The requirements artefact in agile — the product backlog

Instead of a single document, agile teams maintain a product backlog — a prioritised list of work, typically as user stories. The backlog is constantly refined and re-prioritised. The Product Owner owns priority; the BA brings the stakeholder context that informs it.

Key practices around the backlog:

• Definition of Ready (DoR) — agreed criteria a story must meet before entering a sprint. Typically: clear AC, dependencies known, sized, no open questions.
• Definition of Done (DoD) — agreed criteria a story must meet before being called complete. Typically: code reviewed, tested, deployed to staging, AC met, accessibility checked.
• Backlog refinement — weekly ceremony where the team grooms upcoming stories with the BA + PO.
• Story splitting — taking a too-big story and splitting it (by workflow step, data type, user role, happy path vs edge case).

Common myths about agile

Hybrid — the honest answer for most real projects

Most real-world projects aren't pure waterfall or pure agile. They have a regulated frame (waterfall) with iterative delivery inside it (agile). Saying "hybrid" out loud is often more credible than pretending it's one or the other.

What a hybrid looks like in practice

• Programme-level — stage gates at quarterly intervals. Steering committee. Budget tranches. Capability roadmap. (Waterfall-shaped.)
• Team-level — sprints, daily stand-ups, refinement, demos, retros. Backlog of stories. (Agile-shaped.)
• Requirements — a high-level capability spec OR PID at the programme level (signed off) AND user stories at the team level (continuously refined).
• Governance — change-control board for programme-level scope changes; PO-led re-prioritisation for story-level changes.

When hybrid is right

• Regulated industries (financial services, healthcare, public sector) — the regulator wants a spec; the team needs iterative delivery.
• Large programmes with multiple teams — programme-level coordination has to be more structured than story-level work.
• Fixed-deadline projects where scope can flex — the date is locked (waterfall), the scope flexes (agile).
• Organisations with mixed maturity — some teams are agile-fluent, others aren't. The hybrid frame works for both.

Where hybrid goes wrong

• Mini-waterfalls inside sprints. Two-week mini-spec-then-build cycles. Worst of both worlds.
• Documentation that contradicts itself. The PID says one thing; the stories say another. Maintain both — but keep them aligned.
• Mixed sign-off models confusing the team. Be explicit: who signs off what, at what level?

Scrum — the most common agile framework

Scrum is one of several agile frameworks. It's the most widely adopted because it's prescriptive enough to teach but light enough to scale. If a job description says "agile" without specifying further, it almost certainly means Scrum.

The three roles

Strictly speaking, "Business Analyst" isn't a Scrum role — the framework assumes the PO does the BA's job. In practice that doesn't scale; mid-size and large orgs have BAs alongside POs. See the BA/PO split.

The five events

Plus backlog refinement, which strictly isn't a Scrum event but every team runs it weekly. The BA's home ceremony.

The three artefacts

• Product Backlog — the prioritised list of everything that might be in the product. Owned by the PO.
• Sprint Backlog — what the team committed to this sprint. Owned by the team.
• Increment — working software, shippable, at end of every sprint. The thing that actually matters.

Where Scrum gets misapplied

• One-person "Scrum teams". Scrum is a team framework — needs at least 3-9 people.
• Hardware projects. Scrum assumes you can release working software every sprint. Hardware can't.
• Fixed-everything contracts. If scope, time, and cost are all locked, you can't have agile — Scrum's flex is the scope dimension.
• "Scrum-but" — "We do Scrum but skip retros / but have a fixed scope / but ship every six months". Three "buts" means you don't do Scrum.

Kanban — agile without sprints

Kanban is the other major agile framework. Where Scrum batches work into sprints, Kanban runs continuously — work flows when the team has capacity. Often the right answer for ops-heavy or support-heavy teams where unplanned work dominates.

The core practices

• Visualise the work — a board with columns for each stage (Backlog → In Progress → Review → Done).
• Limit Work In Progress (WIP) — only X items in each column at once. Forces focus. Stops scope creep at the team level.
• Manage flow — measure cycle time (story to done). Optimise for smooth flow, not for sprint-end heroics.
• Make policies explicit — what does "Done" mean for this column? Written on the board.
• Improve collaboratively — retro the system, not the people.

When Kanban fits better than Scrum

• Support / operations teams (Bug fixes don't fit sprints.)
• Marketing or content teams (Work types vary wildly in size.)
• Mature teams that find sprint planning overhead exceeds its value.
• Teams with mixed planned + unplanned work.

Where Kanban falls short

• New teams — sprints give cadence and predictability that Kanban doesn't enforce.
• Stakeholder expectations of regular demos — Kanban demos when work's ready, which is uneven.
• Teams that need external commitments — Scrum's sprint goal is easier to "sell" upstream than "we'll get to it when we get to it".

Lean — the parent of agile

Lean started in Toyota manufacturing in the 1950s — eliminate waste, deliver value continuously, respect the people doing the work. Most agile principles trace back to Lean. Lean Startup (Eric Ries, 2011) applies the same ideas to product development under uncertainty.

The five Lean principles

1. Define value from the customer's perspective.
2. Map the value stream — every step from start to finish.
3. Create flow — eliminate the queues and waits between steps.
4. Establish pull — work moves when the next step can take it.
5. Pursue perfection — continuous improvement, never finished.

The Lean Startup loop (Build → Measure → Learn)

For product BAs, this is the bit worth knowing:

• Build the smallest thing that lets you test your assumption (an MVP).
• Measure what happened when real customers used it. Quantitative metrics where possible.
• Learn what the result tells you about your hypothesis — and decide to pivot (change direction) or persevere (keep going).

Lean BA techniques worth borrowing

• Value Stream Mapping — map the entire flow of work, identify which steps add value and which are waste. Brilliant for process-improvement projects.
• Eight wastes (TIMWOODS — Transport, Inventory, Motion, Waiting, Over-production, Over-processing, Defects, Skills) — a checklist for finding inefficiency.
• A3 problem-solving — structured one-page problem statement.
• Genchi Genbutsu ("go and see") — don't theorise about the work, go and watch it being done. This is what Sandra's 2019 advice was about.