A year ago, I watched a senior business analyst paste an entire 80-page RFP into ChatGPT and type 'summarize this.' The output read like a college essay on procurement theory. She looked at me and said, 'See? It's not ready for real work.' I didn't blame her. She'd been burned by hyped tools before, and that first experience only confirmed her skepticism.
The problem wasn't the model. It was the assumption that large language models work like search engines—one shot, best answer first. Business analysis doesn't work that way. You poke, you prod, you rephrase the question three different ways until the stakeholder's real need surfaces. I realized we needed patterns that mapped to how good BAs actually think, not patterns designed for software engineers writing code.
We started with the simplest shift: give the model a role. Not a generic 'you are an expert,' but something specific to the analyst's industry. One BA working on a warehouse management upgrade used 'You're a logistics analyst who's been on the floor for 15 years and you're allergic to buzzwords.' Suddenly, the tone shifted from consultant-speak to the kind of blunt, operational language her stakeholders actually used. That alone cut her revision cycles in half.
Then came the pattern I now wish I'd named something catchier: the rubber duck with memory. BAs are trained to ask clarifying questions. We taught them to prompt the model to do the same. Instead of 'give me user stories,' they'd say, 'Before you write anything, ask me five questions that would make the requirements clearer.' The model would respond with things like 'Is this a greenfield system or a replacement?' and the BA would answer, then ask it to refine its questions again. Two or three rounds of this produced requirements documents that needed far less rework than first drafts from human analysts.
The biggest mistake I made early on was pushing for complex, multi-step prompt chains before they'd built basic intuition. I once handed a team a dozen-shot example prompt for gap analysis, complete with edge cases and output formatting rules. They tried it once, got a mediocre result, and never opened the file again. Turns out, BAs need patterns they can improvise on top of—not rigid templates. Now I tell them to start with a conversation, not a command. Describe the project in a paragraph. Ask the model what it's missing. Then iterate.
One pattern that emerged organically was something we jokingly call the 'peer review' approach. After the model produces a draft, the analyst gives it the same kind of feedback they'd give a junior colleague: 'This section on inventory reconciliation doesn't account for cross-docking. Revise it with that in mind.' The model responds to that kind of directed feedback far better than a vague 'make it better.' It's a pattern that costs nothing to add but dramatically improves output quality.
I still see BAs treating the chat interface like a magic eight ball, expecting the perfect answer on the first shake. The ones who succeed are the ones who stop hunting for the perfect prompt and start treating the model like a very patient, very knowledgeable coworker who just needs context to be useful. That's not a technical skill—it's a conversational one. And it's something BAs are already great at.