Four principles to help a starting Product Owner

Joining a project in the middle as a Product Owner can feel like getting on a moving train. It's new, a bit scary, and there's a lot to catch up on. But, knowing what to expect can help a lot. Let us first look at how the situation where you are jumping to, probably looks like. I will describe three inevitable things you will encounter. And then I will describe three unknowns, which can go many different ways. Keep an eye out for your situation.

Then after that, I will give you four principles that will help you, irrespective of what the unknowns look like.

Three inevitable things and three unknowns of the situation

First inevitable? - you do not know the product

A big challenge is not knowing the product well. At first, you'll need to trust the team you're working with. They've been on this from the start. Try the product, learn it, test it, research the product and the environment to become the “product expert” as fast as you can - it usually takes 3-6 months to do this. Make a plan. Meanwhile - trust the team.

Second inevitable - You encounter a neglected backlog

A good backlog keeps the project on track. But when there hasn't been a leader for a while, the backlog can be messy. Instead of clear tasks, you might find confusing notes. Many of these might have been written by team members thinking about tech stuff, not what users want.

Third inevitable - Adjusting to a Different Team Dynamics

Every team operates with a unique dynamic and rhythm, shaped by personalities, past experiences, and established processes. Entering mid-way, it's inevitable you'll encounter a set workflow and team interactions. This dynamic might be seamless, or there might be visible gaps.?

Regardless of the state, a Product Owner's role is not just to guide product direction but also to foster a positive and collaborative team environment. Understand the existing dynamics, and while it's essential to bring in your expertise and fresh perspectives, it's equally vital to respect established processes and gradually introduce changes.

First unknown - backlog discipline

You do not know how well the team is disciplined to only start work from the backlog. You will have to see what the team culture is, and agree with the “backlog rules”. For example - I used to have a rule that anything small - be it 15 minute tasks that anybody identified, they do not need to go via backlog and ticketed. You may decide like this, or have the limit higher, or no limit. It is up to you and the team. But you do need to talk about this. And it is a must to have some limits and work via the backlog.?

Second unknown - size of the backlog

You? have no idea how big the backlog you encounter will be. It can be a small list, only tens of items, or it can be 2000 items long, collected over several years. In the latter case, the backlog has been misused as the “wishlist”, “lets not forget this”.?

In the first case, a small backlog is often a symptom of lacking backlog discipline. In my experience, you are most likely to encounter a slightly bloated backlog of a few hundred items, and you will have to start cleaning and throwing stuff away. More on this later.

Third unknown - stakeholder dynamics

Team’s relationship with stakeholders is another unknown. This can span from “no contact” to “stakeholder CEO”, an overtly controlling stakeholder. You have to figure out what the situation is, and start to collaborate with the stakeholders. If they are the CEO, stop it, and start protecting the team with the backlog.

Four Principles for new product owners

If you are in the above situation here are my four points to remember:

Principle #1: Set a near term Product Goal

Set a target 2-4 months from now. Then set another target 2-4 months from that one. These are your Product Goals 1 and 2.?

Now, use these goals to?

• Clean the backlog from anything that doesnt contribute to these PGs
• Prioritize the remaining items
• For any new items that are found, reject or move to roadmap all items that do not contribute to these PGs

Contrary to the typical approach of starting with a broad vision and working downwards, it's sometimes more effective to move in the opposite direction. Why? Speed.?

Starting to update a vision, and work downwards in the goal hierarchy is SLOW. it might take a lot of time. You will have to involve stakeholders who you do not yet have a relationship with.

In contrast, interview the team, interview a few important stakeholders, and suggest the first product goal. It won't take you more than a day to decide what it is. And the decision is not as “serious” or “big” as an updated vision would be. People will let you do this.

While this might not always identify the perfect PG, there's a high chance that it will at least steer the product towards a beneficial direction. The beauty of this method is that if the goal is misaligned, it will be quickly evident, allowing for rapid adjustments.

Principle #2: keep/make the backlog small

If you inherited a small backlog, be very careful on the backlog discipline, like we discussed earlier. In this case, in addition to enforcing the discipline, establish an efficient process to find and screen new items that are found. Accept ones that match the product goal, reject the ones that dont. Some may make it to the roadmap.

If you inherited a large backlog, 500+ items, set up meetings to clear out most of it. Target a 100-150 item count backlog. Again, use the product goals for screening through the backlog for the gems that need to stay.

Sometimes it makes sense just to scrap the whole thing and build it from scratch. Decide what seems less work and would result in a faster good quality backlog.

Principle #3: Establish backlog and roadmap ceremonies

You need regular meetings to refine and maintain the backlog. The same goes for the roadmap.

Backlog refinement should be repeated every week. Initially, 1 or 1.5 hours a week. Invite the full team. You should also establish rules for a “good” backlog item. These rules are often called “Definition of Ready”. Use Product goals 1 and 2 to prioritize the backlog items. (spans work of next few months)

The roadmap review can happen on a monthly basis. Invite stakeholders. Roadmap discussions are on a more higher level, often talking rather about epics than individual stories. Use product goals to prioritize on an epic level. Talk about product goals 1-4 (spanning about a year into future)

Focus on the items that are at the top of the backlog, almost ready to transition to the backlog. Are they known enough to progress? Are there any risky assumptions? If necessary, perform a RAT “Riskiest Assumption Testing” and take actions to next sprints to test an important feature up front.

You will not master these regular meetings immediately, so it means experimentation, preparation and practice. But this is a heartbeat of the product leadership, and you have to stick with it until it starts to work.

Principle #4: Talk one on one with key stakeholders

In addition to having them in the roadmap review, talk to key stakeholders also one-on-one. Try to dig deeper what adds value. The discussions one on one focus more on the individual stakeholders' problems. You can also update them on the latest issues they are interested in. Have lunch, have a discussion at the water cooler. Drop in to their office. But plan for these things to happen.

It is better to engage this way in “seeking value” discussions, rather than ask the stakeholders what they need, and then start twisting their arm to answer why they need it. Dont get me wrong, the question of why is important. But it is perhaps even more important to try to build a relationship with the stakeholder where you are seeking to understand how to add value together.

Hope this helps

Jumping into a project halfway as a Product Owner can be tough. There are many things you might not know and many problems to fix. But, if you follow the main ideas we talked about, you can quickly get on track and help your team. It's all about understanding the problems, making a plan, and working together. With time and effort, you and your team can achieve great things.