Anyone who creates digital products for a living knows it’s difficult.

There are many stakeholders, often with either misaligned or conflicting objectives. Experience building digital products helps you in some cases and hurts you in others. Users are often finicky, stubborn, or downright unaware of what they want.

The business is rated on outcomes that require technology to move fast, while the IT department is incentivized to fight off change to promote reliability. Some groups, from competitors to hackers, want to see you fail and will sabotage your work given the chance.

No two digital products are the same. All the previously mentioned elements interact in a specific context for each product, producing different behaviors and distinct results.

This phenomenon is called Systems Thinking.

What Is Systems Thinking?

Donella Meadows wrote the canonical book on the subject, titled Thinking in Systems: A Primer. This book should be required reading for every product development team.

Donella defines a system as:

A set of things (people, cells, whatever) interconnected in a way that produces a behavior over time.

Looking at all the “people, cells, whatever” in any product development effort, it’s easy to see that it fits this definition of a system. There are stakeholders, users, infrastructure, legacy applications, the competition, the industry, etc. The combination of these elements produces a behavior that is specific and contextual to your product.

A system has elements, interconnections, and a purpose. There are many types of systems, for example:

• Systems that have balancing loops, like a thermostat, which has a desired temperature measured against the ambient temperature.
• Systems with one reinforcing loop and one balancing loop, such as inventory levels in a warehouse.

To change a system, you need to understand its goal, elements, and how they interact. In other words, you need to see the whole.

The Ripple Effect of System Changes

Optimizations to parts of the system overwhelmingly push the problem to another part of the system. If you crank up the thermostat, the ambient temperature will quickly get uncomfortable (as will your heating bill).

Russell Ackoff, a pioneer of many philosophies, including systems thinking, said,

A system is never the sum of its parts; it’s the product of their interaction.

Peter M. Senge wrote in The Fifth Discipline,

Systems thinking is a discipline for seeing wholes. It is a framework for seeing interrelationships rather than things, for seeing patterns of change rather than static ‘snapshots.’

For instance, if your internet goes down, your internet-connected thermostat might not get the message you’re cold or be able to do anything about it.

This intuitively makes sense if you work in the digital product development world. If you can see the elements and relationships of the system, you can manipulate the system. I feel the ambient temperature; I adjust the thermostat and the system changes.

For simple systems, this is simple. But not all systems are simple.

And guess what? Product development falls into this category.

Complex Adaptive Systems

Product Development is a type of system called a Complex Adaptive System (CAS), defined by Wikipedia as:

…a system that is complex in that it is a dynamic network of interactions, but the behavior of the ensemble may not be predictable according to the behavior of the components. It is adaptive in that the individual and collective behavior mutate and self-organize corresponding to the change-initiating micro-event or collection of events.[1][2][3]

In other words, a Complex Adaptive System has three characteristics:

• Several heterogeneous agents, each making decisions about how to behave. These decisions change over time.
• The agents interact with each other.
• These decisions and interactions result in emergent behavior, which also changes over time.

As the aforementioned agents of product development interact, they make decisions, and behavior emerges.

For example, the business sets strategy and objectives that cause IT to make decisions affecting users, causing more interactions. Those user interactions may show a decline in engagement or a spike in conversion, causing the business or IT to react. A new technology (oh, hi, GenAI!) comes forth, and everyone races to be the first to use it…

And so on.

Like other systems, improving a single element of the CAS often doesn’t improve the whole. It usually shifts the burden somewhere else.

For example, moving to microservices may scale an offering, but it also brings complexity and pressure to IT. If you don’t investigate how this complexity will affect IT and other elements holistically, you’ll likely end up with new (often worse) problems.

Finally, emergent behavior can’t be predicted. Estimations can be made, and they are, but there’s only one truth about estimations: they’re wrong.

Here’s renowned software book author Ron Jeffries:

It’s based on an unrealistic list of requirements, using weak estimates, made at the moment of maximum ignorance, by people who are always optimistic about their own abilities. It has been squeezed down by managers who think they need to be tough, and sometimes it is just overridden by someone who has made a rash promise to someone higher up the food chain.

So, it all sounds pretty hopeless, doesn’t it? (Or, maybe, fantastic for us consultants. Digital Product Development is an unsolvable problem! We’ll never want for work! Woo-hoo!)

Of course, that’s not exactly true. It’s not hopeless. It just requires appropriate and often novel approaches.

Principles for Managing Complexity

According to Mark Schwartz, AWS Enterprise Strategist and author of many books on IT and software development, when dealing with a CAS:

• Optimize the whole
• Maximize cognitive diversity (i.e., get lots of perspectives)
• Create a set of Simple Rules you won’t deviate from, then let people do the work under those rules toward your goal

The task of CAS leaders isn’t to issue orders, but to put in place conditions that will cause independent actors within it to choose behaviors that will lead to the right outcomes. The enterprise leadership team sets the vision that, in effect, defines what delivering business value will mean.

In essence, Mark says leadership needs to define the vision and business value. He’s also saying Make it Easy to Do the Right Thing by setting guidelines, guardrails, and policy.

At Method, we’ve taken this systems approach to product development to heart (and mind) and turned it into what we call Modern Product.

Systems-Aware Product Development

We use approaches based on the principles of systems thinkers (like Meadows, Schwartz, and others) and combine them with decades of experience.

For example, there are several ways to optimize the whole, which Modern Product attacks with durable, cross-functional teams responsible for the end-to-end lifecycle of a product. Give the team a goal, set some guidelines, and let them work; align on the product vision.

Sounds simple, but there’s a reason there are so many stories and jokes about Business and IT being from different planets.

Digital product development complexity is a challenge. Having a strategy to make decisions and garner solid feedback can make all the difference.

For such a strategy, we can lean on another big brain, Dave Snowden. Snowden created a “sense-making” framework called Cynefin (ku-NEV-in) which breaks problems down into five contexts defined by their nature of cause and effect:

• Simple/Clear
  • Best practices happen here
  • Sense, categorize, and respond
• Complicated
  • Experts work here (lean is good here)
  • There’s a clear relationship between cause and effect
  • There are “known unknowns” and many right answers
  • Sense, analyze, and respond
• Complex
  • This is where product development usually lives (Agile)
  • There’s no clear relationship between cause and effect
  • There are “unknown unknowns” and no right answers
  • Probe, sense, respond (experiment, look for emergence)
  • We’ll come back to this
• Chaotic
  • The realm of the unknown and unknowable
  • Act to stabilize
  • Innovation can and does happen here (new ways of working, etc.)
  • Act and sense, try to move to Complex
• Disorder/Confusion
  • Throw everything at the wall and see what sticks

The Cynefin framework is used to classify issues and situations and provide a general approach to making progress. It’s a tool you can use to decide how to approach a situation.

Applying Cynefin to Product Development

Many people have classified software development into the Complex domain where emergence lives. Since we know a CAS has emergent behavior, we can take the probe-sense-respond approach to figure out what can nudge the behavior in the direction we want it to go.

Essentially, this boils down to creating hypotheses and experimenting to prove or disprove them.

Say you’re trying to increase sales on your site, and the team has a hypothesis that adding crypto as a payment method would draw more customers. Rather than build out all the flows, designs, services, user interfaces, services, infrastructure, partnerships, etc., execute some simple, inexpensive probes, like:

• Create a fake press release and share it with the team and internal stakeholders and sense feedback. If it’s positive…
• Do a 1–2 question informal survey and have it in a modal on your site or at the bottom of your user newsletter. If the responses are positive enough…
• Work up some design mockups or wireframes, share them with power users of your site, and get their feedback. If the feedback is good…
• Do a quick feasibility study of partners that are payment providers for crypto. If it’s feasible…
• Design and test the UX and higher-fidelity designs with the same/other users. If they like them…
• You get the idea.

The user side of your product is only one area that requires the probe-sense-respond approach. Others are:

• Idea/Feature intake and prioritization. Probes here sense if the input to the product team is high quality, the team understands its impact, and they’re working on the right things.
• Flow of work. Is work flowing efficiently through the team? Would a work-in-progress (WIP) probe be worth a try? Here, we’re continually trying to get better and faster. Can we probe dependency or cognitive load issues?
• Architecture. Can teams work on pieces of the service and application landscape without bottlenecks? Can we change the architecture easily? What fitness functions do we need?
• Deployment. Can we test features in production? Can we deploy daily? Rollback easily?
• Operations. Reliability probes and Service Level Indicators probe for how robust and reliable our services and applications are.

There’s always more that can be probed, but strategically, you need to ensure your probes are probing the right things. Monitoring these experiments leads to iteration, adaptation, and innovation, nudging the emergent behavior of your CAS/product toward your objectives.

In effect, Modern Product development aims to create a series of feedback loops throughout the product life cycle.

Final Thoughts

Once you see Product Development as a CAS and you accept that the probe-sense-respond approach is the only way to work, a set of practices emerge. The ability to experiment, generate feedback, learn from that feedback, and adapt the system to that feedback is the ultimate goal.

Our Modern Product approach can assess where you are today and help you create probes and development capabilities to help you continue to realize positive emergent behavior.