7 Tips for Product Owners From 7 Years of Experience
When it comes to product owning there is no manual that guides you through the creation of successful software. You need to stay curious and eager to learn as you work with people that have their own quirks, expectations, and experiences while working on products that are unique.
As product owner you have to deliver good business results, analyze and develop the business case, display leadership, specify and communicate valuable user stories. You have a vast amount of responsibilities and there are many pitfalls on this challenging path.
Let me share 7 tips that I learned over 7 years as product owner in the automotive industry within several multi-enterprise B2B projects.
1. Control the backlog
You do not want to be bothered with bugs and technical debt, so they can be just added to your Jira project? Wouldn’t it be good to get improvement suggestions from your stakeholders, too? And while you are at it, you want to give admin rights to your superiors, so that they can put requests into the backlog efficiently?
Don’t open up your development ticket system to become an idea trashcan if you are not fast enough to clean it up.
If you don’t know the issues in your backlog, you will have a hard time. You have to understand the items and know their priority.
If you lag behind and lost the backlog maintenance war, you may have the following conflicts
- Bugs that are feature requests
- Duplicates
- Stories that contradict each other
- A team and a product owner that have only scattered knowledge about the backlog items
- A backlog spilling over
- Too many tickets that do not fulfill the defined requirements on the definition of ready
Stakeholders may get the impression that you have lost control over the project.
But you should benefit from the provided insights and ideas of your stakeholders. Let’s discuss a possible way to gain from this input in the next tip.
2. Establish a traceable development process
Concerning stakeholder input to the product you may find a solution in using another ticket system, another board, some Wiki or a combination of it.
Make sure to have an overall traceable development process and communicate it. It is important to generate governance that guarantees
- that the SCRUM team knows about the issues in the backlog
- that other stakeholders are sufficiently well informed what happened to their inquiries
I suggest working with a service desk for external users. Concerning the team’s and close stakeholders’ submitted improvements, features and found bugs I prefer using Confluence. Here, the main benefit is that you can collect all requirements on Confluence pages and link them to the tickets in the backlog,
Duplicates can be linked to already available issues — or they can be rejected without having them in the ticket system in the first place.
When you do this with all your user stories, then you have the following benefits
- It is known (or easy to find out) to anyone involved what is inside your product by collecting a few Confluence pages
- Anyone who has access to the wiki knows the implementation status of the requirements
- You will pass quality assessments with ease if you do document your product development process. It also helps you to keep an overview that you will lose when working solely with a ticket system.
Now when anyone writes down an issue it is not yet piling up in your ticket backlog. If you have a platform to discuss all new issues within the team (e.g. the refinement sessions), you can clarify the exact meaning, reformulate it, prioritize it — and the whole team will know about it.
Don’t use the agile manifesto as excuse for not writing any documentation and for accepting insufficient processes.
3. Embrace responsibility
It is the SCRUM master’s and the developers’ responsibility to establish a good process? Maybe. When it is not happening, when the SCRUM master does not care, or you do not even have one in the team, an efficient product development still needs a process. As a good product owner, you need to make it happen; you have to care about anything that might deteriorate the progress towards a successful product.
You need to care about the stakeholders, the UI/UX, the DoD, the DoR, the documentation level, technical debt, financials, releases, the team and the company. Some don’t want to do that, but this is what good product owners are made of.
If the product owner does not care, the product will fail — unless the rest of the team is exceptional. He is the one that needs to emanate leadership and liability. If he does not, it is very likely that the team will drift.
Quality assurance might be not their responsibility then, or writing end-user documentation, carrying out devops stuff, sitting in some meetings, or something else that is not within the core of a developer’s responsibility. The SCRUM guide loses its meaning.
Don’t promote diffusion of responsibility, but trust and liability.
4. Stay curious about “the how”
…if you can. A general rule is that the product owner states the requirements in terms of user stories. These describe “what” is needed and then the development team realizes a solution by thinking about “how” to do it.
This approach is generally fine, the product owner needs to have the main focus on the problem and not on the solution.
However, the product owner should not promote a rather distant customer-supplier relationship between himself and the developers as it deteriorates the team spirit.
You should try to understand the way the development team is going and whether the approach they have chosen is indeed what is needed. Maybe the “how” does not reflect scalability needs as the “what” was not described clearly enough. You might realize it too late through ignorance.
The product owner’s understanding for how a solution is crafted may be crucial for preventing refactoring and architectural adjustment efforts.
Knowing how stuff works improves the communication with technically interested stakeholders.
Finally, caring about the “how” helps you to understand the level of quality in your software and the development process. As you cannot get quality into software “at the end”, you must do it continuously to create a successful product.
5. Adapt
Be agile. I have not seen two projects working with exactly the same process. Depending on the experience, skills, character of the SCRUM team, different expectations, requirements and processes need adaptation.
When working with a team of experienced postdoctoral algorithm experts that show very strong intrinsic motivation, it will be a completely different way of collaboration than with a team of junior web developers, even when you try to do the same SCRUM approach in both cases.
For some teams a strong guidance by a SCRUM master is needed, for others it may be more annoying than beneficial as they already know everything they need to know to work as a self-organized, enabled team.
When you have a fine-grained process in mind that you think everyone needs to stick to, because it worked well in the past, you will not create the highest motivation and efficiency. Hence don’t expect everything to run as it did in your last project or in a book that you read.
Adjust to the circumstances and stay eager to improve.
6. Read
As SCRUM became very popular in many industries, everyone seems to have an opinion on it: what it is, what it is not, how the roles are played, what are the benefits and/or drawbacks.
Many of these opinions may be very superficial due to no direct experience with SCRUM. Still they may seem plausible, or you may have no argument against these opinions even if they lead nowhere.
If you want to be an expert in your role, you should have a clear view on ‘your’ SCRUM. Even SCRUM masters may have an ideological view on the process that does not consider programming experience, programmer’s emotions and the criticality of certain aspects of software development.
I suggest that you find two good books on SCRUM and/or agile methods and study these with care. Remember the important lessons and have them available for fruitful discussion. For me two books were easy to read and instructive
1. Roman Pichler, Agile Product Management With Scrum — Creating Products that Customers Love, Addison-Wesley 2010
2. Kenneth S. Rubin, Essential Scrum — A Practical Guide to the Most Popular Agile Process, Addison-Wesley 2013
In a complex project you will encounter situations/process gaps for which you don’t directly see a good solution. You may think, try and evaluate with the team. However, many such problems have already been solved by others.
Do not reinvent the wheel and learn from written down experience.
7. Work with DoD and DoR
It’s tempting to neglect the definition of ready (DoR) as product owner, eventually it makes your life harder, doesn’t it?
Comply with the basic SCRUM rules.
What makes a product owner’s life even harder are uncompleted sprints, development artefacts that do not fulfill your expectation, or a pile of questions what your stories are about during the sprint — while you are trying to create roadmaps, clarify requirements, calculate financials and prepare the next workshop.
While developing a suitable DoR in the SCRUM team, you will realize that the members might expect from you and your user stories something else than you thought.
The definition of done (DoD) seems to be applied more often, and it is clearly a good idea to have and to use it. If you have requirements on documentation, style guide, test, or whatever fits in your context, you may add it there, the team will usually consent on a reasonable DoD.
You may create a checklist (e.g. in Jira) that needs to be fulfilled before a story can be really closed, to repeatedly make everyone aware of the existence of the DoD.
A product owner’s job is challenging and rewarding. Very strong commitment is needed as product owner to cope with the pressure and become successful, and you should be sure that you have it.
I hope that some of the presented tips will support you on your product journey.
Thanks for reading!
If you found the read interesting, you might want to catch up on some of my other articles:
