The Undervalued Art of Creating Clarity
Why busy teams are not always productive
I believe creating clarity is a core responsibility of every product leader. As organizations grow, more teams get added. Calendars fill up. Roadmaps become longer. Every function has goals, metrics, and important initiatives. Yet somewhere inside all that activity, the work can stop pointing in the same direction.
We have all been in reviews where every workstream was green, but the business result was not moving. Product had shipped its feature. Engineering had completed the platform work. Marketing had launched the campaign. The problem was that each team had formed a slightly different view of what we were trying to accomplish.
This is why being busy is not the same as being productive.
For me, clarity is a shared understanding of where we are going, why it matters, how we will measure progress, and who can make decisions.
#1: Start with the customer problem
Most teams move to solutions too quickly. Someone identifies a customer issue, a competitor launches a feature, or an executive suggests an idea. Within minutes, the conversation shifts to scope, design, architecture, and delivery dates. It feels like progress. The team moved fast. But the team may not yet agree on the problem.
Imagine a team trying to improve checkout. Product may see too many steps. Engineering may focus on payment failures. Design may see a trust problem. The business may want better conversion. All four perspectives can be valid, but they lead to different solutions.
Before discussing what to build, the team must answer a few questions. Who is the customer? What are they trying to accomplish? What is difficult today? How do we know? What should improve if we solve it?
There is a simple test I like. Ask five people on the team, separately, to describe the customer problem in two sentences. The wording does not need to match. The substance should. If the answers describe different problems, the team is not aligned. It may have a slide that everyone approved, but it does not yet have shared clarity.
Starting with the problem also creates more room for innovation. When leaders prescribe the solution, teams optimize the answer they were given. When leaders clarify the problem, teams can explore better answers while staying anchored to the same customer need.
#2: Define a small number of outcomes and the trade-offs underneath them
Once the problem is clear, the next question is simple: what will be different if we succeed? Many teams answer this with output. Launch the experience. Complete the migration. Add the feature. Expand to more markets. Those are milestones. They tell us that work happened. They do not tell us that the work created value. An outcome describes a change in customer behavior, business performance, or operating efficiency. Customers complete the task faster. More new users return. Fewer orders fail. Support contacts decline without reducing customer satisfaction.
I prefer a small number of outcomes. Three clear outcomes can focus an org. Twelve usually allow every team to continue doing what it was already doing. The part that often gets missed is the trade-off.
Leaders frequently ask teams to move faster, improve quality, reduce cost, grow revenue, and lower risk at the same time. When these goals conflict, the team is left to guess which matters most. A strategy makes the choice explicit. We may accept a slower rollout to protect reliability in a critical customer journey. We may prioritize learning speed over feature completeness during an early test. We may automate low-risk decisions but retain human review for actions with meaningful customer consequences. A well-stated trade-off helps hundreds of people make consistent decisions without escalating every disagreement.
Metrics still need judgment. A team can improve a number while making the experience worse. I like to pair business metrics with customer evidence and a few guardrails.
#3: Make ownership explicit
A team can agree on the problem and outcomes and still move slowly because nobody knows who can make the final call. Several leaders may believe they own the same decision. Other teams wait because they are unsure whether they need approval. Meetings get bigger because inviting more people feels safer. The result is delay disguised as collaboration.
For any important decision, three things should be clear: who owns it, who must be consulted, and what threshold requires escalation. The owner is not simply the person who organizes the meeting. The owner has the authority to decide and is accountable for the result. Consultation should be deliberate. The right experts need to be involved when a choice affects architecture, security, finance, legal risk, or another customer journey. But consultation should not automatically become consensus.
Not every decision needs executive approval. Reversible choices should sit close to the team doing the work. Decisions that are difficult to reverse, create meaningful financial exposure, or carry significant customer risk deserve broader review.
Good delegation combines authority with a clear problem, measurable outcomes, known trade-offs, and sensible guardrails.
#4: Reinforce clarity through operating mechanisms
Clarity does not survive on its own.
New data arrives. Customer behavior changes. Technical constraints emerge. New people join without the context that shaped the original decision. Something obvious in January can become open to interpretation by April. We have all been there.
This is why operating mechanisms are important. Regular reviews and planning sessions help maintain alignment as facts change. Each mechanism should have a clear purpose.
A product review should test whether the work still solves the customer problem. A metrics review should examine whether outcomes are moving and what we will change if they are not. A planning session should revisit priorities and trade-offs.
More process is not the answer. Too many templates, reviews, and approval gates can turn clarity into bureaucracy. The goal is a small number of useful forums where teams review facts, resolve disagreements, and make decisions.
The misinterpreted side of clarity
We can present assumptions as facts because we want to sound decisive. We can define every detail and leave teams no room to think. We can use alignment as a reason to close debate too early. Clarity does not mean pretending we know more than we do. A clear leader can say: this is what we know, this is what we believe, this is what remains uncertain, and this is how we will learn.
Clarity also does not require everyone to agree. Teams can disagree with a decision and still execute it well when they understand the reasoning and know what evidence would cause the organization to reconsider.
Most importantly, clarity is not control. If every meaningful choice still requires an executive, the organization may look aligned, but it is actually dependent. That model scales only as far as the executive’s calendar. The purpose of clarity is to make the organization less dependent on its leaders.