Product Management for Platforms

Ali Rawashdeh
Kainos
Published in
5 min readFeb 2, 2017

Over the last 10 years, we’ve seen a significant shift in how organisations interact with their customers. Most organisations now have some form of digital capability, enabling them to meet the needs and expectations of their customers in today’s digital era. When mature organisations have established the ability to create digital products, they start looking for other ways to improve — such as reducing waste and speeding up delivery.

This is where ‘platforms’ come in. Platforms provide a common capability — for example, text messaging — that can be used by many different products and services in an organisation (and in some case by third parties too). When you manage a capability centrally you can often capitalise on economies of scale to keep costs down. But more importantly than anything else, it means that a new product team can get access to data more easily and ship working products faster, resulting in a competitive advantage.

Platforms such as the GOV.UK Platform-as-a-Service have demonstrated the benefit that platforms offer. But it’s easy to get them wrong. You need to make sure you’re solving the right problem and you need to make your platform easy to use. I’ve been the Product Manager for a digital platform for the last 10 months, so I’d like to share the key things I’ve learnt in that time:

1. Developers are users too

The digital era has forced organisations to have a relentless focus on user needs. There’s no point in building a product that user don’t need. The same thing applies to platforms — the functionality that you’re offering needs to meet a real, validated user need.

But, building a successful platform doesn’t just require functionality that works. To integrate your platform into a product might require technical work — if it does, then those technical people are your users, and you need to understand their needs as much as anyone else. If your platform requires technical work to use, speak to your users about the technical tools they use, the data they typically have available and the complexity of your technical interface.

2. On-boarding is a user journey

The product teams that want to use your platform can be considered your users. It’s easy to forget that their journey can start weeks or months before they start using your platform. For instance, the developers we spoke to wanted clear documentation and access to test environments before anything else.

Live use of your digital platform will typically come at the end of a customer’s on-boarding journey. Find out how long your customers expect the on-boarding process to take, how they want to be communicated with and what material they need to see alongside your platform once they get under way.

3. Don’t predict user needs

Let’s take a hypothetical example. Two parts of a business might require a “messaging” capability. A delivery programme is commissioned to deliver the capability for both parts of the business. Later on, you conduct user research and discover that one part of the business actually needed text messaging and the other needed email. Validating the needs of the users earlier on in the process would have avoided this problem.

Government technologists have talked about this too — they say that the best platforms are those that emerge, rather than those that are proscribed.

In my experience people tend to make assumptions about business needs as much as they do with end user needs. As a platform product manager, it’s important that you focus on real, validated needs. You probably can’t speak to every possible future customer of your platform before you start building. But, you can speak to a handful, whilst delivering for the real needs you know about today.

4. Defining metrics can be difficult

Metrics are crucial for monitoring how a service is performing, allowing you to continuously improve and monitor the impact of your changes. Typical metrics might include Completion Rate and Cost per Transaction.

These metrics might look like they apply equally to platforms, but you need to think about all your customers. If you reduce your overall Cost per Transaction, but make it higher for some of your customers — is it really a success? If a developer tries and fails to integrate your platform, is that failure covered by your Completion Rate metric?

For platforms, you need to consider what success looks like from the perspective of your customers — this will help you define effective metrics and put in place the appropriate tools to measure them.

5. Expect stakeholder engagement challenges

Platforms are often invisible, and their success is manifested in the digital products and services that use them. Your customers get all the benefit of using your platform and often get most of the interest from stakeholders. Be aware of this challenge, and be prepared to conduct a roadshow — visiting your stakeholders — if you don’t get the engagement you need at your Show & Tells. These stakeholders can often help to promote your platform and identify other potential customers.

6. Think about how your platform adds value

A culture of code-sharing within an organisation can improve organisational efficiency — maximising reuse and helping to share ideas and innovations. But, from a platform perspective, it can result in some thought-provoking conversations:

“Instead of using your platform, can I copy your code and run one myself?”

This is a good question to hear — it means you’ve created something that other teams in your organisation have a real need for. But, if you’re running your platform as a hosted service — i.e. you’re responsible for operating and improving it — then you need to have a clear, validated understanding of why your customers benefit from using your platform instead of hosting their own.

7. Be prepared for rollout

The process for building a platform and getting it live is similar to that of a typical product or service. However, there are elements of your platform and team that will need to scale quickly as you on-board new customers.

I see many similarities between the functions of a platform team and the functions of a product company, namely:

· Development

· Support

· Rollout

As your platform matures and rollout gathers momentum you may find that support and rollout functions will need to ramp up rapidly. It’s important to think about your team structure and flexibility continually.

8. Build in repeatability

If your on-boarding process contains manual steps, getting new customers onto your platform can put a serious drain on your time. Your team will need to scale proportionally as demand for you platform increases. It’s important to understand which parts of your on-boarding process can be automated, to improve your ability to scale. You can do this using a range of digital and non-digital products such as:

· Documentation — both technical and non-technical — background material, FAQs or detailed interface usage instructions.

· Videos — training material / demonstrations of the service and the benefits it can bring.

· Cost / Usage Models — helping your customers understand what it costs to use your platform, based on their needs and transaction volumes.

In short

Platform Product Management has certain challenges that you wouldn’t typically encounter on the journey to building a digital product. But despite the challenges, it can be a rewarding experience that realises significant benefits for your organisation.

I hope you found this post useful — let me know what you think, on Twitter or in the comments below.

--

--

Ali Rawashdeh
Kainos
Writer for

Digital consultant, tech geek and product person. Passionate about crafting great software. Driven to make the world a better place. @KainosSoftware