Systems Thinking for Product Managers: Soft Systems Methodology (SSM)
How applying Soft Systems Methodology to Product Management can help you understand complex socially rooted problems.
In a previous article, I outlined some of the basic principles of Systems Thinking and how it can be used in Product Management.
Soft Systems Methodology
In this article, we’ll focus on Soft Systems Methodology (SSM), a Systems Thinking method. Developed by Peter Checkland in the early 1970s, SSM is a way to explore complex, socially-rooted problems by focusing on understanding problems over applying immediate solutions. It's especially good for:
Unclear or ill-structured problems (e.g. "improve the user experience of social services").
Systems involving multiple stakeholders with different worldviews.
Designing interventions, not just systems.
It was developed as a response to the limitations of the ‘Hard Systems Methodology’ which aims to solve clearly defined technical problems with optimal solutions, while SSM addresses messy, human-centred problems by exploring multiple perspectives to reach shared understanding and improvement.
In the context of Product Management, SSM can help tackle complex, ambiguous problems by structuring stakeholder perspectives, clarifying requirements, and shaping user-centred solutions through iterative, systemic thinking rather than rigid processes.
For example, if tasked to improve an online service for citizens applying for housing benefits. Stakeholders (citizens, council staff, policymakers, IT teams) may have conflicting views about what "improvement" means. Using SSM would involve creating "rich pictures" to map different perspectives, identifying root definitions of key activities (e.g., what success looks like for each group), and modeling different service designs. This would help to uncover hidden assumptions, align stakeholders on a shared vision and prioritise features that address the messy, real-world needs of users.
Process
SSM is applied in stages:
Problem situation exploration - This involves exploring and understing the real-world situation without rushing to a solution. Gathering perspectives from stakeholders and identifying the problem from different viewpoints. Creating one or more 'Rich Pictures'. A visual representation of the situation. This helps capture the complexity and relationships within the system.
Express the problem - Defining the problem in terms of what you want to achieve and creating a ‘Root definition’. The root definition includes a clear description of the system (what it does), the actors involved (who is part of the system), and the aims (the desired outcome or purpose). Commonly this starts by using the CATWOE acronym to form the root definition, which involves applying the PQR formula.
Build conceptual models - Developing conceptual models of the systems based on the defined root definition. These models are simplified representations of how the system should ideally operate and show activities required to achieve the transformation.
Compare models with reality - Compare the conceptual models with the real-world situation (the rich pictures). Looking for discrepancies, gaps, or areas where the real-world system doesn’t align with the ideal model. Engaging with stakeholders to explore the differences between the model and reality, understanding perspectives.
Identifying improvements - Identifying potential improvements or changes to the system. Considering what could be done differently to achieve the desired outcomes and how stakeholder needs and perspectives influence potential solutions.
Design and implement changes - Based on the analysis, designing interventions or changes to improve the system. Ensuring that the interventions align with the stakeholder perspectives and system’s goals. Working with stakeholders to plan and implement these changes incrementally, revisiting the system to ensure ongoing alignment with the original aims.
Reflect on the process - After implementing the changes, its important to review the entire process. Reflect on what worked, what didn’t, and how the system can continue to evolve. SSM is iterative, so keep refining the system based on feedback.
Example
Many of the steps in the process are self-explanatory, however, to guide you through the process I have outlined an example that shows the first two stages, creating a Rich Picture and Root Definition.
Situation
You are a Product Manager in a digital company, tasked with redesigning a public healthcare service portal. The project involves multiple stakeholders: healthcare administrators, patients, doctors, IT staff, accessibility experts, and legal teams. There are complex processes and regulations that need to be visualised, such as data privacy (GDPR), appointment booking, prescription refills, and insurance verification.
Creating the Rich picture
You can follow this guide to show you how to create a Rich Picture. This example was created by AI using the information we know about the situation and problem. In a real project scenario, this would be created collaboratively with stakeholders to draw out richer, more in-depth insight. They are often created in person and using traditional pen and paper methods.
Insights
From the diagram, we can start to better understand interconnections. The Rich Picture helps us to see:
Multiple pain-points associated with login, authentication.
The people involved and how they engage within the system.
The way in which the technology interconnects, e.g. Appointments and Healthcare portal having dependency on verification.
Importance of UX, WCAG and design.
Creating a root definition
Before creating a root definition, we’ll undertake CATWOE analysis. You can follow this guide to show you how to do this.
CATWOE analysis
C – Customers (Who are the beneficiaries or victims of the system?)
Patients: Need secure, accessible, and easy-to-use services for appointments, records, and prescriptions.
Doctors and clinicians: Require quick, accurate access to patient info and streamlined workflows.
Healthcare administrators: Benefit from efficient service delivery and reduced system overhead.
A – Actors (Who performs the activities in the system?)
IT staff: Develop, maintain, and support the portal.
Product and delivery team: Manage development and ensure stakeholder alignment.
Doctors and healthcare providers: Use the system for care delivery.
Support staff: Assist patients with portal use and handle manual input when needed.
T – Transformation Process (What is the core process that turns inputs into outputs?)
Current state: Fragmented, difficult-to-use systems with inconsistent experiences and unclear compliance.
Desired state: A unified, secure, compliant, accessible portal that streamlines healthcare services and improves user satisfaction.
W – Worldview (What makes this system meaningful?)
A modern public healthcare portal must put users first (especially vulnerable patients), protect data privacy, and support healthcare delivery efficiency while meeting strict regulatory requirements (e.g., GDPR).
O – Owner (Who can make or break the system?)
Government health department / NHS digital leadership: Own funding, strategic decisions, and compliance oversight.
Legal and policy authorities: Can enforce shutdowns or mandate features.
E – Environmental Constraints (What external limitations must be considered?)
Legal requirements: GDPR, NHS policies.
Technical limitations: Legacy system integrations, funding cycles, cybersecurity risks.
Accessibility standards: WCAG 2.1 compliance.
Public expectations: Trust, transparency, and ease of use.
Then we use the outputs from the CATWOE analysis to form the root definition, using Owners (O) and Actors (A) from CATWOE and applying the PQR formula (do P (what), by Q (how), in order to help achieve R (why)).
Root Definition: A public health authority-owned system (O), operated by IT teams and healthcare professionals (A), that provides a secure, accessible, and user-friendly digital portal (P), by redesigning existing fragmented services and processes (Q), to enable patients, doctors, and administrators to manage healthcare interactions effectively while ensuring compliance with GDPR, HIPAA, and accessibility standards (R).
The next step would be to build conceptual models based on this root definition, they should show the ideal state and what the system should do and the activities required to achieve the transformation. Once created, these can be compared with the actual state, as identified through the Rich Picture.
Case studies and further examples
These examples show SSM in use to tackle complex problems. The UK Public sector has a case study library where you can find SSM and other Systems Thinking case studies. These examples show the diversity of its usage:
Local government council – information management & technology strategy - A UK metropolitan borough council used SSM to develop and implement an Information Management and Technology (IM&T) strategy during a period of significant organisational change. SSM facilitated stakeholder engagement, helping to identify contributions to change and challenges in using SSM to facilitate cultural change.
Evaluation of a digital initiative in New Zealand schools - SSM was used to evaluate "Generation XP," a digital initiative aimed at bridging the digital divide in New Zealand schools. The methodology provided insights into stakeholder experiences and the effectiveness of the program.
Integration of healthcare and long-term care in Japan - SSM was used to facilitate the integration of healthcare and long-term care delivery systems in Japan. The approach helped visualise differences and build a community-based integrated care system.
National Health Service (NHS) – Mental Health Trust IT systems - Used to analyse the implementation of electronic systems within a Mental Health Trust, focusing on legal and ethical implications. This highlighted the importance of stakeholder engagement in system design.
Department for Levelling Up, Housing and Communities (DLUHC) – Tackling multiple disadvantage. Applied to understand complex social issues involving multiple disadvantages by mapping systemic factors and stakeholder interactions. This enhanced the design of integrated support services.
Conclusion
Product Managers can be faced with challenging, ambiguous and messy problems that involve multiple processes, people and differing perspectives. Our aim is to ensure that what is implemented has the greatest value to stakeholders, including users. Soft Systems Methodology is an approach that:
Clarifies ambiguous problems: by examining how different stakeholders perceive the problem and the system. This leads to a better understanding of the real challenges.
Improves stakeholder engagement: by focusing on multiple worldviews, it ensures that diverse stakeholder perspectives are heard and considered. This helps Product Managers align teams, users, executives, and other stakeholders around product decisions.
Enables better decision making: by creating conceptual models that explore the ideal state, Product Managers can use these to compare with current reality, which helps to guide strategic decisions and prioritise changes.
Improves iterative improvement: It promotes continuous learning about the system as changes are made, complementing Agile product management.
Reduces risk: By systematically surfacing assumptions, values, and goals, it reduces the risk of building products or features that fail to meet user needs or business objectives due to miscommunication or misunderstood expectations.
Bridges technical-business gap: Enabling Product Managers to mediate between technical teams and business stakeholders by focusing on "what" the system should do rather than jumping straight into "how" it should be implemented.
Further reading
Systems Thinking for Product Managers (to be continued..)
This is the second article in a series I'll release within Product Breaks, focusing on Systems Thinking methodologies and Product Management. Read the introduction and article on Systems Dynamics. Further articles will aim to cover the topics:
Critical Systems Heuristics (CSH)
Viable System Model (VSM)
Strategic Options Development and Analysis (SODA)
 | A guest post by
|