Equal ExpertsContact usPlaybooks
Search…
Overview
Introduction
Principles
Practices
Pitfalls
By Our Customers
By Equal Experts
Contribute
Powered By GitBook
Principles
We recommend the adoption of these Digital Platform principles once you’ve passed our when to start a Digital Platform criteria.

Digital Platform as a product

We believe a Digital Platform must be treated as a product, rather than a project. By that, we mean that for strategic competitive advantage, there must be an organisational mindset of a multi-year investment rather than short-term commodity thinking.
There needs to be dedicated, multi-year funding from the outset. There also needs to be an empowered Product Manager on the Digital Platform teams, who can prioritise work for new and existing platform capabilities. The Product Manager and their teams will solicit and act on feedback from the Digital Services that are the customers of the Digital Platform. This will help to create a Digital Platform with well-articulated goals and will allow the Digital Platform to be incrementally improved over time.

Collaborate with users

Digital Platform teams must have a relentless focus on nurturing bi-directional feedback loops with Digital Service teams. They must understand who their users are and strive to meet their Digital Platform needs.
Digital Platform teams engage in a continuous conversation with each Digital Service team. They must form trusted relationships with multiple team members from each team, in which there is sufficient psychological safety for constructive bi-directional feedback. The Digital Platform teams can then jointly experiment on new platform features with affected Digital Service teams and continue to enhance the Digital Platform as required.
At the outset of a Digital Platform, there will be no Paved Road. Opinionated platform capabilities will gradually emerge from the Digital Platform teams to govern the majority of user journeys for Digital Service teams. It's important people know a Paved Road is on the way.
Digital Service teams will have the greatest success when they understand that the purpose of a Paved Road is to abstract away low-level platform features, decouple them from Digital Platform teams, and accelerate delivery of Digital Services. Our Collaborate with users principle means Digital Platform teams must know about the Digital Service teams but need not know significant details of the Digital Services themselves.
Publicise the Paved Road intentions, with examples of opinionated user journeys planned for the future. The roadmap needs to explain that Digital Service team feedback will shape the Paved Road, and Digital Platform teams will not support user journeys beyond it. This will help to achieve Paved Road buy-in from Digital Service teams.

Accelerate Continuous Delivery and Operability

Cognitive load on Digital Service teams stems from user journey complexity, caused by ways of working, technology choices, and/or processes at inter-team boundaries.
Digital Platform teams need to continuously remove complexity from the Digital Service teams’ user journeys. The goal is to make Continuous Delivery and Operability adoption as easy as possible. One example is gradually standardising a deployment pipeline for building, deploying, and testing a release candidate that automatically runs on code commits. This also applies to the Digital Platform teams themselves.
HMRC experience
Collaboration with Digital Service teams was key to the success of the Multichannel Digital Tax Platform (MDTP) at HMRC. At its peak, we had eight Digital Platform teams in London, and 50+ Digital Service teams in five delivery centres across the country.
We had to strike a balance between listening to the Digital Service teams’ needs, understanding how many Digital Services would benefit from a new platform feature, and occasionally guiding the teams to a different solution if MDTP couldn’t accommodate them.
We used a range of techniques:
  • We ran regular feedback surveys. We asked Digital Service teams what they thought of MDTP and of their relationship with us as the Digital Platform teams. The first few were uncomfortable for us to read, but as we responded and improved, it got easier.
  • We travelled out to the delivery centres regularly. This allowed us to shift into being allies rather than just a group of names on Slack.
  • We listened when Digital Service teams had good ideas on what we needed on MDTP. One Digital Service team created a one-click button to create a standard HMRC Digital Service from scratch. We helped them develop it further, then rolled it out as part of MDTP.
  • We wrote blog posts advertising new MDTP capabilities, and guidance on how to use the new features. This helped to keep people in the loop about new features coming down the line.
  • We trialled new MDTP features with key Digital Service teams in different delivery centres. At one point, we had Digital Service teams approaching us and asking to be part of the trials. We found that people had started to feel some ownership of MDTP, along with us
Beccy Stafford
Previous
When to start a Digital Platform
Next
Practices
Last modified 11mo ago
Copy link
On this page
Digital Platform as a product
Collaborate with users
Advertise the Paved Road
Accelerate Continuous Delivery and Operability