Empower your product teams for the best results
- Service Technology and engineering
- Date 25 November 2020
The shift to product thinking might be uncomfortable, but it delivers successful products that serve user needs.
When I initially joined the product world, I was baffled by many of the terms bandied around, a notable one being ‘product thinking’. What was it? Was I doing it? Should I be?
I’ve since come to form my own understanding of product thinking as the concept of moving beyond the part to look at the whole. This applies to the product – thinking beyond a distinct feature to the product as a whole, throughout its lifecycle – and also to the organisation itself, expanding out from the product team to how the organisation in its entirety enables and empowers the product function, from funding cycles to organisational design.
A shift to product thinking
Many large organisations acknowledge some form of ‘product’ role along with their developers and designers, but it’s not a given that having those (often hardworking, smart) people in place translates to product thinking being adopted by the organisation.
My colleague Paul Murray describes the “agile ceiling” he often sees at client organisations; where the product team are fulfilling their roles as best they can, but can’t reach their potential because the organisation is placing limits on their autonomy and impact.
So how might we lift that ceiling? Product thinking is tightly tied to where control sits within the organisation, and so practising true product thinking requires us to go to the heart of how that organisation operates. We need to look at how teams are designed, how trust is transferred, and how work is funded.
How teams are designed
In many of the organisations we work with, control does not sit with a product team. Instead, there is a combination of project teams and business-as-usual support teams. A feature or ‘product’ is designed, scoped and costed, perhaps in a change department, and then a project team is spun up to build it. Once it’s finished, it gets passed over to BAU teams in an ‘acceptance into service’ process.
This approach to organisational design is fairly antithetical to product thinking. True product teams are 'empowered to figure out the best way to solve the problems they’ve been asked to solve'; rather than being 'given output to deliver'. Where projects are scoped elsewhere and land on product managers’ to do lists, the product manager ends up chivvying things along, rather than adding value.
Enabling a product team to be involved in, and preferably own, the design and scoping of new features or products opens up opportunities. It’s likely that a consistent product team will be able to:
- Choose tools and technology that fit well within the existing ecosystem, and with which the team can work quickly
- Identify where value can be added beyond the original scope, by looping in an outstanding piece of work, or clearing some technical debt
- Strengthen the user voice — and therefore the chances of success – in the product’s design; are we potentially building X when users need Y?
- Understand the implications of this build — how much it’ll cost to maintain, how extensible it might be, what could be saved for a future iteration and what’s worth investing in upfront to save time later — and make sound decisions
How trust is transferred
Our recent work at the Food Standards Agency (FSA) made the case for product thinking, giving digital product teams ownership and control over how products are built and maintained.
By looking collectively at all the Discoveries we had carried out over the year, we were able to highlight consistent themes the organisation was dealing with, from technical challenges to common user needs. This enabled us to recommend product thinking to the organisation as a way of providing cohesion between individual projects, and ensuring these issues were addressed.
We’re now working with the FSA to improve how to get supplier teams up and running quickly and in a cohesive toolset, from the style library to the deployment pipeline. This will better equip the FSA team to own the ecosystem the products operate in, and iterate those products themselves when suppliers move on. Moving the organisation towards product thinking has established the idea that the digital team can own the evolution of how products are built and maintained in the Agency.
The idea of granting a product team relative autonomy in this way can, and does, make people (especially leadership) uncomfortable. While some of this comes from the inevitable friction of making change, there are some specific factors that exacerbate the discomfort.
Firstly, the product owner role is often misallocated to someone too junior and a ‘doer’ from the delivery function, rather than a decision maker, which reduces the likelihood of the organisation trusting them with strategic decisions.
We see far more success in the transition when the individuals selected already have a good sphere of influence and trust — or at least authority — among their colleagues.
Secondly, we often find that strategic objectives have not been defined or communicated across the organisation. This means that there is no shared filter through which to make decisions and therefore disagreement springs up around what should be prioritised and why.
Sharing what the organisation is aiming to achieve in that quarter or year — and making it clear how each area can feed into that — means that the direction is already agreed, so the conversation can focus on the ‘how’ and not the ‘why’.
Finally, the product role is frequently misunderstood across the organisation. Where other teams see the individual as ‘blocking’ the route to development resources they could previously access directly, there is inevitably dissent.
It, therefore, needs to be made clear why the product role is being introduced, and the benefits that its arrival will bring to all teams as well as to the business as a whole.
Alongside this, product owners need to be given explicit and vocal authorisation from the senior team, and they need to feel supported. At HM Land Registry, we are helping to develop a community of practice for the product team with this aim in mind.
How work is funded
A parallel challenge to product thinking comes in the shape of funding. Many of our clients fund work in projects of the type we’ve talked about. A block of money is assigned to build something, often without the involvement of those who will be working on the build. Finance departments 'define important processes like business cases and spending reviews, quietly shaping the questions every department must ask themselves when making investment decisions.' As a result, the locus of control here again sits outside of the product team.
Product thinking requires an organisation to fund product teams, rather than one off builds.
This might, initially, look expensive, and not fit with the normal way of doing things. But there are cost savings to be made through this approach. As the Defra Digital team notes, stable teams deliver better work — they’re already set up with the tools and knowledge; they’re better able to compound value as they build and to hold suppliers to account for their contributing work.
Introducing product thinking to an organisation is far from a comfortable ride — it requires a big shift in control, processes and people — but it’s one we think is well worth it. Product thinking is essentially a set of enablers for excellent product management, and therefore for a successful product that serves its users.
When we work with an organisation to make this shift, we bring with us an evidence base of the success we’ve seen at other, comparable organisations. This can fuel business cases, and also enable us to pre-empt when and where we’re likely to see resistance.
That familiarity turns a ‘blind’ path into one which will be far more likely to continue in the direction of product thinking, ensuring product work aligns with an organisation's strategic objectives, providing a cohesive thread between different parts of the organisation, and delivering high quality results much more quickly.