Why do product teams fail?

As a product designer, I do not mean to explore this territory. However, too much pain over 20 years has made me put my foot here. Before we enter this territory, we must understand that product design space is messy and complex by its nature in the work itself, the industry and human nature. It is a fact, not a make-up requirement,

The story starts with the hens in my backyard. In my mind, a team is a bit like a flock of chickens. We love staying together, yet we can peck at each other surprisingly hard. So I kept asking my ex-colleagues, “How do we align the chickens?” Kathryn, then, unintentionally, sent me a photo like this — a chicken aligning by standing on a perch. The image has kept bouncing around in my head ever since.

But for Kathryn, it was simply a photo of chickens being chickens. There wasn’t a further message. But that difference is what I want to talk about. The same thing can be in front of us, yet we can see something completely different in it. And, it turns out, to align chickens, you just need a perch, somewhere they all want to stand.

共识 — Shared understanding to form a consensus in product design practice

Consensus is not simply agreement. Not everyone has the same understanding, and it is not a state a team can assume it already has.

The mandarin language contains a great deal of wisdom. This is one of them. The word 共识 offers a deeper way of thinking about it.

共 — together, shared, participating with one another.
识 — to know, recognise, learn, discern and understand.

Together, 共识 can be understood as:

Coming to know and understand together.

It does not mean reaching a universal understanding, or making everyone see things in exactly the same way. It means developing a sufficient shared understanding among people to move forward together through interaction. Communication is the entry point, but it is not the whole process. Through questioning, listening, interpreting, testing, acting and learning together, people gradually develop an understanding they can share and work from. See discussion below: Three ways information is communicated.

Consensus is built through alignment, not “common sense”

People enter a conversation with different information, experiences, interpretations, priorities, assumptions and intentions. Therefore, we cannot assume that a team already shares the same:

• understanding
• judgement
• direction
• interpretation
• priorities
• intentions

Even when people use the same words, they may be imagining different things. For example, a team may all agree that they want to “improve the product.” But one person may mean improving usability, another may mean reducing technical debt, and another may mean increasing revenue.

The words are shared. The meaning is not necessarily shared. So, consensus cannot begin with the assumption “We are already aligned.”

It begins with the willingness to discover with our best positive intention:

“How are we each seeing this? What have I missed from their perspective?”

The practice of building consensus

Consensus develops through a flow between people. One person brings what they see, know or believe. Another person brings their own perspective.

They then:

share → listen → interpret → question → clarify → compare → check → adjust → act → learn

This is not a one-way transfer of information. It is a two-way learning process. The person communicating has a responsibility to ensure they are understood. The person receiving has a responsibility to make a genuine effort to understand. Both need to be willing to ask questions, clarify assumptions and check whether they have understood the other person’s meaning correctly.

This requires:

• Mutual willingness to commit to building the understanding, with effort and openness. It takes time and persistence: people communicate back and forth, test their understanding through actions, learn from what happens, and adjust together.
• Good faith is built and reinforced through how people interact with one another. As we learn how someone communicates, what they need, what they are trying to achieve and where they may need support, we become better able to interpret their actions positively and offer help.
• Positive intention and curiosity can help us respond to difficult behaviour with more understanding. People are often focused on their own goals, needs, ego, pressures and desire to demonstrate their capability. There is nothing wrong with wanting to demonstrate one capability. There is something wrong with demonstrating it by diminishing someone else’s. We often infer a person’s motivation from their behaviour, but behaviour does not tell us the whole story. The same behaviour can come from very different intentions.

Four things that develop through the process

1. Shared understanding

We do not assume that we understand the same thing. We bring our different perspectives into the conversation and clarify what each of us is seeing, knowing and interpreting.

What are we each seeing, and what do we mean by it?

2. Shared judgement

People may still interpret the situation differently. Consensus does not require eliminating those differences. Instead, we compare how we are making sense of the situation and why. We examine evidence, assumptions, constraints and reasoning.

How are we making sense of this, and why?

Through this process, the team develops a stronger basis for making decisions together.

3. Shared direction

A team should not assume that everyone already knows where they are going. Each person may begin with a different map. The direction is developed through conversation: we compare our maps, ask questions, identify differences, check assumptions, and gradually work out what direction makes sense together.

Where can we go from here, and what do we need to understand before we move?

The shared direction is therefore an outcome of the process, not a prerequisite for it.

4. Good-faith disagreement

Different interpretations and opinions are inevitable. Good faith means being willing to understand before judging. It starts with positive intention and curiosity — not assuming that a different opinion is an attempt to dismiss or undermine us.

People may sometimes act with poor or even harmful intentions. Good faith does not mean ignoring that possibility or excusing unkind behaviour. It means giving the interaction enough openness to understand what is happening before deciding what it means.

“You are seeing something differently. What are you seeing that I am not seeing? I am willing to understand your perspective. But if you choose to be unkind, that is yours to deal with — I don’t need to make it mine.”

Disagreement can be an opportunity to learn within a safe environment. Trust is necessary to build without attacking people. Disagreement does not mean opposition.

Why do many organisational methods not create consensus

Many organisations use team-building exercises, personality frameworks, workshops, KPIs, consultants and SOPs. These things are not necessarily ineffective. The problem is that they can address only part of the process.

1. Recognising differences

A team-building exercise might use coloured dots or personality types such as Myers-Briggs Type Indicator (MBTI) to show that We all think differently. It creates recognition without practice.

This can create awareness. But awareness isn’t the same as knowing how to work with difference. A team may recognise that people have different personalities and perspectives, yet still have no practice in communicating across those differences: asking questions, resolving conflicting interpretations, and making decisions together from each other prespective. That’s why many team-building exercises don’t actually build a team. After the fun stuff, we move on. Don’t get me wrong, these type of exercise do build rapport and start forming connections. But connection isn’t the same as collaboration.

2. Creating the answer from the top

An organisation might bring in an executive consultant who interviews leaders and employees, synthesises the information and creates an SOP or organisational grant goals. Again, this may produce a useful result.

But the organisation may have received the answer without developing the process that created the shared understanding.

The consultant has done the connecting. The team has not necessarily learned how to connect with one another. Because the consultant costs $200/hour, the boss will not be able to keep them.

A practical organisational workflow flows from bottom to top, and top to bottom. The understanding needs to flow between these people. Each person sees something different, knows something different, and contributes something different. The work moves forward when those differences are connected through interaction — sharing, questioning, interpreting, checking, acting, learning and adjusting.

If one person could do everything, there would be no need for an organisation. I would probably have started my own business already — because, honestly, people can be a pain to deal with, including myself. But I have no choice but to deal with myself, and an organisation has no choice but to deal with other people.

KPI is a goal, not the flow

The same issue can happen with KPIs. A KPI can be useful:

Increase customer retention by 10%.

The organisation now has a clear goal. But the KPI does not necessarily tell the teams what needs to happen, who needs to do what, or how their work connects. A shared KPI does not automatically create shared understanding or provide the steps for moving forward.

The product team might see onboarding as the issue, while engineers focus on reliability. Support may feel that customers lack understanding, and marketing may believe that expectations are misaligned. The organisation, therefore, does not need everyone to have the same task. It needs different tasks to be connected through a shared understanding of the goal, each person‘’’s contribution, and how those contributions flow between people.

The process is not a simple linear flow from KPI to task to outcome. Instead, it is a continuous cycle of information, interpretation, action, and learning among team members. The key distinction is that a “task” helps create “flow.” While a task can be clearly defined, it may still be poorly connected to surrounding work. Consensus among teams is crucial to transform separate tasks into cohesive contributions. Consensus is an organisational capability for its operational process.

When Agile Becomes Reporting

Three ways of information being communicated.

1. Inform: Information is shared one way. The receiver processes it independently, and a response is optional. Example: a conference presentation.

Information → Individual understanding

2. Instruct: Information is shared so the receiver can carry out a specific task. Example: following a recipe or assembly instructions.

Information → Instruction → Action

3. Co-create: Information is the starting point for dialogue. Both parties interpret, contribute, and respond until they reach an understanding neither could have reached alone. Example: an architect and client shaping a brief, or a designer and engineer working through an edge case together.

Information → Interpretation → Contribution → Response → Clarification → New understanding

Most of the real work of product design happens in the third flow, where stakeholders exchange insights to build shared understanding.

Where Agile Can Fall Short

Agile methodologies promote collaboration, but practices can become too focused on information sharing. Daily stand-ups often turn into reporting, and tickets may serve solely as instructions.

While this communication is important for coordination, an overemphasis can hinder deeper engagement among team members. Meaningful interaction requires people to engage, share insights, question assumptions, and contribute to discussions.

The mistake is expecting a coordination ceremony to deliver understanding of the work or assuming that regular communication helps the team understand. Agile promotes interaction, but true meaning comes when individuals relate information to their context and goals. At the same time, ceremonies can facilitate genuine dialogue and help develop a shared understanding.

Consensus as an organisational capability for its operational process

Therefore, consensus should not be treated simply as something a team has. It is something a team practices. The goal is not to get everyone to agree. Or do the tasks for the sake of the goal. It creates the conditions in which people can come to understand, judge, decide and act together.

People do not need to think the same way. They do not need to start with the same map. They do not even need to reach complete agreement. They need enough shared understanding and shared judgement to:

work together → make decisions → act → learn → adjust

And when their understanding changes, they need the ability to return to the conversation and rebuild the consensus. So, ultimately:

共识 — shared understanding is the practice of working through differences together.

And that is why consensus is not something a workshop, consultant, KPI or SOP can simply deliver. Those tools can support the process, but consensus itself is formed through the flow between people.

Perhaps the organisation therefore has one important job: to provide a safer perch for people to stand on together.

And a safer organisation does not mean an organisation where nobody disagrees, nobody speaks up, or everything stays stable. Organisations still have competitors, changing markets, uncertainty and pressure.

Safety is not the absence of shaking and wobbling. It has enough stability to stay connected while things shake.

When people have that stability, speed no longer needs to be the thing we chase in product development. We can move quickly when it makes sense, but we do not have to rush simply to appear fast. Moving fast does not necessarily mean making progress.

Why do product teams fail? was originally published in Bootcamp on Medium, where people are continuing the conversation by highlighting and responding to this story.