Platform Product Management and Beginning Transformations

Platform Product Management

The role of Platform Product Management has been around for years in the technology space. Each business has its own version of this role and it may look dramatically different in each company. Will Larson’s blogs on Infrastructure Engineering are the closest to what I am facing in my day to day. I live and breathe technology. I love learning about it and using it and providing solutions to tough problems with it. There is always the constant frustration that I could be using much more but realistically the apetite for change and adoption of new tools in an organization is extremely limited. There is only going to be a few major shifts one can adopt in a year that people can use successfully. Otherwise a tool is not adopted or poorly adopted.


Bringing in tools is the start of the story. I have seen many tools brought in and they lacked any type of training and followup. Which caused those tools to either wither or cause teams to lose their trust due to lack of knowledge. In a business doing anything new or different requires a significant amount of planning and work even for a real simple easy win. It’s frustrating but part of the process of change. The term “Digital Transformation” is trite but I do feel it is accurate for today’s businesses that are not technology first. The future is with us now but adopting the tools and changing processes is extremely challenging and fraught with failure from multiple angles.


In this new role of Platform Product Managment it is easy and hard. In traditional product management there is a lot of discovery, product-market fit, and iterating on an idea. I think that whole cycle is uncomfortable and challenging and I appreciate people that feel comfortable with that. Platform is hard because at the scale that makes it high-leverage communication between groups of teams is extremely challenging. Working in small marketing organizations I tended to sit close to our system administrators. There was not any barrier between us and trying things out was easy and low risk. Now for anything I want to try managing many different perspectives of people that lack the empathy of other departments.


It is natural to become an expert in one’s realm and begin to neglect what others might be experiencing in their roles. If you rely on other groups to provide resources to do tasks and you are not colocated then it can be easy to create an us vs them relationship without seeing the constraints on both sides. One conversation I had was the mirror images of the platform groups. One is focused solely on software development while the other team is primarily focused on the operational work with much less software development. I had a conversation with a Software Technical Architect that drew the typical Software Development coding pipeline. Build, package, release, deploy and we started talking about “services”. However, I became lost. What do we mean by services? Even a word as simple as that the meaning changes dramatically based on the department. In this case it meant API endpoints but in general in the operational world that is not their typical understanding or the default. That could mean operating sytem jobs such as crons/windows services etc.. It could be offered but much more rarely than what a software development team might offer in my case.


I am hopeful in the next year platform could mean something powerful for my teams that I support. I want to be able to provide great offerings but I’m increasingly hesitant on what is possible in a year. It’s frustrating but there is only so much time, so many resources, and what I thought in my early career was a limitation in creativity was actually my own lack of understanding about how difficult it is to offer anything at all for others to use in a reliable way.