Create Discovery Artifacts That Survive the Customer Call

By Sprint 3, the team had five versions of the same customer conversation: a user flow that implied scope, a worksheet that implied configuration, a sprint note that implied translations were handled, and an access request nobody could call closed. Nothing was obviously wrong, which was the problem. Each artifact looked like evidence of alignment while quietly leaving delivery to guess. Discovery artifacts are only useful when they preserve decisions, evidence, owners, expiry, and unresolved edges for the delivery team.

A discovery artifact is any durable output from discovery that downstream teams use to make or execute a decision: a flow, worksheet, tracker, analysis, decision record, access list, or reconciliation note. It is not useful because it proves a meeting happened. It is useful when an engineer, designer, QA analyst, or delivery lead can act from it after the call is gone.

We fixed the packet by turning each artifact into a decision surface: what it decides, who can act from it, what remains unresolved, and what has to be reconciled before delivery work starts.

Discovery artifacts should decide something

Discovery decays fast. A call feels productive, the notes are rich, and the team leaves with apparent alignment. Two weeks later someone is trying to remember whether content pages were in scope, whether the asset library configuration was final, or whether a missed translation step was already corrected.

That is the job of the artifact. It reduces the number of future decisions made from memory.

I use a plain test: if a capable engineer joins in Sprint 3, can they use the artifact without asking three people to reconstruct the call? If the answer is no, the artifact is still meeting residue.

That test changes how I run discovery. I stop asking, "Did we capture this?" and start asking, "What work will this unblock, and what could someone misread?"

Forward deployed work makes this sharper because the same person may move from customer ambiguity to implementation details quickly. Palantir's description of the forward deployed software engineer role is a useful public reference for that customer-facing engineering posture. In that posture, weak artifacts become weak execution.

The artifact map

The moment that changed the work was realizing that the artifacts were carrying the wrong load. A user flow diagram was being used to discuss scope. A configuration worksheet was carrying access assumptions. Sprint notes were standing in for reconciliation. Reasonable teams can produce unreasonable ambiguity this way.

So I started using an artifact map. It is not a grand framework, mercifully. It makes each artifact answer for its existence.

The map did not create alignment by itself. It made the lack of alignment visible early enough to be useful. That has saved more actual hours than a clean kickoff deck.

A before and after artifact

Here is the difference between an artifact that records activity and one that lets delivery move.

The second version is longer, but not much. The difference is that it carries the decision, evidence, owner, and expiry in the same place. Nobody has to infer whether "nearly complete" means safe to build.

Where discovery usually breaks

Discovery breaks in the handoff, not the meeting. The call can be sharp and the notes can still fail.

The artifact has no owner

A design lead may be finishing user flows for anonymous and logged-in states. A content analyst may be analyzing card-sort responses. An implementation lead may be turning an asset-library plan into a tracker. A QA lead may be chasing a missed CMS migration step.

Each person is doing real work. The gap is that no artifact has a declared owner responsible for saying, "This is now actionable," or "This is still draft and cannot be used as delivery truth."

Draft status is fine when it is visible. Hidden draft status lets people build confidence on a surface that has not hardened.

The artifact captures activity instead of a decision

"User flows are nearly complete" is a status update.

"Anonymous and logged-in flows are approved for the browse, detail, and account routes; content-library journeys remain out of scope pending review" tells engineering where to build, QA where to test, and delivery where to watch for change.

Access needs the same treatment. "Waiting on access" is fog. "Two engineers lack editor access to the staging CMS; client admin owns approval; target date is Friday" is a tracker. I wrote more about treating access as an early field-engineering deliverable in Treat Access as the First Field-Engineering Deliverable.

The artifact omits its unresolved edge

In the story behind this piece, one unresolved question was whether blog-like content types belonged in scope. That question looked small until it touched navigation, templates, permissions, migration, QA coverage, analytics, and sign-off.

The best artifact is not the one that looks most complete. It is the one that names the edge that can still move.

A discovery artifact that hides uncertainty is not cleaner. It is just more expensive later.

Four fields that make discovery artifacts usable

When I review discovery output now, I look for four fields. Missing fields mean the team is closer to reconstructing the call than executing the decision.

Decision

The artifact needs a decision field, even when the decision is "not decided." This sounds pedantic until five people infer five different meanings from a polished diagram.

For a user flow, the decision might be which states are in scope. Anonymous and logged-in users usually need different paths, empty states, and QA cases. If the artifact does not say whether both are committed, the diagram is doing half the job.

For a configuration worksheet, the decision might be which fields are required, which integrations are enabled, and which defaults apply per environment. Without that, the worksheet becomes a menu.

Evidence

The artifact should say what it is based on: a customer call, a review email, a card-sort result, a technical spike, a migration test, or an access audit. Evidence keeps decisions attached to their source.

This matters when the source is imperfect. In one update, the team was relying on meeting notes because the session recording was unavailable. That is fine if the artifact says so. It is dangerous if everyone treats the notes as a replayable record.

Owner

Ownership is the difference between "someone should update this" and "the implementation lead will reconcile this before Sprint 3 planning."

The owner does not have to make every decision. They do have to keep the artifact from becoming archaeological material.

Expiry

Discovery artifacts have a shelf life. A card-sort analysis from 31 responses is more credible than one from 12, but it may still change if more responses arrive or if the customer excludes a segment. A scope tracker before customer review is not the same as a scope tracker after review.

I like explicit expiry language: "Valid through internal review," "Superseded by customer approval," or "Do not use for build estimates until access is confirmed." It feels fussy until it prevents a sprint plan from leaning on stale assumptions. Then it feels like basic hygiene.

The reconciliation note is the least glamorous artifact and the most useful

I used to underrate reconciliation notes. They felt like administrative residue. The real work was the diagram, the worksheet, the tracker, the plan.

That was wrong.

The reconciliation note is where discovery becomes durable because it records how contradictions were resolved. One note can say that a journey appears in the design flow while scope excludes it for the next release. Another can say that the configuration worksheet assumed a translation step, then QA found the CMS patch generation miss and marked it corrected. A third can say that the asset-library plan exists, but the tracker still needs feedback before it can drive delivery.

This is close to the value of architecture decision records: the decision matters, but so does the context that made the decision true. Michael Nygard's short reference on documenting architecture decisions is still useful because it keeps the record small and tied to consequence.

A good reconciliation note is short. Mine usually has five lines of concern:

That last field matters. Old reconciliation without dates is just lore in formal clothing.

What I rejected

The tempting answer is to centralize everything into one master document. I have tried that. It makes everyone briefly happy because the project appears to have one source of truth.

The trouble is that one enormous source of truth often becomes nobody's source of action. Designers need flows. Engineers need configuration. Project leads need scope. Client admins need access requests. QA needs acceptance paths and environment facts. A single document can contain all of that, but it rarely serves each use case well.

I also rejected the opposite pattern: let each discipline keep its own artifacts and trust standups to connect them. That works while the same people are in every conversation and nothing slips. Which is to say, it works for a charmingly short period.

The compromise I trust is federated artifacts with explicit reconciliation. Let each artifact live where it belongs, then make it declare the decision it owns and the artifacts it depends on.

Discovery artifacts still have costs

There is a real downside to this approach: it requires discipline from people who are already busy. Extra fields become a tax if nobody trims them. Trackers become process theater when they outlive the decisions they were meant to carry.

The answer is not to document more. Document the decision-bearing parts and delete the rest. A configuration worksheet does not need meeting color. A user flow does not need every discussion thread pasted into a corner. A scope tracker does not need to repeat the backlog unless it is clarifying commitment status.

The operational rule is simple: the owner enforces expiry during planning, review, or handoff. If an artifact is stale, it gets updated, superseded, or removed from the delivery path. If two artifacts disagree, the reconciliation note closes the gap or names the person who will.

The sharp edge is false finality. A neat artifact can make a provisional decision look settled. That is why expiry and unresolved-edge fields matter. They are annoying in the same way seatbelts are annoying: mostly when nothing has gone wrong yet.

How I run the next customer call differently

The next customer call should not end with "we will circulate notes." It should end with artifacts being assigned to decisions.

I want the conversation to close like this:

That small shift changes the meeting. People hear open questions differently when each one has a landing place. The customer can see which answer affects delivery. The team can see what is safe to build from and what is still wet cement.

FAQ

Why are discovery artifacts unreliable after customer calls?

They become unreliable when they capture conversation without carrying the decision. A useful artifact says what was decided, who owns it, what evidence supports it, and what is still unresolved.

Where should I capture scope questions from discovery?

Use a scope tracker, then connect the question to the artifact it affects, such as a user flow or configuration worksheet. Do not bury scope inside meeting notes where delivery teams have to rediscover it.

What is the difference between meeting notes and reconciliation notes?

Meeting notes record what was said. Reconciliation notes record what changed when artifacts disagreed.

How do I know whether an artifact is ready for handoff?

It is ready when a new team member can act from it without reconstructing the customer call. If they still need tribal context to know what is in scope, what access is blocked, or what configuration is final, the artifact is not ready.

The point is not to make discovery heavier. It is to make future work less dependent on whoever happened to remember the call correctly.