Most probably every job appears differently in real life, than by the book. Over the time we uncovered some real life product owner challenges which can be observed quite frequently. In this article you will learn how we tackled two of them.
Dear Product Owner, you are lucky enough to act in a very interesting, challenging, and creative role. You can make impact with the ideas you are putting into a product and you can help and enable teams to deliver rocketing solutions.
Besides that there also comes a lot of challenges and even pain along with this role, unless you have built up lots of PO superpowers already.
When will it be done? – Forecasting feature deliveries
Most of the time, this is asked by Product Sponsors. Basically, there is absolutely nothing bad in the question itself. Sometimes though, people expect you to answer this question for a very big timeframe. In the worst case scenario, it is not even formulated as a question, but rather comes along with a desired date at which the full scope shall be delivered with a predefined budget. If you are facing that circumstances, you are in a difficult position.
Usually, agile coaches would insist on the following in the first place: "You have to educate your product sponsor in agile principles and mindset. There is no way of having a fixed scope, budget, and timeline in agile. Your sponsor needs to understand that."
I fully subscribe to that. Still, However this does not help you as a PO in that particular situation. You obviously cannot facilitate your C-Level sponsors with this kind of thinking in a short term. This needs to happen continuously, on the long run. So, what you can do to improve your situation?
My first recommendation is, tell him/her honestly, that there is no way in this world, to answer it correctly. This is basically why we are, at all, following agile principles. To adapt to changing situations, to have short cycles with incremental improvements, to do the most important things first, and to continuously invest on finding out what are the most important things, on the go. Unfortunately, this will most probably not satisfy your sponsor.
So here are specific actions, which served me quite well:
- Shrink the timeframe, for which you must do predictions. When asked what of the desired scope, overall, will be done in 6 months down the line, you will not be able to give a reasonable answer. If you manage, to somehow communicate predictions for the next 1-3 months, for sure your forcast will be more reliable. Of course, depending on the maturity of the team(s), the timeframe can vary.
- Create "Feature Boxes". As feature Box I consider a cluster of features that belong together topic-wise. For example a Feature Box in a banking application can deal with cards management. So you will have features like locking the card, reordering the card after it has been lost, changing the card pin, etc. in this particular Feature Box. Stick to forecast not all features of a particular Feature Box, but rather prepare the backlog for the most important features per Feature Box. Draw the line below the items, you are certain about to get delivered. Do it for more feature boxes, so that you can at least be sure to cover a broad improvement area.
If you have a trustful relationship with your sponsor, for sure she/he will be OK with giving that approach a try. But do not overcommit! You need to stick to your commitments, to build up and keep the trust.
When will MY feature be built? – Managing Stakeholders
You most probably won’t get asked this question by your sponsor, but rather by stakeholders. If you are about to build a large product, you will have many stakeholders. Of course, each of them has some interests in being part of the game, and most of the time, every stakeholder is sure, that the features and requirements he/she brings to the table, are the most important ones. That is why prioritization is essential, but difficult. To further enhance your skills in managing stakeholder expectations and navigating through challenging discussions, explore our insights on 'How to effectively prepare for meetings', where we offer strategies to maximize the productivity and outcomes of your meetings.
Most agile coaches would recommend in this case: "There is no such thing like 'my' feature or requirement of a stakeholder. We are building a product together, so people should be open to requirements, regardless their origin".
Same story as above. I fully support that, but again that often does not help you immediately as a PO in your current situation. You can change the mindset of the people just over time, not ad-hoc. Still, you need to work with what you have right now. Embracing Agile Transformation can equip Product Owners with the strategies and frameworks needed to navigate complex stakeholder landscapes.
The following things turned out to be effective and well-accepted by most of the stakeholders.
- Define entry criteria for feature suggestions. I observed in a lot of stakeholder meetings that stakeholders are elaborating over the features they suggested right in that particular meeting and not before. So, these meetings tend to become more of a brainstorming session, where the stakeholders try to get clarity over their needs.
- Often, the result of this thought process is the definition of a technical solution rather than the definition of the purpose and goals of the feature itself. The problem about this behavior is, that you do not get sufficient information for prioritizing one or the other feature. To do prioritization, you need information about the goal, purpose and business impact of the proposed feature, and not information about the solution itself.
- Additionally, you want to put features which your product should incorporate on the backlog, and not pre-defined solutions, to foster the innovation capability of your team.
- So, I learned that defining entry criteria for features helps very much. I used this entry criteria like a business case for each feature. Stakeholders needed to come up with a clear definition of the value this feature should generate, or even a clear goal how customers would benefit from this feature. Demanding this information makes Stakeholders think more about the "what" and the "why" instead of the "how". Providing this information is the pre-condition for this feature to be discussed in the Stakeholder meetings.
- Avoid 1o1 sessions with stakeholders. Stakeholders will always challenge the prioritization of the backlog, unless their item is on top of it. So, it is in the interest of every PO to make the prioritization transparent for everyone. Therefore, it is a big disadvantage to discuss items with each stakeholder one-by-one.
- If you managed to get your stakeholders do define the above mentioned entry criteria for feature suggestions, it makes sense to discuss all their items in a joint meeting, as they are well prepared. There are tools that support the prioritization in an intuitive manner.
- What I like to do, is to get a rough size estimation by the team(s) for the items (as far as this is possible), and an anticipation on the business impact by the PO. For a collaborative meeting you need to prepare some graph to show all features. On one axis you will show the business impact, on the other axis the size (which basically boils down to cost). For that session, the size is given and not negotiable , since it has come from the team (which did a rough size estimation based on a solution idea derived from the feature entry criteria). The business impact, though, should be discussed and understood by the other stakeholders, as well as put on the graph jointly into the right position. After you got a common understanding about the items on the graph, there will be a quite clear picture, of what will get the highest priority.
This is how I tackle the challenges mentioned above . Of course, depending on the environment and people involved, adaptations are required accordingly.
I hope this article gave you an additional perspective and maybe you will even try one of the things.
If you need help with you PO life, or if you want to give feedback about the shared content, I would be happy to receive mails at manuel.klein@squer.at.
