Advice to Product Owners from a Developer

Some Do’s and Don’ts for Product Owners from your team

Christopher Laine
Oct 9 · 9 min read
Photo by You X Ventures on Unsplash

“I think we need to look at cleaning up the repository layer,” said one of our data guys to the team. “It’s way too chatty, and it doesn’t log well.” Collective nods from the engineers and devs.

The testers begin to ask what kind of regression this will take, when the product owner interrupts. We’ll call her Katy.

“Wait,” Katy says. “We can’t refactor that. I’ve looked at it; that seems fine.” Katy was a developer five years ago, and feels she’s technical enough to make that kind of decision.

“Let’s put it on the backlog,” Craig, one of the engineers, says.

“We’ll look at that another time,” Katy says. “We’ll talk about that when we get through our other work.”

“I have free time,” Miguel says. “I could look at spiking that out.”

“No,” Katy says. “I told the business we’d be done with these other five stories by end of the sprint.”

“But those are stretch goals,” I say. “We never agreed to finish anything except what’s already been done.”

“We’re doing this,” Katy says, with a tone of finality. “We need to keep moving.”

For the fifth time this week, several of us bite our tongues. Katy carries on with the stand-up, telling us we have a deadline she’s promised to the sales team which takes precedence. We need to be ready a week early.

What is a Product Owner?

What are the responsibilities of a Product Owner? Let me quote Jack Milunsky from his blog post on DZone. Your role is to:

  • Create and MAINTAIN the Product Backlog
  • Prioritize and sequence the Backlog according to business value or ROI
  • Assist with the elaboration of Epics, Themes and Features into user stories that are granular enough to be achieved in a single sprint
  • Convey the Vision and Goals at the beginning of every Release and Sprint
  • Represent the customer, interface and engage the customer

I would break it down thusly: Your job as a Product Owner is to act as a bridge between the customers and your team. You are there to facilitate, to ensure the backlog is properly organised and filled out, and to empower your team to do its best work. You are there to make sure the devs, testers, engineers and otherwise are freed up to do what they do best: Build great products.

If you’re doing this already, then bravo, and your team must just love you. Let me say that if you are doing these tasks to the best of your ability, then you can lean back in your chair and sigh contentedly. You’re on your game.

Now for a bit of tough but friendly talk for the rest.

What the Product Owner is NOT

In my many years on agile teams, I’ve seen any number of product owners who have, to a greater or lesser degree, gone astray in their role. What I’m about to outline is not simply my opinion, but an amalgam of the opinions I’ve heard from teammates over that time.

You’re not there to shortcut story definitions / acceptance criteria

I’m a developer. I design and write code. I write unit tests, component tests, write documentation and release notes. If I shortcut on any of these things, then I’m not doing my job.

The same is true of the Product Owner and User Stories. If I open up my next story and the description is:

The user wants a button on the page which gets the report data from the server

Then you’re not doing your job. The Product Owner is responsible for making sure I have everything I need to build to the customer’s needs. That’s what the User Story is about. What page needs this button? What report data? Server?!

When a Product Owner doesn’t actually fill in the story or the acceptance criteria, as a developer / tester / engineer / etc. I am left to picking this information out of your head, and having to infer the information I don’t have. That’s a waste of time and effort, a hassle for all involved. Do us all a favour, and fill in that User Story / Acceptance Criteria. It saves everyone involved a lot of pain and headache.

If my job is not just writing code, but also writing tests, documentation, and so on, then your job as the product owner isn’t JUST to convey a product vision, but to make sure your team has everything it needs IN THE STORIES to make this possible.

You’re not there to be technical

Because of a shortfall of POs, I was expected to be the product owner for nearly two years on one of my teams. Now, I’m a Solutions Architect by training, but for that time, I was expected to set aside my Solutions Architect / developer thinking and focus solely on conveying to my team what the customer needed . It was not easy, but in the end, I got there. I learned in time to restrain MY thoughts on technology and architecture (unless the team flat-out asked me to put on my architect’s hat), and allowed the team to focus on the HOW, with me focusing on the WHAT.

This one is particularly true for product owners who were once developers or engineers. There is a natural urge which you must suppress to get down into the technical details, and to try and make technical decisions. Leave that to your experts. Your job is complicated enough without trying to wear that technology hat as well.

What you perceive as technical expertise on your behalf is often not merited. You tell your team the customers’ needs to the best of your ability, in explaining WHAT is the problem to be solved, and let your technical experts come up with the HOW.

You’re not to be setting timelines or deadlines without team input

This is a big one. As a PO, it can be very easy to say to a business stakeholder or customer “Yeah, we can get that done in a couple sprints.” It often is expected to offer up some kind of estimate of how long it will take.

Suppress this urge at all costs, and always respond with “Let me talk to my team, and we’ll get you a high-level estimate in a couple days.”

It is your team who are doing the actual work. While you may feel you have a ‘pretty good idea’ of what it will take, never, ever assume you know. Taking a couple days to let your team tell you what is realistic for them is a small price to pay.

To not do so, and to offer up an estimate without the team’s input is going to:

  1. Likely lead to a mismatch in expectation vs. reality.
  2. Likely lead to frustration and resentment on the part of your teammates for offering up something you couldn’t back up.
  3. Cause unmet expectations with customers / business stakeholders: You made an estimate without knowing what your team would estimate, and now you’re going to be held to that.
  4. Create friction for all involved.

You don’t get to use ‘MVP’ as a means of building a buggy / poor quality product

We use the term MVP in agile software development a lot. Minimal Viable Product. That is, build the smallest change in as quickly as we can to prove what we’ve built has value, then iterate on this to improve it over time.

Great in theory, but in practise, one often sees POs willing to call for ‘MVP’ on the quality front, with some abstract promise of ‘fixing it up later’ (improving logging, refactoring the chatty repository layer, getting CI/CD going with automated tests, etc.). This, in turn, leads to the backlog getting filled up with lots of ‘TODO’ stories for improvements and refactoring, but which ‘somehow’ never get prioritised above the new shiny feature work.

What ends up happening is a few things. First, the team loses faith that you take quality seriously. Secondly, you end up with a pretty slap-dash product full of tiny defects and hacks (known as tech debt) which ultimately can cripple your product. Finally, it creates a false sense of the team’s velocity, because ignoring technical refactoring and cleanup means you are not truly reflecting what it takes to build and maintain your product.

Every sprint, make room for at least a couple technical cleanup and fixup stories. Don’t turn MVP into another word for hack job.

You’re not there to make everyone happy

You talk to four different customers, or several business stakeholders. They, invariably, give you four different things they want done.

It is not your job to say yes to all of them, and foist that extra work on the team.

Customers / business stakeholders want everything now. That’s human nature. However, as a product owner, your job is to shield your team from this, and keep / maintain a backlog of what is most important. You are there to set expectations with stakeholders, and tell them you’ll let them know when it can be done.

Your favourite word in these situations should be ‘No’, or better put, ‘Not Right Now’

Most importantly on this point, do not foist additional work on your team mid-sprint as a ‘stretch goal’ (but one you expect to be done by the end of the sprint), just to make this or that person happy. All you end up doing is upsetting the natural order.

You’re not the team’s boss

I have seen this far too often, where a product owner slowly (or quickly) morphs into the misguided belief that they are ‘in charge’. They come to act as if they are the ‘boss’ and all the devs, engineers, and testers on the team are their ‘staff’.

Quick course correction: You’re not. You are a member of the team who plays a specific role, that of speaking for the customers to the team, and for the team back to your customers. Your role is as a facilitator who ensures the customers’ needs are being built into the software by managing and prioritising the backlog, and working with the team to get the work done in a safe and realistic timeframe.

This ‘working with the team’ can often lead POs to fancy themselves ‘in charge’, and perhaps of the backlog and the work being done, you are in charge. But you are not the boss or the manager of the team. You are not the final arbiter of technical decisions (see above). You are not allowed to dictate terms to the team which they must accept. You are a contributing member of the team with a special role relating to the product’s backlog and direction. I would see the PO as no more the boss than anyone else.

Some advice for the rest of the team: Help your PO to be better

Having been a PO myself, I have made all of the above mistakes at least once, and thank the gods for my ridiculously honest team of course-correcting me as I did so.

I suggest to all teams that it is your responsibility to your PO to help them see where they need course correction the same as you would course correct a dev who wasn’t writing unit tests, or a tester who wasn’t writing down / automating their test cases.

This does not need to be harsh, or mean, or ‘brutally honest’, but it does require you as a team to be willing to give and accept such constructive criticism as a way for all of you to improve.

If you feel you don’t have such a voice in your team, that you aren’t allowed to speak out for fear of persecution or being shot down / ignored / blamed by your PO for speaking your mind in a frank but courteous manner, then maybe you need to speak with your manager about it. Every member of the team is apt to make some mistakes, and for the benefit of all, it is important we can each help each other get better, and in turn listen to this kind of feedback so we can all improve.

Hope this helps

IT Dead Inside

IT is a cesspool, but its home

Christopher Laine

Written by

Writer, sci fi / Lovecraftian nutbag, "master' chef, gym rat, martial artist, Dungeon Master, and programmer. I cover all the useless bases

IT Dead Inside

IT is a cesspool, but its home

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade