The product drift diagnostic: five questions I ask every new client in the first hour

By the end of the first hour with a new client, I usually have a working hypothesis about where the real problem is.

Not the surface problem from the intro call: slow shipping, misalignment, features that do not land, late sprints, too many meetings. Those are real problems, but they are usually symptoms.

The first hour is for finding what produces them.

These are the five questions that do most of the work. None of them start with the product.

1. “Walk me through the last feature that shipped late. Not what it was - why it was late.”

The answer almost never matches the obvious reason.

Teams say, “the spec changed.” Usually that means the original spec was underspecified, and the missing detail was not caught until a developer was already building.

They say, “we underestimated.” Usually that means an edge case was not mapped, surfaced mid-development, and required a conversation that should have happened in planning.

The stated reason for lateness is usually a symptom. The real reason lives in the handoff structure: where information was not captured, transferred, owned, or verified.

This question locates the gap. The follow-up is always simple: who owns that gap?

2. “Who makes the decision when there is disagreement about product direction, and how does the rest of the team find out?”

This question surfaces the decision architecture.

In a healthy team, there is a clear answer: a person or process, a reasonable resolution time, and a reliable way for the decision to reach the people who need to execute it.

In many teams, the answer is more complicated. Sometimes it is the CPO. Sometimes it is whoever has the most context that day. Sometimes it is consensus, which sounds collaborative until nobody is actually accountable and the team starts executing individual interpretations while waiting.

The communication mechanism is often informal. The decision gets made in a meeting, then distributed through whoever remembers to send the Slack message.

This question tells me whether the team has a decision system or a decision habit. Those are not the same thing at scale.

3. “What does a ticket need to contain before a developer picks it up?”

This question usually creates a pause.

The strong answer is specific: acceptance criteria, state definitions, edge cases, dependencies, and a definition of done that everyone means the same thing by.

The common answer is: “It depends.” Or: “We have a template, but people do not always use it.” Or an honest description of a system that works when one senior person writes the ticket and breaks down when anyone else does.

This reveals whether the team has an explicit standard for buildable work, or whether “ready to build” is a judgment call that changes by person and week.

In teams with coordination problems, it is usually the second one.

4. “When was the last time a feature shipped and the team was not sure if it did what it was supposed to?”

This question is uncomfortable. Most teams answer it honestly after a beat.

The answer reveals the feedback loop. A team that ships without knowing the effect either has no feature-level success metric, has a metric but no reliable way to read it, or has measurement without ownership for closing the loop.

That is a team operating on faith.

Not careless faith, but earnest faith. The feature made sense, so it probably worked. The dashboard moved, so the work probably contributed. The relationship between shipped work and observed behavior is assumed instead of verified.

Without that loop, the team cannot learn from what it ships. It can only repeat the process and hope the next bet is better.

5. “What is the most expensive thing your team does that does not need to happen?”

This question produces the most honest answers because it gives people permission to say what they have been thinking for months.

A weekly status meeting everyone knows could be an update. A design review that happens too late and creates rework. A sprint planning session that runs for three hours because the tickets are not ready, so the meeting becomes catch-up disguised as planning.

The answer shows where energy is going without producing progress. It usually points to a coordination failure the team adapted around instead of fixing.

The point of the first hour

Five questions, one hour, and by the end, the pattern is usually visible.

The Product Systems Audit is the five-to-fourteen day version of this exercise: structured, deeper, and ending with a prioritized plan rather than a hypothesis.

The hypothesis from the first hour is usually close. The audit is where it becomes useful.