Beginner's Guide to Prompt Engineering for Business Analysts

"Write user stories for the new onboarding flow." That is a perfectly reasonable sentence. It is also why so many analysts get back a page of bland, interchangeable text mentioning "as a user, I want to log in" and nothing about your actual business. The request was clear to the person typing it, because that person already knew the who, the why and what finished looks like. The assistant knew none of it, so it filled the gaps with averages.

Prompting well is mostly the work you already do in a kickoff: name the audience, state the goal, hand over the source material, define what a good answer looks like. You just have to write it down instead of saying it out loud.

Why Short Prompts Disappoint

Two things go wrong with a thin prompt. Either the assistant invents context it does not have — plausible stakeholders, imaginary rules, a process you have never run — or it retreats into generalities safe enough to apply to any company in your industry.

Both outcomes are worse than a blank page, because they look finished. A generic user story can survive a review meeting. An invented business rule can end up in a spec. The fix is not a longer prompt for its own sake; it is a prompt that removes guesswork.

The Four Parts of a Prompt That Works

Almost every reliable prompt you write will contain these four pieces, in roughly this order.

• Role and reader. "You are helping a business analyst write requirements for a claims team that will read them in a sprint review." The reader matters more than the role.
• Task. One verb, stated plainly. Extract, compare, rewrite, group, draft. If you need three verbs, you probably need three prompts.
• Context and constraints. What you know about the process, the system, the regulations and the people involved. Also what to leave out: no technical design, no pricing, no assumptions about headcount.
• Format. Table, numbered list, three paragraphs, one sentence per item. Say how long and say what columns.

Here is the same onboarding request, rebuilt:

I am a business analyst at a mid-size insurer. Using only the workshop transcript below, produce a numbered list of functional requirements for the claims intake process. For each requirement, cite the line of the transcript it came from. Mark anything that is a policy decision rather than a requirement. If the transcript does not answer something important, list it as an open question instead of guessing. Output a table with these columns: ID, Requirement, Source, Open question.

That prompt takes about ninety seconds to write and saves the first two rounds of corrections.

Feed It Your Own Material

Your value as an analyst is the raw material you carry: interview notes, process maps, ticket exports, policy excerpts, old requirement documents nobody has read since 2019. Paste that in. A model working from your transcript will sound like your organisation; one working from memory will sound like a textbook.

Two habits make this work better. First, tell it what must survive unchanged — field names, regulatory references, system names, the exact wording of anything legal or contractual. Second, ask it to point back at the source. "Cite the section you used" turns a confident paragraph into something you can check in thirty seconds.

Ask for Output You Can Use Immediately

Do not settle for prose you then have to reformat. Analysts live in tables, and so should your outputs.

1. Requirements as a table: ID, statement, source, priority, owner, open question.
2. User stories with acceptance criteria written in Given/When/Then form.
3. Interview notes reduced to themes, direct quotes and unanswered questions.
4. A policy document converted into a rules table with a clause reference per row.

Ask for the column headers you actually want, in the order you want them. It is a small instruction with an outsized effect on how much editing happens afterwards.

Iterate in Small Steps

The most common beginner mistake is asking for everything at once: summarise the transcript, draft the stories, write the test cases, and suggest a rollout plan. You get four mediocre answers instead of one good one.

Break it up. First, ask for the list of requirements. Read it. Delete what is wrong. Then ask for acceptance criteria for item four only. Then ask, "what edge cases would break this requirement?" Each turn builds on a version you have already approved, which is exactly how you would review a junior colleague's work.

Verify Before You Circulate

Treat every output as a first draft from a fast, well-read colleague who has never met your stakeholders. That colleague is useful and occasionally wrong in ways that are hard to spot.

A few habits keep you safe. Check names, numbers, dates and references against the source yourself. Ask the assistant to list its assumptions, then read that list carefully — that is usually where the invented context hides. Ask what it could not determine from the material provided, and turn those gaps into agenda items.

Where requirements touch legal, regulatory, financial or safety obligations, do not rely on a drafted summary. Confirm wording with the source document and the appropriate specialist in your organisation before anything is signed off.

Build a Small Prompt Library

You do not need dozens of prompts. You need four or five you have tested and trust.

Start with the task you repeat most often — interview notes, requirement drafts, meeting summaries, ambiguity reviews — and write one prompt for it. Save it somewhere your team can find it. Next week, improve it using what went wrong. Over a few months you end up with a short set of prompts that produce work in your format, in your vocabulary, with your review standards baked in.

Keep the last step a human one. The prompt handles the blank page; you still decide what belongs in the spec.

Photo: Yan Krukau / Pexels