Prompt Engineering That Actually Works

The 5 layers of a great prompt

• Role - who the model should be (“You are a senior growth PM…”)
• Context - the situation, constraints, audience
• Task - the single, specific outcome you want
• Constraints - format, length, tone, things to avoid
• Examples - 1–3 worked examples (few-shot)

Chain-of-thought

Adding think step by step forces the model to surface its reasoning before concluding. This catches logical errors and dramatically improves analytical tasks.

Output formatting

Ask explicitly for JSON or a markdown table when the output will be parsed or pasted into Notion. Structure is leverage - it makes downstream automation trivial.

Few-shot prompting

One great example beats a paragraph of instructions. For recurring PM tasks, keep a small library of input → output pairs you can paste into the prompt.

---

Part 2: Advanced Techniques

System prompts - your persistent instruction layer

A system prompt is a set of instructions that runs before every message in a conversation. It's the difference between starting every chat from scratch and starting every chat with a fully briefed AI that already knows your role, your standards, and your context.

In Claude Projects and ChatGPT Custom GPTs, the system prompt is set once and applies to the whole project. In API calls, it's the system parameter. Either way, it's the highest-leverage prompt you'll ever write - because it compounds across every subsequent interaction.

What belongs in a system prompt:

• Your role and company context
• The tone and format you always want
• What the AI should never do
• Standing rules that apply to every task ("always return JSON", "always include a confidence score", "never recommend solutions that require engineering if a no-code option exists")

A strong system prompt turns a general-purpose model into a specialist that knows your world.

Multi-turn conversation design

Most people use AI as a single-shot vending machine: one prompt in, one response out, start over. The real leverage is in conversation design - structuring a multi-turn dialogue where each turn builds on the last.

Patterns that work:

• Diverge then converge: Turn 1 - generate 10 options. Turn 2 - filter to the 3 best. Turn 3 - develop the winner in full.
• Critique loop: Turn 1 - generate output. Turn 2 - "critique this output against [criteria]". Turn 3 - "rewrite based on that critique."
• Interrogation first: Turn 1 - "ask me the questions you need answered before writing this brief." Turn 2 - answer them. Turn 3 - write the brief. Output quality is dramatically higher when AI has asked its own clarifying questions.
• Role reversal: Turn 1 - "you are a sceptical CPO reviewing this proposal. What are your top 3 objections?" Turn 2 - address the objections. Turn 3 - rewrite the proposal.

Prompt chaining for complex workflows

A prompt chain is a sequence of AI calls where the output of each step becomes the input of the next. This is the architecture behind most serious AI workflows - including your insight report automation.

Example chain for a growth experiment brief:

1. "Given this metric drop: [DATA], generate 8 hypotheses" → output: hypothesis list
2. "From this list, identify the 2 highest-leverage hypotheses based on: [CRITERIA]" → output: 2 hypotheses
3. "Write a full experiment brief for hypothesis #1 using this template: [TEMPLATE]" → output: brief

Each step is simple. The chain is powerful. This is also how you break tasks that are too complex for one prompt into reliable, auditable steps.

Context engineering - the skill after prompting

Prompting is what you type. Context engineering is everything else the model can see when it answers: project files, retrieved documents, memory, tool outputs, conversation history. As models got better at following instructions, the bottleneck moved from wording to context.

• Curate, don't dump. A long context full of irrelevant material measurably degrades answers. Ten pages of the right thing beats 200 pages of everything.
• Retrieval over paste. If the source changes (docs, tickets, analytics), connect it - a project file, a connector, or an MCP server - instead of pasting a stale copy.
• Memory is a design decision. Decide what should persist across sessions (role, ICP, tone, definitions) and what should be per-task. Persist the stable things in a Project system prompt.
• Watch for context rot. In long threads, early instructions get diluted. Restate the goal, or start a fresh thread with a short handover summary.
• Structure the context. Label sections (<brief>, <data>, <examples>) so the model can reference them precisely.

A practical test: if you handed the same context pack to a smart new colleague, could they do the task? If not, no prompt wording will save you.

Temperature and model selection intuition

You don't need to understand transformer architecture. You do need intuition about two things:

Temperature (in API settings) controls randomness. Low temperature (0–0.3) = consistent, conservative, deterministic - best for structured outputs, JSON, classification. High temperature (0.7–1.0) = more creative, more varied - best for brainstorming, copy variants, ideation. Most chat interfaces don't expose this directly, but some tools do.

Model selection: Bigger ≠ always better. For simple classification or extraction tasks, the fast/cheap tier of any provider is far quicker and cheaper than the frontier tier. Use the most powerful model for: complex reasoning, long document analysis, nuanced judgment calls. Use lighter models for: tagging, classification, simple transformations at scale.

The PM intuition: match model power to task complexity. Over-specifying wastes cost and latency. Under-specifying wastes output quality.