Simon Copsey

30 July 2020

Why Product Thinking Is the Next Evolution of DevOps: 5 Practical Steps to Getting Started

In this article we will together answer some key questions around product thinking and share some thinking tools and actionable steps to help you consider when and how to apply Product Thinking in your organisation.

We’ll explore:

What is Product Thinking, and why is it important today more than ever?
How does it compare to the traditional IT project approach?
Why is it a natural evolution of DevOps?
What are the benefits, and how do we get started?

What Is Product Thinking?

Product Thinking is a way of working that places a relentless focus on ensuring that the end product always remains relevant in solving the customer’s problem, even as the world changes.

This stands in contrast to project-based ways of working that focus on defining lists of requirements upfront and then fulfilling these, regardless of whether or not they remain relevant throughout the duration of the project.

Product Thinking is Required to Adapt to a Volatile World

The world is becoming increasingly volatile, uncertain, complex and ambiguous (VUCA). Information is at our fingertips. Communication travels at the speed of light. Any local event can have global repercussions. The global pandemic has been one example, but so has the ways in which the world has rallied together to fight back.

Against this backdrop of an increasingly VUCA world, our traditional organisational approaches - such as centralised budgeting and planning - are becoming less effective. It is not possible to predict where the world will be in 3, 6 or 12 months, let alone commit the organisation to a budget and a plan for that period.

In order to successfully navigate this new world, organisations need to consider smaller, distributed planning cycles.

Let’s illustrate why this is with a challenge that mirrors an organisation trying to succeed in this VUCA world:

Challenge: As an organisation, our goal is to run as quickly as possible from one end of a long dark hallway without injury. There is only one source of light - an overhead bulb that flashes on and off - that can be used to orientate ourselves in relation to our surroundings.

Scenario 1 Minimally VUCA: The corridor is empty and the bulb flashes once a minute.

Solution: This is quite straight-forward: the hallway is straight, and the floor flat. We can plan our journey when the light is on, and continue moving even when the light is off.

Scenario 2 Moderately VUCA: The corridor is now scattered with a few objects - perhaps lego bricks that are extremely painful to bare feet.

Solution: The challenge remains fairly straightforward, but we must forward-plan our journey more carefully when the light is on.

Scenario 3 Highly VUCA: The scattered objects are now continuously moving in different directions along the floor, and new objects are being thrown in from doorways, even when the light is off.

Solution: This is difficult: the landscape is changing so significantly between the flashes of light that forward-planning more than just a few steps is impossible.

So can we still be effective in highly VUCA conditions? Yes, but we must change the rules of the game. We need more frequent flashes of light to allow us to continuously sense and then adapt our path in tandem with the constantly evolving landscape.

Our approach must change from long-term prediction and planning to short-term adaptation and agility.

Those pieces of work that are exposed to highly VUCA conditions may benefit from having less reliance on a centralised budgeting and planning cycle, and instead adopting a Product Thinking approach.

Comparing Traditional and Product Thinking Approaches

Imagine you work for a major international bank. You have identified small business customers as an emerging segment. The existing business account product does not seem to be appealing to these smaller businesses, and you want to ensure you quickly grow the customer base in this area over the next six months to remain ahead of competitors.

Product Thinking may help here given the problem relates to highly VUCA conditions, where there is no obvious ‘best’ solution. Let’s therefore compare how leadership might approach the problem as a traditional IT project, versus using Product Thinking:

Traditional IT Project Approach

Product Thinking Approach

Metaphor (credit to Henrik Kniberg):

A cannon-ball, which is predictive: relying on correct upfront aiming and a static landscape.

A heat-seeking missile, which is adaptive: autonomously adapting its path in an evolving landscape to maximise impact.

Suited to:

Tackling problems that involve lower uncertainty and volatility and where there is a clearer way forward, e.g.: upgrading switches in a data centre.

Tackling problems that involve higher uncertainty and volatility, where the path forward must evolve as we learn more, e.g.: launching a new customer-facing product or feature.

Leadership steps:

Form a short-lived project team to deliver the project, before being subsequently disbanded.
Provide a destination and route by defining the IT budget and agreeing upfront the roadmap for a 6-month project. This project will begin only once budget and high-level requirements have agreed by leadership.
Measure success in terms of predictability: the team is seen as successful if they deliver the requirements defined upfront on time and to budget.
Form a long-lasting ‘current accounts’ product team with access to the customer, with a focus on iteratively delivering against the current and any future goals that may relate to current accounts.
Provide only a destination in the form of a clear goal (e.g.: “double the adoption and retention of UK small business customers within 6 months”), letting the product team find the best route based on what does and doesn’t work.
Measure success in terms of true impact against the goal.

Why Product Thinking Is an Evolution of DevOps

Traditional IT projects have tended to operate in more stable, minimally-VUCA conditions. In these conditions it remained effective to form short-lived project teams that deliver requirements defined upfront.

However, organisations are increasingly shifting their focus to delivering customer-centric software which inherently requires teams to operate in highly VUCA conditions.

AKA Product thinking! It gives the ability for customer-centric teams to continuously sense and adapt their path to fit the evolving landscape and thereby remain effective in highly VUCA conditions.

Product Thinking enables teams to be able to:

Sense the landscape through customer interaction, allowing the team to understand the customer and their problem to be solved, and to quickly and cheaply experiment with different solutions whilst observing how the customer responds.
Adapt their route by defining a clear goal (outcomes) for the product team, and encouraging the team to choose how to achieve them (outputs). Success is measured in terms of impact against the goal, rather than the degree to which pre-defined requirements are delivered on time and to budget.
Grow their ability by assembling enduring long-lived ‘product’ teams, versus short-lived ‘project’ teams - allowing the team to accumulate a shared understanding of the business domain and customer, and thereby continually grow their effectiveness.

The team will often need to be cross-functional to allow them to both design and build a product. They will wear their ‘design hats’ to sense how customers are actually interacting with the product versus their original expectations, and their ‘developer hats’ to adapt the product roadmap and thereby take them further toward achieving their goal.

Whilst short-lived project teams typically worked using a DevOps methodology to help them increase the efficiency of software delivery (i.e. run down the corridor faster), this must now be evolved with Product Thinking to ensure those teams can be effective (i.e. continuously sense and adapt their path in relation to the evolving landscape around them).

Product Thinking Is an Impact-Seeking Missile for Achieving Crucial Goals

Whilst DevOps enables teams to move fast, Product Thinking enables them to move along the best route toward their goal, where the ‘best’ route is constantly evolving as the landscape changes.

The reason we suggest Product Thinking is an evolution of DevOps, is that teams first need to be moving fast before they have the need - and ability - to change course quickly. This can be in the form of short feedback loops with customers through releasing small changes often, coupled with the local decision-making ability to allow the team to quickly change course.

“...the organization that can most effectively accumulate new knowledge and leverage that insight to make better decisions wins” — Barry O’Reilly

We observe our clients working through this evolutionary path.

They may first adopt a DevOps approach - giving them the ability to quickly release small changes - whilst still directing delivery against a predefined roadmap. Whilst DevOps adoption has increased their agility, the true benefits are realised when they pair it with a Product Thinking approach, disengaging from the predefined roadmap, and sensing-and-adapting their route based on customer feedback from each of their smaller releases.

They are then ‘heat-seeking’ the high-impact results.

Crucial Business Outcomes of Product Thinking in a VUCA World

Leveraging Product Thinking in highly VUCA conditions yields benefits for the organisation, customer and individual, including:

Organisation

Reduce Lead Time: Teams take time to become effective. By using teams as the indivisible unit (vs. the individual), effectiveness is brought forward.
Reduce Key-Person Risk: A product team’s domain knowledge (e.g.: current accounts) will grow over time, meaning they can quickly graduate onto tackling related goals once they have achieved their current goal.
Reduce Waste: By releasing small changes often and measuring the impact, the product team can learn quickly and change course rapidly if they are not having the expected impact on adoption and retention.
Stabilise Technical Debt: Long-lasting teams are their own customer. If they create technical debt, it becomes harder for them to add new functionality in the future. If they reduce technical debt, it becomes easier for them to add new functionality in the future. This is another important feedback loop that product teams can use to inform their chosen path.

Customer

Delight Customers: Short feedback loops with the customer means the product team is well-placed to discover and develop the features that will have the greatest impact on the goal.

Employee

Increase Staff Motivation: Product Thinking provides individuals with greater autonomy, allowing them to choose how to reach their goal. Working as part of a cross-functional team also enables the ‘cross-bleed’ of skills across disciplines, furthering people's space to learn on the job. These alone are two of the three tenants of motivation: autonomy, mastery and purpose.

Product Thinking Case Study: When the Project Approach Has Been Imperfect

We observed that one of our clients had a strong strategic focus on minimising short-term costs. When this was combined with the traditional IT project approach of short-lived project teams that must deliver against a predetermined scope and deadline, it encouraged those teams to reduce quality to meet deadlines. This led to growing technical debt over time, and meant future projects were increasingly complex and therefore increasingly expensive to deliver.

One other client had a natural focus on maximising the utilisation of each individual. This meant each person was often spread across multiple projects, lengthening the time it took to deliver projects. The delayed release of projects slowed feedback from customers - the flashing light - meaning the projects were likely to be less relevant by the time they reached customers. This had the net impact of increasing - versus reducing - costs.

By optimising for reduced cycle time, product teams shorten feedback loops with their customers and thereby constantly sense and adapt their roadmap.

How to Adopt Product Thinking in Incremental Steps

Every organisation is different, and therefore every adoption route will vary. Here are five steps to help you get started in designing your own route for adopting product thinking.

These steps were designed this way to reduce the number and impact of irreversible (“type 1”) decisions (particularly those relating to people) through transparency and staff engagement (“fair process”). Each step is collaborative and brings forward feedback, allowing the onward path to adoption to be adapted as the organisational landscape is better understood:

1) Frame the Business Challenge
2) Understand the Current Reality
3) Choose a Starting Point
4) Get Started, Surfacing Obstacles Early and Often
5) Disperse Learnings and Broaden Reach

Step 1: Frame the Business Challenge

Why do we want to adopt Product Thinking? What is the business challenge we expect Product Thinking to help overcome, and how will we know if we’ve been successful? For example, we may want to reduce developer rework by 30% so we can deliver more features our customers need faster, and increase overall customer retention. We recognise some aspects of success will not be measurable.
What must we not impact? What do we hold dear and want to monitor as we move forward? For example, we may not want to reduce rework at the cost of staff morale, technical debt or customer satisfaction.

Tools to consider: Objectives and Key Results

Step 2: Understand the Current Reality

Where are we now? If we want Product Thinking to generate impact against the business challenge, we need to understand the current baseline for how we deliver projects today. In this case it may involve baselining rework, staff morale, technical debt and customer satisfaction.
What are the key obstacles? As we measure where we are today, we will naturally build insights into the biggest obstacles preventing us from overcoming the business challenge - and the reasons behind them.
How do we design a product team in a way that overcomes those obstacles?What is the shape of the team needed to make inroads on their goal, in a way that tackles the overall business challenge? For example, if we currently have individual product teams but want to unify the customer experience across all products, we may consider component-based teams. There is no right way of choosing a team shape - each shape will optimise performance against some measures, and reduce performance against others. We must simply be conscious in our decisions, and continuously iterate and improve our design.

Tools to consider: Value Stream Mapping, Current Reality Tree, Domain-Driven Design, Team Interaction Models (Team Topologies)

Step 3: Choose a Starting Point

What is a relevant and achievable goal for the product team? For example, “double the adoption and retention of UK small business customers within 6 months”. This goal exists in highly VUCA conditions, and therefore would be well-suited to a product team.
Who should we invite into the product team? What do the role descriptions look like - what domain knowledge is needed, where would this take an individual’s career, and what would be their new reporting line? Who can we interview internally to see if they would like this career change, knowing it will initially be a bumpy ride?
Which senior leaders need to be ready to unblock issues and change policies? We will need senior leaders to provide temporary remedies (e.g.: change an individuals’ manager, grant funding). If these remedies prove successful, we may consider their help in cementing the changes more widely (change department structure, augment budgeting approach).
Do we have ‘just enough’ to get started? What other knowledge, people, assets, access does the team feel must be in place before launching the team? What can come later?

Tools to consider: Objectives and Key Results, Pirate Metrics, Sales Funnel Analysis

Step 4: Get Started, Surfacing Obstacles Early and Often

What obstacles are our product team hitting? We will need to help the team continually surface these obstacles and particularly the causes behind them. We will work with senior leaders to mobilise temporary remedies. If successful, we may consider cementing these remedies as small changes across the organisation.
How are we doing? Are we making progress against our business challenge and product team goal, whilst not negatively impacting the measures we hold dear?
Is there anything we want to try doing differently, without changing too much at once?

Tools to consider: Retrospectives, 5 Whys

Step 5: Disperse Learnings and Broaden Reach

How might we engage the wider organisation in the change journey? How do we share the vision and strategy, and allow it to be collectively owned by staff? How do we ensure other teams feel engaged and able to contribute to the journey, and not hold an “us versus them” sentiment?
How do we build a learning culture? What has the team learnt in terms of technology and in terms of overcoming obstacles? Where are they struggling now? How do we build structures that allow these learnings to naturally dissipate, and common challenges to surfaced and tackled together?

Tools: Dojos, Showcases, World Cafes, Communities

Key Considerations on Your Journey to Product Thinking

As your organisation progresses through its own journey of adopting Product Thinking, you may begin to find you consider the below enabling conditions.

Continuous process improvement, to ensure that obstacles to effective and efficient software delivery are continually identified and removed.
Access to the customer, to enable shorter feedback loops that (in)validate assumptions about customers early, limiting the rework needed to change direction.
Tools and practices that enable iterative software delivery, allowing teams to little and often put a solution in front of the customer for feedback - this is the frequent flashes of light to allow teams to continuously sense and then adapt to our path in tandem with the constantly evolving landscape (e.g. microservices, continuous delivery pipelines).
Access to continuous funding, as product teams must receive continuous investment as they work towards achieving their goal. This makes any centralised budgeting decisions simpler, and less dependent on upfront analysis.
Staff growth and support, to enable staff to have access to learn and integrate new thinking tools as they operate in this different paradigm.
Enable decision making at the edge by ensuring context flows across teams, enabling product teams to make informed local decisions that align and benefit the wider organisation (e.g.: availability of reusable components via communities of practice, shifting organisational vision from leadership, changes in brand requirements from marketing).
Supportive measures of success, ensuring any ways in which teams and staff are measured - formally or informally, encourage adoption of Product Thinking (e.g.: leadership sends a consistent message to show it is safe to fail in the pursuit of finding the best route to achieving their goal).

Summary

Product Thinking is a reorientation of how IT work is delivered in organisations. It focuses on unlocking effectiveness in those teams operating in highly volatile, uncertain, complex and ambiguous (VUCA) conditions, enabling them to follow an adaptive (heat-seeking) path that evolves alongside the changing landscape. This is enabled in teams by providing conditions in which they can sense the landscape, adapt their route and grow their ability.

Leveraging Product Thinking in highly VUCA conditions yields benefits for the organisation, customer and individual, including: reduced lead time, key-person risk, waste and increasingly staff motivation and delighted customers.

The reason we suggest Product Thinking is an evolution of DevOps, is that teams first need to be moving fast before they have the need - and ability - to change course quickly. DevOps is a tool to aid in that initial acceleration.

When considering an adoption route, our focus is on reducing the number and impact of irreversible decisions (particularly those relating to our people) through transparency and staff engagement. Each step is collaborative and brings forward feedback, allowing the onward adoption route to be adapted as the organisational landscape is better understood.

Key steps that may help you design an approach that is correct for your organisation include: Frame the business challenge, understand the current reality, choose a starting point, get started and surface obstacles early and often, disperse learnings.

If you're receiving diminishing returns for your DevOps adoption, is Product Thinking helpful for your situation? I’d be happy to hear about your experiences.