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 kinddecision, 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