A digital platform is an ecosystem designed to enable different groups to co-create value through “plug-and-play” capabilities – Wikipedia.
The technology infrastructure of the platform touches customers and developers beyond the firm’s boundaries. Simply speaking, when a company finds a similar suite of technologies for a multiple of its products, it makes sense to develop a common set of Utilities or APIs which can be used for equivalent goals but in different applications.
A Platform is by default a backend Product, and hence requires a bit different approach when it comes to the role definition of its Product Manager. While the need for a Platform may be different across organizations, the modus operandi for a PM more or less remains the same. A fundamental shift in thinking may still be required which could prove highly fruitful.
There are multiple aspects one may need to keep in mind before picking up the baton, some of which are discussed here:
Knowledge of Tech Stacks
Though the R&D needs to be done by the Development Team, a PM nonetheless needs to be aware of the latest and in-market tools and technologies, even if at a fundamental level. This is because she owns the big picture. For instance, if a platform is a high-risk experiment with uncertain outcomes, even though a Spark framework may make absolute sense to the Technical Manager, because of scalability and resource efficiency, but if that means hiring a team of Big Data Developers to even get started, and thereby delaying the timeline, the PM may need to reiterate the end goal, so that tech team could re-look at alternatives if possible. Though not a mandate in any way, it definitely helps if a Platform PM could speak the developer’s language.
Comfort with Internal Customers
A Platform serves multiple Products, which in turn serve the end-users. As such, it becomes crucial to understand the differences and redefine the usual processes. Feedback, Analytics, Release Management, and Benchmarking need to be customized, and well communicated to stakeholders. A Platform PM, in the end, could be serving Personas across multiple demographics, needs, and capabilities, sometimes totally unrelated because of individual consumer bases of different products.
A PM’s regular day is mostly spent in fire-fighting the unexpected, and it doesn’t get any better when the Product is a Platform. This happens because the big picture is not always clear. The end-user is not a direct consumer. Multiple products may require different specifications, and the onus lies with the PM to decide the ultimate intent, and then to select what goes in and what goes out of the Platform. The team could feel clueless at times, and here the PM should act as the doubt solver.
Being an inward facing component, most of the times, there won’t be a self-explanatory user journey, demo, or even a UI available. Thus, it becomes crucial for a Platform PM to document every story or requirement in an unambiguous, clear language, so even consumer teams could understand a process if needed. She should also be able to present ideas in a way that it registers with people having unrelated purposes in mind.
A Platform is built with a future in mind, and it requires one to be imaginative to assess goals and prioritize tasks. It also requires an infrastructure that should be future-ready. A Platform of any type, after all, is built to support and help grow further.
This article was originally published at Medium