Separate your platform from your product

If you want to be a bad product manager, build your platform as you’re building your product. You know you want your products to work as a system (as described in Make Your Products Part of a System) and to do that you need to build a platform. The easiest thing to do is to build the platform at the same time you’re building your products. That way, you only have to undertake one project, and by doing it all at once you’ll make sure that you’ll include all of the requirements you need. Plus, you need to get your products out as soon as possible, and you don’t have time to wait while a platform is being built. By building everything at once you can save some time and get to the market faster.

If you want to be a good product manager, build your platform, then your products. Making your products part of a system is a good idea and having a common platform is the easiest way to help everything work together and be part of one family. It would seem to make sense to build the platform at the same time as the product, but there are two major reasons this can cause problems:

1. When you build your platform at the same time as you build your product, the platform will be biased to support the product you are building at the same time. The idea of a platform is for it to be product agnostic so that it can support anything in the system. However, when you are creating a platform at the same time, when push comes to shove, you will end up adding in features and capabilities that are needed by the product you are also working to create. Imagine you are building a platform to produce sponges. The requirements for the platform note that it should be able to support all different sizes of sponges, made from different materials, in different shapes, with different surfaces. If at the same time you are writing the requirements for an oval scrubber sponge, the platform will probably be biased towards producing oval scrubber sponges. When you try to produce a square soft sponge, you may find that the platform is not capable because it was not designed in a product-independent fashion. You can imagine how much more challenging it could be with complex software products.
2. When push comes to shove, the product will always take priority. Building a platform is a investment that will realize operational efficiencies, reduce time to market, and improve the ability to adapt and innovate — in the long-term. Facing pressure internally and externally, businesses often focus on short-term wins rather than long-term investments. The Product Strategy Network highlights this in their article A platform is not a pedestal:

It is possible, once a common platform is built, tested, and proven successful, that the time to market for incremental new products based on that platform will be significantly reduced. However, according to [Brandon Ekberg, business manager of the software & meters business unit of Eaton Corporation’s electrical group], that advantage tends to exist more in the realm of theory than in practice. “Problem is, I’ve never had the luxury of stepping back and building a platform from scratch without deliverables attached. Instead, you wind up trying to build the platform and release the end user products at the same time. If there’s anything I’ve learned, is that if it’s at all possible, go and build the platform, perfect the platform, document the platform, test the hell out of the platform, and then bring it back into your product groups for adoption. Because what typically happens is that you have a December deadline and you wind up finishing that platform development at the end of October or November and still try to make your December release. And that’s really difficult. That’s hard on everybody.”

So what is a product manager to do? Here are a few suggestions:

• If possible, separate the platform project from the product projects. Separate business cases, timelines, management and oversight will help.
• If it is not possible to separate them, decide up front what will be part of the platform vs. what will be part of the products. Create very clear rules for dealing with issues as they come up. Appoint a Platform Manager who has the authority to make the decisions. Include representation from all products who could potentially be using the platform to ensure buy-in from the very beginning.
• Alternatively, focus on building the product but pick specific elements to separate out as platform-level components. For example, if you are building a web site that will require login, and there are other products in the future that you are planning on building that will require login, focus on building your first product but ensure that the signon/login component can be part of that platform. Then, when your next product is being developed, you should already have one piece of the platform in place and you can work to develop other shared aspects, over time building a full platform.

This is certainly a challenging aspect of product management, and since these types of scenarios play themselves out “behind the scenes” within organizations, there are fewer case studies and examples of successful platform-product projects. The best way to increase your likelihood of success is to explicitly detail the reason for building the platform, the expected benefits, and the obstacles to achieving them. That will allow you to have an informed discussion with all of the relevant stakeholders to determine the best way to proceed.