Skip to content

Client Notes ​

Decisions or changes that came up in a conversation — captured, linked to the Epic and brief they affect, dated. The relationship's memory between the weekly update and the next bi-weekly sync.

Owners: PO Phase it lives in: Continuous The corpus principle this enacts: The artefacts the chain produces survive the conversation.

Where it lives in the chain ​

How to do this ​

After every client conversation that touches scope, schedule, or signal:

  1. Note, within 2 hours. Slack thread, Confluence page, repo doc — whatever the team uses, one place, consistently.
  2. Link to the affected Epic, brief, or signal reading.
  3. Date and source — "2026-05-18 · bi-weekly sync · Maya (client) and Alex (PO) present."
  4. Tag the kind — decision, change request, concern raised, deadline shifted.
  5. Surface to the trio at the next standup if action is required.

What good practice looks like ​

A client mentions in conversation: "By the way, we'd love to see the grading report by school by next quarter." That is a Client Note, not yet a feature request, not yet a brief — but the conversation happened, the team needs the record, and the next bi-weekly sync should not be surprised by the request becoming a deliverable.

The Note is written:

2026-05-18 — Maya mentioned (bi-weekly sync) interest in per-school grading reports by Q3. Not yet scoped. Surfacing at next portfolio review to assess against capacity.

Three months later, when the request becomes a brief, the team has the original moment — what the client said, in their words, when they said it. That is what makes the brief witnessable; what makes the relationship navigable; what keeps the client's understanding of "what we asked for" aligned with the team's understanding of "what they asked for."

A team that doesn't keep client notes rediscovers requests every quarter, surprises clients with forgotten asks, and accumulates a relationship debt nobody can name but everyone feels.

200apps · How We Work · NWIRE