# Write a PMM job brief Claude can act on the first time

A brief for Claude names a role, one bounded job, the inputs it may use, the output shape, an evidence rule and who approves the result before it ships.

URL: https://www.hiresteve.ai/blog/claude-job-brief
Updated: 2026-10-12

A usable brief for Claude has six parts: the role Claude takes, one bounded job, the inputs it may use, the shape of the output, the rule for evidence, and the person who approves the result. Write all six into the message before you send it.

## Give Claude a role before the job

Anthropic's [prompting guidance](https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/claude-prompting-best-practices), checked September 16, 2026, describes Claude as a brilliant but new employee who lacks context on your norms and workflows, and says that setting a role in the system prompt focuses its behavior and tone, even in a single sentence. The guide puts the role in an API system prompt. In an ordinary Claude chat, put the role in your message or Project instructions.

Two things stand in for it. For a job you repeat, put the role in a [Claude Project's instructions](/blog/claude-project-setup), which apply to every chat inside the Project. For a one-off, open the message with it: "You are a product marketer at [company] drafting a battlecard row; the readers are account executives with two minutes before a call." One sentence tells Claude who the output is for and how it should sound.

## Name one deliverable and the inputs it may use

Ask for one deliverable. "Help with battlecards" returns a generic page. "Draft the pricing-objection row for the [competitor] battlecard" returns something a seller can read. A job with two deliverables is two briefs.

Then list what Claude may use, and say the list is the boundary. Paste the competitor's pricing page text with its URL and the date you copied it, attach your own pricing sheet, name the Project files that apply. Add one sentence: "Use only these inputs; if they do not cover a point, say so." Without that boundary, Claude may fill gaps from general knowledge, so unsupported details can enter otherwise fluent copy. Check what you are allowed to paste first; the [lesson on protecting GTM inputs](/blog/safe-gtm-data) covers that.

Richard King makes the same point about sequence in [The Claude skill stack for product marketing](https://productmarketingalliance.substack.com/p/the-claude-skill-stack-for-product-marketing) (Product Marketing Alliance, April 2, 2026): running anything before the context is set up "is like asking a new hire to write your positioning doc on their first day."

## Specify the output shape

The same Anthropic page says to be specific about the desired output format and constraints, and to give instructions as numbered steps when order matters. For a PMM job, describe where the answer will be pasted. A battlecard row has a fixed shape. If the brief does not state it, Claude may choose a shape that you then have to reformat.

Here is one brief filled in for a single job. The competitor, file names and limits are placeholders for practice, not a real card.

| Element | What goes in the brief |
| --- | --- |
| Role | Product marketer at [company]; readers are account executives with two minutes before a call |
| Job | Draft the pricing-objection row for the [competitor] battlecard |
| Inputs | [Competitor] pricing page text, copied [date], with URL; our pricing sheet v[n]; `competitors/[competitor].md` from the Project |
| Output shape | Three lines: the objection in the buyer's words (under 20 words), our response (under 40 words), one proof point with its source URL. Plain text, no headings |
| Evidence rule | Every number and feature claim carries the URL and date it came from. No source, no claim; write "unverified" instead |
| Approver | [Name], battlecard owner, before it goes into the sales deck |

Write the output shape as tightly as the table does. Length limits and "plain text, no headings" reduce reformatting. The [battlecard lesson](/blog/battlecards-sales-actually-uses) presents a three-line format designed for quick reference during a call.

## State the evidence rule in the brief itself

The evidence rule is one sentence: every material claim carries a source Claude was given, or it is cut or marked unverified. Put it in the brief every time, even inside a Project whose instructions already say so. It costs one line and it changes what comes back.

A brief with no evidence rule can return fluent prose whose factual claims still need checking. With the rule, Claude has explicit instructions to attach URLs to sourced lines and mark unsupported lines, leaving you to find the evidence or drop the point. For a whole competitor, the rule grows into a [claim ledger](/blog/competitive-claim-ledger) with a date and status per claim. For one brief, the sentence is enough.

## Name who approves it

State in the brief who signs off and where the output goes next. "[Name] reviews this before it goes into the deck" is enough. The approver is the person accountable for the destination: the battlecard owner for a battlecard row, the messaging owner for a positioning line. This is our recommendation; none of the vendor or practitioner guidance linked above covers it.

Without a named owner, someone may use the output before it is checked. That can put an unchecked pricing claim into a sales call.

## Check the result before anyone uses it

**A brief does not replace source and approval checks**

The brief tells Claude what output shape and citation behavior to aim for. If web access is enabled, Claude can fetch a source, but you still verify the passage. Name the approver in the brief because Claude cannot reliably infer your organization's sign-off policy.

- Open every cited source and confirm the passage supports the line that cites it.
- Confirm each line stays inside the inputs you supplied; anything else is a guess.
- Confirm the output matches the shape closely enough to paste without editing.
- Confirm every unsupported point is marked, not smoothed into prose.
- Send it to the named approver and treat it as a draft until they answer.

The source check is easy to skip when the prose reads well. [How to verify AI research](/blog/verify-ai-research) walks through it in detail.

## Reuse the brief for the next job

The six elements do not change between jobs; the job and the inputs do. Keep the brief as a snippet and swap those two lines. Inside a Project, the role and the evidence rule can live in the instructions, and each message carries the rest. Handing a working brief to a teammate is its own lesson: [make a Claude workflow transferable](/blog/claude-workflow-handoff).

The wording below is the whole brief as sentence starters. Fill the brackets and delete any line a Project already covers.

Prompt: the six-element brief

```prompt
Role: You are [role] at [company]. The reader is [audience] with [time or context].
Job: Produce [one deliverable] for [destination].
Inputs: Use only the following: [pasted text with URL and date], [attached files], [Project files]. If they do not cover a point, say so.
Output: [sections or lines, in order, with length limits and format].
Evidence: Every material claim carries the URL and date it came from. No source, no claim; mark it "unverified" instead.
Approval: [Name] reviews this before it is used. Treat it as a draft until then.
```

## Where Steve fits, and where it does not

For a one-off brief, the method above is the complete answer. A monitoring product adds nothing to one memo or one pricing question. The method stops being enough when the same brief runs for every competitor, every time a pricing page changes, and the checks above have to happen each time.

Steve handles that case for battlecards. Each claim on a Steve battlecard shows its status (Confirmed, Needs verification or Unverified) and links to its sources. When news changes a claim, Steve suggests an update and you choose to keep the current version, apply the update or accept both. Steve does not write a brief for arbitrary jobs; a one-off positioning memo or review-mining pass still needs the six lines above.

If recurring battlecard upkeep is the job, review [Steve's competitive-intelligence product](/products/competitive-intel) and confirm current availability for your account. Otherwise keep the six lines and use them.

## Frequently asked

### Do I still need a role line if I use a Claude Project?

Only if the Project instructions do not already state one. A standing role belongs in Project instructions; the task message then carries the job, inputs, output shape and evidence rule. In a plain chat, put the role in the first sentence.

### How detailed should the output shape be?

Detailed enough to paste the answer into its destination without reformatting. Name the sections or lines, their order, length limits and what each must contain. If you keep having to rewrite the layout, add the missing detail to the brief.

### What happens when Claude has no source for a claim?

The claim is cut or marked unverified, never kept as ordinary prose. Tell Claude to flag unsupported statements and list what would confirm them. You then decide whether to find the evidence or drop the point.

### Where do I keep the brief between jobs?

As a text snippet you paste and edit. Keep the role and evidence rule in Project instructions when the job repeats, and retype only the job, inputs, output shape and approver. Save the filled-in copy beside the deliverable so the next person can see what produced it.