Over the last few articles in this series, I’ve looked at how different systems thinking approaches might be useful in Product Management. So far I’ve covered a broader introduction to Systems Thinking, Soft Systems Methodology, System Dynamics, Critical Systems Heuristics and the Viable System Model.
Across those articles I’ve looked at messy problem situations, feedback and behaviour, boundaries and power and organisational viability.
Strategic Options Development and Analysis, usually shortened to SODA, takes the series into a slightly different part of systems practice.
Product Management has plenty of ways to prioritise, we rank opportunities, score initiatives, compare cost and value and decide what should happen first. All of that happens after somebody has decided what is available to choose from.
What happens before we decide what should come first is particularly relevant, especially in government where Product Managers can become involved after quite a lot of shaping has already taken place. Something may already feature in a business case, have funding attached to it or have been discussed for long enough that it is becoming difficult to imagine doing something else.
There might still be several options on paper, but they are not necessarily equally open. SODA provides a way of looking further upstream, at how a messy strategic situation becomes a set of possible strategic responses in the first place.
Strategic Options Development and Analysis (SODA)
I first came across SODA while studying for my MSc in Systems Thinking in Practice. I have less practical experience with it than some of the other approaches in this series, so most of what I am drawing on comes from studying and applying it academically, then looking back at it through my experience as a Product Manager.
SODA comes from operational research and is particularly associated with Colin Eden and Fran Ackermann. It is intended to help individuals and groups structure difficult strategic situations, explore possible options in relation to what they are trying to achieve and work towards agreement about action.
It uses cognitive maps to represent how people understand a situation. Concepts are connected through causal relationships which can show how actions, issues and intermediate outcomes relate to wider aims. The language of the people involved is retained rather than immediately being translated into a single supposedly neutral description.
There is a similarity with some of the causal modelling I discussed in the System Dynamics article, but the purpose is different.
In System Dynamics I was interested in feedback, behaviour over time and the structures producing that behaviour. SODA uses causal relationships to represent reasoning about a strategic situation, i.e. what people think is happening, what matters and what might be done about it.
What interests me about SODA’s application is how reasoning is used to develop the strategic options themselves.
Applying SODA
Different groups around the same product or service will rarely understand the situation in exactly the same way. I covered this more directly when looking at Soft Systems Methodology. With SODA, what I find more interesting is what happens next.
Those different constructions can be represented, connected and used to explore goals, strategic issues and possible actions. Rather than treating the current option list as the starting point, the options can emerge through trying to understand the situation.
This is important because problem framing affects what looks like a reasonable response.
For example, if a backlog is principally described as a technology problem, technology replacement is likely to feature heavily in the proposed options. If the same backlog is also connected to policy choices, application quality, operating processes, organisational capacity or the way cases are routed, the options become different.
This does not necessarily make the decision easier and it may make the situation look more complicated for a while. But complexity that already exists does not disappear because we decide not to represent it.
For Product Management, this is where I think SODA could be applied. We spend a lot of time evaluating options and often pay less attention to whether the option set itself is any good.
Process
There are several ways SODA can be used and the full methodology goes further than I can cover here. For Product Managers trying to understand its basic logic, we can look at six broad activities.
1. Understand the different perspectives
This can involve individual interviews as well as facilitated group sessions.
The aim goes beyond gathering requirements. You are interested in how somebody understands the situation, what they believe is happening, what matters, what they are trying to achieve and what they think could change.
Their own language is useful because converting everything immediately into programme terminology can remove some of the differences that the process is trying to understand.
2. Build cognitive maps
Those perspectives can be represented using cognitive maps.
Concepts are connected to show how the person believes different things relate. Within SODA these relationships can form a means–ends structure, connecting possible actions and intermediate consequences to broader goals.
We are not primarily looking for reinforcing or balancing loops here, as described in the System Dynamics article. The purpose is to make reasoning about the strategic situation visible.
3. Bring perspectives together
Individual maps can then contribute to a wider group discussion. This is where connections, tensions and differences can become more apparent.
Something one part of the organisation describes as unavoidable may be seen elsewhere as a choice. Two groups may want the same outcome while having very different explanations for why it is not currently happening.
The result does not have to produce one perfectly agreed view of the situation, it needs to create enough shared understanding for a more useful strategic conversation.
4. Explore goals and strategic issues
The wider map helps expose what the organisation is actually trying to achieve and which issues appear significant in getting there.
Product teams are often given something which already looks like the problem to solve. Sometimes it is, but sometimes it is a symptom, a constraint or a proposed solution described as a problem.
SODA gives us somewhere to test those relationships before deciding what deserves intervention.
5. Develop possible options
This is the part I find most relevant to Product Management.
Possible actions are developed through exploring the situation rather than beginning with a fixed list of proposals. Some may deal with one particular issue, while others might affect several parts of the situation. Options can also be combined into portfolios rather than being treated as mutually exclusive alternatives.
It’s important to recognise the outcome of strategic thinking does not always need to be Option A, Option B or Option C.
The more credible strategy may involve elements of several interventions, sequenced differently or aimed at different parts of the problem.
The quality of later prioritisation depends partly on the quality of this option development.
6. Decide how to move forward
SODA is intended to support action rather than end with a diagram.
The maps form part of the conversation about goals, strategic issues and possible actions. Negotiation matters because people may continue to hold different interests and interpretations. They do not need to agree about everything, but they do need enough understanding to make decisions about what happens next.
Example
Consider a hypothetical government organisation responsible for assessing a growing volume of statutory applications. Its backlog has been increasing for several years and demand is expected to continue rising.
A proposed response has already started attracting attention:
We need a new case-management platform.
There are good reasons for this view, the current technology is old, staff work across several systems and some processes involve manual transfers of information.
It would be quite easy for the strategic conversation to become a comparison between replacing the platform, improving the existing platform or doing nothing. However, SODA would give us a reason to spend longer with the situation before settling on that option set.
Looking at the different stakeholders involved:
Caseworkers may describe how a substantial number of applications enter the organisation incomplete, creating repeated contact and additional checking.
Service teams might find that applicants do not understand what evidence they need to provide.
Policy colleagues may explain that low-risk and high-risk cases follow much the same process because of decisions about assurance.
Technology teams may point towards particular hand-offs between systems rather than the entire platform being the source of delay.
Finance may be concerned that additional staff are being recruited simply to prevent the backlog from growing faster.
None of these explanations means there isn’t a technology problem but they do produce a different set of strategic possibilities. A new platform remains an option but another might involve triaging applications differently according to risk. Other options could improve guidance and pre-application support to reduce incomplete submissions or review whether the same checks are necessary for every type of case.
There may even be an option that combines several of these interventions while replacing parts of the technology over a longer period.
This gives us something more interesting to evaluate, if the strategic discussion had begun with:
replace the platform
improve the platform
do nothing
then several plausible responses would never have entered the prioritisation exercise at all. The conclusion, however may still be that the organisation needs a new case-management platform.
In this case, SODA does not exist to produce the unexpected answer, its value here is that the organisation has developed that option in relation to a wider understanding of the situation and considered other combinations of action before committing to it.
This distinction is important because options have a habit of becoming harder to change over time.
When the options have already hardened
Unfortunately, Product Managers do not always arrive while these choices are still open. An option may already be in a business case and funding might have been agreed against it or a programme formed around delivery. So changing the option at this point means changing more than an idea.
I have started to think about it roughly like this:
Possible response → strategic option → preferred option → funded option → committed delivery
This is not part of SODA, it is just a way of describing something I have seen in product environments, particularly in government.
At the beginning of that sequence, rejecting an option might involve little more than changing some thinking. Later on, new evidence may mean revisiting a business case, moving funding, changing a programme plan or altering something that has already been communicated widely. The impact is much greater later on, for example procurement may bring contractual implications, teams may have been recruited or reorganised and delivery dates may depend on decisions already made.
Organisations need to make these commitments eventually. Strategy is not about keeping every possibility open forever. The more interesting question is what happened before the commitment and how much of the situation had been explored or whether substantially different responses were considered.
Was the preferred option preferred because it survived that exploration, or because it appeared early and gradually became harder to challenge?
This is one reason earlier involvement from Product Management can make a difference. If the product team is present while several responses are still realistic, it can bring user evidence, operational understanding, technical knowledge and product judgement into the development of those options.
If it arrives once an option has become a funded programme, the situation is different. Discovery can still change how something is implemented, expose assumptions and improve the resulting service. There may simply be much less room to question whether this was the right intervention in the first place.
I have seen projects described as being in discovery when in practice the most significant strategic decision was no longer open. This didn’t make the discovery pointless. But it does mean we should be clear about the kind of discovery taking place.
What this means for Product Management
Revisiting SODA has made me think less about whether Product Managers need another methodology and more about where we enter the strategic process.
When I inherit a set of options, I want to understand their history as well as their relative merits.
Where did they come from?
Who was involved in developing them?
What understanding of the situation led to them?
What was the organisation trying to achieve?
What else was considered?
Why did those possibilities disappear?
Some answers will reveal genuine constraints and other constraints may have accumulated through organisational commitment, e.g:
“The business case assumes it.”
“We’ve already decided.”
“The programme was funded to deliver this.”
“We promised it by the end of the year.”
While important, they do not all describe the same type of constraint. Understanding what can still move, what cannot and what it would take to change something is part of understanding the product environment.
I wouldn’t suggest arriving on an existing product and reopening every decision, as organisations need some stability if they are going to deliver anything. But there is value in knowing how the choices in front of us were formed rather than treating them as inevitable.
For me, one question follows from that: Are we developing strategic options, or are we deciding how to deliver an option that has already been chosen? Knowing this changes what Product Managers can influence and what kind of activity is useful next.
Considerations
SODA is much more than putting stakeholder views onto a Miro board.
How perspectives are elicited has an impact, cognitive maps have a particular structure and analysis, facilitation and negotiation are part of the methodology. The simplified process I have described is enough to explain why I find the approach interesting, but it is not a substitute for learning or practising SODA properly.
Making different perspectives visible also does not remove differences in power. A senior policy stakeholder, an operational lead and somebody who uses the service can all contribute useful perspectives without having anything close to equal influence over the eventual decision.
That connects back to Critical Systems Heuristics. Who participates, whose knowledge is considered legitimate and who is actually able to change a decision remain important questions.
There is also a practical limit to option development, at some point an organisation has to choose. The point I take from SODA is not that strategic decisions should remain permanently unsettled. It is that where there is still genuine uncertainty about what should be done, there is value in doing the exploration before one possible response gathers so much commitment that the remaining options exist largely on paper but are impractical to pursue.
Conclusion
Product Management has plenty of ways to decide between competing priorities.
SODA has made me think more about what happens before that: how an uncertain strategic situation becomes a set of possible actions and how quickly those possibilities can narrow once an organisation starts committing to them.
That feels particularly relevant in government, where policy, funding, business cases, procurement and programme structures can all affect how easy it is to revisit a decision. Eventually choices have to narrow. I would just rather Product Managers were involved while there was still something meaningful to shape.
Sometimes the useful point is not when somebody hands us a list of options to prioritise. It is earlier, while that list is still being formed.
Further reading:
For anyone wanting to go further into SODA itself, I would start with Fran Ackermann and Colin Eden’s Strategic Options Development and Analysis. Their chapter goes into the cognitive mapping, option development and negotiation behind the methodology in considerably more depth than I have attempted here.
The Government Office for Science also includes SODA in its An introductory systems thinking toolkit for civil servants. This is particularly useful if you are interested in how the approach relates to government and public-sector problems.
Systems Thinking for Product Managers (to be continued..)
So far in this series I have covered:
Soft Systems Methodology (SSM)
System Dynamics
Critical Systems Heuristics (CSH)
Viable System Model (VSM)
Strategic Options Development and Analysis (SODA)
There are still a few areas I want to explore, including Hard Systems Thinking and approaches to understanding systems failure.
The aim remains to look at what established systems thinking approaches can add to the way Product Managers understand and manage products in complex environments.
