DEV Community: Analyst First

What separates BAs who compound from BAs who plateau

Analyst First — Thu, 18 Jun 2026 11:08:10 +0000

This is the last piece in a series that started with how to push back on stakeholders and moved through artifacts, discovery, and the written rhythm. It ends with the question underneath all of it: why do two BAs who start with the same skills end up, five years later, in completely different places.

I have watched this happen enough times to be sure it is not talent and not luck. The BA who compounds and the BA who plateaus are usually indistinguishable in year one. By year five the gap is enormous and nearly impossible to close. Something happened in between, repeatedly, that almost nobody can see while it is happening.

This piece is about what that something is.

The two BAs in year one

Picture two analysts hired the same month. Same training, same competence, same eagerness. Both write clean acceptance criteria. Both run reasonable stakeholder meetings. Both pass their probation comfortably.

In year one they are interchangeable. If anything, the one who plateaus often looks better early, because plateauing BAs are frequently the ones who optimise for visible output: more tickets closed, more documents produced, more meetings attended. The compounding BA can look slower, because they are spending time on things that do not show up in any metric.

That invisible time is the whole story.

What the compounding BA does with the invisible time

The compounding BA spends a portion of every week doing things that produce no immediate output:

They write down predictions and check them later. Not because anyone asked, but because they are building a private record of how often their judgement is right and in what specific ways it is wrong.

They sit with a requirement they have already shipped and ask what they would do differently. Not to revise it, since it is shipped, but to extract the lesson while it is fresh.

They notice when a stakeholder conversation went badly and trace back to the exact moment it turned, instead of blaming the stakeholder and moving on.

They keep a running file of patterns they have seen across projects, and they revise it when a new project contradicts an old pattern.

None of this shows up in a performance review. All of it compounds.

Why it compounds

The mechanism is calibration. Every prediction written and checked, every shipped requirement reviewed, every bad conversation traced back, adds one data point to the BA's internal model of how the work actually behaves. Over a year that is fifty data points. Over five years it is two hundred and fifty.

Calibration is the thing that cannot be taught in a course and cannot be faked in a meeting. It is the difference between a BA who says "I think this will be a problem" as a guess and a BA who says "I think this will be a problem, and here is the specific way it will go wrong, and here is roughly when we will know." The second BA is right often enough that senior people start to route decisions through them. That routing is what advancement actually is.

The plateauing BA never builds the calibration, because they spent the invisible time on visible output. They have five years of experience in the sense that they did the job for five years. They do not have five years of calibration, because they never ran the loop that produces it. They have, in a real sense, the same year of experience five times.

The compounding is invisible until it isn't

Here is the cruel part. For the first two or three years, the two BAs look similar to everyone including themselves. The compounding BA often feels like they are falling behind, because the plateauing BA has more visible output and gets praised for it. The compounding investments feel like a tax with no return.

Then, somewhere around year three or four, the curves separate visibly. The compounding BA starts being right about things before anyone else. Their one-pagers start landing because they have learned, through two hundred reps, exactly how to frame a concern so a senior person hears it. Their discovery conversations surface things others miss because they have traced enough bad conversations to know where the bodies are buried. Senior people start asking for them by name.

The plateauing BA, at the same moment, starts to feel stuck without understanding why. They are doing everything they did in year one, which worked in year one, and it is no longer producing advancement. They often conclude the problem is politics, or their manager, or the company, and they leave for a similar role elsewhere, where the same pattern repeats.

Why almost nobody does the compounding work

If the compounding work is this powerful and this simple, the obvious question is why almost nobody does it.

Three reasons, each real.

The first is that the feedback loop is too long. The compounding investments pay off in years three through five. Human motivation is calibrated for feedback in days or weeks. Doing something every week for three years before it visibly pays off requires a kind of faith that most people cannot sustain without evidence, and the evidence does not arrive until after the faith was required.

The second is that the work is invisible and therefore unrewarded. Organisations pay for visible output. A BA who spends three hours a week on private calibration that produces no ticket, no document, no deliverable, is spending three hours a week that the organisation does not value and cannot see. The incentive gradient points away from the compounding work at every step.

The third is that it is uncomfortable. Checking your old predictions means confronting how often you were wrong. Tracing a bad conversation back means owning your part in it. Reviewing a shipped requirement means seeing what you missed. The compounding work is, fundamentally, a practice of looking directly at your own errors, repeatedly, on purpose. Most people will do almost anything to avoid that.

What this means if you are early

If you are a BA in your first year or two, the entire content of this series reduces to one instruction: spend some of the invisible time on calibration, every week, even though it will feel pointless for a long time.

The specific practices are in the earlier pieces. Write predictions and check them. Keep the weekly artifact. Trace bad conversations. Review shipped work. Build the one-pagers and watch how they land. None of it is complicated. All of it is uncomfortable and slow to pay off, which is exactly why it remains rare, which is exactly why it remains valuable.

The BAs who do this do not have more talent than the ones who do not. They have a higher tolerance for delayed, invisible, uncomfortable work. That tolerance is the entire moat.

What this means if you are not early

If you are five or ten years in and you recognise yourself in the plateauing BA, the news is better than it feels. The compounding work produces results from the day you start it, regardless of how many years you spent not doing it. The calibration loop does not care that you are starting late. It only cares that you run it.

The version of you three years from now will have three years of calibration data that the current version does not. That is true whether you are in year two or year twelve. The only question the compounding work asks is whether you will start running the loop now, knowing the payoff is years out and invisible until it arrives.

That is the whole craft. Not the frameworks, not the templates, not the questions. Those are tools. The craft is the willingness to do the slow, invisible, uncomfortable work of looking at your own judgement, over and over, for years, until being right becomes a thing people can rely on.

Start this week. Check back in three years.

What changed about being a BA between 2020 and 2025 (and what didn't)

Analyst First — Wed, 17 Jun 2026 11:47:59 +0000

A senior BA at a services firm asked me last month what's changed about the job in the last five years. He'd been heads-down on client work since 2020 and was preparing for a career conversation. He wanted a clean list.

The clean list exists. Five things changed visibly. Three things didn't change at all. The interesting part is which list matters for your next five years, and most career advice for BAs gets this exactly backwards.

What actually changed (the surface)

One. AI tools became normal in the workflow. In 2020 a BA who used GPT-style tools at work was rare and slightly suspicious. By 2024 it was standard. Claude, ChatGPT, Notion AI, Miro AI — most BAs now use at least one daily. The companies that banned them in 2023 quietly unbanned them in 2024. The shift happened faster than any previous tool adoption I've watched.

What the tools are actually used for, honestly: drafting acceptance criteria first-pass, summarising stakeholder transcripts, generating user-story candidates from prose, restructuring rambling requirements documents, and producing meeting notes. Not requirements analysis itself. Mostly the boring documentation overhead that used to eat a third of the week.

Two. Async work permanently changed how requirements get captured. Remote and hybrid teams meant that the spoken stakeholder workshop became the recorded one, then the Loom video, then often nothing — replaced by Slack threads and shared documents. Requirements gathering got faster and noisier. Fewer formal workshops, more continuous capture across channels.

The good BAs adapted by treating Slack and Loom as raw input that needs analysis, the same way they used to treat workshop transcripts. The mediocre BAs treated the messages as the requirement itself, copy-pasted them into tickets, and shipped confusion.

Three. "Product Owner" became the title services firms preferred. In 2020, most Indian IT services firms hired BAs. By 2025 the same role had been quietly relabelled as PO on most job postings. The work didn't change. The title did, because clients running Scrum wanted to see "PO" on the staff aug invoice. Anyone who saw this as a real role transformation rather than a relabelling exercise wasted two years chasing certifications for a job they were already doing.

Four. Tools got cheaper, more numerous, more interchangeable. Jira's monopoly weakened. Linear, ClickUp, monday, Notion, Coda, Asana all became viable for requirements work. The good news: BAs got more leverage to push back on tool decisions. The bad news: a lot of BA energy went into tool migrations that didn't change outcomes.

Five. Stakeholder expectations sped up. "When can you have this back to me" used to mean a few days. By 2025 the expectation in many orgs is hours. Partly because AI tools made faster turnaround possible, partly because async work made stakeholders impatient with waiting on a workshop they're not in. The BAs who responded by getting faster shipped more low-quality work. The ones who held the line on analysis time got better outcomes but had to negotiate harder for it.

What didn't change (the underlying craft)

One. Requirements still come in wrong. Stakeholders still describe their preferred solution and call it a requirement. They still leave out the trigger that generated the request. They still believe the priority they assigned is meaningful. They still misremember what they said in the workshop last week. The job of decoding what they actually need from what they actually said is identical to what it was in 2020, or 2015, or 2005.

Two. The work that matters is still problem understanding, not story writing. The BA who can articulate why a feature should exist, who's affected, and what changes if it ships still outperforms the BA who writes beautiful INVEST-compliant stories about unvalidated requirements. AI tools made the story-writing part faster. They did nothing for the problem-understanding part, which is judgement and remains stubbornly human.

Three. Stakeholders still don't know what they want until they see what they don't. The iterative discovery process — show a prototype, get a real reaction, refine, repeat — is the same as it ever was. The cycle time shrank because tools got better, but the cycle itself is unchanged. The BAs who treat the first stakeholder statement as the requirement, even now, ship the wrong thing.

The gap that nobody talks about

Here's the actual point of this piece. The gap between "what changed" and "what didn't" is widening, and most BAs are on the wrong side of it.

A BA who has spent five years getting better at the surface changes — faster AI-assisted documentation, more tool fluency, better Slack-thread synthesis — has a CV that looks current. They can write the right keywords. They can talk about AI tools confidently in interviews. They've earned a few certifications in the new tools their company uses.

What they have not done is gotten meaningfully better at the underlying craft. Their problem-understanding is the same level it was in 2020. Their ability to interrogate a requirement is the same. Their stakeholder management is the same. They are faster at producing documents that nobody reads with the same level of insight as before.

This is fine for the moment because the market still values surface signals. It will not stay fine.

Two forces are closing the gap:

The first is AI itself. Surface BA work is exactly what AI tools are best at. Drafting stories, summarising transcripts, formatting acceptance criteria, generating documentation. Any BA whose value is concentrated in those activities is competing directly with a tool that costs $20 a month and gets better every quarter. The market is going to notice within the next few years.

The second is that companies are starting to feel the cost of BAs who can document fast but can't think well. The features ship, the documentation is clean, the metrics don't move. Eventually someone asks why, and the answer points back to requirements that were well-formed but aimed at the wrong target. The teams that get burned by this start hiring differently.

What to actually invest in for the next five years

If the surface changes are dangerous to over-index on, what should a BA invest in instead?

Problem decomposition. The ability to take a vague stakeholder statement and break it into the actual underlying needs, with evidence, in a way that survives challenge. This is the muscle that doesn't atrophy and that AI cannot replicate. It's also the hardest to teach, which is why most BA training avoids it.

Stakeholder interrogation. Not asking what they want. Asking what they're trying to do, who else is affected, what changes if you ship, what happens if you don't, what they've tried before. The questions are the work. The BAs who can ask these questions well, in real time, in a room with a defensive stakeholder, will be valuable in five years the same way they're valuable now.

Judgement under ambiguity. Knowing when a requirement is real versus when it's someone's preferred solution to a misdiagnosed problem. Knowing when to push back and when to absorb. Knowing what to document formally versus what to handle in a hallway conversation. This judgement is built case by case over years and cannot be downloaded.

Domain depth. A BA who understands payments deeply, or insurance underwriting, or regulatory compliance, or healthcare workflows, has something AI cannot easily acquire and most other BAs don't have. Generalist BAs are increasingly replaceable. Specialist BAs are increasingly necessary.

None of these things are new. They were the right things to invest in in 2020 too. The difference is that the cost of NOT investing in them is rising faster now, because the surface skills are getting commoditised.

The honest summary

Five years of change in the BA role is real but mostly cosmetic. AI tools, async work, the PO rebranding, tool proliferation, faster turnarounds — these changed how the work happens, not what the work is.

The work itself — turning vague stakeholder statements into shipped features that actually solve the underlying problem — is the same job it was in 2020. It will be the same job in five years. The BAs who recognise this and invest accordingly will compound. The ones who chase the surface changes will find themselves doing increasingly commoditised work for stakeholders who increasingly notice they could have used a tool instead.

If you're preparing for a career conversation, that's the honest framing. The market signals are changing. The actual job mostly isn't.

The AI-assisted requirements workflow that actually works

Analyst First — Tue, 16 Jun 2026 10:12:30 +0000

I've watched BAs adopt AI tools over the last two years and noticed a pattern. The ones who use AI as a faster acceptance-criteria generator produce faster bad requirements. The ones who use AI as a thinking partner before they touch the AC produce something interesting. Same tools, opposite outcomes.

This piece is the workflow that produces the second outcome. It is not theoretical. It is what the BAs I respect actually do when they sit down with a new stakeholder request and an open Claude or ChatGPT window.

Three stages, in order. Each stage has a clear thing AI is good at and a clear thing it is not.

Stage 1: Stakeholder interrogation, with AI as opposition

The first hour after a stakeholder request lands is the highest-leverage time in the entire requirements process. It is also the time most BAs skip, because the request "feels clear" and the temptation is to start scoping.

The AI's job in this stage is to be opposition. You paste the request verbatim and ask: "Read this request as a hostile reviewer. What is unstated. What contradiction is hiding. What assumption is the stakeholder making that they have not named."

The model will produce a list. Most items on the list will be wrong or trivial. But two or three items will be real. Those are the questions you bring to the stakeholder before scoping.

This is high-leverage because the alternative — the BA generating the same questions by themselves — depends on the BA being well-rested, focused, and not pattern-matching to a similar request from last month. The AI has no such limitations. It interrogates the same way every time, which is exactly what you want from opposition.

What AI is bad at in this stage: it cannot tell you which of the two or three real questions actually matters in this organisation, with this stakeholder, this quarter. That judgement is yours.

The artifact from stage 1 is a short list of three to five questions to take to the stakeholder. Not the requirements document. The questions.

Stage 2: Stakeholder conversation, with AI removed entirely

This is the stage where AI causes the most damage in the workflows I have seen.

The temptation is to bring the AI into the stakeholder conversation. Record the meeting, paste the transcript into the model, ask for a summary. Or worse, have the model draft requirements in real time as the stakeholder talks.

This destroys the conversation. The stakeholder feels surveilled, even when they have consented. The BA stops listening because they are reading model output. The questions that emerge from the conversation become AI-shaped rather than human-shaped, which means they pattern-match to what the model has seen before, which means they miss the parts of the situation that are unique to this organisation.

The fix is brutal. AI does not come into the room. The BA takes notes, asks the questions from stage 1, listens to the answers, asks follow-up questions based on what they hear, ends the meeting with a clear set of notes and an unclear set of impressions.

The impressions are the valuable part. The notes can be reconstructed from any meeting. The impressions can only be captured by a present human.

What you have after stage 2: handwritten or typed notes, a list of decisions the stakeholder made or deferred, and your own impressions about what the stakeholder is not yet ready to say.

Stage 3: Synthesis, with AI as fast first draft

This is where most BAs start using AI. It is the stage where AI is most useful and least dangerous, because the thinking has already happened.

Paste your notes into the model. Ask it to produce a structured draft: problem statement, scope, acceptance criteria, open questions. The model will produce something usable in two minutes that would have taken you forty.

Then comes the actual work of the synthesis stage. You read the draft and ask yourself, for every line: do I believe this. Where the draft is correct, you leave it. Where the draft is wrong, you change it. Where the draft is missing something important, you add it.

The draft is not the requirements document. The draft is the scaffold against which you do the requirements work.

Most BAs stop at the draft. They polish the language, fix the formatting, and ship. That is the failure mode that produces faster bad requirements. The discipline is to treat the draft as an opinionated proposal you are evaluating, not a finished artifact you are editing.

What AI is bad at in stage 3: it cannot tell you which of the acceptance criteria will fail when production traffic hits the feature. It cannot tell you which stakeholder will object to the language and why. It cannot tell you whether the timeline implied in the doc is realistic for this team. Those are your judgement calls.

The three things to never delegate

Across all three stages, there are three things AI should never be asked to do. Each comes from a real failure mode I have watched repeatedly.

Never delegate the decision about whether the requirement should exist at all. AI cannot reach this question because it does not have access to the organisational politics, the prior attempts that failed, or the strategic tradeoffs. It will always produce a draft that assumes the requirement is valid. Your job is to question whether it is.

Never delegate the read on the stakeholder. When the stakeholder said "we need this by Friday," they were communicating something underneath the words. Maybe pressure from above. Maybe political signalling. Maybe genuine urgency. AI cannot read that signal. You must, or the requirement you produce will be technically correct and politically wrong.

Never delegate the language of pushback. When a requirement looks wrong and you need to push back to the stakeholder, the words matter at a level of specificity AI cannot match. The wrong phrasing in a pushback creates an enemy. The right phrasing creates an ally. AI-drafted pushback language tends toward generic professional politeness, which lands as either condescending or evasive. Write your own.

What this workflow costs

This workflow is slower than the "paste request into AI, get AC, ship" version by about an hour per requirement. It is faster than the no-AI version by about three hours per requirement. The net is two hours saved, plus a requirement that is roughly twice as likely to survive production contact with reality.

The two hours are not the point. The point is that the BA who runs this workflow develops calibrated taste over the course of a year. They start to see, in stage 1, which questions the model will surface and which it will miss. They start to develop a feel for when stage 2 is going well and when the stakeholder is performing for the room. They start to recognise, in stage 3, which kinds of acceptance criteria the model gets right and which it consistently gets wrong.

The calibration is the asset. The faster requirements are a side effect.

The framing that matters

AI is a power tool. Power tools make skilled craftspeople more productive and unskilled craftspeople more dangerous. The same drill that lets a carpenter assemble a cabinet in an hour lets an unskilled user split the wood and drive screws at the wrong angle in the same hour.

Requirements work has the same dynamic. The BAs who already had strong instincts before AI now have those instincts compounded by tools that handle the mechanical work. The BAs who never developed the instincts now produce more bad requirements faster, which their organisations interpret as productivity until the project fails.

The workflow above is the difference. Use AI where it has leverage. Stay out of where it doesn't. Build the calibration that lets you tell the difference, because in five years that calibration will be the only thing in the job that is still scarce.

The next piece returns to the artifact-rhythm series, looking at why team-level writing cultures collapse even when individual writing habits work. Subscribe below to get it.