Growing as a Product Leader

7 min read5 days ago

Product Owner in Practice series · Article 6 of 7

After a few years in the role, many Product Owners run into an uncomfortable question: am I growing, or just getting faster at the same job? The backlog moves, sprints close, stakeholders are reasonably happy. But the decisions look a lot like the ones from two years ago.

Earlier in this series, we covered the role, the first 90 days, discovery, the path from backlog to delivery, and what to monitor. This article is about what comes after you master the basics: how to grow.

PO maturity isn’t measured by years in the job or by certifications. It shows in the kind of decisions you make and in the results you can point to. The good news is that this growth follows a recognizable path, with concrete behaviors at each stage. And you can find out where you stand.

By the end, you’ll be able to: place yourself on a maturity model with an objective self-assessment, choose your next step, understand your product in business numbers, and measure whether you’re actually improving.

A four-level maturity model

This is the model I use when talking with POs about their development. These are stages almost everyone goes through, not labels, and each level has a clear next step.

Worth noting: a PO’s level also depends on the organization. Some companies design the role for level 1 or 2. In that case, growing means showing results in the space you have and using those results to widen it. The monthly product review from article 1 and the forecasting from article 5 help a lot here.

Self-assessment

Answer yes or no, honestly. Your level is the last block where you answer yes to every item.

Level 2

The team’s backlog is ordered, and the next two sprints are refined.
The team rarely runs out of work that is ready to start.
You can say how many items the team delivers per week.

Level 3

You know the product’s key results by heart and where they stand today.
You talked to at least one customer in the last two weeks.
Every item at the top of the backlog connects to a key result.
You have said no to someone more senior, with a reason, and the decision was respected.
You have answered “when will it be done?” with a probability range.
You have changed or dropped a delivery based on data after release.

Level 4

You take part in setting the OKRs, not just receiving them.
You know how much the product earns or saves, and what a week of delay on the main bets costs.
Other POs come to you to think through decisions.

Pick one unchecked item from your next level and make it your goal for the coming month. Growing one item at a time works better than trying to change everything at once.

Understanding the product in business numbers

The jump from level 3 to level 4 runs through understanding the business in numbers. Do this exercise once every six months:

Where the value comes from: new revenue, revenue retention, cost reduction, risk reduction, or a regulatory obligation. Almost every product has one main source.
Which indicator translates that value: for example, accounts opened per month and the average value of an active account in its first year.
What a week of delay costs on the main bet: if the new account opening flow brings in 400 extra accounts a week, each week of delay is the revenue from those accounts that never comes in. Ask finance for the numbers; nobody expects the PO to make them up.

With that number, the conversation with leadership shifts from “we need more people” to “each week of delay costs X; with this change, we gain Y weeks”. It is also the number that gives substance to the cost of delay used in prioritization (article 4).

Deciding under uncertainty

Nobody gets it right every time. With experience, a PO learns to bet small, learn fast, and walk away without drama. Which experiment to run depends on what you need to learn:

Before each bet, write down the criterion for dropping it: “if conversion doesn’t pass 40% in four weeks, we go back to the previous flow.” Without that criterion written beforehand, every bet tends to become permanent.

How to know you’re improving

A PO’s work shows up in the team’s flow and in the product’s results, not in the number of stories written. Pick three or four of the metrics below, take a baseline, and compare after six weeks.

How to compare: pull the last two or three months of what is already on the board; log your hours for two weeks before changing anything; change one practice at a time; compare after six weeks using the median, not the average; and bring the numbers to the team’s retrospective.

Get Bruno Novaes’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

A control metric: always track production bugs and rework. If refinement got faster and items keep coming back, the problem just moved somewhere else.

What not to measure: number of stories written, velocity as a target, or meeting hours. These numbers go up easily and say nothing about value.

Pitfalls along the way

Taking the title without the authority. If you don’t decide the order of the backlog, it is hard to answer for the product’s value. Sort out the decision matrix before anything else (article 1).
Living only in delivery. Without a customer block on your calendar, discovery doesn’t happen, and prioritization turns into opinion.
The backlog as a storage unit. Four hundred items are not a plan; they are usually requests nobody managed to turn down or prioritize.
Promising a date based on the average. A date calculated from the average has roughly a coin flip’s chance of being met (article 5).
Celebrating the deploy. Delivery without an evaluated hypothesis is activity, not results.
Growing alone. The jump to level 4 runs through developing other POs. Sharing what works speeds up your own growth.

Reading list

Inspired, by Marty Cagan: what sets product teams apart from teams that only ship features.
Escaping the Build Trap, by Melissa Perri: how to stop measuring success by output.
Continuous Discovery Habits, by Teresa Torres: the weekly discovery routine and the opportunity solution tree.
The Mom Test, by Rob Fitzpatrick: how to talk to customers without being fooled by their politeness.
User Story Mapping, by Jeff Patton: how to see the whole journey before slicing.
When Will It Be Done?, by Daniel Vacanti: forecasting with flow data, no estimates required.

With AI

AI to choose your next step. Once a month, hand over your self-assessment and your latest monthly product review, and ask for questions that help you choose your next step. AI tends to agree with you; explicitly ask it to push back.

My self-assessment on the PO maturity model: [checked and unchecked items].
My latest monthly product review: [summary].

Act as an experienced, demanding PO. Ask me five questions, one at a time,
that help me choose ONE behavior to develop next month.

At the end, suggest a concrete way to practice it and to tell whether 
it worked.

AI as a critic of your decisions. Before a big decision, ask the AI to argue against it from different perspectives. The point isn’t to obey it: it is to walk into the real conversation without blind spots.

Context and key results: [context kit]. 
Decision I'm about to make: [text]. 
Assumptions: [list].

Act as the CFO and then as the head of technology, one at a time.
Each should present the three strongest objections to the decision, 
with the reasoning.

Don't be nice. Then step out of the roles and tell me:
- which assumption, if wrong, changes the decision the most;
- what cheap piece of data I could get before deciding.

Wrapping up

Growing as a product leader is, at its core, changing the kind of question you answer: from “what are we doing this sprint?” to “which bets will move business results, and how will we know?”. It doesn’t happen all at once. It happens one behavior at a time, with evidence that it worked.

In the last article of the series: how to use AI professionally across all of a PO’s work, going beyond quick questions: with context, routines, and review.

What about you: which level of the model do you recognize yourself in today, and what is holding back your next step? Tell me in the comments.

References

Schwaber, K.; Sutherland, J. The Scrum Guide, 2020. The Product Owner’s accountability for product value and for ordering the Product Backlog.
Reinertsen, D. The Principles of Product Development Flow. Celeritas, 2009. The origin of cost of delay as an economic prioritization criterion.
Nielsen, J. Why You Only Need to Test with 5 Users. Nielsen Norman Group, 2000. The basis for prototype tests with five people.
Cagan, M. Inspired: How to Create Tech Products Customers Love. 2nd ed. Wiley, 2017.
Perri, M. Escaping the Build Trap. O’Reilly, 2018.
Torres, T. Continuous Discovery Habits. Product Talk, 2021.
Fitzpatrick, R. The Mom Test. 2013.
Patton, J. User Story Mapping. O’Reilly, 2014.
Vacanti, D. When Will It Be Done? 2020.