Large organisations often have internal platforms. My first assignment at the Ministry of Justice in 2015 was an internal platform to help development teams run and change their software. I got to pair with colleagues at GDS who were developing ‘Government as a Platform’. There was a lot of mutual learning and sharing in those early days, and I got to assess the early versions of a couple of their products. In the five or six year since then I’ve become a Head of Product, working with, supporting, and learning from many other Product Managers puzzling over what it means to work on a platform. I’ve gotten insights from within my own organisation, across government and from commercial organisations too. The challenges and opportunities are staggeringly consistent.

I’m revisiting platforms in 2021. My role has broadened and I now provide leadership across our user-centred professions of business analysis, content, delivery management, design, product management, and user research. One of our core value propositions is ‘improve how we develop and run our products’. One way we can do this is to take custom activity that we keep duplicating and instead package it up as a scalable product. So we’re looking at opportunities like a user-research library, design patterns, content systems, improved service manual, etc. All internal knowledge platforms. I pulled together an early version of this document in the New Year as part of this work and have been tweaking it since.

Below I share some tips for platforms but I’ll start off with a bonus one: don’t get lost in the word ‘platform’. A platform is a product, just like any other product. Granted: it’s a product that helps to build other products. But focus on the ‘product’ bit more than the platform and the rest of my tips become obvious. A product is a product. We shouldn’t cut corners just because it’s an internal product built for our colleagues. If a product’s worth doing then it’s worth doing right. Otherwise it will fail. Your internal platform is a product. It’s a staff-facing or business-to-business product so you’re designing for professional users. Give it the love and attention it needs and set it up for success.

Here are 5 hard-won tips for building successful internal platforms.

1. Trust is the key to success

Trust is the value proposition for internal platforms.

We all have a tendency towards exceptionalism. We believe we’re doing something so unique it requires a totally bespoke approach. The truth is we’re often more similar than we are different. Platforms take a custom activity that used to be in someone’s control. And remove that control.

People need to trust a platform before they’ll hand over responsibility for critical elements of their organisation. We need to invest more time and effort in helping people to use our platform than we do in building the platform’s features. An attitude of ‘if we build it they will come’ doesn’t work.

Successful internal platforms must design for trust. Trust is built in the real world, where customers and users interact with the platform. They need to engage with things like: Communication and engagement: Products need to speak with their users. Being an internal product doesn’t change this. Your communication strategy is critically important. Do you have one? Do you have someone on the team who’s dedicated to this?

Product support: Same as above. Being an internal product doesn’t excuse you from needing to provide
‘Sales’: How do we know if customers will commit to our platform? Early-stage platforms often talk about having ‘buy-in’ for their product. How do we measure and test buy-in? Janice Fraser has a model for this, suggesting we measure observable behaviour. Do potential customers demonstrate understanding of the product? Do they demonstrate belief in the product? Do they advocate for the product? Are they making decisions in support of it?
Change management: Introducing a platform requires customers and users to change how they work. There are many models to help manage this change, one example being the ‘ADKAR’ model.
Maintaining brand visibility over time: Platforms need ongoing activity and communication in order to maintain success after the initial changes are introduced. Once again, there are many models for approaching this. One is ‘the five conditions for collective impact’.

Platforms often start-off being described as ‘technical’. And might be run by a team referred to as ‘technical’, i.e. made up of one main skillset or specialism. This can overly focus on the technical features of a platform for months, even years. Broadening out the skills within a team can help increase the speed with which they realise they need to focus on building trust with their customers and users.

2. Aim for simplicity

We can simplify things when people trust us. It’s easy to fall into the trap of offering lots of options for customers and users to choose from but experience suggests that what they value most is simplicity. If they trust us, they want the benefit of things we’ve figured out on their behalf.

Thinking of the ‘Cloud Platform’ I helped develop in 2015: what we learned was that our software products at the time were similar. They were web forms with databases. Our Developers need our organisation to understand this and to design a platform accordingly. It was frustrating for them to be faced with lots of infrastructure options at the beginning of a product. We’d already figured out what our software needed, why didn’t we reinvent the wheel every time we started something new? They needed ‘sensible defaults’ that helped them to spin-up a new environment and get to work quickly. Without the need to make loads of decisions that we’ve already figured out before. The Cloud Platform introduced ‘sensible defaults’ that instantly provided the benefit of everything we’d learned up tol that point. Developers could change them as and when required but they catered to most situations.

We promote inertia when we keep solving the same problems again and again. Sensible defaults avoid repetitive decision-making in areas we already know. They allow us to invest our time and effort in solving new problems.

Simon Wardley’s mapping can help us to identify when it’s the right time to take something that’s currently bespoke and turn it into a product. And Wardley’s doctrine might help us to identify what simplification might mean in practice.

3. Understand your customers and users

GDS and MOJ were developing platforms in parallel in 2015. Platforms were seen as a ‘technical thing’ at this point and it was difficult to obtain researchers for platform teams. After establishing that platforms are simply a type of staff-facing product and aligning them with the Service Standard it became clear that research was a critical skill. However, existing modes of research didn’t work when lifted and shifted into this space.

Will Myddelton was leading user research for platforms for ‘Government as a Platform’ at GDS at this time. Will established version one of a model for research in GDS’ platforms and made time to share it with me. I took it back and we tweaked it for our context.

In summary, there are customers and users:

Customers: These are the people who will end-up paying to use the Platform. At MOJ, ‘Head of Digital’ was considered the main type of customer for the Cloud Platform. Research showed that their needs were fairly simple. They needed to know how much it would cost to host and run their software, something that had not been clear until this point. And they needed to trust that software would be run well and that incidents would be well-managed - along with help to communicate this to their internal clients.
Primary users: These are the people who’re using the platform. In the narrowest sense, this was ‘Developers’ for something like MOJ’s Cloud Platform. Although the whole development team might potentially use the platform in some situations and some contexts.
End users: For something like GDS’ Verify service, that appears within the user journey of software that integrates with it, it’s also necessary to research and test with the end users of that software.

4. Content is your competitive advantage

Let’s start with the obvious. Because it’s easy to ignore the obvious. The word ‘platform’ is often misunderstood and misused. It can get in the way of people understanding what the product actually is. It’s important to define the word and use it consistently. And to use it judiciously. Practically, it’s more valuable to define what ‘platform’ means to us - in our context - for our customers and users - than it is to define the single, all-encompassing definition of the word ‘platform’ for everyone in all places. Platforms are ‘staff-facing’ or ‘business-to-business/B2B’ products. Also remember, platforms don’t have to be technology. That’s where the definitions come from. But user research library, design patterns, etc, are all internal products that help us build products.

Beyond this, it’s content which is the main feature of the support wrapper around the platform in which we build trust with our customers and users. There’s a critical difference between technical documentation (e.g. comprehensive description of the thing) - guidance (e.g. simple instructions to use the thing) - and communication (e.g. helping people to find and understand the thing). Content is what helps people to use your platform.

5. Rewire the house whilst keeping the lights on

Platforms rarely come out of nowhere. They’re often the ‘productification’ of previously bespoke activity. This means they rarely have the luxury of starting from scratch. They need to meet existing commitments and support work in progress. Whilst simultaneously redesigning, improving, and productifying. This is like rewiring a house whilst keeping the lights on.

Platforms need at least two modes of activity to achieve this: One is ‘keeping the lights on’. Operational activity needed to meet commitments and support work in progress. Something like Scrum will probably work well here. Two is ‘rewiring the house’. Research and development needed to build and improve the platform. Something like Kanban will probably work well here. The team needs to separate these two modes and approach them separately. If they coexist in the same meetings and ceremonies then once will drown the other. Typically, operational activity will swamp research and development unless the team actively sets constraints around each type of work.

Yak-shaving is common. Unpicking situations where a platform’s approach goes against a local culture can uncover large and previously hidden issues. Estimation is difficult for this reason. Experience suggests that an estimate based on precedent - i.e. looking at the closest previous work and assuming it’ll take a similar amount of time - is more effective than general sizing activity.

There you go. Five tips for product managers looking to create successful internal products. I think being assigned an internal product was the making of my carrer. It felt so strange and alien that I had to return to first principles in many areas and ask ‘what’s the intent behind my normal product management tricks?’. Hving reconnencted with first principles it freed me up to be pragmantic: keeping what worked, dropping what didn’t work, and filling in the gaps through learning from experience and from others. Are you in this space now? How are you finding it? Do any of the tips sound useful for you? Have you already noticed something similar and tried it out? Have you developed any of your own tips for internal products?