Platform Product Management
One of the most difficult – but highest leverage – types of product management is to define successful platforms. By platforms, I am referring to foundation software that is used by application developers to create end-user solutions. Examples include operating systems (e.g. Windows, MacOS, Palm OS), operating environments (e.g. Java, Flash), Web services (e.g. Amazon’s or eBay’s integration API’s), and game developer platforms (e.g. XNA).
Before I go further, it’s important to point out what is not a platform. There are too many so-called “platforms” out there that are really just unfinished products. The team didn’t do the work required to provide a complete solution, so they market it as a platform and push the work off on the customer or a developer to finish. If you don’t have multiple commercial software products or services built upon your software then you’re not a platform in the sense I’m describing.
But assuming you are, then you know how difficult platform product management can be. To begin with, there are three very different constituencies:
– The application providers are the businesses that choose to use your platform to build their solution.
– The developers work for the application providers and they write their software using your platform services.
– The end-users are the ones that run the application provider’s products and ultimately use your services.
Each of these three constituencies brings very different needs and requirements. You simply can’t be a successful platform without meeting the key needs across all three.
The application provider is going to be concerned with business viability – their viability if they use your services, and your viability in case you go out of business or discontinue support for the platform. The application provider cares about your pricing, licensing, quality, support, and global availability, among other factors.
The developers are looking for services that make it easy for them to quickly create maintainable, reliable code in the languages they want to use, working with their favorite tools and infrastructure, on the devices they need to deliver on.
The end-users care mainly about the end result. If the features and services they want aren’t there or don’t work in the way they need, they don’t buy the application, which means the application provider fails, which means you lose a customer and eventually you fail too.
One of the biggest mistakes that platform product managers make is in the prioritization of the three constituencies. The developers are the most vocal group and the easiest for the company to relate to, so they usually get considered first. The application provider is the one writing the check so they come close behind. But the end-user is often so far removed from the platform provider that they rarely interact directly. Unfortunately, this is precisely the reverse of what’s needed. It is a big (but common) mistake to optimize for developers over the end-user. It is ok for the developers to work a little harder if the application is something the end-users like and use, versus making the developers happy but nobody wants the end result.
Countless platform-wannabees made this mistake. The reasoning is very simple: I’m a developer; I know what other developers want; so I’ll create something to help both my colleagues and myself. I would have to include Client-side Java in this camp. Great development environment; terrible user experience; terrific opportunity for Macromedia.
Many extremely successful platforms have been downright awful for the developers. But they succeeded because of compelling value to the end-users and therefore to the application providers. You don’t have to look further than early Windows for an example of this.
I’m not advocating platforms that make life miserable for developers, but product management is all about choices and priorities, and it’s essential to understand that the delivered application is what matters the most.
There are other important dimensions to platform product management that make this area challenging. For example, there are many different delivery models (e.g. embedded, private-label, co-branded, hosted) and many forms of customization that may be required (e.g. end-user, customer’s IT, solution provider/SI, vendor, source-code). Each of these is an article in itself.
Support is also very difficult for platform providers. The bar is high as you’re a critical dependency for all of your customers. That said, the great thing about working on platforms is that they’re very high leverage and if you do it well you can create a thriving ecosystem where you and your application provider partners succeed together.