The five system questions I ask at the start of every engagement

The product is almost never where the problem begins.

The product is where the problem becomes visible: features that ship wrong, velocity that does not match team size, quality that varies by sprint, customers who feel the inconsistency before the team can name it.

The problem itself is usually upstream, in the system that produces the product.

That is why the first questions I ask at the start of an engagement are not about the product roadmap. I want to understand how decisions travel, how quality is enforced, how blockers move, where recurring failure appears, and whether the client’s definition of success matches the evidence.

1. Describe the last decision the whole team learned about at different times.

This question maps the information architecture, not the org chart.

Every team has a formal version of decision communication: the sprint meeting, the product update, the all-hands, the roadmap review. I am asking about what happened outside the formal channel.

A direction changed in a leadership conversation. One developer heard it in a one-on-one. The designer found out when the ticket changed. QA discovered it when the expected behavior no longer matched the test case.

That is the real decision system.

The question reveals whether the team has a reliable transmission layer or whether critical information moves by proximity, memory, and whoever remembered to send the message. Osmosis can work when the team is small and close together. It fails quietly as the team grows, distributes, or starts running multiple streams at once.

2. Who can stop a feature from shipping, and when?

This surfaces the quality gate architecture.

The wrong answer is not a specific person or a specific stage. The wrong answer is “it depends,” because it usually means the gate exists informally and inconsistently.

Sometimes a developer flags the issue, sometimes QA catches it, sometimes the feature ships and the founder sees it in production, and sometimes nobody stops it because everyone assumed someone else owned the standard.

Inconsistent quality gates produce inconsistent output. Not because people are careless, but because the team has not agreed on what “ready” means, who has authority to challenge it, and when the challenge is supposed to happen.

A clear gate does not slow the team down by default. It often reduces the rework cycles that were already slowing the team down invisibly.

3. What does a developer do when blocked and the decision-maker is unavailable?

This locates the escalation path.

The failure modes are predictable. The developer waits and loses hours to a dependency that could have been resolved quickly. Alternatively, the developer makes a reasonable interpretation and keeps building, which can produce a feature that is complete, coherent, and wrong.

Both outcomes are expensive.

The fix is not constant availability from the founder or product lead. It is an explicit protocol for what happens when a decision is needed: who else can make the call, which documented standard applies, what the default should be, and how the decision gets recorded afterward.

Most teams do not have that path. The result depends on the individual developer’s comfort with ambiguity, which is a risky way to run product execution.

4. Walk me through a feature that came back from QA twice for the same kind of issue.

This question identifies the recurring failure pattern.

A feature that comes back from QA once might be a mistake. A feature that comes back twice for the same class of issue is usually a system signal.

The class of issue matters more than the individual bug. “Implementation did not match the design” points to design-to-dev handoff. “Edge cases were missed” points to specification quality. “It worked locally but failed in production” points to environment or testing protocol. “The customer expectation was misunderstood” points to discovery, support feedback, or product decision logic.

QA is not the root cause in most of these cases. QA is where the missing context becomes visible.

5. What would have to be true for this engagement to be a success?

This question sounds obvious, but it usually exposes the client’s theory of the problem.

If the client says success means “shipping faster,” while the previous answers show poor brief quality and repeated QA returns, then speed may be the symptom rather than the cause. If they say success means “better ownership,” while every example points to unclear decision rights, then the team might not need motivation; it might need a clearer operating model.

That mismatch is not a problem with the client; it is a finding.

It shapes how the engagement starts. The work should not begin with the solution the team already believes in; it should begin by testing whether the diagnosis matches the evidence.

That is the structured logic behind the Product Systems Audit: the first-hour hypothesis becomes a five-to-fourteen day diagnosis, and the diagnosis becomes a prioritised plan that the team can actually act on.

The product is still important.

I just do not trust it as the first witness.