Introduction

This article is a continuation of a previous article on practical tips and techniques that I have used as a Product Owner (PO) for many years. In the precious article I had categorized my overall experience into 6 buckets:

1. Ideation of features (discussed in the previous article))

2. Prioritization of Work

3. Product Backlog creation and maintenance

4. Stakeholder Management

5. Team Management

6. Product Metrics Design and Management

For this post, I will be concentrating on Prioritization of Work and Product Backlog creation and maintenance. I will try to cover up the other topics in a future post.

Prioritization of Work

Once you have a list of requirements in hand, it’s of utmost importance to do the prioritization of this list to determine what work to take up and when. How well prioritization is done is what differentiates a new and experienced POs.

In my case when I started doing product ownership, I was really bad at prioritization. I used to mostly prioritize work that I found interesting. I used to prioritize expensive (effort wise) features that, in my opinion, will change the way users use the product. I was always sure that the “feature” will be a “game changer” or revolutionize the product.

This is where guidance or mentorship from a senior PO or Product Manager comes handy. If one has a good and helpful PM or mentor with whom they can discuss their ideas, it really helps. They will be able to see that a lot of their ideas that they think will be a “game changer” can probably be done at a later time or in some cases realise that end users simply do not need it. It always helps to discuss your ideas with others, especially those who disagree with your idea. This helps as it forces you to take feedback and not think in a silo.

Learning it the hard way

For me, I had to learn the hard way what I was doing wrong. I prioritized building features that were “cool” and I liked versus those which end users actually wanted or had been asking for some time. I was very fortunate to have worked under a Senior Director who used to give a lot of leeway to new POs like me. He used to let them completely own their products and left almost all decisions of the products. This led to POs having a lot of freedom and taking more initiatives. It also led to them making lots of mistakes as well. And like me, they all learned from their mistakes and became much better POs.

Back to prioritization. Over the years I realized that prioritization of seemingly “cool” features is extremely foolish. As I had mentioned before, a cool feature may have zero adoption from the end user side. I learned this the hard way after multiple “cool” features fared very badly when usage metrics were checked. But in cases where we implemented a seemingly “boring” looking feature we saw significant increase in usage metrics as well as appreciation from end users.

Key Learnings and Takeaways

If you are in a team where the product roadmap is fixed and you have priorities set by the senior management, then features related to those priorities come first.
For example in my case, the product’s migration from on-premise to cloud movement is something that was fixed and defined in the product roadmap, and we had to work within its set timeline and priorities.
Ask yourself, Is the new feature you are considering just something “cool” that you want to implement or is it a genuine end user requirement. Be honest about this. It’s also easy to lie to yourself. I have done it in the past.
What is the effort involved to build this new enhancement? Does it have dependency with other teams? Will that other team have the bandwidth to pick up the work related to the new feature?
Come up with real-time data to justify the prioritization of your feature. Be honest and be ready to change your mind if the data does not match with what you have expected. Many times the data doesn’t meet your expectations.
In case you have multiple features to implement, one solid point to start is how many end users are impacted by the change. Also, how many users have asked for this feature?
Talk to people
1. Sometimes you can have tunnel vision about the requirements. As much as possible, validate your prioritization with other/senior POs, and your own team members. Take their feedback. Don’t be afraid to get multiple opinions
2. Have discussion with all members of your team. They work with the product daily and generally have a good understanding of the product. You will be pleasantly surprised by ideas on what is important and what is not.
3. Over the years I have found that discussing upcoming features with your team generally helps you in prioritization as you get to hear multiple view, supporting as well as contradictory

8. Consider learning and using prioritization frameworks like RICE framework.

Product Backlog - Creation and Maintenance

Creating and maintaining the product backlog is an important function of a PO. It’s important for the team as well. It gives a place where PO can categorize and bucketize the incoming feature requests and make sense of them. For the team, it serves as the roadmap of the future of the product.

There are different levels of backlogs - Epics, Features and User Stories. Some POs just use User stories whereas some use Features and User Stories both. In my case, I used to work with all the 3 levels. This gave me a much finer hold on defining The Why and the How of the product.

Story of the Product

Epics are very important part of the overall product backlog as they represent the “story” of the product. I have used them for story telling and show what is the current vision and long-term strategy of the product. I also made sure that the Epics were divided in such a way that showed the path the product has taken in the past, the journey the product is currently on and the future of the product. Further on Features and User stories gave me the flexibility of defining the “story” in more granular details.

Key Learnings and Takeaways

Make sure the Epics you create have broad scope and are well thought out to accommodate future features. This also helps in cases like change in priority of an existing features. Or sudden need to accomodate a new high priority feature.
Any new requirement that comes in generally should fit in into one of the already define epics. If not, then maybe rethink the requirement. Or try breaking/modifying the requirement to fit the narrative of the epic
In some cases, you may get some requirements that may not fit into any epic. In that case, maybe create a backlog epic and link the requirement to it
Its also important to close the Epics. After one point let’s say you are done with more than 50% of the features in an epic, do not add any more features to the epic and move towards its completion. If you keep it open for long and keep adding features to it, the epic will never complete
Once after the team has achieved a major milestone, I always used to have a discussion with the team about the product backlog. It has the below benefits:
1. It gives you an opportunity to show the team what they have achieved and how their work is contributing towards the overall success of the product
2. It gives the team a sense of closure about the work they have been doing, maybe a few months
3. It gives the team an overall idea about the future of the product and what are some of the upcoming things features
4. It keeps all team members on the same page. Even when interacting with other product team or higher management, they will never be surprised. They will always have visibility about whats next
5. It fosters transparency within the team and eventually leads to trust within the team
Review and clean up your product backlog at regular intervals. Consider moving features from one epic to another if it makes sense and fits the overall product strategy

Please let me know your thoughts on these tips and techniques. I know that they may not be perfect and would like to improve. Please feel free to drop me a mail at gouravmoy.mohanty91@gmail.com

Thanks for reading. I will be writing a follow up blog post for the other points. Stay tuned!