Key Takeaways
- Product owners plays an equally important role in leading an Agile, scrum team.
- Agile is still misunderstood although a lot of companies claim of its canonical adoption.
- Product owners take care of the whole product, not a mere function, feature, or documentation.
- Product owners could be distinct and different from the product managers. However, as per scrum guide, a scrum team does not have a product manager, so a product manager may as well be treated as stakeholder.
- Product owner is a servant-leader.
Software development has always been a costly and risky business. Standish Group in their Chaos Manifesto 2013 state that fewer than a third of all projects were successfully completed on time and on budget in the period under review. In the year 2015, a study by the same group revealed around the same number, that is, only 29% projects of all size were considered successful. What gives?
In a world where business development is accelerating very quickly, it is undeniable that every enterprise needs to have good product owners. Product owners who will help control chaos, manage risk, think ahead, deflect interruptions, resolve issues among conflicting stakeholders and provide clarity of direction to the teams they support.
Since 2001 Agile has been used as an alternative approach to the traditional waterfall methodology, which has proven difficult to implement in a modern software engineering. But wait, Agile is still misunderstood.
Many Agile neophytes try to implement Agile by mixing it up with the waterfall methodology, removing certain of the Agile practices and later label themselves as successfully being Agile. And one of such a common misconception about Agile is how the product owner fits into the team, the topic of this article.
So to the product owners out there, what is your raison d’etre? Why does your job title even exist?
Who is a Product Owner (PO)?
Product owner is simply a person who owns a product. It is a product, not just a mere function, feature, or document. It is about the whole product. Product owner is the decision maker for an Agile team. In the words of Ryu Kawano Suliawan, CEO of Midtrans: “product owners are mini CEOs.” He or she is most responsible for the success of the product they manage by having the development team produce the maximal, best possible result.
Minimally, the product owners perform these tasks:
- Create an understandable, workable story at the product backlog.
- Prioritizing the product backlog to best achieve the goals that has been set.
- Optimizing and maximizing the output of the (scrum) team.
- Managing chaos by, mostly, clarifying anything unclear outside and inside the team.
- Help the team plan iterations.
- Attend all scrum meetings, most importantly: standups, retrospectives.
- Define acceptance criteria and/or key performance indicators for the product.
Optionally, product owner may perform tasks that usually are carried out by product managers. As, not every company has the both roles.
A lot of Agile teams simply don’t have a “working” product owner. Or the product owner is not even sure of what it means to be a product owner.
The most important aspect of the job description of a product owner: to manage chaos.
Essential things a Product Owner does
Understand the business and the team
As a product owner, you must have a strong knowledge about the company’s business as well as about the team itself. Thus, when let’s say the business needs to revise something, or to make something new about the product, the PO must be consulted to give voice about the possibilities of such a thing, the likelihood whether the solution offered would improve the overall experience, cut time, etc., and also to give recommendation or alternatives on how to best approach the problem.
Bridge the team and the stakeholders
The product owner’s main task is to help the team and the business stakeholders communicate directly. He should be very instrumental at bringing the right people together. It is therefore not uncommon for the product owner to act as a proxy for the stakeholders to the agile team.
However, just who the stakeholders are to be precise? The product owner can represent these stakeholders:
- The management
- Domain experts
- End users
- Auditors
- Support teams
Other related product owners
Maintain and prepare the backlog
So long there is a product, there is a backlog. In Agile lingo, a backlog is simply a to-do list. Each item in the list is called a story. It has a type whether the story is a chore or a feature to be developed. A story is “sized” by estimating its difficulty (done by the engineer during sprint planning), and also equally important, it has a well-described definition of ready and done.
Before an engineer can working on a story, the story must have been in the backlog and selected for the sprint backlog during the sprint planning activity. Therefore, the backlog has to be prioritized with the right balance of:
- Customer value (right problem solved)
- Business value (revenue generated)
- Technical value (fosters learning, reduces risk, solid solutions, intelligent workflow)
- Quality value (mitigated risk)
It is also important to note that a stakeholder also should not try to force the product owner to take on a story. Product owner should assess the story fully, regarding the risks associated with including the story into the iteration.
Set up and maintain the sprint
If you are doing “Well guys, we have this many stories and we have four months left. So I want you all to have one-fourth of the product backlog done by the end of this sprint,” then you are not a good servant-leader, a role very core to being a good Product Owner.
It is important to keep in mind that a product owner should never act as if he or she has the most important say in any discussion with the team. They do not even have the right to force how many stories are going to be in the next sprint.
However, he has the right to maintain the sprint. So during the sprint, the product owner could in fact decide to exclude a story from the current deployment schedule, after consulting with the engineering team. The PO is the sole person in the team to decide what gets deployed.
For instance, if the feature to be included depends on the other team’s work, and that work is still on progress, then it is a very reasonable decision to not include the story. Other example is when a feature depends on a third-party product that’s not implemented yet.
Additional things Product Owners usually do
Devise Key Performance Indicator (KPI)
Stakeholders want to know how successful the product is. Is it performing well? How much does it help the people using it? Is it fast enough to use?
The product owner must provide list of measurable KPIs by which the product can be judged whether it is performing well or not. The product owner monitors these KPIs and adapts the backlog based on the feedback they provide.
Test and verify a story for deployment
Once the engineers have marked the story as ready for test, the product owner shall bear the responsibility for ensuring it is thoroughly tested. They should strive to find irregularities, oddities, and bugs before including the feature into the deployment package. They work with the test engineers and user representatives to enable this testing.
Ensure a cohesive working environment
Well. Obviously. She has to ensure that everyone works, the scrum master is helpful, the engineers are doing their jobs, and the team is cohesive and happy. It is not a small feat, someone must work and orchestrate it. Failing at it, the team will fail and became dysfunctional.
Publish release log
Ok, so for after every deployment, what are the features deployed? What are the changes? For the newly built product, how are they going to affect the customer and the business? How does it going to make things better, faster, and require less work if possible?
The product owner, is advised to release the “Release Log” or simply, to do a press release to the company and possible the outside world. He may use Slack, Email, or whatnots to distribute an appropriate release note.
Sharing session
The product owner may need to give a demo about how the product works. And this is why, it is very important that the product owner tests the product himself, so as to know its limitation, expected performance, et cetera.
Hiring
The team’s product may be expanding. In such a case, the product owner must consult with the human resource department shall he want to add a new member into the team.
However, the decision to hire someone or not should not get decided by the product owner, but someone like the Vice President of Engineering, the CTO, or someone with a similar role. The product owner also need to ensure that in the case someone is leaving the team, it won’t disrupt and render the team dysfunctional.
Product Owner vs Product Manager
The Product Manager is a more market-centric role. They usually work very closely with the marketing team, and sometimes with the Chief Marketing Officer directly as explained by Sky Kok, the CTO of Indonesian job directory website Karir.com.
Things that are performed traditionally by Product Managers are:
- Business case development by finding new ways to improve the product experience as a whole.
- Listen deeply, being the expert on the market and the customer. But not the solution as that should be delivered by the engineering team.
- Define the yearly/quarterly roadmap of the product(s).
- Deal with the pricing, sales and marketing of the products.
- Acquiring, buying or building decision.
In Scrum Guide however, there is no mention of the product manager and therefore, they may be positioned as a stakeholder in many scrum-adopting organizations. In fact, a scrum-adopting organization may not have Product Manager by title at all, so the roles are thusly split with the Solution department, Business Development department, and the Product Owner.
“As a product owner, I am…”
You may come from any background:
- Business stakeholder
- IT department
- Business analyst
- Product manager
- Or even: new hire
I have witnessed the effect of when a product owner from a set of the categories above, is put into a team. There is no background that is better from the other, it is all came down to willingness to adopt and accept the new challenges that entail with it, although traditionally, as a product owner you are more likely to come from the business analyst team.
The reason why does many PO traditionally come from the analyst background is because the business analyst team is in between of the technical and business people, so they have a wide perspective of the product in question. However, by knowing what are you expected of doings, your raison d’etre, you should hopefully able to fit in yourself and immerse with the role as described.
About the Author
Adam Pahlevi takes pleasure in producing readable and high performing code. He works as a Software Engineer at Midtrans, and during his free time he focused to bootstrap his new obsession: Tripisco. What he likes doing? Basically: sharing and meeting people. He has written articles, giving talk as far as in Spain, and organizing meetups. Do contact him when you are in Indonesia.
