Skip to content

Change 5 of 6

Alignment

Leaders set direction. Teams decide.

Give teams the context to make decisions without escalating every choice.

The change

Context flows down. Learning flows back.

Decentralized decisions only work when teams understand the direction. A high-level goal is rarely enough to resolve the tradeoffs that appear in daily product work. Without useful context, teams either make conflicting choices or escalate decisions back to leaders.

The solution is to connect company direction, product strategy, and the choices teams make each week. The Product Team maintains the product vision and strategy, connecting company values and direction to the outcomes Stream Teams pursue. Leaders explain the reasoning and constraints behind those choices. Teams can then show how their decisions support it and feed back what they learn from customers.

As AI speeds up local decisions and delivery, unclear direction can turn into conflicting customer experiences more quickly.

What changes in practice

  1. Explain the choices behind the strategy.

    Make the intended customer, opportunity, and tradeoffs clear. State what you are choosing to leave out as well as what you will pursue. Connect those choices to the outcomes in the annual plan and quarterly objectives.

  2. Check understanding through decisions.

    Ask a team to explain how a proposed choice fits the direction. Check the reasoning together, then let the team act within its scope. This checks shared understanding without turning each solution into an approval request.

  3. Make learning travel back.

    Teams should surface evidence that challenges assumptions. Direction can evolve as the organization understands its customers better.

A practical example

Connect team outcomes to the same customer.

Search is improving holiday recommendations for leisure travelers. Booking is adding upsells for optional extras. Both could improve their own metrics, but the product’s current priority is business travelers, with rates that already include those extras. Their effort is going elsewhere.

The Product Team makes that priority explicit and agrees relevant outcomes: more business travelers choosing suitable stays, and more completed business bookings with higher total booking value. Search and Booking use those outcomes to reconsider their priorities, choose solutions within their scopes, and check completion and cancellation rates together.

Search and Booking start outside a pale blue band labeled Business strategy. Curved arrows move each team into a separate position inside the band, showing their scopes aligning with the shared strategy while remaining distinct.

Alignment in practice

Real case studies from UXDX conferences and other sources.

Browse 4 alignment case studies ↗

Common objections

I am being demoted. As product manager I made the decisions, now the team does.
It can feel that way at first, and in practice the role moves up. Product managers join the Product Team, the group that sets vision, strategy and objectives across several Stream Teams. Day to day, the job shifts from briefing a team on a plan to certifying the reasoning behind the team's own plan, which is harder and more senior work. Not every PM will want to make that move, particularly those who enjoyed running the backlog, so it's worth investing in the ones who do.
You need several Stream Teams to build a product. If they are autonomous, how do you coordinate them on the strategy?
A lot of the coordination is handled by how the teams are set up. Each Stream Team owns its own value stream, and the boundaries are drawn so teams overlap as little as possible, which means much of their work doesn't need coordinating in the first place. The Product Team then sets the product vision, the strategy and the objectives each Stream Team works toward. Just as importantly, it shares the reasoning behind them, so teams can find their own route to the goal while pulling in the same direction. Some work will still span several streams, and when it does you can run a project. Either update the objectives of the teams involved so each can deliver its part, or, if the problem isn't well understood yet, combine the teams for the duration of the work. If the same shared need keeps coming up, that's usually a sign it should become an Internal Product Team with its own roadmap. The rest of the work can then go ahead without a standing coordination layer.
I’m ultimately accountable. Why should I let the team decide?
You remain accountable for the product’s results and for giving teams the direction, capabilities, and decision boundaries they need. Teams take responsibility for decisions within those boundaries. Agree the outcomes and guardrails up front, share the strategic reasoning, and certify the team’s reasoning so you know it can make sound decisions without seeking approval for every change. Review the evidence together. If results stall, investigate the cause with the team; if a guardrail is breached or a decision exceeds its authority, intervene. Keeping every decision yourself leaves the team responsible for results it cannot influence.
My team is not ready to make these calls
That's common, and building that capability is the place to start. It's often the work that coordination and admin were crowding out of your week. Enabling Teams, capability standards and apprenticeship all help close the gap. Start the team on a bounded scope it can already handle, and widen it as its decisions prove sound.
Decisions will be slower and less consistent if every team makes its own
In our experience it tends to go the other way. A lot of the delay in a decision comes from escalation: waiting for the meeting, preparing the briefing, chasing the follow-up. A team that already has the context can usually decide there and then. Consistency comes from sharing the same strategy, the same operating principles and the same capability standards, and from reviews that look at whether the outcome moved. Some decisions do need a single owner, and when that's the case, name the owner and explain why.
My peers are not changing, so I will be the only one delegating
That's a common position to be in, so start where you control the conditions. A pilot on one value stream with one team only needs your decisions to change, so you don't have to wait for the whole organization. Improvements in lead time and outcomes from that pilot tend to persuade peers more than a presentation would. In the meantime, expect to do some translating at the boundary, because the people around you will still ask for status updates in the old format.
What happens to my role as a functional manager?
Much of the admin and coordination work goes away, which leaves more time for the parts of the job that most need your experience: developing people, raising the standard of the craft and bringing your functional perspective into product strategy. Depending on where you can have the most impact, the role moves into the Product Team or an Enabling Team. The functional manager role explains how the four parts of the job are split.
Is this another layer of planning meetings?
It should mean fewer meetings overall, because the aim is to cut down on repeated clarification and approval. Share context that teams can reuse, check that they can reason with it, and give them a way to feed back. If a meeting isn't improving those decisions, it's fair to ask whether you need it.
All common objections ↗