On a fateful afternoon in January 15, 1990, more than half of AT&T’s lines went dead.
AT&T had the sturdiest and most reliable network that had been able to live through hurricanes and earthquakes. Yet, a single glitch in its Manhattan switching-station created a chain reaction that crashed half of the long distance switching system in America.
The outage remained for 9 hours during which almost 70 million calls went awry, some 200,000 airline reservation calls were lost and many news agencies such as CBS couldn’t even reach out to their local bureau.
A team of 100 baffled AT&T technicians were able to reverse engineer the problem that started in Manhattan. It took almost 2 weeks before the actual issue was identified, that was a single line of faulty software code. At the onset of the outage AT&T’s managers followed the standard procedures to get the network up and running but nothing worked. The question is — “How can you respond to such scenarios?”
Most Product Managers might not have been in any chaotic environment yet it is important to know how to respond to such situations. There are well established processes that Product Managers follow on a daily basis to build products, solve a customer’s problem or manage a platform migration, yet sometimes the outcome is undesirable.
Digital product delivery frameworks provide great means to achieve the end goal but we continue to struggle every now and then. Take the example of SAFe implementation in many companies where they are still struggling after having introduced it few years back. Teams fail to bring any context to execution and keep using standardized methods even when systems fail to respond.
It is the predictability of the system that we always take for granted. In 1970s, Daniel Kahneman and Amos Tversky worked on Cognitive Biases in humans and came to the conclusion that we are born irrational and many of our decisions defy logic. In the light of all this information, it seems that decision making is always going to be fraught with challenges and it would be based on a leader’s instincts than on facts.
Dave Snowden and Mary Boone published an article in HBR talking about the Cynefin framework (“A Leader’s Framework for Decision Making”, Harvard Business Review November 2007). I have used it a few times as a sense making and a problem solving tool. There is no silver bullet to solve all the decision making problems that we product managers face, but there are ways to solve Complex adaptive challenges in a better way than the conventional project management style.
Processes on which we are heavily dependent on are Linear processes while complexity doesn’t respond well to linearity, this is where the Cynefin framework helps us assess the situation and then respond accordingly.
“Cynefin, pronounced ku-nev-in, is a Welsh word that signifies the multiple factors in our environment and our experience that influence us in ways we can never understand.”Dave Snowden
Cynefin framework brings together systems, people and decision making and allows leaders to develop insights based on the domain they are in. The framework puts all issues into three buckets- Ordered, Unordered and Disorder.
Cynefin classifies the problems that leaders face into five different contexts defined by the relationship between cause and effect. Simple and complicated are ordered domains while complex and chaotic are unordered. The disorder refers to the situation when it is not clear which of the other four references prevails.
There is a clear relationship between cause and effect in this domain. There are “Known Knowns” and there is a common understanding of what problem everyone is trying to solve and what steps need to be taken. The result is predictable, and we have done it so many times that the best practices already exist.
Obvious context can be something as simple as doing Unit testing, adding an extra column in a report, adding a link to the support page, updating an icon on the landing page. There is no innovation that happens in this domain.
What should a Product Manager do?
Simple contexts require Product Managers to Sense-Categorize-Respond. So, product managers should study the facts and assess the situation, categorize them and take appropriate measures. There is no over analysis required and decisions can be delegated to the Scrum/Kanban team. Most software development falls in this context.
You might also be interested in: Scrum for Product Managers
There are certain things that we should be cautious about. Oversimplification and complacency because of past successes. As you can see that the Simple domain lies next to the Chaotic domain and it doesn’t take long before the best practices lead one into the chaotic domain. We have seen this happen for AT&T in the 1990s and the result was catastrophic. This is what happened with companies like Kodak, Nokia, Sears, and many others.
Last year, my team had launched many products but during one such launch we didn’t do proper unit testing. Seems a trivial issue to many in the software development world but it resulted in an outage for many of our webpages. To avoid losing control of the situation, Product managers should have a clear line of communication with the team and should not take past practices for granted.
There is a cause and effect in this context but it’s not obvious. The outcomes are predictable, but need some expertise to understand what needs to be done by the team to move from complicated to the obvious domain. A watch is a complicated system, which can be taken apart by an expert watchmaker and then put back together.
If a police roadblock is an example of an obvious system, then a traffic signal is a complicated system. Complicated problems can have many right solutions and this where a Product Manager faces the biggest challenge. This is the realm of new product launches or regulatory requirements where “Known Unknowns” come into play.
In 2017, CRTC Canada made changes to the Wireless Code of Conduct and said that “Extra data charges and data roaming charges should be capped to prevent bill shock.” It took us weeks to understand the problem and we had to pull in all the experts to come up with a solution. The outcome was known but we had to analyze the impact on all systems and the best approach to the problem.
What Should a Product Manager Do?
The decision making process was to Sense-Analyze-Respond. Product Managers have to assess the situation based on the existing facts, analyze the available options with the help of experts and then decide what good practices can be developed. There is no one perfect solution in this domain, hence it’s difficult to find best practices as we are able to do in the obvious domain.
Agile ceremonies such as standups, refinement, sprint review, retrospectives etc are the governing constraints that help manage people’s behavior in this domain.
Dave Snowden cautions us against Analysis Paralysis that might happen when we bring in experts to solve a problem. Also, in the presence of experts we tend to overlook any innovative solution coming from non-experts.
For example –some of the best ideas come from the call center agents who are closer to the customers than many other people in the organization. The product manager ensures that the best idea is chosen and within an acceptable time frame. It might be possible to do it through a Design sprint or a discovery sprint.
In this domain cause and effect can only be understood in hindsight. Product Management lives in this domain and “Unknown Unknowns” come into play. Unlike a complicated domain where there is at least one correct solution, in complex domain it is almost impossible to simply analyze and find one right solution. To bring this comparison to life, Dave Snowden compares a Ferrari (complicated) with that of a Brazilian rain forest (complex).
Though Ferrari is a complicated machine, an expert can break it down and put it back together, similar to what we see in the complicated domain. On the other hand, the rainforest is always in flux. A rainforest has a constantly changing wildlife, climate, flora and fauna etc. The whole is much more than the sum of its parts.
Another great example is the 1969 moon landing mission. It wasn’t just about the spacecraft but a myriad of other complex things such as the software engineering tasks, astronaut training, physical and emotional stress etc that needed to be handled.
You might also be interested in: 5 Lessons from SpaceX for Product Managers in 2020
Last year, Telus communications launched the new unlimited plans in the Canadian market. In the early phases of the discovery when we were looking at the end to end customer journey and trying to understand all the systems impacted, it seemed that we were pretty much in the dark. There were too many legacy systems that had not been touched in years. The experts had a very good idea of their specific systems but changes in one had a cascading impact on others, which was hard to anticipate. To add to that there was the pressure from the competitors too. Our plans kept changing based on the competitor’s market response.
What should a Product Manager do?
The way to go forward in this complex domain is to – Probe, Sense and Respond.
Instead of enforcing a plan of action, leaders go ahead with many safe to fail experiments, which tell them how the environment is behaving. It is possible that the outcomes keep changing in this domain, hence product managers rely on a high feedback loop to adapt to emergent practices. In this domain there is flexibility in constraints and teams enjoy more autonomy because there is a need for out of the box thinking.
At Telus, we time boxed our experiments in 2 week sprints during which we worked on a lot of spikes in collaboration with other cross-functional teams. So, these Agile practices became our enabling constraints. These sprints created a high feedback loop to help us analyze the situation and respond. Good Product managers need to build multiple hypothesis and run the safe to fail experiments.
During our launches for complex products, we run many A/B and multi-variate tests. Things might seem absurd sometimes, for example we once found that the hypothesis that added more friction in the user’s journey lead to a greater satisfaction.
So, it is important that the Product Manager keeps probing the hypothesis and makes sense of the situation before things go out of control. In the complex domain non-functional requirements become more important than in the ordered domains.
In the complex domain, the biggest challenge for Product Leaders is the temptation to micromanage the teams in order to achieve the desired outcome. The emphasis should be on allowing the team to work in the experimental mode and not be discouraged by any failures.
There is no cause and effect relationship in this domain because the relationship keeps changing. So looking for the right answer is fruitless. This is the domain of Unknowables. Chaos is when a product launch brings down your website because of some bug you might have missed during testing.
Incidents such as Chernobyl fall into this domain. Chaotic domain has no constraints, and you expect the team to come up with many independent hypotheses. This is where diversity and multiculturalism are effective in bringing better ideas. Chaos is a temporary domain because it is impossible to have something unconstrained for long.
You might also be interested in: Learning from Failure: Product Manager Style
What should a Product Manager do?
In this domain, the leader’s job is to stop the bleeding first. There would be no time for experimentation and safe to fail experiments. So, the approach should be – Act, Sense and Respond. The leader has to act first to address the burning issues, sense where there is stability in the system and then take further action to move the situation from chaotic to a complex domain.
Few weeks back when we decommissioned an old service and replaced it with a new one, it brought down some of the critical customer facing applications. The engineering team had no idea what had happened as everything looked fine in the staging environment. In our case, we acted first by launching a fix but unfortunately it didn’t fix the issue.
Though there is a bias for action there would be a possibility that your actions might not be successful. When we weren’t able to fix the issue we had to roll back the changes. The product manager should be aiming to move out of this domain into the Complex domain.
Product managers spend a lot of time trying to find the right solution and that is a good practice, but we still see a lot of failures where the product doesn’t meet the customer’s needs. The reason is that we treat complex problems as complicated ones. Changing customer needs, shifting market forces, employee attrition, new technologies etc have created a lot of unpredictability in our work environment and this is the complexity that Product Managers have to manage.
Product managers need to adapt to different models of leadership based on the context of the situation they are in. Unfortunately, most of our training helps us to manage ordered domains where everything is pretty much linear. In the face of complexity, our conventional approach falls apart. Cynefin provides us with the tool to make sense of what’s happening and respond appropriately.
This framework has helped me determine how Agile practices need to be used in various domains. It is quite evident that agile practices are effective in complicated and complex domains. As mentioned earlier, agile practices could be used as governing constraints or enabling constraints depending on the domain.
Experts might differ on this, but if waterfall has to exist then it would be in the obvious domain where product managers have to manage a highly predictable system. When product managers work on complex innovation projects they encounter many Unknown Unknowns. The challenge would be to learn and discover these unknown elements and move them into the known domain. Mostly products in the growth phase follow the same trajectory.
On the contrary, changes to products in the mature phase would mostly have known knowns. Product managers have to understand which part of a new requirement lies in which domain. There is no doubt that the priority should be to tackle the most complex item first. That helps in reducing the risks and move the changes into a more obvious domain. So going with a one size fits all approach to problem solving hasn’t helped us much and this is where Cynefin framework can come handy.
If you’re interested in this topic, we recommend checking out these resources, which Dibya used as references:
- A Leader’s Framework for Decision Making, Harvard Business Review, November 2007, David J. Snowden and Mary E. Boone
- The Practice of Adaptive Leadership: Tools and Tactics for Changing Your Organization and the World 2009, Ronald A. Heifetz, Marty Linsky and Alexander Grashow.
- Strong and Agile: Improving Product Outcomes Using Cynefin and a Product Lifestyle, 22 May 2016, Craig Strong
Meet the Author
Dibya Ranjan Pal is a Digital Product Manager for TELUS Digital.A s a behavioral product manager Dibya effectively communicates, educates, and translates behavioral science insights for the engineering and design team while building habit forming product features.
Driven by a strong founder-level vision for the group, Dibya has a clear line of sight into the series of products/features that needs to be built thereby enforcing great execution against the vision and strategy