17 Aug 2022
As a product organization scales, it is impacted by 2 types of ‘thinking’ - design thinking and systems thinking. While being complete opposites these collections of tools, procedures and methods of each type of approach impact the design of an organization's product management team as it grows from a startup to large scale organization.
Organizations are like living systems, as they scale, there are inherent scale factors that impact the way the “System” functions.
Being aware of these elements and how they impact product management function design and the operations of the business are key to escaping the feature factories and project based mindsets that are inherent in large systematic organizations and have created the problem of lack of innovation and stagnated growth.
In this article, we will look at the
The meaning of design thinking and service design
The meaning of systems thinking and systems design
The 2 key differences between them
The shift of methodology occurring across different sizes of organizations as it scales
The 4 factors that impact these across organizations
This article doesn’t cover how to use design and systems thinking as there is plenty of material available on those topics.
“Design thinking is an innovation method that enables the creation of new products and services – both for existing businesses and for start-ups.” – quote ref
While design thinking is an age-old concept it has evolved in digital product development and is now a comprehensive methodology that in many product teams, involves various iterative cycles of product discovery.
They do this to understand the users, test assumptions with the ultimate goal of defining the problems and create innovative prototypes.
This process allows product teams to test out potential solutions for the problems and more often than not identify new opportunities.
Service design is a part of the design thinking methodology where the product team plans and organizes people & processes in a business to improve the customer experiences of the customer.
In the software world, it involves looking at the various touch points of people, processes and tech in an organization and how the customer experience (CX) and user experience (UX) can be improved as a whole.
To think of it as a mini ecosystem, service design evolves connecting the dots from the business goals to customer experience and user experience on a product level.
Product teams build prototypes across their service design, test it out and then decide on building or ideating further and then building their product for ‘go to market’.
‘Systems thinking is a holistic approach to analysis that focuses on the way that a system's constituent parts interrelate and how systems work over time and within the context of larger systems.’ – quote ref
It is the – ‘what, why, when, where, and how’ of the system.
Systems thinking has evolved in digital product development and is used in many large-scale product organizations for their product management function and business design, where they have multiple products across their portfolio.
These organizations use systems thinking to plan and execute their portfolio strategy while ensuring they maintain some level of control and governance across all product teams.
Systems design is a part of systems thinking methodology where you design customer experiences, processes and products based on the dynamics of the ecosystem of the system, it looks at more complexities and dependencies in the system.
For instance, if you have multiple enterprise products in a portfolio, systems design allows you to connect the enterprise architecture of the system and build seamless experiences across the portfolio. It works on a strategic and tactical level holistically and allows for system wide changes.
In addition to this, when looking at a large-scale product organization, there are multiple dependencies and patterns that may emerge across this portfolio. This is where systems design comes in by allowing the organization to identify these patterns and build its processes and experiences around them in a lean manner and scale.
While they might sound and seem similar, the key difference is
Design thinking is iterative and linear focusing on the customer.
While system thinking is more complex focusing beyond the customer, for instance how to scale and maintain the systematic operations of the organization.
In the product world, design thinking applies at a product and experience level while, systems thinking applies on a portfolio and scaling level looking at longer term trends and partnerships.
The general pattern for product organizations is that as they scale, they move naturally from design thinking to systems thinking, however, this is an absolute approach rather than the balanced approach.
The 2 biggest challenges that larger organizations face are to:
maintain business sustainability and portfolio viability while growing
maintain business agility and empowered teams
Many organizations have tried to balance the use of both concepts but only a few global organizations and their product teams have been successful in utilizing both concepts in balance and at scale.
Generally, the teams end up working at a systematic level and this results in systematic dysfunction and breakdown of an organization into silos.
This involves solving the problem and/or finding opportunities which potentially disrupt an ecosystem.
Product teams in startups lean more towards the linear approach and thus favor design thinking.
While in growth mode, an organization is compelled to understand how to scale its processes, this is where systems thinking comes in. It allows an organization to identify patterns in problems and opportunities while evolving new products and experiences at a larger scale, potentially using the same people or improving efficiencies in processes
This involves looking at the holistic approach behind people, process and tech (including data!!).
By applying systems thinking an organization can map out its processes and people requirements that need to scale and then design its product experiences around it.
As an organization reaches a certain critical mass, the focus is on maintaining market share and continuing its operations with stability becomes a priority or occasionally meeting certain growth goals.
The key product challenge for many product leaders ends up being the ability to maintain a culture of innovation while being lean.
This involves avoiding bureaucracy and lengthy processes for operations to go smoothly while ensuring teams are empowered to move fast to make decisions and pivot quickly.
This ensures that teams are able to deploy changes as they require without causing significant business disruption or customer experience downtime.
When looking at systems thinking on larger product portfolios there is a fine balance between
empowerment, autonomy and innovation
governance, process and controls
This is where blending both design thinking and systems thinking comes in without too much duplication in process & people that would drive costs up and reduce bottom lines.
For large scale organizations - this one is key because you can break a portfolio down into products, experiences and platforms not to mention local vs global.
In a larger organization, you may have multiple products and experiences across these products. In this instance, service design doesn’t happen at the product level but rather at the system level.
For instance, how does google drive interact with google photos for customers? A customer’s experience with google photos (product 1), is impacted by that of the storage dependencies – the limit of their google drive (product 2). To unlock the experience of having unlimited photo storage, you will have to have the standard or premium google storage plans. (Assuming you don’t need more than 2 TB their upper tier limit!) Note: Google drive is now replaced by Google One.
In this instance, google must make decisions at a portfolio level and both the product teams must be in sync with each other otherwise all hell might break lose.
Alternatively, the product team might want to plan some changes because of something they learned using their design thinking processes in product discovery, but this may have an impact on a systematic level.
In this case, the product team must have a way of identifying and communicating dependencies and problems it may cause at a systematic level, this is where systems level maps and key architectural maps come in.
There might be organizations where the product portfolio and its experiences are not completely interrelated.
For instance, google pay and google drive storage are not interrelated and have no dependencies but a customer can use google pay to pay for their google one subscription plan.
In this instance, changes to google pay and google drive aren’t interrelated except for that one customer experience to use google pay as a payment option.
Meanwhile, in enterprise products such as ERPs or commerce platforms, you may have the elements of localization based on experiences required at the user level for regulatory compliance purposes such as tax rules or even cultural expectations of the local population.
In this case, the product teams would require a function design at the local level which then roll up to the global product level depending on how many features coexist and limitations on the systematic design of the product. (For instance – one codebase across global and local).
If there is one development team then the prioritization must happen at a system level and not the product level and this is where more systematic problems may arise when the team wants to pivot quickly.
There might be a decision to fork the codebases and have local and international ones. This has a direct impact on maintenance costs, development & deployment strategy and even customer experiences but may be unavoidable.
The key to remember during product management function design is that the systematic categorizations of the portfolio and its experiences will impact the team’s ability to innovate and deliver solutions.
There is a fine balance of accountability, responsibility and authority that needs to be addressed.
When it comes to people's approach to systems design and service design, an organization must look at the budget available to the skills required and ultimately how the organization's structure and reporting lines impact the capability and capacity to deliver solutions in a timely manner while being innovative.
For startups where funding is limited to the funds raised or funds remaining, there is a limited budget which results in constraints across the number of skilled people that can be hired.
This becomes a systematic constraint that needs to be understood with the requirements of building and going to market with the product.
These systematic constraints impact the product strategy and service design ultimately.
In large organizations, funding is generally not limited but there are processes that control spending to optimize revenue and measure success based on some sort of accounting practices for reporting on profitability. This also results in systematically breaking down product teams across “business units”, sometimes even smaller companies.
This is a bigger systematic constraint that impacts product management function design as a larger organization might find itself constrained by the accountability and governance of these teams.
The impacts here are direct to team size and impact the time to deliver solutions to the market.
When an organization looks at skills it needs to consider how to maintain innovation, build great customer experiences and drive revenue while maintaining operations and carrying out marketing activities to drive growth.
This results in the need for specialized skills as an organization grows from a startup mode to a larger company.
In addition to this, there may be a need to hire specialists in product management with certain subject matter expertise as the organization grows as it needs to adhere to industry-level competition and even regulatory compliance.
Further to this, there may be a split of the product teams into experience and platform teams where the platform teams tend to be more technical while the experience teams are focused on driving customer-centric thinking. A general observation here is that a clear difference between system and design thinking approaches can be seen when an organization reaches this level of complexity.
An example here can be noted about the fintech industry where most fintech product organizations prefer to hire subject matter experts (SME’s) who have expertise in financial products or banking as the learning curve can be too great for new entrants into the industry.
A larger organization generally has more decentralized teams based on its systematic constraints such as technical complexity, size of customer base and their capacity to service those customers. This results in a larger number of product managers at different levels.
An example of this is a couple of associate product managers, product managers and senior product managers reporting to a group product manager or product director who then reports to a head or vice president of product ultimately reporting to executive vice president or chief product officer.
In this case, each group product manager or product director may be in charge of a specific business unit or platform team.
Reporting lines and size of the teams directly impacts the systems design. Refer to the career pathway guide and product management function guide on digitalproductjobs.com under the section what the ideal % split between tactical and strategic responsibilities should be for more guidance.
When a product organization's design takes place, the analysis must be done across the balance between governance (controls & processes), empowering teams and being effective with lean processes.
Large organizations are bound by certain practices such as hiring external auditors and internal auditors. This takes place to maintain a view of profitability but also review the chances of fraudulent practices which may lead to brand damage or even increase the public liability insurance.
When money is involved, there is always a chance of funds being misused by incorrect spending – for instance building the incorrect features which add no value to the customer or bottom line of the business OR in some circumstances, abuse of these funds where fraudulent actors commit crimes.
Systems thinking allows an organization to review patterns of spend across product teams and assess for anomalies but also assign teams the right level of decision-making authority to pivot quickly and be innovative. This is where truly understanding how to maintain an approach of design thinking along with systems thinking comes in as it impacts how an organization should design its procedures, processes and controls.
An example out of my professional work experience is setting a limit for the time spent on ideation or research where funds are limited or the time to deliver is limited. I have also found that this may help focus on the bigger picture and avoid rabbit holes although it can limit the level of innovation, so discretion is best maintained here on a case-by-case basis.
There are many use cases for using OKRs vs not using OKRs, what is important to call out is that using OKRs has a systematic impact on larger portfolios – in many cases a positive impact!
However, if used wrong OKRs can be significantly decremental.
It is important to note that not every organization will have the maturity and alignment in product development to effectively utilize the OKR framework.
One of the largest factors that impacts all of the above 3 elements is technology, however it should not be set as number one, as customer, people and process should come before technology.
There are 2 main types of technologies that impact systematic function of an organization – the technology architecture and infrastructure and the product management stack.
As an organization grows its investment into technology, platforms and software products grows significantly. Large organizations tend to have older legacy systems due to the time they have spent operating and the inherent nature of monolithic architectures of the past. This has a significant impact on innovation and the ability to change.
When designing the product architecture in larger organizations there is a systematic impact of existing architecture that needs to be considered. This generally has an impact on how teams operate from deploying code to maintaining which ultimately drives the capacity requirements for product teams at a systems level.
These inherent problems do not exist for smaller organizations and startups as the number of dependencies is limited which ultimately allows them to utilize design thinking concepts more freely during the product development lifecycle.
The product management team is at the heart and soul of an organization from the business teams such as ‘sales, operations, customer service to marketing’ AND the research and development teams such as ‘engineering, design and quality assurance’ with this comes the need of various tools to help communicate and organize the day-to-day activities.
The requirement for the use of these tools tends to grow as an organization scale and its processes become more complex but also access to data.
Examples of these tools are business modelling, OKR management, idea validation boards, prioritization tools, road mapping tools, release planning documentation, release note and change log tracking, persona mapping, engagement analytics, A/B test management, session replay, user guides onboarding documentation, feature flagging manager, user testing and feedback management system, tag management, design and prototyping tools to most importantly which almost every product team uses the collaboration, workshop management to task management tools.
Organizations are like living systems, as they scale, there are inherent scale factors that impact the way the “System” functions.
Being aware of these elements and how they impact function design and operation is key to escaping the feature factories that are inherent as an organization scales.
21 Sep 2023Your Guide to Backlog: Product vs. Sprint Backlog