Reflection on SR2’s panel discussion: Government's Shift to a Product Mindset
25 November 2021: A thought-provoking discussion with industry leaders:
Product v Project Delivery
The discussion kicked-off with a nice opener for Heather, what is the difference between product delivery and project delivery?
Product delivery is a mindset, project delivery is a process was the essence of the response. Product based approaches focus the team on the outcomes required for the end users, not how a product is built (while that is still important, of course). It is about being ok with failure, being prepared and brave enough to put something in front of users at an early stage, knowing it might not be complete to get feedback to ensure the right product is built. It is about having an incremental approach to delivery, knowing that it is better to get some value delivered early without having to have the complete answer.
Fergus added that product delivery is “post-agile”, that is extends the good agile principles put in place by GDS and brings the focus onto the outcomes, not just the delivery of features as if they were a specification. Product and service are often used interchangeably within a Government context, thinking about the service as a whole, and not just systems is important to success.
Ben had a slightly different slant on the topic, though it was very insightful. The time horizon is often very different for projects and products. A project may be a relatively short piece of work to deliver a specific requirement, however, a product often needs to be viewed as a longer term investment that can be delivered incrementally. By looking at the product’s lifecycle, beyond the project for delivery, the choices made in building the product can be can be made within the context of a longer time-frame for delivering the benefits, ultimately leading to a better product or service.
My thoughts turned to the economics of product-based delivery at this point, specifically Government procurement and funding processes. Something that Ben would come back to later in the discussion. I also thought about the need for Government to think about products and services as capabilities that need to evolve as policy changes and respond quickly to those policy demands. Working in a product-centric model allows for new demands to be prioritised above or replace those needs currently being built.
Incremental Delivery
The next round of discussion with the panel focused on strategies for Incremental Delivery, and the need to be responsive to change.
Recommended by LinkedIn
Heather, who has been involved with the Universal Credit service for a number of years was keen to get across that it is important to have a product-mindset from the start, to get something out, get feedback and then optimise it over time. Incremental delivery and getting feedback was critical to the development of the product and associated service.
Ben and Fergus both reflected on a condition called “Discoveryitis”. The overwhelming desire to do too much Discovery work and to feel the need to have all the answers before the product or service is built. Taking this approach risks losing the benefits of incremental delivery and gaining real user feedback to shape the product. This often leads to a tension between the need to release something early with limited capability and making the Minimum Viable Product (MVP) too big, especially with a replacement system.
Heather went on to consider “risk” in the context of incremental delivery. What risk are departments willing to take? What is the risk associated with something not working? What is the risk of some user’s needs not being met? All good questions when considering your incremental delivery strategy.
I reflected on my experiences of building Digital Services at the Metropolitan Police and the strategies we used to deliver incrementally. We thought about which processes were critical to provide a digital service for, which data sets do we consider as part of an increment, and how to run existing systems in parallel as replacement services are bought on-line. All useful things to think about when considering the incremental delivery strategy and product roadmap.
Embedding a Product Mindset in Government
Finally, the panel turned to the question: What changes need to be made in Government to enable product-based delivery to work? The hallenges to be tackled included funding, and the attitude of Central Government towards IT.
With respect to funding, Ben implied that the current funding structures still create a barrier re-enforcing shorter-term, project-based thinking. Or they require big specifications and procurement exercises that do not put users at the heart of the delivery of the product or service. Moving the spend from IT to the business, with a business focused on delivering outcomes, not systems, is a new way of thinking that could help product-centric models stick.
Central Government is coming to realise that we are not just the IT people, and that we are building services to implement policy, not just delivering systems. Embedding service users and operational owners is now more common in Government IT delivery providing the experience to delivery the right outcomes, something Government needs to maintain investment in.
Approaches to be adopted should include using Problem Statements as part of the roadmap of the product and allow stakeholder to engage in what the product/service is, not just whether it is being built to the specification, on budget and on time. By focusing stakeholders on the outcomes required and the problem to resolve, this provides space for teams to collaborate and figure out what the right approach is within the team.
And Next?
A lot has been done over the past 10-12 years to change the way Government delivers IT. Many Central Government agencies have experimented and our shared experiences of doing product-based delivery has identified challenges that will be tackled to ensure that product-based delivery models evolve, and citizens get the services they deserve.
John - many thanks for making the time to write up our discussion. Really useful to see. If the chat hadn't been cut (for very necessary reasons), would love to have heard your thoughts on the subject). Cheers again!
Hi John, I enjoyed reading the narrative along with your thoughts and conclusions. It would have been good to experience the live session. Was it recorded by any chance ?
Good insights John, thank you. A simple but useful distillation might be: Product v Project = Outcomes v Outputs
John Wright - this is such a great summary of the chat today. Great to have you onboard and hope to follow up this topic in the future.