When our business analysts first got access to an internal LLM, I figured they would take to it quickly. They were already good at asking questions in stakeholder interviews. How different could writing a prompt be? Quite different, it turned out. Their first attempts were vague one-liners like summarize this requirements doc and then they would get a bland paragraph that didn't match their mental model. One analyst told me the tool was confidently useless.
I made a mistake early on by handing them a cheat sheet of prompt templates. It was full of fancy instructions like act as a senior business analyst and think step by step. They copied those templates and still got mediocre results. The problem wasn't the template. It was that the prompts didn't capture the context they carried around in their heads. A business analyst knows which stakeholders are difficult, which KPIs are vanity metrics, and which edge cases have burned the team before. None of that was making it into the prompt.
So we stopped using templates and started using patterns built around context. The first pattern I call the anchor. Before asking the model to do anything, write one sentence that anchors the request in the specific business problem. Instead of list risks for this project, an analyst would write, We are migrating a legacy claims system for a regional insurer and the biggest risk is data loss during cutover. That single sentence changed the output from generic project management fluff to something specific about reconciliation and fallback plans.
The second pattern is the constraint pass. Analysts naturally think in terms of scope and constraints, but they rarely write those down. I tell them to add two or three constraints before the instruction, like we have no budget for additional software, the timeline is fixed at six months, and the current team has never used ETL tools. This works because it mimics the mental filters they apply when evaluating any vendor proposal or requirements list.
Another pattern that helped was the counterexample. When an analyst wants the model to critique a set of requirements or a process flow, they should include one real example of a past failure. Something like, in our last CRM rollout we forgot to define data ownership and that caused six months of duplicate records. The model then uses that as a lens to spot similar gaps. Without a counterexample, the critique tends to be too polite and too generic.
There was one awkward moment when I realized my own prompts were too long. I had written a monster prompt with five paragraphs of background, three constraints, and a detailed output format. The model lost the thread and started inventing requirements that didn't exist. A junior analyst simplified it to two sentences and got a better answer. I had to admit that more context isn't always better. The trick is deciding which context changes the answer.
What I have learned is that business analysts don't need prompt engineering as a separate skill. They need to translate the mental model they already use when writing a requirements document or a stakeholder email. The patterns that work are just that mental model made explicit. Once they saw prompts as a way to hand over their unspoken assumptions, the quality of their outputs jumped. And I stopped handing out templates.