The power of stories and micro decisions: water polo teams vs product teams

By Pedro Cerqueira

I was a water polo player before I was a product manager. I played water polo for 20 years and learned many important lessons. Some of the most important lessons only acquired real meaning a few years after I had stopped playing, when I was able to observe and be part of teams in an organisational role.

Water polo is a competitive team sport played in a pool, where players pass and shoot a ball to score goals against the opposing team’s net while swimming and treading water.

After so many years doing something you actually start to unconsciously see and feel the World through different lenses. If I’m about to make an important decision at work, it almost feels like my brain takes me back to when I was about to shoot a decisive penalty. It’s difficult to put this into words, but I think it’s worth giving it a “shot”! Please bear with me as, like in most analogies, the ones in this article are imperfect, although I believe they can be helpful when considering how high-performance product teams work best to win.

Like a water polo player or any player in a team sport, every individual in a Product team must play with their teammates for their team to win.

The Competition

In water polo, several opposing teams compete against each other to win a competition.

Like in water polo, in the world of product development, there is always some kind of competition (even if this is not immediately apparent at your team’s product scope level).

• Whether it’s direct competition from another product like the one between Coca-Cola and Pepsi that offers similar products for the same market.
• Whether it’s indirect competition like when Netflix competes with movie theatres offering different products to fulfil similar needs.
• Whether it’s internal competition as your team replaces or AB tests an earlier version of your product against a newer one.
• Or any other scenario in which your product competes for the user’s money, attention or time, like when TikTok or YouTube compete for the time you could spend with family and friends or when a new Apple iPhone competes for the money you could use on education.

At the team level, it’s a competition of ability, motivation, insights, resilience, cooperation, rewards, priorities, time management, adaptability, experience against other humans in other companies (or bots like the ones who created this article’s images).

No matter whether you are creating something entirely new that didn’t exist before (Zero-to-One) or improving, iterating on, or scaling something that already exists (One-to-N), no matter how disruptive, big or small, product development teams and their products are always competing.

The Game, the Team and the Players

In water polo, competing means you need a strategy (or a few) to enter each game to win.

The team deliberately practices the strategy every day so that each player knows why and how to play together to win.

Each team might have a few highly rehearsed plays, but victory usually comes from their joint ability to adapt to the unique and unpredictable game’s circumstances as they unfold.

As Mike Tyson said, “Everyone has a plan until they get punched in the mouth”.

Or to paraphrase a 19th century field marshal: “No plan survives contact with the enemy”.

During a single game, every player will make thousands of micro decisions based on what they are experiencing from their teammates, opponents, referees, coaches, the field of play and even the crowd. We can think of these micro decisions, as something as small and unconscious, as moving a leg muscle to initiate a change in direction after the end of an attack. Or as something more meaningful, such as raising an arm above the water to shoot at the goal with 5 seconds left on the shot clock.

Most of these micro decisions can be trained, but it’s hard to coordinate all of them as each player adapts to their ever-changing reality during the game.

For example, if a player decides to shoot at the goal, all the players in the same team must initiate their defensive moves at the right time; otherwise, the opponents can take advantage of a single player’s delay to score in a counterattack. Coordination is a must during the entire game.

These micro decisions are the sole responsibility of each player, but the sum of all these micro decisions made by all the players in a team during a game determines the outcome: victory, tie or loss.

As an individual player with a specific role in the game (e.g. goalkeeper, wing, centre-back, etc.), one’s micro decisions cannot be made by someone else, but they can certainly be influenced.

Besides practicing together day in and day out, the main influencing factor is to have a clear strategy for each critical stage of the game. With it, each player in the team knows the general intent at each moment of the game, whether during attack, attack/defense transition or defense.

The team with the individuals who consistently make the best joint decisions during the different stages of the game is more likely to win.

Just like in water polo, a Product team is composed of individual players with specific roles who are constantly making micro decisions in their areas of expertise (some non-exhaustive examples):

• Engineers are trained at designing, developing, and implementing great technical solutions.
• Designers are trained to deep-dive (no pun intended) into the problem and connect the dots between different disciplines’ knowledge to solve a customer problem that delivers a meaningful experience.
• Analysts are trained at uncovering, understanding and interpreting data related to the product’s performance, user behaviour, and market trends.
• Researchers are trained at conducting user research and gathering insights to inform the product development process and areas of investment.
• Product Managers are trained to help the other roles come together by guiding the product’s Discovery, Delivery, and Launch to success.

This does not mean that every Product team needs all of these roles, but I would advocate that someone in the team needs to “play these positions” to a certain extent. If you want to win a game that involves goals, I bet you probably want to have a goalkeeper. You can try to win without one, but that will be less likely to happen unless other teams don’t have one, too.

The Scoreboard

For every product improvement the team is pursuing (aka the game it’s playing), there will always be someone keeping score regardless of whether or not someone in the team is measuring it. That someone might be your users, customers, buyers, shareholders, etc. They will dictate the victory.

Just like in water polo, I believe that victory in the Product world comes from each individual’s ability to make the right decisions as the game unfolds (the team might make some decisions together, but it’s impractical and inefficient to apply this formula to all decisions).

This happens at every possible “stage of the game”, for example:

• When engineers decide on the specific technology, architecture or libraries to use, it can affect the product’s time-to-market, performance, maintainability, and overall user experience.
• When designers define the UX journey and interactions, they translate them into interfaces and experiences that fulfil the customer’s needs and directly impact the overall perception of the product.
• When analysts decide which events must be tracked, it can significantly impact the team’s ability to measure success, learn and iterate.
• When researchers decide on a specific research methodology, it can significantly impact the quality and relevance of the information obtained.

To increase the chances of each individual in a team making the right decisions, there needs to be a common strategy they all build, know and follow.

Falling back to the water polo parallel, let’s say a team decides the best defensive strategy is to play press to prevent the ball from getting to the powerful centre-forward adversary who is highly likely to score. All it takes for the centre-forward to get the ball is for one of the defenders to ignore the strategy and fail to play press as initially planned.

The Game Strategy (The Product Story)

Besides intensive and continuous team practice, I believe that the individuals in the Product team will be better equipped to make the right decisions when the Product Manager shares the strategy and the Why behind a product improvement or, as I would call it, “The Product Story”.

The Product Manager usually has access to additional business context and doesn’t spend so much time “underwater” at the same level of (technical) detail as their teammates, putting them in a perfect position to start crafting this story. The goal is not for the Product Manager to create it solo, but rather to advocate for its existence, particularly if no one else does. When the Product Story is crafted collaboratively, leveraging the perspectives and the checks and balances of the different team roles, it is more likely that the strategy for each improvement leads the team to victory.

As a side note, the concept of a Product Development team used here encompasses a group of people that are working together to solve a problem. This is regardless of whether they are colocated, distributed, virtual, full-time, part-time or under the same or different reporting lines, business units or organisations. Different configurations will have their pros and cons, but they will all benefit from a well-crafted Product Story.

If the different teammates don’t play together when building the Product Story, the likelihood of success will be lower. Imagine the following example scenarios:

• If an engineer doesn’t contribute, the designed solution might not be the right one to be launched in the optimal time-to-market to assure customer acquisition.
• If a designer doesn’t contribute, there may be a mismatch between what users want, what the product offers, and the business goals.
• If an analyst doesn’t contribute, the product might be based on speculative quant assumptions, leading to poor decision-making and wasted resources.
• If a researcher doesn’t contribute, the product may fail to resonate with the target audience due to wrong qualitative assumptions, resulting in low adoption rates and reduced customer satisfaction.

As a Product Manager, I usually try to craft the Product Story by starting with the Why for each relevant product improvement. I often use the 5 Whys technique to make sure I understand why we’re doing something. This should help motivate the team to take action! I try to be as unbiased as I can. If I can’t convince myself why it’s worth it, maybe I shouldn’t start working on it just yet and, instead, should be asking more questions.

Once consciously on board, I just try to tell the story that connects the Why to the Who, What, When, Where, How and How Much (the 5W2H technique).

This should help the team execute (play) to the best of their ability!

I try to be pragmatic and tell a simple and logical story while addressing questions like the ones below:

Figure 1 — Table containing the main Product vs Water polo strategic questions

Once there’s an initial draft, I encourage everyone on the team to ask questions, add, change, remove, comment, challenge, confirm and correct it so we end up with a better story than when we started.

In the end, this is the best story/strategy this team can create together, and it’s the one each team member will have in mind when making the micro decisions during their day-to-day in producing a given product improvement a reality (aka trying to win at the game they are playing)..

Just like in water polo, if these Product teams “practice together and play often” (e.g. for several uninterrupted years), each new Product Story emerges organically with almost no communication overhead as every team member knows exactly what they need to do and can predict pretty accurately what others will do under specific circumstances.

When Product Teams are less used or don’t have the opportunity to “practice and play together”, this is when consciously making the time to write and share the Product Story has the most significant impact in helping these teams win. I believe the Product Manager should take the initiative to create a first draft, share it with the team and encourage them to ask questions, correct and suggest improvements to ensure the story benefits from the team’s wisdom. I cannot stress enough that the team should be composed of whoever is necessary to win. It’s up to the Product Manager to step up, climb through any organizational obstacles, share the story and allow it to evolve based on the feedback from all those who need to be involved.

The Product Story should influence each player’s micro decisions. It won’t be a playbook telling each player exactly which individual decisions to make, but it should help individuals optimize the outcome of their joint decisions.

Then the game will start and the sum of all these micro decisions made by all the players in a team will determine the game’s outcome: victory, tie or loss.

Originally published at https://www.farfetchtechblog.com on October 17th, 2023.