Inward Facing Platform Product Management

Inward Facing Platforms

Every business has some form of an inward facing software development platform. It might look like infrastructure as a service, an assemblage of ingredients or it might be leveraging cloud services offerings like AWS or Heroku directly. Your business may or may not have product management representing these concerns. It could be fostered by infrastructure staff or software engineering managers. I have only seen a handful of posts online about the role of the inward platform product manager. Unless your business is growing or scaling significantly your platform may shape slowly and the details not that important until your run into challenges. The offerings on the market as part of the public cloud or VMWare are good enough for most businesses and do not necessitate much enhancement.


I work at a good size mortgage company that is growing and the foundations of creating a new platform stems out of a desire for a service orchestration platform. Around 2017, Microsoft unveiled and open sourced the service orchestration platform it built Azure on, Service Fabric, and there was a lot of buzz and excitement because many people saw the simplification of running applications on such a platform. At the time I was in a QA Engineer role and tried to push forward discussions on whether Service Fabric was possible for us at the time with our existing infrastructure staff. We had training, a task force with engaged developers, and brought in some additional Microsoft training. Ultimately the timing was off and there wasn’t staffing or commitment from our infrastructure group to accomplish this.


At the beginning of 2019 I moved from QA Architecture to becoming a Platform Product Owner. A significant portion of 2019 and 2020 was building alignment across Technology Leadership driven by my boss. Leadership settled on three major initiatives. One of those major initiatives is the “Developer Platform”. While we agreed and pledged commitment to the developer platform nothing came of it for months. Around the point we hit 100 software engineers on staff the question became, “What are we doing to fund the developer platform?”.

I found the book “Team Topologies” incredibly helpful in describing what we were trying to accomplish and it suggested some models to implement how we would go about organizing teams. One challenge I run into is the Platform Engineering group is inundated with operational requests constantly. Another challenge is the developer experience team developed mission drift and increasing cognitive load of diverse applications to support. The concept of a team with a mission and a deadline helped establish for some stakeholders reasons why some requests would not be worked on. Ultimately, we shifted teams around to reduce their cognitive load across too many concerns and missions.

I also found the writings of Will Larson especially “How to invest in technical infrastructure” helpful. Camille Fournier also has a great article on Product for Internal Platforms which sums up the role really well. I had a hard time finding good articles on this role since there are many meanings of platform and it is a difficult concept to search.

From transitioning to the role to the present there have been a variety of communication challenges. Communicating platform improvements to business leaders without requiring them to have technical expertise to understand what we’re trying to accomplish. When I presented to the broader business, I used the analogy of the platform being a base camp to re-provision and to repair and replace one’s shoes with something more high powered like winged boots. Recently I explained our current platform offering is like delivering the ingredients of a cake for teams to assemble into an edible cake. In the future we want to deliver the whole cake and enable the software developers to only add the frosting (application).

While I would love to end this with a simple set of steps to get your organization working on the development platform overall the key elements were gathering alignment and timeliness. The growth of the company hit a critical mass where we did need to commit to working on something to fix the problem of scaling our development processes. What did help build alignment and understanding over time were also a lot of other activities done over time. Defining the status quo, setting a vision, backcasting. This book Technology strategy patterns has many great strategies that can be applied to drive change in an organization. It is unfortunate that I stumbled upon it so late.

  • A vision statement across technology departments
  • One-page summary documents explaining a topic or direction
  • Sharing of decision mental models
  • Mental models of platform options (status Quo, enhancing the current platform, leveraging cloud, and investing in a completely new platform)
  • RACI’s for every new technology addition to make the roles and responsibilities clear
  • Business Case for re-platforming
  • An in-depth writeup on enhancing the current platform and the trade offs it would cause
  • Lots of one-off discussions