Platform Product Management

The Gartner definition of a platform is “a product that serves or enables other products or services”.

Platform product management is a specific type of product management that focuses on creating and managing a platform that enables other products or services to be built on top of it. The role of platform product management is to understand the needs of platform users and developers and to create a platform that meets those needs in a way that encourages adoption and innovation. This often involves working closely with engineering, design, and business teams to design, build, and launch new capabilities on the platform.

Main differences between platform PMs and traditional PMs

• Users - one of the main differences is that platforms do not serve one specific type of user but two very distinct users (consumers and producers). This means you’ll need to advocate and cater to the needs of both. Examples of platforms are marketplaces (serving buyers and sellers), rideshare apps (serving riders and drivers) and social media (here, the same person can be both a producer and consumer at different times).
• Features vs capabilities - when dealing with platforms, you should think of capabilities instead of features. Capabilities are the ability to achieve specific results, whereas features are end-to-end flows to add value or accomplish a task. For example, using Uber, a feature would be searching the destination. A capability would be to calculate the shortest route to get to the destination. This capability could be used in multiple instances, such as when a rider books a trip or when the driver needs to find the passenger and get them to their destination. Uber Eats could also use this capability for drivers to pick up food from restaurants and deliver it to the user.
• Planning and balancing both user types - when planning and building roadmaps, you should also cater for both users and not favour one over the other. At certain points in the overall platform lifecycle, it will make sense to prioritise one over the other depending on your desired outcome, but this should only be temporary. An unbalanced platform would not benefit from network effects which are crucial in platform businesses, i.e., consumers use the platform for the consumers already present, and consumers use the platform to reach all the available producers. This creates a loop where more producers bring more consumers to the platform and vice-versa.

Platform PM challenges

• Technically minded - platform PMs should be able to consider and balance requirements that don’t necessarily manifest in a feature but in the behavioural characteristics of a product/platform (e.g. uptime, performance). They should understand the overall architecture and plan for integrations with other systems via APIs while keeping security and other non-functional requirements in mind.
• Focus on the big picture - this type of PM should have a zoomed-out macro view and understand the impact of adding new functionality to the platform. Many stakeholders and teams will want to add their own requirements, so the platform PM needs to be ruthless at prioritisation and saying no when it doesn’t go in the platform’s strategic direction.
• Manage long-term roadmaps - often platform-related capabilities are not quick to implement as many other product features (most capabilities take years and not months to implement). Platform PMs should have an eye for the longer term and a strong vision for their platforms.

Internal Product Management

Internal product management is focused on managing the development and implementation of products and services used internally within a company. These products and services are not typically sold to external customers but are used to support the company’s operations and internal processes. Examples of internal products could be an internal portal to onboard suppliers to a marketplace or tools used by the customer support teams. Internal PMs must have a deep understanding of the company’s current and future needs and any potential challenges that may arise.

The role of internal product management is to understand the needs and pain points of the company’s internal stakeholders and to develop and deliver products that address these needs effectively. This often involves evaluating how workers use programs and their workflows and working closely with IT, engineering, and other teams within the company to design, build, and roll out new products and features.

Main differences between internal PMs and traditional PMs

• Users - as the name indicates, internal PMs deal with internal employees, whereas traditional PMs deal with end users/consumers. This is great for user research, as you have all your users at hand’s reach!
• Product Market Fit - one of the external PMs’ goals is to reach PMF. Internal PMs do not need PMF, per se. Their goal is for internal teams to use their product and improve staff’s workflows and needs. Unfortunately, in some companies, employees are forced to use these products, which is not the best situation. Ideally, you’d want your staff to use your products of their own will as you’re improving their lives. In any case, these PMs should build great internal products and ensure employees are happy with them.
• Advocates for their product - as there’s no dedicated marketing or sales team, it’s up to internal PMs to spread the word and get employees to use their product.

Internal PM challenges

• Prioritisation - as internal PMs’ customers are literally in the building (or in this remote world, on Slack), they’ll be constantly bombarded with requests. Similar to platform PMs, these PMs need to be comfortable saying no if it goes against the product vision.
• Stakeholder management - as (most) internal products don’t generate direct revenue, it can be harder to sell their value to upper management. Mastering communication and having solid data on cost savings is key here. You can also articulate other top-line benefits such as accelerated time to market, more secure offerings, and higher innovation velocity.
• Features rollout - you may be tempted to roll out your new features/products to 100% of your users as they’re just internal. Be mindful that if you impact your whole organisation, nobody is able to perform their work and build the main company products (external facing, most likely).

Internal Platform Product Management

It turns out I started working on this type of product management. The main difference compared to platform PMs is that I am not dealing with two types of users (consumers and producers) and I’m dealing with a single type of user: internal employees.

My main goal is to streamline internal processes, improve efficiency, and create a unified and consistent user experience across all products and services by creating an internal platform. This provides the company with a competitive advantage by reducing costs despite its hyper-growth. This internal platform allows other teams to build on top of it and serves as a centralised place for all common capabilities, such as security, so the different teams do not need to reinvent the wheel.

Ultimately, the core product management skills apply to these three types of product managers. You’ll need to learn the nuances of each PM type, but it’s no different from learning a new domain (e.g. a fintech PM joining an e-commerce company).

For companies such as Uber, Netflix and Atlassian, creating an internal developer platform (IDP) is an important step as they scale to employing thousands of engineers. Humanitec CEO Kaspar von Grünberg defines an IDP “as a self-service layer that allows developers to interact independently with their organisation’s delivery setup, enabling them to self-serve environments, deployments, databases, logs and anything else they need to run their applications.”

Such companies need to be ready to scale for the increased number of engineers, products and codebase size and complexity. Startups must focus primarily on their most important customers to secure product-market fit ahead of scaling. However, companies fortunate to move into rocketship growth should place equal importance on internal engineers, empowering them to build fast and at scale.

IDPs improve collaboration and productivity by ensuring everyone accesses the same tools and consolidated information, streamlining the development process. A single tool, such as a developer portal, provides a one-stop shop for engineers, saving them from manually searching for resources in multiple disparate places. An IDP can provide a single point of access to the company’s full tech stack and frameworks, allowing engineers to fast-track the creation of applications and services. A single, central platform for development ensures that developers have access to the same standardised resources required to create the best products and services.

Finally, an IDP can also be an excellent tool for onboarding new team members, with a single developer portal allowing all new technical hires to benefit from easy-to-access resources to get up to speed fast.

Starting something new and adopting a product mindset

IDPs tend to start with a few engineers standardising ways of development, building tools and best practices for other engineers without product involvement. However, the true value of a developer platform comes when companies start seeing it as a real product, rather than addressing problems through ad-hoc fixes.

In early 2022 I was hired as the first product manager for an internal developer platform. Building something new can be exciting and rewarding but also challenging, as you need to convince other people that what you are creating will add sufficient value to warrant committing to and using. I found it especially refreshing to communicate with those who hadn’t worked with product managers before, sharing my passion for the function while explaining common misconceptions like the often-confused difference between product and project managers.

Here are some tips for others launching an IDP based on what worked for me:

1. Understand the customers. What are the developers’ needs and pain points and how will your product address these? Conduct user interviews, map developer workflows and solicit feedback. Identifying the problems your product will solve is critical to rallying people behind it.
2. Articulate a clear vision and strategy. People need to understand why the leadership is investing, or should invest, in the product. Vision is critical to winning the trust of the engineers you’re developing the platform for, giving them confidence that your plan will work and not only be talk. The strategy provides your team with a clear direction and keeps them focused on the end user.
3. Gain visibility across the organisation. Take any opportunities to present your vision and roadmap to relevant audiences and make yourself known as the entry point to discuss the developer experience. Actively build relationships with engineers so they see you as their ally and you hear firsthand how the customer feels about everything you’re working on.
4. Cultivate alliances with potential early adopters and advocates. Identify the key leaders and influencers within the organisation who will use newly developed features within the platform, provide initial user feedback, and then advocate for their adoption within their teams and networks.
5. Be persistent and patient. Building something new and changing habits takes time. It’s important to continue to communicate the value of your solution. Indeed it’s hard to over-communicate or repeat yourself too much.

By understanding your customers’ needs and having a compelling vision and plan to address these, you maximise the resources you can unlock to execute on the product. Over the past year, I’ve seen my group double in size, not only in engineering but also in product management and other supporting functions.

More and more organisations are adopting developer platforms to accelerate software delivery and eliminate manual, repetitive work. IDPs are not for every company. The resources are considerable and trade-offs must be factored in. But I would urge any company with 1000+ engineers looking to drive efficiencies as they grow to put building out an IDP high on their agenda of investment opportunities.

Internal platforms should not be mandated, so if we want our teams to use and advocate for them, we should solve real problems they face. Through a discovery process aligned with a solid product strategy, we can develop needle-moving capabilities that delight internal users.

The product discovery process generally fits into a design process best visualised as a double diamond.

The first diamond is where we come up with all the problems we want to solve aligned to our strategy and the second is focused on the solutions. By the end of the double diamond, we should have specific solutions that we can implement for our developers, already validated by the end users. Implementation of these solutions sits outside the double diamond. Some companies use the second diamond for the actual implementation but for the sake of this article, let’s assume we’re purely focused on the discovery part.

Discover

The first stage (Discover) is for research, exploring the root causes of the problem with various user research methods. This step is divergent, meaning all ideas are considered and included.

Here we use the following tools and techniques:

• Brainstorm with the team on the problems to solve
• User interviews
• Surveys
• Opportunity Solution Tree by Teresa Torres
• Quantitative analysis from data captured in analytics events, logs, etc
• Review existing customer complaints in customer support tickets, internal Slack or even social media (in the unlikely scenario that external users are impacted sufficiently to take their grievances to Twitter!)

Define

The Define step is the convergent part of the problem space (first diamond). From all the ideas generated from the previous step, we now narrow everything down into a clear definition of the problems we want to solve.

To better succeed at this step, we should have a clear picture of the product strategy and the metrics we’re trying to impact and determine if the problem is worth solving relative to other opportunities.

With this in mind, we can use the following tools and techniques to generate insights from all the problems discovered in the previous step:

• Finding patterns
• Assessing the impact of fixing problems
• 5 Whys
• User stories
• Jobs to be done

Develop

Develop is the first step of the solution space (second diamond). Here the team builds prototypes of the solution and tests them with real users. This step is divergent, meaning all solutions are prototyped or have proofs of concept.

The tools for this step are the following:

• Ideation / Brainstorming
• Rapid prototyping / Proof of Concept
• Experimentation
• MVP for simple things not requiring UIs (e.g. Command-Line Interfaces or simple tooling)

Deliver

The Deliver step is about delivering the prototypes or MVP to the end-user and getting feedback to improve the solution, looping back to the Ideation/Develop phase and re-testing until we reach the final solution we want to implement.

We can use a range of tools here, including:

• User Testing
• Experimentation
• Data-informed solution selection (e.g. RICE, DACI)

A great way to test with internal users is to have previously recruited people willing to try alpha/beta versions of our product and provide early feedback. These users then become the strongest advocates of our platforms, making it a win-win situation.

Overall, the product discovery process for internal platforms is similar to that of linear products. The main difference is the easy access to our users, which we should use to our advantage to build solutions they love.

There are many reasons as to why products fail but the most common among them remains that there is no real problem that the product is solving. Customers already have ways to get their jobs done, albeit sometimes cumbersome ways, so for an innovation to succeed, companies need to identify and optimise opportunities to simplify users’ lives.

Consider these three high-profile cases of products that launched, and subsequently failed, because they didn’t address a key customer need.

Google Glass

Google Glass was developed by Google X, the facility within Alphabet focused on developing moonshot products like self-driving cars. Google’s smart glasses were launched in 2013 and discontinued in 2015, after users failed to embrace the product.

In addition to there being no real problem that Google Glass was trying to solve, there was a lack of consensus as to when the product should be used: if at all times, as an everyday fashion accessory, or only for specific occasions to take photos, as one would use a camera. The user group that would wear it as a fashionable item would want something more aesthetically pleasing for approximately US$1500. People also had privacy concerns, understandably given that there was a visible camera on the front of the glasses.

In lieu of any official product launch, Google’s strategy for Glass was apparently to seed the product with journalists and influencers to become ‘early adopters’ who would in turn generate sufficient hype to trigger sales from the wider public. However, since nothing was communicated to the general public about when and where they’d be able to buy the product, this early adopter activity had limited impact.

The two main functions of Google Glass were, firstly, to take photos and, secondly, scroll the internet at the corner of the user’s eyesight. However, smartphones already existed that allowed users to do all this with far superior battery life. Google should have undertaken more user research to find the use cases for which people would actually need or desire this product. A product is only as good as its product market fit, and in this sense Google Glass did not pass muster.

Amazon Fire Phone

Launched in 2014 and discontinued 13 months later, Amazon Fire Phone was Amazon’s first and only venture into the smartphone market. It was insufficiently differentiated from existing smartphones to meet a customer need, particularly given its many drawbacks.

Fire Phone’s main features were its 3D graphics capability, and Firefly, a tool that enabled people to scan and recognise objects, songs and text, allowing them to quickly buy these products from Amazon’s online store.

However, Fire Phone users were unable to access key Google apps like Gmail and Maps, forced instead to use Amazon Appstore. This was a significant barrier for the 78% of smartphone users then on Android and the 18% using Apple. Without a frictionless way to onboard, users will rarely go to the effort — particularly if a high cost is involved, as with Fire Phone’s off-contract price at launch of US$650 for its basic model.

Moreover, Amazon had an exclusivity deal with AT&T which meant that only customers willing to sign up with this network would buy the Fire Phone.

Segway

Segway is an electric two-wheeled, self-balancing vehicle for individuals to transport themselves, launched in 2001 and discontinued in June 2020.

Segway tried to be a general purpose product but ended up being used only in certain activities as guided tours while exploring a new city, or by police for certain patrolling activities. Segways could not climb stairs, which failed to make it a viable replacement for walking, but nor was it efficient enough to improve upon existing transport options such as scooters or bikes.

Segways were initially sold for high prices (around US$5000), equivalent to some motorbikes and scooters, therefore not satisfying any need for lowest-cost transport. Like Google with its Glass launch, Segway Inc seemed to hope it could generate buzz leading to sales without nailing any clear problem. The complete opposite happened, with people criticising the design for being dorky rather than cool. Solid user research would have helped.

Also like Google Glass, little was communicated about how to use the product. Many users were unsure how to charge the Segway, where to park it, and even whether they should be used on roads or sidewalks. Segways were banned in some countries where it didn’t fit into existing regulations — not without reason, with Segways developing a reputation as dangerous vehicles after several serious accidents. Sadly, one of Segway Inc’s owners, Jimi Heselden, died in an accident riding a Segway.

But all is not lost, if we learn from failure

Thorough user research is needed at every step of product development to validate the users’ problems and gather feedback on prototyped solutions.

Moreover, once you have a product, in order to cross the chasm (to borrow Geoffrey Moore’s concept from Crossing the Chasm) between early adopters and early majority users, companies should target a specific niche market big enough to influence others, rather than getting distracted with a wide cross-section of users right out of the gate.

Yet while all three products mentioned above failed to achieve product-market fit, they all paved the way for future innovations. Glass opened the doors to competitors to further innovate with the technology, such as Facebook’s forthcoming smart glasses to be launched soon in partnership with Ray-Ban, or Microsoft’s HoloLens announced only days after Google Glass was discontinued in 2015. Amazon Fire Phone assisted in the development of Amazon’s Echo smart speakers and the Alexa digital assistant.

Both Google Glass and Amazon Fire Phone should be seen as part of their companies’ strategies for product development: making bets/investments in different areas, sometimes winning and sometimes losing, but failing fast and taking on board learnings. As Jeff Bezos has said: “If the size of your failures isn’t growing, you’re not going to be inventing at a size that can actually move the needle”.

Meanwhile, some claim that Segway was a prototype for the electric scooters we see today.

Before coronavirus, many companies were uncomfortable with remote working practices, but I expect many will ease their positions following the current lockdowns, armed with the learnings from this working from home rush.

In order to be efficient at remote working, I have had to adopt new tools and tactics as I realised that the old ways were not scalable for non-collocated teams, especially in the role of product manager which is all about collaboration.

Here are the top tools and tactics in my arsenal for effective remote working:

• Over-communicate
• Improve documentation
• Ensure structured onboarding for new employees
• Maintain team/company culture
• Adopt new tools for remote working
• Attend meetups and conferences
• Be kind to yourself

Over-communicate

There’s no such thing as too much communication — we may think that we’re communicating enough but often it is not the case. Ensure you maintain regular conversations with your team both through quick calls and instant messaging tools like Slack.

Slack should be used as an asynchronous tool, given that most of us are no longer simply working 9 to 5. Different people may have different work schedules due to family and children at home, and attend scheduled meetings but shift the rest of their working hours. If I send a message at night or during a weekend, I don’t expect an immediate reply — it’s purely to ensure we remember to discuss that the following time we catch up.

Many people are talking about “Zoom fatigue” but personally I prefer video over voice calls in order to read facial expressions and reactions in trickier conversations. Again, we should be understanding of the personal circumstances of who we are on the call with — our flatmates or children passing in the background should not make us uncomfortable.

Improve documentation

Now is a good time to improve our documentation, so that teams are clear on processes and what needs to be done, given that it’s no longer as easy to chat with your work neighbour. While doing so, we can look to improve outdated processes and workflows, while keeping this documentation simple for new starters to understand.

Structured onboarding for new employees

More than ever, now it’s time to have a structured onboarding program for newcomers. This could include an overview session with each of the different business units of the company and more detailed deep-dive sessions with the new starter’s team. A strong onboarding program should also ease the process of configuring all software and products the new starter will use, particularly if they’re a developer. At my company we’ve remotely onboarded both engineers and product people during lockdown and having a structured onboarding system was key to quickly integrating new people into the team. This allowed them not only to understand what they’ll be doing on a daily basis but also the impact their work will have on the vision and strategy of the wider organisation.

Maintain team/company culture

If you’re used to having Friday afternoon drinks, you should still do so remotely. This will allow different teams to interact in a casual setting and maintain a positive mindset. At my company we’re also keeping our stand-up meetings funny and engaging by sometimes wearing silly hats. As with in-person social events, these should be optional as not everyone will be keen to participate, especially if they are a regular diary item.

Adopt new tools for remote working

There are a variety of tools to enable and enhance remote collaboration. Mainly for product managers, Miro is a great tool for white-boarding and running retrospectives and Lookback and UserTesting for remote user testing. Also, obviously critical is a good platform for video calls and instant messaging, presumably one already in place from before this pandemic.

Now more than ever, we should limit unnecessary meetings and pre-circulate agendas in order to ensure they run as efficiently as possible. Many of us will be juggling responsibilities other than work during the day, so it’s important to respect everyone’s time.

Attend meetups and conferences

Isolation has given me not only time to read more but also to participate in more meetups and conferences, now streamed directly into your home. Due to video streaming, I’ve participated in meetups based in London, New York, Sydney, Singapore and San Francisco.

Upskilling and keeping up to date with industry trends through these events can help us feel less isolated from our peers.

Be kind to yourself

Finally, what we’re doing is not remote working as it’s typically conceived; we’re working from home during a global pandemic. When I moved to Australia to be closer to one of our major customers, I was working remotely for the headquarters based in Europe. There were processes and structures in place and I was collocated with colleagues working on different projects. I was not entirely isolated from society. I could spend my days working alongside our customer, or from our Sydney office, home or a café. I worked in the evenings to liaise with others working on the project, so it did not matter from where I worked. Reminding ourselves about the unusual times we’re in should allow us to be easier on ourselves if we’re concerned that we’re not delivering at our usual level.

With the lockdown, I’ve made the most of my time indoors to get inspired, upskill and challenge myself by making my way through some self-development books on my list for some time. Here are ten I recommend for every product manager and people leader, junior and experienced alike.

1 — Radical Candor by Kim Scott

This is the best guide I’ve seen to giving honest feedback. To achieve Scott’s idea of Radical Candor, we need to both Care Personally and Challenge Directly. If we fail to achieve either of those two, we become guilty of obnoxious aggression, ruinous empathy, or manipulative insincerity.

Scott shares the feedback a stranger gave her while walking her puppy; if she doesn’t train the dog how to sit, the dog may eventually die on a busy street. The stranger’s feedback was radically candid as she both cared for and challenged Scott.

2 — The Coaching Habit by Michael Bungay Stanier

In The Coaching Habit we are given seven questions that encompass the fundamentals of coaching. These questions can improve how we engage with others, manage our relationships, and help guiding our peers to develop themselves and solve problems.

The main takeaways from this book are twofold: we should focus on empowering people rather than giving them the answers, and knowing how to ask is as important as knowing what to ask.

Out of the original seven questions, three are enough to keep a useful coaching conversation: What’s on your mind? And what else? What’s the real challenge here for you?

We should resist the urge to talk and just listen and we’ll be surprised with the results.

3 — Never Split the Difference by Chris Voss, Tahl Raz

Chris Voss shares his experience as an FBI hostage negotiator to equip us with the negotiation skills needed to succeed in both our professional and personal lives. We learn that emotion, not logic, determines the success of negotiations and we’re far better equipped once we truly understand what the other party wants.

Voss shares several tricks to achieve this: including, using mirroring techniques to encourage the other party to bond with us, giving someone’s emotion a name (labelling), and becoming comfortable with saying “No”.

Many other tips are detailed in this great book filled with the author’s wisdom learned through life-or-death scenarios.

4 — Indistractable by Nir Eyal, Julie Li

This book contains the best tips I have read on how to gain focus, with tactics that are readily implemented in everyday life. Eyal describes a 4-step strategy on how to become “indistractable”.

He takes a dim view of instant notifications on both phones and computers and advises us to be unreachable for certain hours of the day so we can stay productive. He also cautions against the over-use of group chat platforms in the workplace, arguing that despite Slack originally being a tool for productivity, it often has the opposite effect.

5 — Inspired by Marty Cagan

Written by the founder of the Silicon Valley Product Group, Marty Cagan wrote what I consider the best outline of product management fundamentals.

Inspired is full of real-world examples of how the big tech companies like Google, Apple and Netflix created the digital products we all use.

My favourite quote from this book is “If you’re just using your engineers to code, you’re only getting about half their value”. Engineers should participate in the whole process (e.g. discovery sessions) as they’ll bring different skills to the table. Their analytical skills will allow them to glean different insights from customer interviews and ask the tough questions about what could go wrong that nobody wants to hear but generate better solutions.

6 — Hooked by Nir Eyal, Ryan Hoover

Eyal brings a background in user psychology and a deep understanding on how we are wired to analyse what makes a habit-forming product. Drawing on real-world examples from tech giants like Instagram and Twitter, he shows how his ‘Hook model’ keeps users coming back through a 4-stage process: trigger, action, variable reward and investment.

Eyal asks searching questions about the moral implications of creating psychologically addictive products and outlines the measures of care companies need to take.

A must read for every product manager or company founder.

7 — Nail It Then Scale It by Nathan Furr, Paul Ahlstrom

This book is for every entrepreneur who wants to start their own company. The Nail It then Scale It (NISI) process has 5 steps: nail the pain, nail the solution, nail the go-to-market strategy, nail the business model and scale it.

The most important takeaway is the importance of communicating and testing with real customers at each step, in order to validate that we’re on the right track. The majority of start-ups that fail bypass some of this user testing. The real-life scenarios and examples drawn from the authors’ experiences make this an easy, enjoyable read.

8 — Escaping the Build Trap by Melissa Perri

This book starts by defining the build trap: when organisations become stuck measuring their success by outputs rather than outcomes. It then focuses on the importance of companies being product-led, on the role of the product manager, and how to organise our teams to focus on outcomes and escape the build trap. Perri also shares good tips on how to communicate strategy from the C-level down to individual contributors to ensure everyone is on the same page. Throughout, she returns to an engaging fictional case study of a company she saved from the build trap, which makes her lessons easy to absorb.

9 — Product-Led Growth by Wes Bush

Product-Led Growth is about building products like Slack and Jira that sell themselves without marketing or sales teams. This book offers a step-by-step approach on how to achieve this model instead of the typical sales approach. Bush focuses on how SaaS companies should decide whether to use free trial, freemium model or a hybrid of the two to attract customers, and how to convert them into paying users.

10 — The Lean Product Playbook by Dan Olsen

This book argues that the majority of products fail due to poor product-market fit. Dan Olsen offers a “Lean Product Process” composed of 6 steps: determine your target customer, identify underserved customer needs, define your value proposition, specify your MVP feature set, create your MVP prototype and test your MVP with customers. Olsen cautions us to take care not to focus so single-mindedly on our proposed solutions that we forget the actual problems we’re trying to solve.