The challenging role of internal platform product management

This article is about being a technical product manager in an enterprise serving internal stakeholders. I do not cover the role of a product manager governing an externally facing platform product.

At the beginning of 2019, I moved away from my role as a QA architect into a nascent position as the platform product owner. Product management is a rewarding role when you have a tangible product. When your portfolio is a wide agglomeration of products in maintenance mode and a large backlog of dreams with no alignment of what to build it can be frustrating waiting for alignment and feel disillusioned. It feels like internal platform product management is a daunting product management position that given enough patience can be rewarding. There is a great opportunity in the enterprise to create value by improving a wide swath of how work is done. Achieving results on that backlog is another story.

To be successful in this role you must be tenacious in pursuing monumental long-term goals. All the while keeping your team motivated and not letting the doubts of others deter your progress. While I read product management books and articles online I was not prepared for the unique circumstances of the role. The skills I learned can help you avoid painful lessons that I encountered on my journey.


The job of the product manager is to tell the story of the product. What happens when that product portfolio is a little bit of everything ever made? Or the tools and products that people mostly “must” use? What if you have passionate stakeholders that want a new platform and development time spent on it while all enterprise resources are fully committed to a months-long data center migration. You end up living an exercise in futility and many long conversations around what could be.

I cannot tell you how many times I entertained the discussion of setting up a shadow platform development team. Is it possible to staff this? Sure! Would it be successful? NO! It’s called DevOps for a reason. An island of software developers cannot create a platform in a vacuum especially if you for some reason are like me and do not leverage the public cloud much at all. You need alignment in an organization to achieve major results and one product manager cannot align all of IT leadership. It is not possible as one person and it is not a fast process. What you can do is communicate via a roadmap but eventually, you and your stakeholders will realize that the roadmap is stymied and active requests are not being worked on.

I created multiple roadmaps for my teams illustrating months of limited to zero progress on big future efforts because of toil and lack of access to the means to make an impact for these two teams on requested features. This caused significant consternation for parties involved and their frustration in not seeing requests completed finally led to a change in staffing and alignment around our goals. If you are in this role I cannot overstate how important it is to embrace failure.

Do not be afraid to fail or attempt to be a hero to avoid failure. Often we think of negotiation as a skill to get opportunities but it is also a helpful escape hatch to leave dead-end projects. While I did not find the perfect way to fail that did not irritate everyone involved in failing I achieved the goal of convincing the people involved to change a system that was not working.


While on this frustrating journey I reached out to experts like Paul Ford, Clement Kao, and Matt LeMay and their advice started with gaining alignment first then working on big challenges. In fact, in the book Product Management in Practice, Matt LeMay writes, “a product manager cannot succeed if there is not clarity among senior leaders about a company’s strategy and vision.” Ultimately, as a product manager or owner, you do not control what senior management does but you can point it out and assist your boss with navigating the long process to drive alignment. Routinely communicating the desired outcomes and goals for the business can go a long way towards encouraging others to change how work is being done.

Failure happens. While you shouldn’t seek to fail there’s no reason to avoid it if the systems you are working in are broken. When I stepped into my role it became clear that some systems in place were failing and early expectations were for me to exert herculean effort to maintain that effort. I chose to let failing systems fail. It cost me some reputation points for a few months but I recovered none the less. I wish I knew an easier way to extricate myself out of the position but I did not have a clear idea of what a better proposal could be.

Time fixes all things. There was a perception that I was the roadblock for other’s success by not assisting with low-value projects and using the platform team’s time for these random projects. When we did eventually find alignment and my great team working on DevLab delivered a prototype then weekly updates and all apprehension disappeared. Now that my project is a smashing success I have the leverage to dedicate time to more high-value enterprise projects and hold others accountable for their progress outside my team.

Stakeholder Management

There were multiple times in this journey where I created more problems for myself than I needed to. It is possible that due to my deep background in technology and understanding of how and what seems easy or not. This became a problem when working with some stakeholders. I regret I did not come to my work with a “beginner’s mind” and let the process work for itself. This process is a level of delegation I am still working on improving. With software any request is possible and as a product manager I struggled to say the words, “I hear you” even when the requests were extreme or unrealistic. I am learning to rely on the experts around me to advocate for the best solutions. Listening and repeating what others say what they want and leaving it up to me and my team to decide if it is something we can deliver on and offer.

To this day I am not sure what stakeholder management is? The purpose of this management is not to make everyone happy. The role might be to act passionate and engage with ideas while showing everyone you are trying so hard but some person somewhere is stopping that feature from being worked on. Everyone has great ideas and important things to work on there is not enough time and thought to put into all these great ideas. It seems best to be the foolish sap that tries their darndest to get things done or get it right but cannot seem to figure it out. How am I supposed to do this, my friend? I am still trying to figure that out.

How to be successful in platform product management

  • Communicate what is successful and what is not
    • All other communication is trial and error just keep trying and something will stick
  • Manage up for alignment
    • Expect this to be a long ongoing process and at times there will be backsliding but it can be corrected a week at a time.
  • Smile, listen, and say, “I hear you”, and do not build what people ask for