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 started in the tentative position of a platform product owner. Product management is a rewarding role when you have a tangible product. Patience and tenacity are central to success in this role. You own a wide variety of products that you can unify via purpose and initiatives. There is an opportunity in the enterprise to create value by improving the systems and processes of doing work. 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, I was unprepared 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 competing commitments? Passionate stakeholders want a new platform and development time spent on its creation. 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. Cross-functional alignment in an organization achieves results. One product manager cannot align all of IT leadership. Alignment is not a fast process. You can communicate via a roadmap. In time your stakeholders will realize that the roadmap progress is glacial. New requests are not making progress.
I created multiple roadmaps for my teams depicting months of limited to zero progress on future efforts because of toil and lack of investment. Lack of progress caused significant consternation for parties involved. The frustration in lack of progress 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. It is also a helpful escape hatch to leave dead-end projects. I did not fail as well as I would like. I did achieve my goal to convince others to change a system that was not working.
While on this journey, I reached out to experts like Paul Ford, Clement Kao, and Matt LeMay. Their advice started with gaining alignment first then working on significant 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 work processes.
Failure happens. Do not seek to fail. On the other hand, do not defer the unavoidable if you are out of options. When I stepped into my role, it became clear that some systems were failing. Early expectations were for me to exert herculean effort to maintain that situation. I chose to let failing systems fail. It cost me some reputation points for a few months. I recovered nonetheless. I wish I knew an easier way to extricate myself from the position. 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 my team aligned and delivered a prototype all apprehension disappeared. Now 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.
There were multiple times in this journey where I created more problems for myself than I needed to. It is best to put your expertise aside and approach with a “beginner’s mind” and let the process work for itself. In software development, any request is possible. As a product manager, I struggled to say the words “I hear you” even when the appeals were extreme or unrealistic. I am learning to rely on the experts around me to advocate for the best solutions. Creating a process that demonstrates listening helps evaluate the risk and decision on whether to pursue the opportunity. The team can 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 to help despite circumstances stopping that. 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.
- Communicate what is successful and what is not
- All other communication is trial and error. Keep trying. Something will stick.
- Manage up for alignment
- Expect this to be a long ongoing process.
- Smile, listen, say, “I hear you,” and do not build solutions people bring to you.