In my first months as a (Junior) Product Manager (PM), I attended courses, read books, and listened to many great podcasts to learn all the skills it takes to be a great PM. I quickly found myself adapting a lot of these tools and processes that I believed PMs use in their day-to-day. Agile, Scrum, writing user stories, arranging my product backlog. Creating roadmaps and strategies, analyzing data, A/B testing, and product discovery. All these practices can make your life as a PM easier. Strictly following them, however, doesn't make me a great PM. The most significant thing I learned in my first year as a PM is that one of my primary responsibilities is to communicate—both with the team and my stakeholders.
There is no overcommunication.
Communicate with your stakeholders.
I work on an internal product used in many of our global warehouses. And when I started as a PM, I didn't align well enough with my local and international colleagues. Roman Pichler's Strategize taught me that no matter how well-thought-out your product strategy and roadmap are, they are worthless if the key stakeholders don't support them. Be diplomatic. Involve your stakeholders in strategy and roadmap refinements. In the end, you'll feel much more in control of the product if you are vocal and open about what you do.
Don't forget that collaboration requires leadership. As the person in charge of the product, you should lead the strategy-validation work. (1) Don't shy away from difficult conversations, and (sometimes) be critical towards your peers. It's okay to disagree and stand behind your view. Have the courage to make a decision. And if people can't agree, use data to back it up. This learning also crystallized in the escalation of critical incidents. In our domain, if something is not working, it usually affects thousands of workers, resulting in production stops across many warehouses. And these cases, it's great if I know the root cause of the issue. But it doesn't help any operations managers if I keep it to myself. Even more important, they don't care what's going wrong. They need our product to work. They need a solution. So let them see that you're putting all your attention on this problem. And always keep them in the loop.
My stakeholder management is still not perfect. But what I'm trying to say is that there is no over-communication. I've never reached a point where my stakeholders came to me and said: "Leon, stop updating me on all the developments that are in progress." Or, "I know too much about the bug paralyzing our production." Thus, keep them informed. Because the one thing they can't neglect if they're informed is that you're on top of it. Be like glass, not concrete.
Communicate with your team.
The first book I ever read on product management - Jeff Patton's User Story Mapping - was all about building shared understanding. Patton argues that even though we put stuff in writing to communicate more clearly, way too often, the opposite is true. Shared documents aren't shared understanding (2).
Product management was nothing they taught me at business school. The idea that documents can waste your time devastated me. So I ignored it. I spent half a day writing an extensive 10-pager and found myself in either of these 3 situations; a) nobody read it, b) it created even more confusion, or c) it was interpreted (and worse case executed) in a dozen different ways. Eventually, I was open to exploring new processes. So, I did what felt natural: I took my documents and copy-pasted them into Jira stories. This obviously didn't solve anything. In retrospect, I can say that it's not about the processes. It's about the content AND alignment. It doesn't matter if you use Google Docs, Jira, or sticky notes. If you create stories on your own, you and your team will never get to a common denominator.
Today, we meet in person and map everything that has been said on a shared Miro board. It can be revisited and creates the shared understanding needed to build the right things in the right way.
There is always more to build than there is time and money for.
Your goal should never be to build it all! (2). In my first months as a Junior PM, I made a common mistake. I said yes to too many things. Feature requests, improvement ideas, random restructurings, and so on. I thought we could do it all and didn't want to disappoint my stakeholders. So we started hacking things together, building some of these features and creating sub-branches that were never used anywhere. (Even though the users initially demanded them sooo badly.) When I found myself in this feature soup, I discovered Patton's book. I realized that our team's duty isn't to build more software faster. It's to maximize the outcome and impact of what I choose to build.
Today, I still listen to my users. Yet, whenever someone comes to me with a set of requirements, I challenge them with simple questions to identify the underlying problem.
- Who are those changes for?
- How are they going to use this?
- What problem does this solve for them?
- How does it impact the business?
The idea is to keep asking questions until you are satisfied with the answer. Always look for the problem. The initial idea doesn't matter. It's about how obsessed you're with identifying the problem. Usually, if the requester cannot give you answers that satisfy you, the "requirement" might actually not be very urgent or valuable at all.
And if the answers help emphasize the user's pain points, you still don't have to fall into the trap of building something. Stick to your product strategy. Go to the balcony. Take a time out and tell them that you've to think about it. (As a Junior, I have the privilege to say that I "needed to consult my manager" before making a decision. Even if that is not the case, it gives me the space to reflect on what has been said). Yes and No are essential phrases, but another really important one sometimes is "Wait a minute." Giving you space to reflect before answering can make all the difference between a reactive Yes and a Proactive No (3).
In my day-to-day, Warren Buffet's famous avoid-it-all-costs lists help me to focus on the most valuable initiatives. Every month, I write down everything that comes to my mind, every project, feature idea, and problem statement I could tackle next. Usually, it's a list of between 20 to 30 items. Then, I reflect on which of these add value and pick the top 3 I'll focus on. For these items, I define what success looks like. I put everything else on an avoid-it-all-costs list, as Warren Buffet suggests you do.
If any junior PMs can add more perspective, please reach out.
References (and also book recommendations)
(1) Pichler, Roman. 2016,Strategize.
(2) Patton, Jeff. 2014, User Story Mapping.
(3) Ury, William. 2008, The power of a positive No.