This is the first in a two-part series on systems thinking based on a recent exchange between veteran product manager and friend of ProductPlan John Cutler, and ProductPlan’s Director of Product Management, Annie Dunham.
The conversation touched on a number of topics but immediately focused on the ways in which product management and the environments in which it operates have become significantly more complex in recent years. While some fundamental product principles remain constant, much of the discipline is undergoing a transformation. It’s moving away from the idea of building and shipping a product, to designing, delivering, and maintaining a product system.
One of the strategies for dealing with this shift is the concept of systems thinking.
So, what is systems thinking?
Systems thinking is a way of understanding phenomena rooted in systems theory. To set the stage a bit for the conversation, it’s helpful to offer some quick background on systems theory in general, especially before diving into its relationship to the current state of product management.
Modern systems theory arose in the early 20th century and defined systems as organized entities with interrelated and interconnected parts. Makes sense. What else do systems consist of? There are boundaries, internal feedback loops, and adaptations wherein the system corrects itself and moves toward a stable state.
Most significantly, systems behave in characteristically nonlinear ways, meaning they don’t usually operate within traditional cause-and-effect dynamics. In other words, the relationship between input and output in a given system is not always proportional and any single action can have a sweeping impact on the entire system—think of something like the butterfly effect in which relatively small causes can have unpredictable, outsized effects.
So, how can we relate systems thinking to product management?
John Cutler: In terms of product management, systems thinking is about situational awareness: the ability to accurately perceive the elements in your environment, with respect to time, space, meaning, and their status and future status after a variable has changed. It’s about understanding how a certain set of factors in a system can create wildly complex effects. Modern SaaS companies are increasingly service-oriented ecosystems, socio-technical systems with various touch points into your product and various actors and agents interacting with your product during development and long after its launch.
These actors, i.e. development teams, your customers, your product stakeholders, etc., have unique goals and there are different internal systems that are meant to support these goals. Different dynamics within your organization affect your product process. The idea of linear flows that you expect in product development are incomplete because current product environments are significantly more complex, dynamic, and “alive” than previous development environments.
“Think about how your product integrates with different solutions, and where products are heading in terms of trends.”
So, you need to be thinking about how your product integrates with different solutions, where products are heading in terms of trends. You need to think about internal and external factors as part of your overall product.
John Cutler: Exactly. Service design theory fits the current product management model fairly well because of the idea of touch points, layers, views, and more. Today’s product management dynamic in many ways defies structure, organization, and the linear-oriented, waterfall processes of the past. The systems perspective lets you envision the journey of one actor moving across all of the touch points.
Annie Dunham: In other words, there’s the product and then there’s the product organization, each of which is its own system. As a product manager, you could spend all of your time worrying about the organizational component. How is everyone working together? What information do people in the system need? At the same time, nothing stands alone anymore. Whether it integrates with something else, or it’s part of a larger existing product, it can get overwhelming pretty quickly. Some companies have even adopted internal NPS scores for the product team in an effort to figure out how to systematize the qualitative feedback they constantly receive from other teams regarding their own process. How do you measure success beyond product usage? How can you evaluate and improve how well the product system works?
John Cutler: Absolutely. Many companies are also going from a situation where they’re going to do NPS every year, to a model where product teams and companies are doing a rolling NPS. They’re surveying internal and external customers on a regular basis. It’s a much more dynamic feedback loop, going from an annual email NPS, to rolling NPS, such that we can identify the actual impact of a new feature on NPS score with some precision. This helps identify the direct impact of features, sales cycles, seasonality, and more. In an effort to increase the feedback in the system, many product teams are going from not doing NPS at all, to doing it once a year, to once a month, to rolling NPS for internal and external customers.
So, beyond faster feedback loops, how else is the idea of product systems playing out?
John Cutler: Ten years ago, you would have had six different value streams, each with their own features, priorities, revenue goals, etc. By the end of the year, if you delivered on most of those that was a pretty good outcome. The competition wasn’t as fierce at that point because everyone had the same (not-that-great) model so no one was producing anything particularly groundbreaking.
But, if a competitor suddenly says they’re going to deliver monthly, that’s a game changer. That’s going to completely disrupt the way you think about your roadmap and product strategy. Now, it can be something like, “Hey we have this opportunity. Let’s update the roadmap and mobilize some resources and ship something while the moment is right…” You start to see an increased cadence of roadmap and strategy updates based on live feedback from customers as opposed to long, annual planning sessions around different value streams.
How does that move away from multiple value streams impact the way product teams are structured?
John Cutler: That can play out in a number of ways. When I worked at AppFolio, some of their teams utilized “dynamic reteaming” to introduce more flux into the product organization and distribute knowledge, specialization, etc. But, this creates some uncertainty. You don’t have the pre-optimization of a manager managing a team of several people that is going to be stable. Product is often the team that feels that pain—if you go and shuffle up a team on a product person, it can be very damaging; it can sometimes really mess with the dynamic of the team. But, from a systems thinking perspective, this creates organizational resilience. It strengthens the overall system by minimizing the amount of concentrated expertise on any single team and, in theory, distributes that institutional knowledge throughout the broader system on an ongoing basis.
Annie Dunham: There can be other benefits and risks involved in this shuffling beyond just breadth of knowledge among your team. With constant reorganization and realignment, the passion, the curiosity, coming to the table caring about the issue as much as you the product manager care about the issue, can sometimes not transfer from team to team. Ideally, you want to be producing a system in which nothing’s getting foisted on the team anymore; they’re excited to solve the problem and there’s a significant amount of trust in and reliance on other team members.
Can you shuffle teams too much? What is required of teams and individuals to handle this kind of constant reorganization?
- Craft: People need to know what they’re doing. In other words, you need to be a good match for your environment.
- Sensemaking: You need to know and understand the environment you’re working in.
- Adaptation: You need to be good at adapting to changes in your environment.
- Leverage: You need money and time and passion and psychological safety to get things done and try novel approaches.
You might be good at one or two of these, but to be a successful product manager you need all four. You might be very flexible and great at adapting but if you don’t understand the environment you’re in, it’s going to be difficult for you to adapt appropriately. You might also be great at sensemaking and skilled at the craft of product management, but not able to adapt well to changes in a dynamic environment or exert the leverage you need to get things done despite your great intention and plans.
Think about a healthy organism: we’re all going to get sick or have health problems etc., but it’s the ability to respond quickly and appropriately to handle these types of setbacks without letting them become chronic.
There is risk in a dynamic environment, but the biggest risk is that you can’t sense that there are cracks forming in the system.
Annie Dunham: Ideally, you are developing and instilling certain behaviors and cultures across your organization so that everyone knows how to respond. In a sense, managing that system-wide complexity becomes part of product management.
We’ll talk more about how the concepts of “the product” and “product success” change in the context of systems in part two of this series. Stay tuned!