Skip to content

July 10, 2026/4 min read

A Decision Is Not Real Until Something Dies

A recommendation should explain which option the team supports, why it is suitable, and which alternatives no longer need development.

Six pale material strips stop at clean cuts while one ochre band continues through a narrow dark threshold.

A group can agree that it likes a direction without deciding what the team should do next. If every alternative remains in development, the agreement has not yet changed the work.

Choosing a direction also means accepting what the team will stop pursuing. That can be uncomfortable. A safer version, an alternate line, or an extra design route may feel useful to retain in case someone objects later.

Sometimes that caution is justified. Early exploration may require range, and a client may need to compare genuinely different strategic choices. But keeping every option available can also postpone the selection the team was expected to make.

Complete the comparison before presenting

I have been in many conversations where a team wants to show the client a wide range and let them decide. The reasons often sound reasonable: demonstrate the possibilities, invite a response, or avoid rejecting something prematurely.

Those are appropriate aims when the purpose of the review is exploration. They are less useful when the client expects a recommendation.

A set of polished but unranked options leaves the client to determine what the team believes. The client must compare, prioritize, and sometimes combine material without the context the team gained while making it.

Generating options is part of the assignment. Evaluating them is another part. Before a recommendation review, the team should understand which options answer the brief, how they differ, and why one is preferable under the project’s constraints.

The client can then make a decision with the benefit of that work.

State the recommendation and its reasons

Showing several options does not prevent the team from recommending one. Two routes may involve different risks, audiences, costs, or approval requirements. Those differences are useful to discuss.

Explain what each option solves and what it requires. Then state which one the team recommends and why. The reasons should relate to the brief, audience, medium, schedule, budget, and approval process.

This is more useful than asking which version people like. It gives them a proposition to examine. They can challenge an assumption, identify a missing requirement, or decide that a different tradeoff matters more.

The client may choose another route. A recommendation does not remove that authority. It makes the team’s judgment and the consequences of the choice explicit.

A private preference is not enough. If the team knows which option it supports but presents all of them as equally suitable, the client has no way to use that judgment.

Check whether a combination still works

When several options are presented, someone may ask to combine the headline from one, the structure from another, and the tone of a third.

That response can contain useful information. The client may value the warmth of one option and the clarity of another. The team should understand those preferences before deciding what to change.

But components are not automatically interchangeable. A route’s headline, pacing, visual language, and tone may depend on one another. Combining selected parts creates a new version whose logic has not yet been assessed.

Treat the proposed combination as something to develop and evaluate. Does the headline still suit the tone? Does the structure support the same message? Do the elements address the same audience? A combination that appears agreeable in the meeting may be confusing when viewed as a complete piece.

The team needs to explain those dependencies and assess the resulting version, rather than assume that selecting liked parts produces a stronger whole.

The presentation affects the working relationship

Repeatedly presenting material without a recommendation can establish an expectation that the client will assemble the direction. The team may continue to execute well while contributing less to the decisions that determine what gets made.

That pattern can be difficult to change. If each review invites selection among interchangeable parts, the client has little reason to expect a coherent recommendation at the next one.

Teams sometimes blame a poor result entirely on what happened in the meeting. A stakeholder selected the safest option or combined incompatible ideas. Those choices matter, but so does how the alternatives were prepared and explained.

Presenting unresolved options asks the client to resolve them. If the team has relevant judgment, it needs to provide it before the decision rather than complain afterward that the client lacked it.

Show the reasoning, not every attempt

A large deck can demonstrate effort without clarifying a recommendation. The client does not need to inspect every rejected version to benefit from the team’s exploration.

They do need to understand why the selected route is suitable. What does it accomplish that the others do not? Which requirement does it prioritize? What does it risk or give up? What evidence supports the judgment?

Include alternatives when they clarify a real choice. Remove those that have no credible reason to proceed. Do not keep an option in the presentation solely because it received internal support or makes the range look broader.

The resulting review should make the decision easier to understand. Once a direction is selected, tell the team what remains open and which versions no longer need work. The recommendation becomes operational when it changes the team’s priorities and use of time.