Joining a project that’s already underway as a product owner can feel like getting on a moving train. Knowing what to expect can help.
I will describe three inevitable things you will encounter starting out as a product owner and three unknowns, which can go different ways. Lastly, I will give you four principles that will help, irrespective of what the unknowns look like.
The first inevitable: You do not know the product
A big challenge is not knowing the product. 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 it as well as the environment to become the “product expert” as fast as you can (usually takes three to six months), and make a plan.
The second inevitable: You’ll encounter a neglected backlog
A good backlog keeps the project on track. 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 rather than what users want.
The third inevitable: You’ll need to adjust to different team dynamics
Every team operates with a unique dynamic and rhythm, shaped by personalities, past experiences, and established processes. If you’re entering mid-way, you'll inevitably 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 only to guide the product direction but to foster a positive and collaborative team environment.
Understand existing dynamics, and while it's essential to bring in your expertise and fresh perspective, it's equally vital to respect established processes and gradually introduce changes.
The first unknown: Backlog discipline
You do not know how well the team is disciplined to start work from the backlog. You will have to see what the culture is and agree on the “backlog rules.” For example, anything small (a 15-minute task) does not need to be made into a ticket. You may decide like this, or have the limit higher, or no limit at all! It is up to you and the team, but you do need to talk about it. It’s a must to have some limits and work via the backlog.
The second unknown: Size of the backlog
You have no idea how big the backlog will be. It could be a small list with only ten items, or it could be 2,000 items long, collected over several years. In the latter case, the backlog has been misused as a “wishlist.”
In the first case, a small backlog is often a symptom of a lack of 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).
The third unknown: Stakeholder dynamics
Team relationships with stakeholders are 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 collaborate accordingly. If it’s the “CEO,” stop and start protecting the team with the backlog.
Four principles for new product owners
If any of the above resonates, here are four principles to remember.
Principle one: Set a near-term product goal
Set a target that’s two to four months from now. Then, set another target two or four months from that one.
Now, use these goals to:
- Clean the backlog from anything that doesn’t contribute to product goals.
- Prioritize remaining items.
- For any new items, reject or roadmap those that do not contribute.
Contrary to the typical approach of starting with a broad vision and working downward, it's sometimes more effective to move in the opposite direction. Why? Speed.
Updating a vision and working downward in the goal hierarchy takes a lot of time. You will have to involve stakeholders that you do not yet have a relationship with.
Alternatively, interview the team, including a few important stakeholders, and suggest the first product goal. It won't take you more than a day to decide, and the decision is not as serious as, for example, an updated vision.
While this might not always identify the perfect goal, there's a high chance that it will at least steer the product in a beneficial direction. The beauty of this method is that if the goal is misaligned, it will be evident, allowing for rapid adjustments.
Principle two: Keep/make the backlog small
If you inherit a small backlog, as I mentioned earlier, be careful about backlog discipline. In addition to enforcing discipline, establish an efficient process to find and screen new items that are found. Accept ones that match the product goal and reject those that don’t. Some may even make it to the roadmap.
If you inherit a large backlog of 500+ items, set up meetings to clear it. Target a 100-150 item count backlog. Again, use the product goals for screening those that need to stay.
Sometimes, it makes sense just to scrap the whole thing and build it from scratch. Decide on what seems like less work that would result in a faster, good-quality backlog.
Principle three: Establish backlog and roadmap ceremonies
You need regular meetings to refine and maintain the backlog. The same goes for the roadmap.
Backlog refinement should happen weekly, taking between one and two hours. Invite the full team. You should also establish rules for a “good” backlog item. These rules are often called the “definition of ready.” Use product goals one and two to prioritize backlog items (spanning work over the next few months).
The roadmap review can happen on a monthly basis and should include stakeholders. Roadmap discussions are on a higher level, often focusing on epics rather than individual stories. Use product goals to prioritize on an epic level. Talk about product goals one to four (spanning about a year into the future).
Focus on items at the top of the backlog that are almost ready to transition. Are they known enough to progress? Are there any risky assumptions? If necessary, perform riskiest assuming testing (RAT) and take actions for the next sprints to test an important feature upfront.
You will not master regular meetings immediately; it takes experimentation, preparation, and practice. But this is the heartbeat of product leadership, and you have to stick with it until it works.
Principle four: Talk one-on-one with key stakeholders
In addition to having them in the roadmap review, talk to key stakeholders one-on-one. Dig deeper into what adds value. Such discussions focus more on the individual stakeholders' problems. You can also update them on the latest issues they are interested in.
It is better to engage in a casual way, e.g., over lunch or at the water cooler, rather than asking what they need in a meeting and then twisting their arm to answer why they need it. Don’t get me wrong, asking “why” is important, but so is building a relationship to understand how to add value together.
Getting started as a product owner
Jumping into a project halfway through 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 principles in this blog post, 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.
For more information on creating a healthier backlog, check out this article.
Published: Nov 7, 2023
