What Product Owners Should Not Do
Now that we've told you what to do as a Product Owner, here are some behaviors that you'll want to avoid in the future.
CORE
·
Join the DZone community and get the full member experience.
Join For Free
Last time I set out some of the things a Product Owner should be doing—or at least considering doing. Even a quick look at that list will tell you the Product Owner is going to be a busy person.
So in this post, I'd like to suggest some things Product Owners should NOT be doing.
Product Owners Cutting Code Should NOT Be Cutting Code
Having a former coder in the Product Owner role can be a great boon. Not only do they know how to talk with the technical team and (hopefully) can command their respect, but they can also see how technology can apply.
But to be an effective Product Owner they need to step away from the keyboard and stop writing code.
Two reasons.
One: time. Product Owners add value by ensuring that the code which is written addresses the most valuable opportunities with the smallest, most elegant, delightful way possible.
Every minute spent coding is a minute not doing that.
Second: Product Owners need to empathize with the customer, with the business users, they need to eat, sleep, and breath customers.
Being a good coder—let alone someone called an architect—is to empathize with code, the system, the mechanics of how a system works.
Importantly both requirements and code need to be able to come together and discuss what they see and find a way to bring the two (sometimes opposing) views together. It is a lot easier to have that discussion if the two sides are represented by different people.
Asking one person to divide their brain in two and discuss opposing views with themselves is unlikely to bring about the best result and is probably a recipe for confusion and stress.
That's not to say both sides shouldn't appreciate the other. I said before, former coders have a great advantage in being a Product Owner. And I want the technical team to meet customers. But I want discussions to be between two (or more) people.
(I might allow an exception here for Minimally Viable Teams but once the team moves beyond the MVT stage the PO should stop coding.)
Product Owners Should Not Be Line Managers
OK, senior Product Owners should line-manage junior Product Owners, but they certainly should not be line-managing anyone else. They most certainly they should not be line-managing the technical team.
Product Owner authority comes not from a line on an organization chart, or the ability to award (or deny) a pay rise or bonus. Product Owner authority stems from their specialist knowledge of what customers want from a product and what the organization considers valuable.
If the Product Owner cannot demonstrate their specialist knowledge in this way then either they should learn fast or they should consider if they are in the right role.
Product Owners need to trust the technical team and the technical team needs to trust the Product Owner. Authority complicates this relationship because one side is allowed to issue orders when trust is absent and the other side has to obey.
And again, Product Owner simply don't have the time to line manage anyone.
Being a good line manager requires empathy with employees and time to spend observing and talking to employees, helping them develop themselves, helping them with problems and so on.
Product Owners Should Not Make Promises for Other People to Keep
Specifically, that means they should not issue "Roadmaps" which list features with delivery dates based on effort estimates. The whole issue of estimation is a minefield; very few teams are in a position to estimate accurately and most humans are atrocious at time estimation anyway. So any plans based on effort estimation are a fantasy anyway. But even putting that to one side...
Issuing such plans commits other people to keep promises. That is just unfair.
Product Owners can create and share scenario plans about how the product —and world—might unfold in the future.
Product Owners can co-create and share capacity plans which show how an organization intends (strategically) to allocate resources. And Product Owners can work with teams in executing against those capacity plans in order to deliver functionality the Product Owner thinks should be delivered by a date the Product Owner thinks is necessary.
In other words: provided a Product Owner is making the promise that they intend to keep themselves (i.e. they have skin in the game), then they might issue some kind of forward plan.
Product Owners Should Dump Outbound Marketing at the First Opportunity
Outbound marketing, e.g. advertising, press releases, public relations and product evangelism, often end up on the Product Owner plate—particularly when the Product Owner is a Product Manager. And in a small company (think early stage start-up) this just needs to be accepted.
However, in a larger organization, or a growing start-up, Product Owners should seek to pass this work to a dedicated Product Marketing specialist as soon as possible. Both roles deserve enough time to do the job properly.
The Marketing Specialist and Product Owner will work closely together—they are, after all, two sides of the same coin, the Marketing coin. The Marketing Specialist handles outbound marketing (telling people about the product) and the Product Owner handles inbound marketing (what do people want from the product?). (Again, in organizations with established Product Management this is usually easier to see.)
Product Owners Should Dump Pre-Sales at the First Opportunity
As with outbound marketing, Product Owners often get dragged in as pre-sales support to account managers. And again this is more common in small companies and early-stage start-ups.
There are some advantages to playing second fiddle to a salesperson. The Product Owner might get actual customer contact (salespeople too often block Product people from meeting customers). And Product Owners should be exposed to some of the commercial pressures that salespeople—and customers—encounter.
But doing pre-sales is very time-consuming. And being wheeled in to help deliver a sales will distort the Product Owner's view of the market—just because this customer wants the product in orange doesn't mean other customers want orange.
And again, pre-sales is more effectively done by specialist staff as soon as the company can afford them.
Want to receive these posts by e-mail? - join the newsletter today and receive a free eBook: Xanpan: Team Centric Agile Software Development
Published at DZone with permission of Allan Kelly, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.
Comments