Shared Understanding: What Distinguishes The Best Product Teams

According to Atlassian Product Manager with eleven years of experience. Shared understanding — the main skill of an excellent product team. It distinguishes good teams from the best ones. The best product manager is not the one who knows all the answers. He or she is the one who ensures their team understands What they do, for Whom, and Why. experience in adopting shared understanding—a long and complex process with amazing results.

Shared Understanding
template for →
Rice Framework
Table of Content
Arrow Down
Shared Understanding
template for →

How to Be a Good Product Manager

According to Quora discussions, there are two main lists:

  • Specific skills: analytics, UX/UI, interviews, research, A/B tests, etc.
  • General skills: empathy, strategic thinking, proactiveness, adaptability, ability to foresee unintended consequences, etc.

Still, the set of good PM skills is not hard to determine and learn.

But product management isn’t only about skills. It's about making decisions.

Two Ways of Decision-Making

After a hundred hours of user interviews with PMs, we spotted two approaches:

  1. Superhero—a know-it-all and almighty PM, answering the team's every question and making all the decisions.
  2. Facilitator— a PM that helps the team to understand problems and make decisions.

Product Consultant’s Trap

Stories about Steve Jobs inspire to be a superhero.

Superheroism gets you in a trap. Instead of being a manager, you become a consultant—a person who answers any question about the product.

Being a Product-Superhero is a Slippery Slope

I really liked Sherif’s experience story. Sherif Mansour is a Distinguished Product Manager at Atlassian.

A shot from “What is product management?”

Early in his career, he believed that a PM is a superhero with answers to all the questions. Eventually, it led to a problem: He had to answer each and every question about the product. Even like “place the button here,” “color it blue,” “make API requests this way,” and so on. He became overloaded with day-to-day things.

At a one-on-one meeting with his manager, he described dozens of subtleties about what they do with the team. What buttons they put and how overwhelmed he is. But what he heard was that he should focus on more strategic things.

That is one of the biggest traps in product management:

You downshift yourself from Product Manager to Product Consultant by constantly answering more and more questions by your teammates. (idea by Ivan Spasojevic from Quora thread)

Product Consultant Problems

  1. Question count grows—scope decreases.
  2. Work stops without you.
  3. The team does more unnecessary work.

You must check and study everything. Otherwise, it will be implemented wrong. Probably with no clear purpose.

You seek help in roadmap planning, product requirement documents, and backlog prioritization.

However, provided your team reads all that, they perceive the tasks differently.

Writing ideas and strategies down, or reading them, doesn’t necessarily mean comprehending them.

Product Management is a Team Sport

A shot from Mind the Product in 2019

In his speech at Mind The Product conference, Sherif Mansour points out what was the main misconception in his entire career—Product Managers make all the decisions.

You have to switch that mindset and empower your teams with decision making.

A PM owns the velocity of decision-making. And the mission is to increase it by building a team's shared understanding. That was his most valuable lesson.

Three W’s of Shared Understanding

The team must clearly understand:

  • The Who—They have enough context on who they’re solving for.
  • The What—They understand what problem they’re solving.
  • The Why—They understand how it fits into the bigger picture.

One of the signals of shared understanding is that your team runs fine without you touching the backlog. They don’t need you to take up the tasks right for your customers and strategy. They are always fully aware of what they do, how, and why.

Can your designers, engineers, and analysts decide on solutions on their own?

Signals of the Great Shared Understanding

  • You haven’t seen your backlog for months, and your team is executing fine.
  • Your team challenges you on things they’re doing, which aren’t aligned with your north star.
  • Your team references customers by name.
  • Your team wants to work on outcomes over output. They say, “This will help us increase retention” not “I need to complete the epic to receive a bonus.”
  • Team demos are formed around “we’re building X to solve the customer’s problem Y” without any prompting.
  • Their side-projects are all aligned with your roadmap.

Think: As a PM/CEO/owner, are you ready not to intrude on the team plans and not assign all tasks yourself?

What Makes a Distinguished Product Manager

Sherif points out two main crafts of product management:

  • Building Shared Understanding—doing customer research, data insights, collections, surveys, rapid prototyping, and so on. Important that you do these activities together as a team. Thus you better understand the customer problem and intent and build shared understanding together.
  • Identify Gaps in Shared Understanding—asking your team if they clearly get the What, the Who, and the Why. Talk to your team or do the surveys. And when you find the gaps, you conduct activities to close them.
Example results on “The 3 W’s” survey

Personal Experience in Building Shared Understanding

The whole story of how our team uses is an attempt to build Shared Understanding at

1. Sharing customer emotions with the whole team.

We use the “The Mom Test” method for customer interviews. We try not to sell, not to make a demo or say anything about our solutions. We only listen to how our potential customers describe their workflow, problems, and pain points.

We ask for permission to record a video for the rest of our team. It's important to share the most vivid moments of the user story with their emotions and wording. That exercise helps to get a sense of customer's problems and doesn't take a lot of the team's time.

2. Expressing product objectives in evaluation criteria.

We used to have a document with company goals and objectives. But it was difficult to remember key metrics and aims without a hint. Later we transformed them into task evaluation criteria in Ducalis.

We have three sets of criteria:

  • Common criteria the whole team must understand: Activation, Retention, Service Speed, and Collaboration Assistance.
  • Developers criteria: Development Complexity.
  • Managers criteria: Sales Potential and Feature Demand.
A set of criteria for backlog grooming

3. Evaluating backlog together on Fridays

Every team member must estimate tasks and ideas from the backlog. Developers and product managers have slightly different criteria. We assign scores subjectively, so it’s easy and fast. The important thing is to do this regularly. We use weekly sprints, and so we groom the backlog every week.

Task evaluation by criteria in Ducalis

4. Planning sprints on Mondays

After the grooming, we get all our tasks ranked by priority. The Top Priority list is advisory. The team populates the sprint independently. On the planning, we explain the What, the Who and the Why. We can adjust our plans if the context has changed over the weekends.

Backlog issues sorted by priority

5. Finding gaps in shared understanding

  • If we don’t understand how to assess a criterion, we put a dash. Then we discuss the criterion together and may rewrite its description. If we don’t understand the task, we leave comments in Jira. This helps the reporter to find confusion in the idea or lack of alignment with the vision.
  • The scores are discarded 30 days after the task was evaluated. If it wasn’t complete, we estimate and rethink it once again. Pretty often, we decide to delete the task. Re-evaluation is critical. Thus we understand the backlog relevance as we regularly receive a new customer context.

All that together gives us a picture of Team Alignment. We see where the team has disagreements or lacks shared understanding.

The Results of Building Shared Understanding in Team

The system began to bear fruit within a few months. Here’s the feedback from the team:

  • Most times, it’s great. Both managers and developers now have a better understanding of the product. We try to look from different angles. Our discussions became more reasoned.
  • Shared Understanding seems to be of high level.
  • We lack the indicators of where we’re going. Like, the customer number should be X, revenue K, and so on. This would help when studying priorities. Does the task contribute to the values? [This one we’ve fixed]
  • Lots of things still hinge on Vit [CEO]. He doesn’t delegate or entrust the task implementation much.

As you see, we can’t say that everything is splendid. But it becomes better each week. Building shared understanding requires much effort. But it’s worth it. We still think sometimes, “It’s faster to implement than explain.” But it’s just boxing the problems for the future.

Try Our Methods at

Don’t forget to sign up and try to evaluate the issues. The product itself will guide you through the methodology.

Reading List

P.S. Steve Jobs Syndrome—being a lone genius who foresees the future. A person who is not interested in customers’ or colleagues’ opinions. The one to know what to do next. But still, we remember Steve saying, “Hire smart people and let them tell you what to do.

Create Account for Free
Request a Demo

Start prioritizing today

No Credit card required

Shared Understanding
template for →