Product owners need a diverse skill set to be successful. Your past experience, your current organisation and the specific industry make the requirements to your job unique. Nevertheless there are some common pitfalls and anti-patterns which many product owners unwillingly fall into. This short list of product owner anti-patterns hopefully helps you to avoid these common errors.
Output over outcome
Instead of measuring output you should focus on outcomes. A team’s velocity metric can be useful but certainly not for measuring your product’s success.
Establish KPIs which track business and product success. In the most simple form that is revenue and active users for most products. You should probably establish your own northstar and growth metric.
Working in the shadows
Breaking down a grand idea into small releasable chunks is hard. Releasing something that seems unfinished is tough as well. But reality hardly ever meets your fiction. Therefore it is your duty to give yourself a reality check whenever possible. Establish early feedback cycles. From customer interviews to paper prototypes, sprint demos and A/B tests. There is nothing wrong with finding out that some assumptions were wrong. Ignoring the possibility of your own fallibility is.
The same goes for your progress. Do not commit to a release date three months away and then announce whatever the progress has been a week before the deadline. Share your achievements, failures and updated projections whenever you have them. That means right after every story burnt and every sprint closed.
Push instead of pull
As a product owner you are the one held accountable. You feel the pressure from the top to deliver. This can lead to passing this pressure onto the development team forcing them to commit to more work than they are comfortable with. But this is very short sighted as it will cause a magnitude of problems further down the road. This behaviour will lead to dissatisfied team members. Dissatisfied team members eventually leave. It will also grow a them vs. us attitude where you will earn resistance beyond what’s reasonable. It pushes the team to take shortcuts and create technical debt.
By pushing more work into the system than it can handle the pipeline will clog up eventually. Instead try to establish a sustainable pace of development. There is a reason the pull principle is a pillar of successful agile teams.
Stand-up as status report
Have you found yourself in a stand-up or daily scrum meeting where you go around and everyone reports what they did yesterday and what they are going to do today without any further communication? That’s a status report. Everyone is just running their script to get out of the meeting as quickly as possible.
Instead treat the daily scrum as a planning session for the next 24 hour iteration. You want to inspect the sprint progress, align within the team what can be done until the next daily scrum, how you can help each other and where risks and impediments are arising.
The yes man
Saying no is hard. We are hardwired to please others, even more so if they have formal role power. But saying no is important to stay focused on the top priority. It is much easier to say no if you have hard facts to back it up.
How much value is expected of this new idea that you’re getting pitched? How much is the cost of delay of other features you’re working on? Answering these questions often needs further details from the requester. This extra round of inquiry alone often makes an idea evaporate, illustrating how serious the idea was from the start.
Making mistakes is easy
It is okay to make mistakes, everyone does. With a healthy dose of introspection and a will to get better every day we can try to avoid these common product owner anti-patterns. This way we can all make work more meaningful.