How We Communicate With Our Clients

At the start of a product build

Once info has been collected, the Scoping Doc has been reviewed and we are all aligned on the build, we can proceed updating the client.

We can use this moment to let the client into the complexity and nuance of what we're building.

When communicating to the client for the official build kick-off we should provide the same info we collected during our Shaping phase:

- Problem the client wants solved
- Description of what the tool should be (solution with key features)
- Inputs (Data dependencies)
- What good looks like from a client perspective (validation rules)
- How the build will be broken down (phases with estimates, no details by cycle)

This will help us manage expectations with the client but it will also be a source of truth the client will sign on.

During a build

Whether it's to deliver a weekly update, a new feature or a bug resolution, we will make sure our messages always touch on these points:

1. What we've been working on
2. What we'll work on next
3. When you can expect to hear from us again
4. What's blocking us [OPTIONAL]
(if work blocked by access or data only the client can provide)

These same points can be used as guidance from async or in-call communication.