The thinking a team can act on

One of the questions I find most useful in a product review is what would have to change for us to choose a different course. Answering it requires us to explain which beliefs support the plan, where those beliefs came from, and what we would do if they no longer held. A team that can answer has given itself a way to act with conviction while remaining open to a better decision.

The harder question is whether the organization can follow through. A product manager might discover that an important assumption is wrong while the team continues delivering against it, because the target belongs to one function, the required capability belongs to another, and the customer commitment has already been made. Revising the analysis leaves those commitments intact unless someone takes responsibility for connecting them again.

I think we should treat that connection as part of product leadership. The quality of our thinking includes what we allow it to change, from the requirement an individual contributor is developing to the investment an executive has already sponsored. Making that possible requires an account of the decision that other people can examine, and enough understanding of their responsibilities to know what a revision would ask of them.

Find the assumption that carries the decision

Consider a hypothetical team building an assistant to reduce customer-support escalations. The proposal assumes that customers who no longer need a person have had their problems resolved. But fewer escalations could also mean that customers found it harder to reach anyone or gave up after receiving an unhelpful answer. The same headline result could support very different accounts of what the product accomplished.

For the product manager developing this proposal, the next useful step is to identify evidence that distinguishes those explanations. Examining conversations the assistant marked complete could reveal whether the requested action occurred; looking at repeat contact and giving customers a usable way to report an unresolved problem could expose failures that the completion event misses. The goal is to find the weakest necessary connection between the proposed intervention and the outcome it promises. More evidence about how many people used the assistant would leave that connection unexamined.

It helps to separate the observation from the explanation before deciding what to build. Suppose many customers ask when their refund will arrive. We know they want an update. We have not yet established whether they lack information, whether the payment has failed, or whether different systems report incompatible states. Each explanation suggests a different intervention, and a convincing conversational answer could leave the underlying problem entirely untouched.

The investigation should also remain capable of revealing a larger opportunity. If customers cannot tell whether a return has been received or a payment initiated, making those states reliable and visible in the purchase journey might prevent much of the need for support. That possibility changes the product boundary. Understanding the cause can justify a more ambitious investment than the feature that first brought the problem to our attention.

I would expect an individual contributor to bring a provisional recommendation together with the assumption that deserves the next test. They should be able to explain what a different result would change, even when making that change requires someone else’s authority. This gives colleagues something more useful to engage with than either an unqualified commitment or a list of everything that remains unknown.

Give disagreement a job

A team leader has considerable influence over whether that investigation improves the decision or becomes a performance of thoroughness. Asking for someone to challenge the proposal helps only if the challenge reaches its underlying evidence and is allowed to affect what the team does next.

In the refund example, a useful objection might be that the proposed evaluation counts a payment request as a completed refund. The challenger can point to the distinction, explain the result it could conceal, and suggest examining whether the money actually reached the customer. That gives the team a question it can resolve. A broad warning that the assistant might be unreliable leaves the owner to guess which part of the plan needs attention.

Leaders should apply the same precision when developing people. If a product manager’s analysis is weak, examine the inference that failed and work through what would support it. Ask them to investigate the alternative and return with a revised recommendation. This lets the next piece of work show whether their reasoning has improved, rather than whether they have learned to reproduce a manager’s preferred vocabulary. Access to customers, data, and specialist help belongs in that development commitment; a person cannot investigate evidence the organization will not let them see.

There also has to be a point at which the team acts. The decision owner should determine whether an objection warrants changing the proposal, running a bounded test, or proceeding with an explicitly accepted uncertainty. Its treatment should depend on the consequence of error and the usefulness of further investigation. A reversible trial may be the fastest way to learn, while a change that can move money needs confidence in the controls before it reaches customers. Agreeing when the test will end and what its results will permit prevents the investigation from becoming a reason to postpone the choice indefinitely.

This is a demanding form of trust. The proposer remains responsible for doing the work, the challenger is responsible for making the concern intelligible, and the leader is responsible for a timely decision. None needs to pretend that agreement has been reached where it has not. A record of the unresolved issue and the conditions for reopening it can support committed execution without erasing a material disagreement.

Follow the correction across the system

Once the team discovers that a completed conversation is insufficient evidence of a completed refund, the correction has consequences beyond the metric. The interface needs to distinguish a requested payment from a pending or completed one. The payment service needs a way to handle retries without issuing the refund twice. Support needs to know who will investigate a failed payment, and the customer needs a route to help while it remains unresolved.

This is what I want systems thinking to accomplish. We should be able to follow a changed premise through the requirements, the technical behavior, and the people responsible for exceptions. Fixing the definition in the product document while leaving the old definition in a dashboard or service commitment would preserve part of the original error.

Cross-functional disagreement can help expose those connections. Finance may be protecting against unauthorized payments, engineering against duplicate execution, and support against customers being left in a state no one owns. Those concerns require different answers. Before treating a stakeholder as resistant, I would ask which failure they believe the proposal permits and what would need to be true for them to support it. Their explanation might reveal a requirement we missed, an operating choice we can redesign, or a cost the organization needs to accept deliberately.

We should distinguish those possibilities before bargaining over the solution. An obligation to prevent duplicate refunds does not establish that every refund requires manual review. A wish to avoid operational overload does not determine which team must handle every exception. The shared objective gives us a basis for comparing arrangements, while the specific constraints tell us which arrangements could actually work.

Where interests still conflict, product leadership includes making the disagreement decidable. We may need to compare customer benefit with additional review cost, narrow the eligible population, or fund a capability whose cost falls on one team while its benefit appears elsewhere. The person with authority over that trade-off must make the commitment explicit. Asking the product manager to keep seeking alignment cannot supply capacity that another team has never agreed to provide.

Let the evidence reach the commitment

For executive leaders, the difficult test comes when sound analysis challenges a promise already embedded in the business plan. Suppose the budget assumes that the assistant will permit a substantial reduction in support staffing. If the test reveals that unresolved payments need more specialist attention than expected, the organization has to revisit the staffing assumption along with the product. Otherwise, the team is being asked to demonstrate a benefit while losing the capacity needed to handle the cases that would disprove it.

A useful target should make clear which outcome matters and what would invalidate an apparent improvement. In this example, we would need to examine resolution, repeat contact, and operating cost together. We should also inspect what happened to people who failed to reach the assistant or a support agent, because measuring only the customers who completed the new flow could conceal precisely those for whom it worked least well. The executive’s responsibility includes deciding how those results affect expansion and expenditure.

This does not require reopening the entire strategy whenever a result is disappointing. A missed outcome might reflect the wrong diagnosis, an incomplete implementation, or a test that did not expose enough users to the intended experience. We should establish which explanation is supported before abandoning the investment. Equally, a favorable result should not excuse us from checking whether the improvement came from the mechanism we expected. The next allocation of resources depends on understanding what we can reasonably expect to repeat.

Senior leaders should make their own assumptions available for this examination. When a customer deadline is fixed, they can identify which scope or rollout choices remain open. When a better solution requires work from another function, they can resolve the competing priority. When the evidence defeats the original approach, they can change the commitment and explain why. These actions give the people closest to the problem a credible reason to investigate it honestly.

We should preserve the important revisions so the next team inherits the reason for a decision as well as the decision itself. In the refund example, the useful lesson is why a conversation-level measure failed to establish a payment outcome, what evidence resolved the uncertainty, and which conditions made the revised design viable. That is something another product manager can examine and adapt. A record saying only that the assistant succeeded would teach considerably less.

The benefit I would hope for is a team able to pursue ideas beyond the experience of any one member. An individual can identify an opportunity, colleagues can expose what it depends on, and leaders can provide a way to test and support it. On the next important initiative, we should make those connections explicit while there is still time for an answer to change the work. The team should know which decision it owns, whose help it can rely on, and what will happen if its investigation reveals a better possibility.