Build a Prompt Library You Can Reuse

The best prompt an analyst wrote this month is sitting in a chat history she will never scroll back to. It took her three rounds to get right. It had the audience, the limits, an example and a closing request for assumptions. It produced a draft she was proud of. And next Tuesday, facing a similar task for a different project, she will start again from a blank box and make the same early mistakes. If you are joining us on day five, here is where we are. This week is five days on prompting for business analysts, following one analyst who is writing the requirements for a service request intake form for a facilities team that currently takes requests by email, where repairs get lost and urgency is unclear. Day one showed that a prompt is a specification with five parts: role, task, context, constraints and format. Day two covered the context to supply and what to keep out. Day three covered asking for a named output shape, one task at a time. Day four covered treating the first answer as a draft and using specific follow-ups to improve it. Today we turn the prompts that worked into a reusable library.

That is the hidden cost of treating prompts as one-off messages. Most analyst work repeats. The shape of an interview question list, a requirements review, a stakeholder summary, a set of acceptance criteria or a release note barely changes from one project to the next. Only the content changes. A prompt that has already been refined, tested and corrected is a reusable asset, and the analysts who see it that way spend less time on setup and more on judgment. This final day is about turning the techniques from the week, five parts, rich context, a named output shape and structured follow-ups, into something permanent.

From a good prompt to a template

A template is a prompt with the project-specific parts replaced by placeholders. Take a finished prompt, such as the one for the intake form, and strip out what belongs to that one project: the facilities team, the email problem, the finance exclusion. What remains is the structure, and the structure is the valuable part. Replace each removed item with a labelled gap, such as the team, the current process and its pain, the limits, and the example to match. Next time, you fill in the gaps and send.

Good templates share a few features. They start with the role and the task, so the intent is clear on a quick read. They have one clearly marked place for each piece of context, so nothing gets forgotten. They end with the standing requests that worked: list your assumptions, list your open questions, keep to this format. And they carry a note to the user, outside the prompt itself, saying when to use the template and what to check in the answer. That note is your own review standard written down once, and it is what keeps a template from becoming a shortcut that skips the thinking.

Anonymising your prompts, replacing names with roles and a company with "the client", pays off here. A template written with roles and placeholders contains no client information, so it is safe to store, safe to share with colleagues, and safe to use on the next engagement without editing out what you did last time.

Be honest about what a template cannot do. It gives you a strong starting point, and it does not remove the need to think about the specific situation. A template for requirements drafting will happily produce a plausible list for a project where the real problem is a missing decision, not a missing requirement. Use the template to save setup time, and then spend the time you saved on the questions that only you can ask: who is affected, what has been tried before, and what would make this change fail. A library works best in the hands of an analyst who still asks those first.

A starter library for analysts

Eight to ten templates cover most weeks. The table below is a starting list, with the kind of time an analyst might expect to save on each. The figures are illustrative: your own will depend on the task and on how much you edit the output.

A STARTER LIBRARY OF PROMPT TEMPLATES

Illustrative estimates, not measured results. Track your own for a month.

Name each template so you can find it in a few seconds, with the task first, for example "Review: ambiguity check" or "Draft: requirements from notes." Keep them in one place you already use, such as a notes app, a shared team folder or a wiki page, and add a version date to each. When you improve a template after a good session, update the file and keep the old version for a week in case the change was a step backwards.

If you work in a team, a shared library does something more valuable than saving time: it makes a method common. Two analysts using the same ambiguity check produce reviews that look the same, which makes the work easier to compare, hand over and teach. It also shows quickly where a prompt is weak, because five people will hit the same problem within a fortnight.

Give the library an owner and a rhythm. One person, often the most senior analyst or the team lead, holds the master copy, and everyone else proposes changes with a short note of what the change fixed. A short review once a month is enough: retire templates nobody used, merge near-duplicates, and add the one or two new ones that came out of real work. Without an owner, libraries tend to grow into a long folder of near-identical files that nobody trusts. With one, it stays small, current and worth opening, which is the difference between a tool a team uses and a folder it forgets.

A five-day practice plan

Skills like this settle in through small repeated use, not a single afternoon of reading. Here is a plan that costs about fifteen minutes a day. On Monday, take a task you are already doing and write the prompt with all five parts, then keep it. On Tuesday, add one real, anonymised example and compare the result with the day before. On Wednesday, end your prompt with the assumptions and open questions request, and take at least one of the questions to a stakeholder. On Thursday, run the six follow-ups (challenge, test, widen, narrow, check and tidy) on a draft and record which changed it most. On Friday, turn your best prompt of the week into a template, name it and save it.

At the end of the week you will have a working template, a better sense of which follow-ups earn their place in your own work, and a habit that sits comfortably alongside the skills you already have. Everything here rests on the same professional instincts that make you good at analysis: asking who it is for, saying what done looks like, and reviewing before you sign. Next week the series moves to product, with the step from a list of requirements to a roadmap.

Go out and be successful.

Oluwatosin Ogunkoya · Flotog BA Insights · 1:1 mentoring and coaching for BAs at every career stage · www.flotogbainsights.com

NEXT WEEK

From Requirements to Roadmap - How a BA moves from a list of requirements to the sequencing and trade-offs that a product roadmap needs.