Working on Platforms for PMs
We talk a lot about Product Management roles that are client-facing, but often times we overlook platform/service PM roles. In today’s industry, more and more companies are looking to solidify their competitive positioning by evolving their stand-alone products into platforms. As a result, platform PM openings will continue to expand & have increasingly larger impact within companies.
I had the opportunity to work with a team on building the first large-scale notification platform at Intuit, and it was an extremely challenging but rewarding experience.
Here are some high-level observations that I have made since working on these platforms.
Domain knowledge is critical
When I started working with the team on building out our notification platform, I assumed we could dive right in and begin executing. I quickly learned that there was a lot of foundational knowledge we needed to gather first.
The world of notifications is complex since it involves multiple delivery channels (email/push/sms), rules, and third-party integrations. Since the platform we were building was going to be used by the entire company, we needed to make sure we didn’t take shortcuts and built it correctly from day 1.
There is a similar amount of domain knowledge that I am trying to gather as I begin working on our partner platform. Because we are integrating partner content into our app, there are many legal implications with everything that we build. It has forced our team to evaluate how we set up our processes for shipping new features to market.
Ensuring that you have the proper domain knowledge before you dive into execution is a step that every PM should take when working on a new platform.
Scale over Speed
When you are working on isolated products, you sometimes have the ability to “move fast and break things.” However, when working on a platform, you often times don’t have that luxury.
Every platform should be built in a way that is scalable, since the cost of fixing mistakes increases exponentially due to dependencies. As we will get into in the final section, it can sometimes be difficult to convince all stakeholders that speed shouldn’t always take precedent.
Taking short cuts when building a platform may deliver short-term results; however, it will likely hinder the potential of the platform down the road. Having a strong lead architect and engineering team to support you can go a long way in communicating this message across the company.
Stakeholder Management is complex
As any experienced PM can attest to, one of the most complex aspects of the job is managing key stakeholders. When working on a platform, the amount of stakeholders multiplies beyond the typical amount you may be used to dealing with.
Platforms need to connect with different internal product teams, underlying domain services and third parties. Each of these areas will have key stakeholders who will want their requests solved for first.
Trying to find a balance between enhancing the foundation of the platform and solving for individual use-cases can be difficult. On the one hand, solving for end-to-end experiences can be helpful for building credibility around a platform. However, zooming in too far when working on individual situations, is how teams inadvertently take short-cuts that hurt the long term potential of the platform.
At the end of the day, you only have limited time and resources and there is always something to new to be built. As a platform PM, it is important that you help all stakeholders see the cohesive vision so that you can manage inbound requests and focus on the most critical tasks first.
Working on a platform can be an incredibly challenging experience, but also be an extremely rewarding one that can give you a leg up in the industry.
If you’ve ever worked on a platform, feel free to share your thoughts/experiences in the comments!