If product ownership works in software development then why can’t it work in IT infrastructure as well? We are appointing product owners for our IT infrastructure, starting with end-user computing.
Introduction to product ownership
Product ownership is well established in software teams and is pivotal to the success of software applications.
The product owner sets the vision, roadmap and decides what gets prioritised. Their job is to maximise the value of the investment.
Their work doesn’t stop when the application goes live. They make sure the service continually meets the needs of its customers after the launch.
It’s a different story when it comes to IT infrastructure – for things like computers, printers, networks and Wi-Fi.
Typically after a large network rollout, little is done to improve the network or keep it up to date. It’s kept ticking over for years, until it’s well past its use-by date.
We think there is a better way.
Infrastructure product owner – a new paradigm for technology
We’re appointing new product owners roles for our IT infrastructure, starting with end-user computing – i.e. devices and software used by staff.
This product owner will constantly focus on improving employees’ computing experience. They’ll make sure that staff have the right devices, operating systems and collaboration tools to do their jobs.
The product owner will be backed up by a long-lived, cross-functional team, including members with delivery, technical, commercial and supplier management skills.
This permanent team will have all the skills required to deliver end-to-end customer value.
Continual renewal and improvements
The product owner will have the delegated budget and the remit to make continual improvements.
Small and frequent upgrades should be less risky, less expensive and less disruptive than big replacement programmes that come around once in a blue moon.
We know that much of our failure demand is down to the lack of major and minor upgrades.
A joined up view
Having a product ownership will allow us to coordinate different programmes of work, especially where they have similar technical requirements.
This should cut down on duplication and overlap.
The product owner will have an overview of programmes going on across the organisation. They’ll prioritise changes based on what’s good value and best for our users.
Single point of contact
The product owner will be the consistent point of contact for staff, programmes or stakeholders who have ideas, feedback or requests.
This will make it easier for colleagues to ask for devices or applications.
It will also give the product owner an in-depth understanding of the business and allow them to fight for improvements.
Challenges we have faced so far
As this is a new way of working we are working through the issues as they arise.
Each area cannot work in isolation.
There will have to be a lot of cooperation between product owners – for instance, to ensure that a request for video conferencing by the device team can be supported by the network team.
All requests must come through the product owner for prioritisation.
This requires all partners such as procurement, finance, legal and governance boards to not approve changes that are received outside the product team.
Limited change capacity means tough prioritisation decisions.
The product owner must balance the needs of the programmes versus the needs of the user. This has the potential to disappoint those requests are not prioritised.
Restrictive contracts can limited speed of iteration.
Some legacy supplier contracts allow for continual iteration and some are be more restrictive.
If product ownership works in software development then why can’t it work in technology infrastructure as well?
The benefits of continual improvement, a joined-up view and a single point of contact should outweigh the issues we will face.
Only time will tell if this new approach results in higher customer satisfaction scores for the technology team.