The Biggest Skills Gap in Business Analysis Isn't What You Think

When I talk to business analysis professionals about what AI means for their careers, the anxiety usually surfaces as a cluster of practical questions. Do I need to become a data scientist? Should I understand how large language models work? Is prompt engineering something I need to add to my skill set?

Those are reasonable things to wonder about, and data literacy and AI fluency are genuinely worth developing. But after 25 years in enterprise product management, and in my current role at IIBA, where I get to see what's happening across the global business analysis community, I keep arriving at the same conclusion: none of those is the biggest gap practitioners face right now.

The gap that concerns me most is something more fundamental. Business analysis professionals have been trained, quite deliberately and for good reasons, to resolve uncertainty before they act. AI-native workflows tend to reward resolving uncertainty through acting. That inversion is the thing most organizations aren't talking about yet, and I think it's worth some honest reflection.

Why We Developed This Instinct

The impulse to front-load analysis made complete sense in the world that produced it. When building software was expensive and iteration was slow, being wrong early carried real costs. It led to comprehensive requirements documents, thorough discovery phases, and careful stakeholder alignment before any development began. All of these were rational responses to a cost structure where rework was painful and getting it right the first time genuinely mattered.

That environment shaped business analysis as a discipline. Thoroughness upfront was a genuine differentiator. A practitioner who could reduce ambiguity before a team committed to a direction was adding measurable value, and the profession built practices, frameworks, and career paths around that capability.

That logic hasn't disappeared entirely, and I want to be clear that I'm not suggesting it has. But AI has shifted the underlying economics in ways that most of our professional training hasn't yet caught up with.

The Fundamental Change

Two things have shifted in ways that matter directly to how business analysis professionals operate day to day. First, analysis is cheaper. The research-to-insight cycle that once took weeks can now be compressed considerably. Thorough analysis remains important, but it's no longer the bottleneck it once was, and it's also no longer where competitive advantage tends to live.

Second, experimentation is faster. A working prototype that would have taken a developer several days to build can now be sketched in an afternoon. When you can generate several different approaches to the same problem and put them in front of real users within a single day, some questions that previously required extensive upfront analysis are better answered by running a well-designed experiment. The fastest path to the right answer is often through trying something small and learning from it, rather than through a more thorough document.

This is the inversion I mentioned earlier. Practitioners trained to eliminate uncertainty before acting are now operating in an environment where acting to eliminate uncertainty is frequently the smarter approach. It's a meaningful shift, and it runs against habits that took years (and sometimes decades) to build.

What This Looks Like in Practice

The gap tends to show up in recognizable patterns. A practitioner working from the older model will often spend considerable time trying to fully understand a problem space before proposing anything, when a rough prototype tested with a small group of users would have taught them more, and faster. They'll seek stakeholder alignment on details that could be resolved empirically. They'll treat a well-structured analysis document as the deliverable when the real deliverable is a decision, and the fastest route to that decision might run through a quick experiment rather than a longer analysis cycle.

There's a related risk worth naming directly here: AI can produce outputs that look polished and authoritative, even when the reasoning behind them is thin or the framing is wrong. A practitioner who hasn't developed the judgment to evaluate what AI produces (i.e., to recognize when an assumption is unstated, when a problem has been misframed, or when a proposed solution addresses the wrong question) will produce confident mistakes more quickly than they could have before. AI fluency without analytical judgment is a liability, and it can be a hard one to spot from the outside.

Rigour Is Being Redistributed, Not Abandoned

I want to be careful here, because it would be easy to read this as an argument that analytical rigour no longer matters. It remains critical to developing sound analytic judgment, but what's changing is where it gets applied.

In the traditional model, rigour was front-loaded. You invested heavily in getting things right before the work began. In an AI-native workflow, that same discipline needs to be distributed across rapid learning cycles. The rigour lies in designing the right experiment, asking the right evaluative questions, and knowing what the results mean for the decision at hand.

This requires practitioners to think in terms of learning loops: what don't I know, what is the fastest way to find out, what will the result tell me, and what do I do differently as a result. Business analysis professionals are well-positioned to develop this capacity. The underlying skills (structuring problems, identifying what matters most, translating findings into decisions) are the same ones the profession has always valued. But the context in which they get applied is shifting.

What Organizations Need to Examine

Closing this gap isn't only a practitioner’s responsibility. Organizations have a significant role to play in whether the mindset shift truly takes hold. 

If practitioners are still being measured primarily on the completeness of their upfront analysis, the incentive structure is actively working against the new way of operating. The organizations that develop genuinely strong AI-native business analysis capability will be those that start measuring something different: how quickly practitioners are learning, and how well they're designing the experiments that generate that learning.

Senior practitioners also become more important in this environment, not less. The apprenticeship path that used to run naturally through artefact production (write requirements, receive feedback, calibrate your judgment over time) is changing. Deliberate coaching and structured feedback need to fill the space that used to be occupied by the natural rhythm of producing and reviewing documents.

That investment is easy to deprioritize when output is fast and looks good. Consistently skipping it is how organizations end up with teams that are fluent in AI tooling but underdeveloped in the judgment that makes those tools useful.

The Question Worth Sitting With

If you're a business analysis professional trying to orient yourself in this moment, I'd gently suggest setting aside the question of which AI tools to learn, at least temporarily. Instead, ask yourself this: when I encounter uncertainty in my work, is my first instinct to analyze my way through it or to design the smallest experiment that would help me resolve it?

If the answer is the former, you're in good company. Most of us were trained that way, for reasons that made sense at the time. Developing the latter instinct—and, perhaps more importantly, knowing which approach fits which situation—is the real work of becoming effective in an AI-native environment.

The gap we're talking about is a trained habit of mind. A technical skills course or certification can support that journey, but it won’t close it. Doing so takes deliberate practice, honest feedback, and leaders who are willing to measure the things that matter right now.

Resources can't do the work for you, but they can point you in the right direction. The KnowledgeHub is a good place to start. Explore it free for seven days.

---

About the Author