Prompt Engineering Fundamentals
Beginner 10 min Module 6 of 6
Module 6 of 6

Building Your Use Case

Everything in this course has been building toward one thing: you, with a real problem, writing a prompt that actually works. This module puts every technique together and walks you through building, testing, and refining a prompt for a task you do in your own work.

By the end of this module you will be able to

The Six-Step Workflow

Every strong prompt starts with clarity about what you actually need. These six steps give you a repeatable process for any task.

1
Define the task. One specific deliverable, not a vague goal. "Write a 200-word product description for our new feature" is a task. "Help with marketing" is not.
2
Name the audience. Who will read or use this output? A VP who skims quickly is different from a technical engineer who reads every line.
3
Specify the format. Bullets, paragraphs, a table, JSON, a numbered list? If you do not say, the model will guess.
4
Add at least one example. Even a one-sentence example of the tone or style you want reduces ambiguity dramatically.
5
Set constraints. What should the output avoid? "Do not include jargon" or "do not exceed 150 words" are constraints that prevent the most common failure modes.
6
Test and iterate. Run the prompt. Note what is wrong. Fix one thing at a time. Three iterations will take you from a mediocre output to a consistently good one.

Five Domains Where Prompting Returns the Most

Prompting works across thousands of tasks, but these five domains consistently deliver the highest return relative to the time invested in learning the skill:

1. Writing. Email drafts, meeting summaries, reports, proposals, and documentation. Any writing task that you do repeatedly is a candidate for a saved prompt template.

2. Analysis. Summarizing long documents, extracting key points from a report, comparing options, identifying patterns in feedback. AI is especially fast at tasks that require reading a large amount of text before drawing a conclusion.

3. Coding. Generating boilerplate, explaining unfamiliar code, debugging, writing tests, translating between programming languages. Even non-engineers benefit here for automating repetitive tasks.

4. Research synthesis. Combining information from multiple sources into a coherent summary. Particularly valuable for competitive research, literature reviews, and market analysis.

5. Customer-facing communication. Drafting responses, writing FAQs, personalizing templates at scale. Prompting gives you a consistent brand voice without requiring every team member to be a skilled writer.

A Worked Example: Status Report to VP

Here is a real prompt built through the six-step workflow. The task: summarize a team's weekly status report for a VP audience.

Draft 1 (no framework):

Summarize this status report.

Result: a wall of text, generic phrasing, no clear priority signal. Now applying the workflow:

Draft 2 (with CLEAR and constraints):

[R] You are a senior communications manager at a tech company.
[C] This is a weekly engineering team status report. The reader is a VP of Product who has 5 minutes and needs to know: what shipped, what is blocked, and what needs their decision.
[A] Write for someone who skims. They will not read paragraphs.
[L] Keep the total response under 200 words.
[Format] Use three sections: Shipped This Week (bullets), Blockers Needing VP Action (bullets), Coming Next Week (bullets).
[Constraint] Do not include implementation details. Focus on business outcomes and decisions needed.

[paste status report here]

This draft will produce a structurally correct output. After testing, you might refine once more to add a constraint like "if there are no blockers, say 'No blockers this week'" so the output handles that case cleanly.

Iteration: How Prompts Improve

The most common mistake is giving up after one try. A prompt that produces 70% of what you need is not a failed prompt, it is a first draft.

When an output is wrong, diagnose before rewriting. Ask: is this a missing context problem? A format problem? A tone problem? A compound task problem? Fix one thing at a time. Changing three things at once makes it impossible to know which fix worked.

A practical shortcut: when the output is bad, ask the model directly: "What information would help you answer this better?" It often identifies the exact context you forgot to provide.

When Prompting Is Not Enough

Prompting works within the patterns the model already learned during training. For most tasks, those patterns are broad enough to cover what you need. But three situations call for a different approach:

Highly specialized domains. If your task requires expertise in a narrow field where public training data is sparse — niche legal jurisdictions, proprietary internal terminology, specialized scientific subfields — the model may not have the patterns needed to perform well, no matter how well you write the prompt.

Very high accuracy requirements. For tasks where an error rate above 1-2% is unacceptable, prompting alone is rarely sufficient. Medical diagnostics, financial reporting, legal review at scale: these require evaluation frameworks and possibly fine-tuning.

Consistent performance at scale. A prompt that works 90% of the time in manual use may degrade under automated, high-volume conditions. Hu et al. (arXiv:2106.09685) introduced LoRA, a technique that allows fine-tuning large models with far fewer parameters than traditional approaches, making domain adaptation more accessible. When prompting plateaus, fine-tuning is the natural next step.

The prompting vs. fine-tuning boundary Start with prompting. It is faster, cheaper, and more flexible. Move to fine-tuning when you have a clearly defined task, a dataset of good examples, and a performance target that prompting cannot consistently reach.
Practice: What is missing from this prompt? "Write a summary of the attached document for my team."
Three things are missing: (1) Length — how long? One paragraph, one page, three bullets? (2) Audience — who is "my team" and what do they need to take away? (3) Format — bullets, prose, a structured summary with sections? Without these three, the model will make its best guesses, which may not match what you actually need.
Knowledge check
What does iterating on a prompt mean in practice?
Correct. Iterating means diagnosing the specific failure, fixing one thing at a time, and testing again. Changing everything at once makes it impossible to know what worked.
Iterating is a specific diagnostic process: test, note what is wrong, fix one specific thing, test again. Rewriting from scratch loses the parts that were working.
When should you consider fine-tuning instead of prompting?
Correct. Fine-tuning is appropriate when you have a specific task, a dataset of examples, and a performance target that prompting cannot consistently meet. Start with prompting first.
Fine-tuning is not the default, it is the next step after prompting plateaus. The right trigger is: specific task, good dataset, performance requirement that prompting cannot meet.
Which paper introduced LoRA, a technique for efficient fine-tuning of large models?
Correct. Hu et al. (arXiv:2106.09685) introduced Low-Rank Adaptation (LoRA), which allows fine-tuning large models efficiently by updating only a small fraction of parameters.
Not quite. Hu et al. (arXiv:2106.09685) introduced LoRA. Brown et al. covers few-shot learning; Wei et al. covers chain-of-thought prompting.
Before you go
Reflection: Write one prompt for a real task in your own work using the six-step workflow. Share the result on LinkedIn with #PromptEngineering.
Coming up: Capstone You have now covered every core technique in this course. In the capstone, you will build a complete three-prompt library for your own role and earn your certificate of completion.
You might also like
Was this module helpful?
← Module 5: Avoiding Bad Outputs Capstone: Build Your Prompt Library →