2 things I learned in my first year as a (Junior) Product Owner
I don’t know what I think until I’ve written it down. — Flannery O’Connor
Disclaimer: I wrote this article for myself. To figure out stuff while I am executing. To reflect, and to learn. I came to believe that the writing process helps me to crystallize the chaos in my mind. It can only get better, so if you want to share your tips and feedback with me, feel free to leave a comment.
There is no over-communication.
In my first months as a Junior Product Owner (PO), I attended courses, read books and listen to a bunch of great podcasts to learn all about the skills it takes to be a great PO. I quickly found myself adapting a lot of these tools and processes that I believed POs use in their day-to-day. Agile, Scrum events, writing user stories, arranging my product backlog. Creating roadmaps, strategies, analysing data, A/B testing, and product discovery. All these practices can make your life as a PO easier. Strictly following them, however, doesn’t make me a great PO. The greatest learning in my first year as a PO is that one of my main responsibilities is to communicate. Both with the team and my stakeholders.
Communicate with your stakeholders
I work on an internal product that is used in many of our global warehouses. And when I started as a PO, 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.
But don’t forget that collaboration requires leadership. “As the person in charge of the product, you should lead the strategy-validation work.” (Pichler 2016) Don’t shy away from difficult conversations, and (sometimes) be critical towards your peers. It’s okay if you disagree and stand behind your view. Have the courage to make a decision if people can’t agree, and use data to back it up.
This learning also crystallized in the escalation of criticals. In our domain, if there is something not working, it usually affects thousands of workers and results in production stops across many warehouses. It’s great if I know the root cause of this issue, but it doesn’t help any of the 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.
To be honest, 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 that is 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. That you truly own your product.
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 (2014) 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.”
Product management was nothing they taught me at business school, so the idea that documents can waste your time devastated me. So I ignored it. I spend 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 x different ways. Eventually, I was open to exploring new processes. So I did what only felt natural to me: 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 + alignment. This means that it doesn't matter if you use 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 that is needed to build the right things in the right way.
There is always more to build than there is time and money for.
“So your goal should never be to build it all!” (Patton 2014). In my first months as a Junior PO, I made a common mistake and 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 soo badly.) When I found myself in this feature soup, I discovered Patton’s book and realised that our team’s duty isn’t to build more software faster. It’s to maximise the outcome and impact of what I choose to build. (Patton 2014)
Today, I still listen to my users, but whenever someone comes to me with a set of requirements I challenge them with some 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?
Then again, if that doesn’t work, you can use the 5-why-method. 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 you emphasise the user's pain points, you still don’t have to fall into the trap to build 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 line 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 one that is really important sometimes is ‘Wait a minute.’ Giving you some space to reflect before answering can make all the difference between a reactive Yes and a Proactive No.” (Ury 2008).
In my day-to-day, Warren Buffet’s famous avoid-it-all-costs lists help me to create a focus for the most valuable initiatives. Every month, I write down everything that comes to my mind, every project, feature idea, and problem statement, that 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 that I’ll be focusing on. For these items, I define what success looks like? (This is crucial so you don’t lose yourself in this project). Everything else, I put on an avoid-it-all-costs list, as Warren Buffet suggest you do.
Any Junior POs who can add more perspective here, please do in the comments!
References, (and also book recommendations)
- (1) Pichler, Roman. 2016, Strategize.
- (2) Patton, Jeff. 2014, User Story Mapping. O’Reilly.
- (3) Ury, William. 2008, The power of a positive No. Hodder Paperbacks.