Professional, lesson 1

The discovery brief

Start from a measured outcome, not a capability

The Lumen Supply board has approved "use agents" for support. Ops, finance and support each want a different number to move, and nobody has said which. Six months in, each team reads a different chart. This is the brief writer at Lumen Supply, an online electronics shop. You will watch a brief pass a weak check, then fix the check so a team can test what it accepts.

I doWatch the failure and its fix.

One board decision, three teams, three numbers

The board decision is a capability: use agents for support, at 10,000 tickets a day across three regions. Ops wants faster first replies. Finance wants a lower cost per ticket. Support wants fewer escalations to senior agents.

Claude reads one team's note and drafts a brief. A checker decides whether the draft can be tested. Three things go wrong: a named capability leaves a field weak, a target only restates the baseline, and scope waits for later.

A brief a team can test

This brief starts from the ops note. It names the metric, p95 first reply time, and the baseline, 38 minutes. The note gives no target or deadline, so Claude proposes 15 minutes by the end of Q2 and marks both for the team to confirm. It also lists the decisions that stay with people and the constraints.

Open the draft cards. The first draft was complete, so the check accepted it.

BoardName the outcome the ops note wants.
Toolreads the ops note

ClaudeMetric: p95 first reply time, measured in the helpdesk from ticket creation to the first human or automated reply, reported for each of the three regions separately. Baseline: 38 minutes (p95, last month, all regions). Slowest hours are the two after a product launch.. Target: 15 minutes p95 in every region, including during the two hours after a product launch. PROPOSED, not in the ops note: team to confirm.. Deadline: End of Q2. PROPOSED, not in the ops note: team to confirm..

Show the result

{
  "title": "Cut p95 first reply time for support tickets, in all three regions",
  "metric": "p95 first reply time, measured in the helpdesk from ticket creation to the first human or automated reply, reported for each of the three regions separately",
  "baseline": "38 minutes (p95, last month, all regions). Slowest hours are the two after a product launch.",
  "target": "15 minutes p95 in every region, including during the two hours after a product launch. PROPOSED, not in the ops note: team to confirm.",
  "deadline": "End of Q2. PROPOSED, not in the ops note: team to confirm.",
  "stays_with_people": "Refunds above 500 dollars and any change touching customer account security are decided by a person. Human agents keep ownership of final replies on these cases.",
  "constraints": [
    "No added workload for the 120 floor staff in Q1; the rota is already tight.",
    "The gain must hold in all three regions, not only the quietest one.",
    "EU customer data must stay in the EU.",
    "Helpdesk vendor API limit: 20 calls per second.",
    "Board has approved the decision to use agents for support."
  ]
}

Checkaccepted
Show the result
```
{
  "accepted": true
}
```

A brief a team can test: Metric: p95 first reply time, measured in the helpdesk from ticket creation to the first human or automated reply, reported for each of the three regions separately. Baseline: 38 minutes (p95, last month, all regions). Slowest hours are the two after a product launch.. Target: 15 minutes p95 in every region, including during the two hours after a product launch. PROPOSED, not in the ops note: team to confirm.. Deadline: End of Q2. PROPOSED, not in the ops note: team to confirm..

The six fields, written as code

The starting checker asks for a title and nothing else. The fix checks six fields: the metric, the baseline, the target, the deadline, what stays with people, and the constraints.

A metric is a number with a unit and a way to measure it. A capability word with nothing measured, such as "agents deployed", is not one. A target with no baseline beside it means nothing. A target that only restates the baseline, such as "below 38 minutes", is a direction: any cut meets it.

A constraint changes the design, such as data that must stay in the EU or a spend cap. Each has an owner, and when two collide the brief ranks them and says which one gives. Scope is written down too, so a change to it becomes visible.

starter/brief.py

1"""EDIT THIS FILE. check_brief() accepts any brief that has a title.2A brief that names a capability, with no metric and no baseline, passes.3Run `./workshop check discovery-brief` until it is green, then4`./workshop watch discovery-brief`.5"""67from kit.api import Json8910def check_brief(brief: Json) -> list[str]:11 """Return the fields that are empty or too weak to test.12 An empty list accepts the brief. The fields are metric, baseline,13 target, deadline, stays_with_people and constraints.14 """15 return [] if brief.get("title") else ["title"]

Can a team tell if "use agents" worked?

The board decision names a technology. It names no metric, no baseline and no decision that stays with people. Suppose a team builds exactly what the board approved.

Predict: Six months later, can the team tell whether "use agents for support" worked?

AYes. Tickets are being handled by agents, so it worked.
BNo. The decision gives no metric and no baseline to compare against.

Show the answer

B. A capability is what you build. An outcome is what changes. Without a baseline, no target can be met or missed.

A brief with no real target passes the starting check

This is the same board decision with the starting checker, on the ops note. The ask said to use the ops note for constraints only, yet Claude read all three notes.

The brief has a metric, a baseline and a deadline. Its targets say "below the 38-minute baseline" and "below 4.20 dollars". Those are directions, so any cut at all would meet them. The checker accepts it.

This is a real Claude Haiku 5.5 run, recorded once and replayed here.

BoardUse agents for support.
Toolreads the ops note
Toolreads the ops note
Toolreads the ops note

ClaudeMetric: p95 first reply time per region (helpdesk timestamps); cost per ticket from monthly finance close; escalation rate to senior agents; quality check on escalated and reopened tickets.. Baseline: p95 first reply time 38 minutes last month (helpdesk, ticket creation to first human or automated reply). Support cost 4.20 dollars per ticket last quarter (pay, tooling, helpdesk licence). About 22% of tickets escalated to senior agents. Volume about 10,000 tickets a day across three regions.. Target: Reduce p95 first reply time below the 38-minute baseline in all three regions, including during the two hours after product launches. Reduce cost per ticket below 4.20 dollars, visible in the monthly close. Reduce escalations to senior agents by solving more tickets correctly, not by hiding them.. Deadline: In place before the holiday peak. Exact date not stated in the notes; to be confirmed by the board..

Show the result

{
  "title": "Pilot: AI agents for customer support (board-approved)",
  "baseline": "p95 first reply time 38 minutes last month (helpdesk, ticket creation to first human or automated reply). Support cost 4.20 dollars per ticket last quarter (pay, tooling, helpdesk licence). About 22% of tickets escalated to senior agents. Volume about 10,000 tickets a day across three regions.",
  "target": "Reduce p95 first reply time below the 38-minute baseline in all three regions, including during the two hours after product launches. Reduce cost per ticket below 4.20 dollars, visible in the monthly close. Reduce escalations to senior agents by solving more tickets correctly, not by hiding them.",
  "metric": "p95 first reply time per region (helpdesk timestamps); cost per ticket from monthly finance close; escalation rate to senior agents; quality check on escalated and reopened tickets.",
  "deadline": "In place before the holiday peak. Exact date not stated in the notes; to be confirmed by the board."
}

ClaudeMetric: p95 first reply time per region (helpdesk timestamps); cost per ticket from monthly finance close; senior escalation rate; quality check on escalated and reopened tickets. Pilot ends with a single board-ready number for each.. Baseline: p95 first reply time 38 minutes last month (helpdesk, ticket creation to first human or automated reply). Support cost 4.20 dollars per ticket last quarter (pay, tooling, helpdesk licence). About 22% of tickets escalated to senior agents. Volume about 10,000 tickets a day across three regions.. Target: Reduce p95 first reply time below the 38-minute baseline in all three regions, including the two hours after product launches. Reduce cost per ticket below 4.20 dollars, visible in the monthly close. Reduce senior escalations by solving more tickets correctly, not by hiding them.. Deadline: In place before the holiday peak. Exact date not stated in the notes; to be confirmed by the board..

Show the result

{
  "title": "Pilot: AI agents for customer support (board-approved)",
  "baseline": "p95 first reply time 38 minutes last month (helpdesk, ticket creation to first human or automated reply). Support cost 4.20 dollars per ticket last quarter (pay, tooling, helpdesk licence). About 22% of tickets escalated to senior agents. Volume about 10,000 tickets a day across three regions.",
  "target": "Reduce p95 first reply time below the 38-minute baseline in all three regions, including the two hours after product launches. Reduce cost per ticket below 4.20 dollars, visible in the monthly close. Reduce senior escalations by solving more tickets correctly, not by hiding them.",
  "metric": "p95 first reply time per region (helpdesk timestamps); cost per ticket from monthly finance close; senior escalation rate; quality check on escalated and reopened tickets. Pilot ends with a single board-ready number for each.",
  "deadline": "In place before the holiday peak. Exact date not stated in the notes; to be confirmed by the board.",
  "stays_with_people": "Refunds above 500 dollars (named human approver). Anything touching customer account security. Any complaint naming a lawyer. Anything about customer safety. Tickets that matter most must still reach a person quickly.",
  "constraints": [
    "No added workload on the 120-person floor during the first quarter; rota is already tight.",
    "EU customer data stays in the EU.",
    "Helpdesk vendor limit: 20 API calls per second.",
    "Must work in English, German and Spanish.",
    "Model spend within the existing 30,000 dollars per month tooling budget.",
    "No contract that raises cost per ticket during the pilot.",
    "Any refund denial needs a named approver for audit."
  ]
}

Checkaccepted
Show the result
```
{
  "accepted": true
}
```

Accepted, but it cannot be tested: target.

The checker names each weak field

The fixed checker returns the fields that are empty or too weak. On this draft it returns the target, and the refusal says to give a new number, not the baseline.

Claude revises and asks again: 15 minutes p95, 3.50 dollars a ticket, and escalations below 22 percent, each marked as proposed for the board to confirm. The check accepts it.

The check tests that a new figure is present, not that it is a good one. The escalation line still only restates its baseline, and a human has to read it. The refusal costs one more request: four instead of three.

brief.pygreen lines are what the fix adds

1"""Score a brief: name each field that is empty or too weak to test."""23import re45from kit.api import Json67CAPABILITY = re.compile(r"\b(agents?|ai|claude|llm|bots?|automation)\b", re.I)8MEASURE = re.compile(9 r"%|\b(rate|time|cost|share|percent|minutes|hours|days|dollars)\b", re.I10)11FIGURE = re.compile(r"\d\s*(%|[a-z]+)|\$\s*\d", re.I)12NUMBER = re.compile(r"\d+(?:[.,]\d+)*")13MIN_CONSTRAINTS = 2141516def has_figure(text: object) -> bool:17 """True when the text holds a number with a unit, like 38 minutes."""18 return bool(FIGURE.search(str(text or "")))192021def new_figure(target: object, *known: object) -> bool:22 """True when the target holds a figure the baseline does not.23 "Below the 38-minute baseline" restates today's number: a direction.24 """25 seen = set(NUMBER.findall(" ".join(str(k or "") for k in known)))26 found = NUMBER.findall(str(target or ""))2728 return has_figure(target) and any(n not in seen for n in found)293031def check_brief(brief: Json) -> list[str]:32 """Return the fields that are empty or too weak to test.33 A capability word with nothing measured is not a metric, a figure34 needs a unit, a target with no baseline beside it means nothing, and35 a target that only restates the baseline is a direction.36 """37 weak = []38 metric = str(brief.get("metric") or "").strip()39 names_tech = CAPABILITY.search(metric) and not MEASURE.search(metric)40 if not metric or names_tech:41 weak.append("metric")4243 if not has_figure(brief.get("baseline")):44 weak.append("baseline")4546 known = (brief.get("baseline"), metric)47 if not new_figure(brief.get("target"), *known) or "baseline" in weak:48 weak.append("target")4950 for name in ("deadline", "stays_with_people"):51 if not str(brief.get(name) or "").strip():52 weak.append(name)5354 constraints = [c for c in brief.get("constraints") or [] if str(c).strip()]55 if len(constraints) < MIN_CONSTRAINTS:56 weak.append("constraints")5758 return weak

We doChange one setting at a time and predict.

The same note, two briefs

Switch between the two board asks. Both runs use the fixed checker on the ops note, and the card marked "This is where the runs split" is the draft.

The "Use agents" ask reads all three notes, and its targets restate each baseline, so the check refuses it once. The outcome ask reads one note and gives 15 minutes by the end of Q2 on the first draft.

Finance and support tell the same story. Their capability drafts set no new number, and the checker refuses the target until Claude names one. Finance was refused twice, because its revision dropped the constraints.

This part is interactive in the lab: run ./workshop watch discovery-brief.

Try it: checker, ask and note

Change one setting at a time. Turn the checker on or off, pick the board ask, then pick a note.

Every combination is a recorded run, so this works with no internet. Some briefs with the checker off are accepted and still cannot be tested. The result line says which.

This part is interactive in the lab: run ./workshop watch discovery-brief.

The refusal tells Claude what to fix

The highlighted lines build the refusal. It names each weak field and how to fix it, so Claude revises instead of guessing. The checker decides. The prompt is only a request.

This support run proposed a target of 15% beside the 22% baseline, so the first check accepted it. A draft whose target only restates the baseline would come back with the refusal above.

Beyond this lab, three notes still need one brief. Reconcile them into one measured outcome with a named owner for the final call. Each audience then gets the view it decides with, drawn from the same numbers. The lab does not run that step, and the questions below ask about it.

app/tools.pyfile: 93 lines

···57 lines not shown58HINTS = {59 "metric": "name a measure with a unit, not the technology",60 "baseline": "give today's figure, taken from the note",61 "target": "give a new number to reach, not the baseline",62 "deadline": "give a date or a quarter",63 "stays_with_people": "name a decision that stays with people",64 "constraints": "give at least two constraints that change the design",65}666768def refusal(weak: list[str]) -> Json:69 """A structured refusal that names each weak field and how to fix it."""70 fixes = "; ".join(f"{n}: {HINTS.get(n, 'fill it in')}" for n in weak)7172 return {73 "error": {74 "category": "weak_fields",75 "retryable": True,76 "message": f"The brief cannot be tested yet. {fixes}.",77 }78 }798081def note_text(team: str) -> Json:82 """The text of one note, or a not_found error."""83 note = NOTES.get(team)84 if note is None:85 return {86 "error": {87 "category": "not_found",88 "retryable": False,···5 lines not shown

BoardName the outcome the support note wants.
Toolreads the support note

ClaudeMetric: Share of support tickets escalated to a senior agent, measured per month, with the reopen rate after AI handling as a guard metric so fewer escalations cannot come from hidden problems.. Baseline: About 22% of tickets escalated to a senior agent today (from the head of support's note).. Target: PROPOSED, for team to confirm: 15% or lower escalation share, with reopen rate after AI handling no worse than today's level.. Deadline: Live before the holiday peak. Exact date PROPOSED, for team to confirm: [date to be set by the team]..

Show the result

{
  "title": "Agent-assisted support: reduce senior escalations without hiding them",
  "metric": "Share of support tickets escalated to a senior agent, measured per month, with the reopen rate after AI handling as a guard metric so fewer escalations cannot come from hidden problems.",
  "baseline": "About 22% of tickets escalated to a senior agent today (from the head of support's note).",
  "target": "PROPOSED, for team to confirm: 15% or lower escalation share, with reopen rate after AI handling no worse than today's level.",
  "deadline": "Live before the holiday peak. Exact date PROPOSED, for team to confirm: [date to be set by the team].",
  "stays_with_people": "Any ticket about customer safety; any complaint that names a lawyer; every refund above 500 dollars. These go to a person.",
  "constraints": [
    "Fewer escalations must come from better resolution, not from hiding tickets; escalations must stay visible in reporting.",
    "Must work in English, German and Spanish.",
    "Safety, legal-threat and refunds over 500 dollars reach a human quickly.",
    "Senior agents' workload is a concern; the change must not add load to them.",
    "The system supports people and does not replace them; staff are informed of this plainly."
  ]
}

Checkaccepted
Show the result
```
{
  "accepted": true
}
```

A brief a team can test: Metric: Share of support tickets escalated to a senior agent, measured per month, with the reopen rate after AI handling as a guard metric so fewer escalations cannot come from hidden problems.. Baseline: About 22% of tickets escalated to a senior agent today (from the head of support's note).. Target: PROPOSED, for team to confirm: 15% or lower escalation share, with reopen rate after AI handling no worse than today's level.. Deadline: Live before the holiday peak. Exact date PROPOSED, for team to confirm: [date to be set by the team]..

You doFix the starting code, then test yourself.

You do: refuse a brief nobody can test

Copy the starting code and open work/discovery-brief/brief.py. check_brief() accepts any brief that has a title, so a brief that names a capability and no metric passes.

Terminal

./workshop start discovery-brief
./workshop check discovery-brief
./workshop watch discovery-brief

The checks refuse a capability brief and a target with no baseline, and name each empty field. They accept a complete brief and the sample in brief.yaml.

Check your understanding

Answer each question, then read why every option is right or wrong. The wrong options are the mistakes engineers make on the job.

1. A regional retailer with 10,000 support tickets a day tells you the board wants agents on the queue inside one 90-day quarter. The budget is fixed at 30,000 dollars a month. The request names the technology and a launch date but no result the business should see, and the three team leads each describe success differently. What do you ask first?

AWhich agent framework and cloud platform the engineers already know best.
BWhich tickets the support team finds most tedious to answer by hand today.
CWhich result must move, by how much, and what that figure is today.
DWhich executive will sign off the budget before the quarter begins.

Show the answer

Answer: C

A A framework is a way to build. With 90 days on the clock, choosing it before the goal is agreed spends the time on the wrong question.
B Tedious tickets are a scope guess. They say where the work is boring, not what the business wants to change or how it would be measured.
C Correct. A measured result with today's figure is what the team can test at the end of the quarter.
D A name on a sign-off does not say what the project is for, so it settles who approves and nothing about success.

2. A brief sets the goal "cut handle time by 30 percent" for a pilot that starts in two weeks. Ops measures handle time from first reply to close and reports 14 minutes, while finance measures from creation to close and reports 26, and neither is written down. The readout is fixed for week 12. What comes before the target is set?

AAgree one definition and one baseline figure, then take the 30 percent from it.
BAverage the two figures to 20 minutes, a baseline both teams can accept.
CUse the ops figure, since the ops team runs the queue and knows the work.
DStart the pilot and read the baseline off the first month of live results.

Show the answer

Answer: A

A Correct. A target is a change from a baseline, and two definitions give two different changes for the same pilot.
B An average of two definitions measures nothing real. Neither team can reproduce 20 minutes from its own data.
C Taking one team's number settles the argument by rank, and finance then reads a different result at the readout.
D A baseline taken after the change cannot show what the change did, and the pilot has no starting point.

3. The board asks what a testable outcome for the support agent pilot looks like. The pilot window is 12 weeks, finance closes the books monthly, and the helpdesk already stores a cost per ticket for every quarter before any change. Select two parts that the outcome needs so that someone outside the team can test it at the readout.

AA count of tickets the agents touched by week 12.
BA metric with a unit, such as cost per ticket in dollars.
CA shortlist of vendors that could supply the agents.
DA baseline figure taken before the change, such as 4.20 dollars.

Show the answer

Answer: B, D

A Tickets touched counts activity. It can rise while cost and wait times stay the same, so it does not test anything.
B Correct. A metric with a unit can be measured by someone other than the team that built the project.
C A vendor shortlist is part of how to build. It says nothing about what should get better.
D Correct. Without today's figure a target cannot be met or missed, and the readout has nothing to compare against.

4. A vendor demo shows an agent closing 8 test tickets in 4 minutes, and two directors ask to buy it at once. No metric has been agreed and the scope is unclear. The vendor's offer price lapses in 30 days, which is also when the current contract renews. What do you do before anything is signed?

ATake a 90-day paid trial on the live queue and decide from what the team sees.
BAsk for a reference customer with a similar ticket volume and compare notes.
CHave the directors rank the features they liked so the brief follows the demo.
DName the outcome the demo should move and today's figure, then test on it.

Show the answer

Answer: D

A A trial with no agreed measure produces impressions. Nobody can say afterwards whether the result was good enough.
B A reference shows what worked for another queue. It does not say what this project must move.
C A feature ranking describes the product the directors saw, and the brief then follows the demo instead of the business need.
D Correct. The demo shows what is possible. The outcome and baseline say whether buying it is worth doing.

5. A support design must be fast, cheap and accurate. The budget caps spend at 30,000 dollars a month, the agreement caps p95 reply time at 2 seconds, and every accuracy gain adds calls that push both up. The three sponsors disagree about which goal matters most, and design starts on Monday. What should the brief record?

AA weight for each goal, such as 40, 30 and 30 percent, folded into one score.
BA ranking of the goals, with the one that wins a clash, agreed by sponsors.
CEach goal as a listed risk with a mitigation note, reviewed once a month.
DAccuracy as the single target, since a wrong answer costs more than a slow one.

Show the answer

Answer: B

A One blended score lets a miss on one limit hide behind a gain on another, and it names no decider for a clash.
B Correct. A written ranking tells the design which limit gives first, and the sponsors have agreed to it in advance.
C A risk list records that the goals collide. It does not say which one wins when they do.
D Accuracy alone ignores two limits that are written into a budget and a contract.

6. A design must hold a 2 second p95 reply time and a cost of 0.02 dollars a ticket, both written in the signed agreement and the budget. The accurate design costs 0.05 dollars a ticket, so the two limits cannot both hold. Launch is in six weeks. What do you do?

AShip the cheap design and list the accuracy gap on the project risk register.
BLet the engineering lead pick the trade, since the team built both designs.
CName the limit that gives, say why, and have its owner sign the trade.
DLaunch the accurate design and ask finance to raise the cap after go-live.

Show the answer

Answer: C

A A line on a risk register is not a decision. Nobody agreed to the gap, so nobody owns it.
B The trade changes cost and service for other teams. The builder is not the owner of either limit.
C Correct. A limit that gives should be named, and the person who owns it should agree to the change.
D Asking after go-live commits the spend first. If finance refuses, the cap is already broken.

7. Half way through the build, legal says EU customer data cannot leave the EU, but the model endpoint the team chose is in the US. Five weeks remain on a fixed budget. The design review that passed two weeks ago had nobody from legal in the room. Which practice would have caught this at the cheapest point?

ACollect constraints at discovery, each with an owner who approves the design.
BAsk legal to review the finished design during the last sprint before release.
CKeep a risk register that the whole team rereads at the start of every sprint.
DLet the engineers decide which constraints matter, to keep the design moving.

Show the answer

Answer: A

A Correct. A constraint written down at discovery changes the design while changing it is still cheap.
B A review at the end finds the problem when a rebuild is the only fix left.
C A register records a risk only when someone thinks to list it, and it does not make an owner approve the design.
D The engineers do not own data residency, so they cannot rule on it.

8. A support agent project handles EU tickets and has 30,000 dollars a month for model spend. The team is writing the constraints section of the brief, which goes to legal and finance for sign-off before design starts. Select two items that belong in that section because they limit what the design may do.

ACustomer data for the EU region stays in the EU, owned by legal.
BCustomers may be unhappy when a reply is slow, which is a risk to watch.
CModel spend stays inside 30,000 dollars a month, owned by finance.
DThe team hopes to reach 90 percent satisfaction by the end of the year.

Show the answer

Answer: A, C

A Correct. It changes where the system can run, and it has an owner who can approve a change.
B This is a risk to watch. It does not limit what the design may do.
C Correct. A spend cap changes which model and how many calls are allowed, and finance owns it.
D A hope is a goal, not a constraint. The brief holds it as a target, with a baseline.

9. Ops wants faster first replies, finance wants a lower cost per ticket, and support wants fewer escalations. Each sponsor has sent a note, all three share one budget, and the pilot has a single ten minute slot on the next board agenda. Nobody owns the final call yet. What goes into the brief?

AThe metric from the sponsor with the largest budget share, and nothing else.
BA general goal of better support that all three teams can put their name to.
CThree briefs, one for each sponsor, each reported on its own chart.
DOne measured outcome that reconciles the notes, with a named final owner.

Show the answer

Answer: D

A The other two teams then see a project that ignores their number, and they stop backing it.
B A goal everyone agrees with is one nobody can test, so it settles nothing.
C Three charts and three definitions of success are the problem the brief is meant to remove.
D Correct. One outcome with an owner turns three wishes into something a team can test.

10. The head of support fears the agent will replace her senior staff. The draft brief says nothing about which decisions stay with people, the holiday peak starts in 8 weeks, and escalations are 22 percent of tickets today. The team has no written scope yet. What should the brief do?

ALeave scope for the first design meeting, when the team knows more.
BState which decisions stay with people, such as refunds above 500 dollars.
CLog her fear as a risk and have the sponsor address it in the launch message.
DReview every ticket by hand until the holiday peak has passed.

Show the answer

Answer: B

A Scope left for later becomes the first argument in the design meeting, with the fear unresolved.
B Correct. A stated boundary lets the team check the claim, and any change to it becomes visible.
C A logged risk and a message are not in the brief, so nobody can check them or see them change.
D Reviewing every ticket removes the saving the project exists to make.

11. The finance partner asks for a weekly update with ticket counts, and the sponsor wants one line a month on cost per ticket. The pilot team has three people and time for a single status report. Finance reads the log weekly, and the sponsor reads one page a month. How do you build the report?

ASend the weekly counts to everyone, so there is one format for both readers.
BSend only the sponsor's monthly line, and tell finance to ask if it needs more.
CGive each audience the view its decision needs, drawn from the same numbers.
DHold the report until the first monthly close, then send every figure at once.

Show the answer

Answer: C

A Weekly counts bury the sponsor's one decision under detail that person did not ask for.
B Finance then has no view of its own number and will build a second one.
C Correct. Each audience decides something different, and both views come from the same data.
D A long silence lets each team form its own picture, and the pictures will not match.

12. A project brief for a support agent will be read by three teams and the board. Some reviewers want scope left out to keep the brief to one page. The pilot runs 12 weeks, and one stakeholder has already asked to widen it to billing tickets in week 3. Select two reasons to write the scope into the brief.

AIt lets a stakeholder check a claim, such as which refunds stay with people.
BIt keeps the brief short, because scope becomes obvious once the build starts.
CIt gives the board a figure to quote in the first monthly report.
DIt makes a later widening visible, so it is agreed rather than assumed.

Show the answer

Answer: A, D

A Correct. A stated boundary can be checked by the person it affects.
B Scope is not obvious. Each team reads it differently until it is written down.
C A figure to quote is a metric. Scope says what is in and out, not how it is measured.
D Correct. A written scope turns a quiet widening into a decision that someone has to approve.

Play: predict the output

This checker asks every figure for a number, and nothing more.

python

def has_figure(text: str) -> bool:
    return re.search(r"\d", text) is not None


brief = {"metric": "first reply time", "baseline": "45", "target": "30"}

Predict: Does this brief pass the figure check?

AYes. Both fields hold a number, so the check accepts them.
BNo. The check sees that 30 is lower than 45 and asks why.

Show the answer

A. Thirty could be seconds, minutes or percent, and each reading sets a different goal. Ask every figure for its unit, so the team and finance measure the same thing.

References

Define success criteria: what makes a goal specific, measurable and tied to a number.
Create strong empirical evaluations: how the metric in the brief becomes a test set.
Building effective agents: why the simplest design that meets the goal comes first.
Demystifying evals for AI agents: how teams grade an agent against the outcome the brief names.

Conclusions

Ask for a measured outcome, with a baseline taken before the change.
Write scope and constraints into the brief, each with an owner.
Let a checker refuse a brief that cannot be tested, and name the weak field.

You can now turn a board decision into a brief a team can test.

Outcome

What changes for the business, not what is built

Baseline

Today's figure for the metric, taken before any change

Success metric

A number with a unit and a way to measure it

Scope

What the project covers and what stays with people