Empowered teams require strong alignment

Published in

Paper Planes

6 min readJul 13, 2021

When kicking of a new product or initiative, our job as PMs involves providing the right guidance for what, when and why something needs to be built.

But more often than not, what we see is:

The team working on features that are actually secondary to the product’s success.
The features being worked are not really solving the problem as it was proposed.
The PM or other team members need to constantly provide details of the implementation and process.
The team is unclear of their own and other members’ roles.
The team is unclear of what are the next steps in the plan.

This is a result of misalignment. Misalignment that brings wasted resources, conflict, and micromanagement.

In other words:

Misalignment can be spotted when there’s a mismatch in what people are actually doing, compared with what was expected them to do.

It can also be spotted when there’s micromanagement — a natural reaction to poor alignment.

Illustration by Henrik Kniberg, from the book “Strong Product People”

The traditional way of closing alignment gaps has been to add more detail to the conversation: more detailed information, more detailed control, more detailed instructions. More detailed requirements to the backlog cards, constantly checking the work being done. It meant telling team members precisely what they needed and how.

But if we want empowered product teams— teams that are cross-functional (product, design and engineering), focused on and measured by outcomes (rather than outputs), and empowered to figure out the best way to solve the problems they’ve been asked to solve, — more detail is not the way.

Enter the Mission Brief

In military missions, military leaders usually aren’t in the field with their subordinates — they cannot micromanage even if they wanted to.

Instead, they rely on artifacts as the Mission Brief: a document that gives the high level context, goals, strategy, process, and boundaries of the mission at hand.

In Product development that can revolve around:

What triggered this product or initiative? Why is it believed to be worth the money/time/people? (Context)
How is this aligned with the overall strategy and mission of the company? (Context)
What are our main goals? What do we want to achieve with this? How do we know we’re successful? (Goals)
How are we going to achieve this? (Strategy)
What we want to avoid? What this product is not about? (Boundaries)
Who’s responsible for what? How will we work together? How should we communicate? (Process)

Clarity and common ground

The goal with the mission briefing, is first and foremost, to ensure that everyone is exactly on the same page.

It’s very common to believe that after a meeting, or onboarding people on Slack, that everyone understands what needs to be achieved. The issue is that, even if everyone is confident of what needs to be done, each person understood slightly different version of what was communicated, and also missed important details.

And the worst part is that nobody’s aware of it: everyone thinks they are on the same page, until they start working and, issues, inefficiencies and conflicts start popping up.

This is often first spotted when discussing prioritization.

The mission briefing — or some variation of it — brings clarity and common ground to every team member.

Empowerment

The second goal, is to provide the team with the right information so that they can make their own and best decisions when they’re presented with new facts on the field.

For example, in case the team finds that approach A is actually not viable, considering they understand what’s the end goal and the limitations, they can confidently come with a new approach that provides the same outcome. This without having to speak with the PM, Head of Product or CEO to ask: “What should we do now?”.

The same can happen process-wise: My Pull Request has just been merged. Should it now pass through QA, or can it be immediately deployed to production? And what if it’s a hotfix? (Or) Who makes the design decisions? (Or) What will happen after we launch the MVP? Will we need to onboard new users? How many and when?

This sort of information empowers team members to make their own decisions when planning their work or when presented with new facts.

For example, by knowing that they will onboard 1000 users 1 month after the launch date, the DevOps members know what they need to prepare for — they won’t need to question the PM for every decision they need to make. At most, they can come with options to pick, and with arguments about what option they believe is best.

A living document

The mission brief isn’t important only when starting a product or initiative — it’s also important when there are strategy changes across the product or company: changes in business goals, process or even in people’s roles. It’s a living document.

You cannot ever be too explicit when it comes to strategical alignment — the worst you can do is to not make a constantly effort for it.

In practice

As many topics I write here, this is something I’ve been working on to improve as a PM for the past 2 years.

To a certain extent, I’m happy with the evolution, believing I’ve been able to provide better and clearer context to the team. More specifically, when starting new products, I’ve been putting more effort in detailing:

What is this product about, and why it exists/is being created? (Context)
What are the main business goals for this product? (Goals)
On a high level, how are we going to achieve these? (Strategy)
How do we measure our success? (Goals, usually through OKRs)

Sometimes I add the Opportunity Solution Tree or Impact Map to the mix, which also brings great high level information of the outcomes we’re trying to achieve and why. In total, this may result in a document between 1 to 5 pages.

Even though surely there’s lot of room to grow, I believe teams have now better understanding of the business context and the outcomes we want to achieve with the product.

What I’m improving

Nonetheless, specially since I started working on a bigger product made of various interconnected teams, I’m starting to realize there are aspects that can and should be improved when under certain contexts:

More explicit updates to the mission brief

When teams are small, it’s easy for everyone to adapt and understand the changes happening, be them business, product, or process-wise. But when teams grow, strong alignment becomes more difficult and more critical.

So when there are business changes (ex: delivery date has changed), or team or process changes (ex: a member moved to other team, or part of the process changed), there needs to be clear messaging about what and what didn’t change. Maybe even do the exercise to revisit the document every few months.

We need to communicate and be explicit of what are the new business goals, and which didn’t change. We need to communicate clearly the team members’ movements and how does those affect existent roles — never leave people in doubt. We need to communicate what is changing in the process, what didn’t, and how it connects to the already existent parts.

More explicit process and roles

Similarly to the previous item, when teams are small is easy to understand the process and the roles of each one, but when we get bigger teams or various teams that need to work closely together, process becomes more complex and harder to understand.

Because of this, I believe it’s even more important to document the process and everyone’s roles (having myself recently become a huge fan of drawing diagrams with Miro to demonstrate our workflows).

Having an explicit process and roles helps teams spend less time discussing the next steps, and in discussing who’s responsibility to make certain decisions.

The flow is more streamlined, leaving more time and energy to discuss what matters most: product solutions for product problems.

Strong alignment is a requirement for every empowered team. Without it, teams aren’t clear of what land they are navigating towards to, why they are on this mission, the strategy and process for how they will achieve this, and what aspects we don’t want to pursue.

Only with strong alignment product teams will be the most efficient and creative when sailing towards our goals, and when presented with the surprises of the ocean.