I’m a product manager for a content management system that runs some of the most-visited websites in the world. Our team reports to the CTO, and we sit within the engineering arm of the organization. Prior to this I’d had a year’s product experience at a customer-facing SaaS company and naively I believed I could copy-paste this experience. I was wrong. At its heart a CMS is a platform, not a product. I quickly found that I needed to become a platform product manager.

There are many differences between product management in a consumer-facing world and a platform world. This article describes my experience of how stakeholder and user needs for a platform product – as distinct from user needs for a solutions product – influence the platform product manager’s ability to create value, and hopefully provides some guidance to anyone interested in how you should alter your thinking when you switch product types.

Platform vs Product

What’s the difference between a platform and a product?

Here are some answers:

“A product is something you sell. A platform is common infrastructure that you build products on.”

“Platforms are structures that allow multiple products to be built within the same technical framework”

“Platforms exist to make it easier to solve a problem that’s common to multiple businesses or products.”

Our content management system is a platform that is used by web sites to build their content. It’s a set of reusable components, a common infrastructure, and a group of APIs that feed the front-end output for multiple web sites, which are also separate business units. We build tools that editors use to publish content to the site, but these are only one piece of the CMS puzzle. The editor output is, in essence, one piece of the many APIs that produce the revenue-generating product/website.

Users and Stakeholders – Solutions vs Platform Product

At my former role managing a revenue-facing product, the product created value for multiple customer personas, and the product manager supported stakeholders throughout the company including sales, marketing, and customer service. Although there were plenty of stakeholder management challenges, we did not have to consider how to support the infrastructure of separate business units.

For a CMS product underlying multiple websites (which are also their own business units), there are multiple users and stakeholder constituencies whose needs need to be taken into account:

1. Developers who build products based off our core platform
2. Editors who use the CMS product to build content for the end users, but have unique content strategies based on the end users reading their content
3. End users who eventually consume the web content who have unique reasons for consuming a site’s content
4. PMs and PMMs who manage customer-facing products driven by the CMS

Each of these constituencies have both overlapping and divergent needs. To build a roadmap for a platform product, the CMS product manager needs to support the use cases that are common among the groups, while also supporting the key ways in which they are different.

Building Roadmaps – Solutions vs Platform Product

At my customer-facing role, I built my roadmap by talking with customers and partners, and vetted business ideas through experimentation. Each experiment and product tweak was a lever to pull towards the goal of increasing revenue.

I quickly learned that this product management style would not work in a platform world. Constant iteration and tweaking of the product is not only extremely difficult to do, but can also endanger the quality of the product. After spending time with users, I realized that this quick-hit iterative approach completely misses the point of what the users are looking for.

In a CMS platform environment:

• The business demands that the platform be a solid foundation upon which to run their products
• Developers need maintainable solutions that don’t require endless hours of QA for each upgrade
• Editors need to maintain a solid and up-to-date conversation with users, which requires stable yet innovative technology
• End users want web pages that perform well

Platform products need to provide a reliable and extensible experience.

Reliable and extensible platform products – how do you get there?

Quality Assurance

One of the best ways to provide reliable platform product is to maintain rock-solid QA.

In a platform world, bugs in code aren’t irritants that can be easily fixed by a quick push to production, but problems that break the fundamental systems upon which your users’ products are built. More so than in a solutions product environment, bugs erode user confidence in the product.

Platform product managers must find creative ways to lead QA to best regression test product to suss out bugs. Because others products are built from your product, platform products are, in the words of Marty Cagan, “a critical dependency for all of your customers/products you support… and there is no room for error.”

Long-term Thinking

The day-to-day experience of being a platform product manager can feel like walking a marathon. Unlike in a solutions product role in which products are iterated on and shipped constantly, platform products require longer release cycles, which means careful management of user expectations and timelines.

That said, there is a flipside to that idea. Platforms also need to be extensible so that businesses can rely on the products for the foreseeable future. Therefore, platform PMs need to be creative experts in their domain – able to think critically about their users’ needs while thinking creatively with their team about how to build a platform that allows for future growth and revenue opportunities.

Continual Reassessment of Priorities

Product managers often reassess priorities, making sure they are aligned with what will provide the most value. Platform product managers have so many constituencies that – in my experience – a reassessment of priorities needs to happen much more often than in a solutions-based product world.

For long-term planning purposes, platform PMs must remain in continual communication with each of the constituencies they support. This requires meetings, of course, but also multiple little conversations on Slack, email, within ticket comments, in the hallway, wherever. Platform PMs must remain open to continually running through detail after detail with their constituency, so that they support them in their day-to-day use of the product, and understand their long-term needs.

Conclusion

As Brian De Haaff, co-founder of product roadmap software company Aha!, says: “Working with several software products and services built upon a common platform is no easy feat.” It’s hard to focus on the less glamorous product management work of quality assurance and release management, maintaining steady effort and focus for the long term. That said, product management for a platform is just as challenging and interesting as product management for a revenue-generating solution. Whether the product directly affects revenue or provides a platform and tools that allow users’ businesses and products to thrive, it is great fun to build a product that allows its users to shine.