Ideal Product Owner. How to find one?
Disclaimer
In this article I argue from the employer’s perspective. My goal is not to hurt anyone's feelings or sense of injustice, but to reflect an approach to finding a candidate that will serve the interests of the business. When I represent a business, I put its needs and goals first. In another article, for example, I might consider the process from the candidate's point of view, and then the emphasis would be different.
This article is dedicated to how, in my opinion, you need to look for a Product Owner who will become an independent, effective unit in a team, capable of completing all assigned tasks and bringing real value and profit to the company.
Perhaps not everyone will like what I write, especially potential candidates for a similar role. However, as I already said, each side protects its own interests. These interests often do not coincide between the business and the candidate. In this article, I speak on behalf of the business, because its tasks are now a priority for me. In another article, I might consider the situation from the employee's or the client's point of view, because each role has its own interests and perspective.
Preamble
Some may immediately have a question – “What is the difference between a Product Manager and a Product Owner?”
Well, let's start with this.
Difference between Product Manager and Product Owner
In short, in a few points, something like this:
Focus and Responsibilities:
Product Owner is more focused on operational product management in the context of development and interaction with the team. His main task is managing the backlog, prioritizing tasks, creating and describing user stories, participating in Scrum ceremonies, working with the criteria of readiness (DoR) and completion (DoD). Product Owner is most often focused on short-term goals and works closely with developers.
A Product Manager deals with more strategic issues: he is responsible for the vision of the product, its development in the market, strategy, interaction with customers and stakeholders. The Product Manager also analyzes the market, competitors, and user needs in order to develop long-term product plans and determine its unique value proposition. His tasks are more global and include the formation of business goals and product life cycle management.
Responsibility to the team:
Product Owner works directly with the development team, providing it with everything necessary for effective work. He describes requirements, manages the backlog and regularly participates in planning, grooming and retrospectives (SCRAM ceremonies).
The Product Manager is responsible for coordination not only within the development team, but also with other departments of the company – marketing, sales, customer support, etc. He interacts more with external stakeholders, clients and company management.
Priorities:
Product Owner is focused on ensuring that the development team gets the right tasks at the right time and that they are completed with a high degree of quality. He is responsible for short-term results and implementation of features in the product.
A Product Manager sets priorities from a more global perspective – based on the company's business goals and strategy. It decides what features should be added or removed to ensure the product provides maximum value to users and the business.
Key success metric:
Product Owners most often measure their success through the successful and timely implementation of product increments.
The Product Manager focuses on market indicators: profit growth, market share, customer satisfaction and other business metrics.
In some companies, the same role may combine the responsibilities of both Product Owner and Product Manager, but ideally these functions are separated for greater efficiency in product management. And in our case, I consider these roles as separated from each other.
How I understand the role of Product Owner
When I talk about the Product Owner role, I primarily mean a SCRUM role, but with some additions.
In my opinion, Product Owner is the key link between the product team and the development department. The main outcome of the product team is the BRD (Business Requirement Document), which serves as the starting point for the work of the Product Owner. This document details the business requirements for the product, new features or product improvements that need to be implemented. The Product Owner’s task is to “translate” these requirements into technical language (or functional, if you like) and on the basis of this create a product backlog, which he will manage.
Hard Skills Product Ovnera
I propose to highlight all areas of responsibility and tasks of Product Owner separately, so that we have somewhere to “spot” what might happen.
Hard Skills according to SCRUM role
Product backlog management and prioritization;
Description and detail of user stories (User Stories);
Definition and description of criteria for readiness (Definition of Ready) and completion (Definition of Done);
Interaction with interested parties (stakeholders) to collect business requirements;
Participation in sprint planning and prioritization;
Conducting grooming sessions to improve and clarify requirements;
Preparing and conducting product demos at the end of sprints;
Constant communication with the development team to resolve issues and clarify details;
Ensuring the quality and timeliness of task completion;
Maintaining transparency and relevance of the backlog for the team and stakeholders;
Participation in retrospectives to improve development processes;
Following the development of the product at all stages from idea to release;
Assessing and controlling product increments to achieve business goals;
Solving problems and eliminating obstacles that prevent the development team from completing tasks;
Hard Skills tailored to my additional requirements
It is important to me that Product Owner can translate business requirements into technical language. This requires experience with documents such as BRD and WBS. In addition, the Product Owner's key task is to increase the efficiency and accuracy of the development team's estimates. Therefore, skills in working with tools such as BurnUp, BurnDown and Velocity Charts are also of great importance.
Yes, sometimes these tasks are handled by the Scrum Master. But to be honest, I may be too conservative for this role. I don’t want to offend anyone, but from a business point of view, based on my experience, the Scrum Master role seems unnecessary and does not bring much benefit.
It is logical to assume that since the Product Owner works closely with the development team, he needs to understand the development processes at a basic level. Experience with tools such as Postman, SQL, Git is important. Also critical is an understanding of basic technical terminology (by the way, I described it earlier in three articles, I will attach links below) and skills in working with basic tools. For example, using the browser console, knowledge of the DOM model, HTML and CSS to quickly check the front after the completion of the sprint. Experience with APIs via Postman and understanding of JSON will also be a big advantage.
I described the basic terminology earlier in three articles:
From API to CI/CD: Basic terms in IT that you should know
From Gantt to WBS: Key Terms in Project Management
From A/B to OKR: Key Terms in Product Management
And here I wrote an article about what a WBS is and how to compile it:
Elite Suffering with Work Breakdown Structure (WBS)
So, let’s sketch out a list of “additional” responsibilities and areas of responsibility:
Ability to compose and read BRD, WBS;
Ability to work with Postman, Git, SQL;
Basic understanding of HTML, CSS;
Ability to work with the browser console;
Ability to work with API via Postman / JSON;
Optimizing development team productivity;
Application of Velocity Chart, BurnUp / BurnDown Charts;
Skill in manual testing of the front (it’s not a fact that it will be useful, you never know);
Skill of manual back testing (it’s not a fact that it will be useful, you never know);
Ability to work with Figma, Miro, Mural, Draw.io:
Creation of flowcharts;
Creation of wireframes;
Using and navigating the design and UI-Kit of the product in Figma;
Well, it is logical that knowledge of English should be at least at the Upper Intermediate (C1) level.
Making a Test Task
Let's be honest: the market dictates the rules of the game, and this even applies to test tasks. A few years ago, when candidates were “sold out like hotcakes,” no one would have bothered to carry out a long technical specification. Moreover, many simply refused to waste time on any test tasks.
But times have changed. Now the competition for a place has increased significantly, and for a position you almost have to fight with axes until first blood is drawn. In such a situation, a test task is an excellent tool. This will allow you to weed out less prepared candidates and identify the best of the best. So a powerful TK sounds like a good plan, right?
I can already feel how candidates are starting to hate this article 🙂
What to add to the technical specification and what to leave for the interview stage
In general, there is a simple and logical answer here. Let's divide all the skills into 3 categories. For example:
Skills that can be tested in practice
Skills that require a lot of practice and skill
Skills that can be learned in a short period of time
Skills that are difficult to test in practice
Skills that require a lot of practice and skill
Skills that can be learned in a short period of time
In the test task, we are primarily interested in practical skills, which require significant experience and practice. Such skills are more difficult to develop from scratch, so it is important that the candidate already has them at the time of application. This will allow you to immediately select the most trained specialists who are ready to work without long training.
There is no point in including skills that are difficult to test in a practical task in the technical specifications. It is better to leave them for the oral part of the interview, where they can be discussed and assessed during the interview.
Scope TK
You can combine tasks from the practical and theoretical parts, because a complete list may take too much time from the candidate, even in current market conditions. Personally, I think that 4-5 hours to complete a test task in modern realities is quite adequate. If the position is attractive and you expect to earn $5-7 thousand per month, then spending even a whole day to demonstrate your skills should not be a problem. Ultimately, I speak from my experience in hiring candidates and working in similar positions.
Let's go:
Create a mockup in Miro or Figma for any product from the market (product of the candidate's choice).
We evaluate the candidate's skills in creating mockups, his ability to visualize ideas, neatness and attention to detail. It is also important that the candidate is able to structure information and correctly interpret it in visual form.
Describe the User Stories that correspond to the product in the presented mockup;
Formulate DOR, DOD and Acceptance Criteria for these User Stories;
Create a WBS (Work Breakdown Structure) that will describe the structure of the selected product;
Develop a Release Plan calendar that includes the Design, Development, Product, and QA teams. Specify release dates for each command and display their relationship with each other;
Offer an example roadmap for a new feature, from idea to release. What key steps will you include in this process?
Answer the questions:
How do you determine that BRD is ready to be decomposed and translated into User Stories?
Provide a list of APIs you have worked with before;
Based on the job description, in which areas and initiatives do you feel most experienced, competent, and confident?
How do you deal with technical debt? At what point do you decide to prioritize tasks related to technical debt?
What metrics, besides Velocity and BurnDown, do you use to evaluate team performance and product quality?
Based on what criteria do you prioritize the product backlog?
What steps are you taking to improve the accuracy of your development team's task estimates?
Give an example of a time when you were able to introduce a new methodology or process to a team to improve the quality of work or speed up development. How did you do it?
How do you assess and minimize risks in a project? Give an example of risk management from your experience.
Soft Skills
A Product Owner must have not only Hard Skills, but also a developed set of Soft Skills that help to effectively interact with the team and stakeholders. These soft skills ensure the Product Owner's success in managing a team and product, helping to establish effective interaction with different departments and adapt to changes.
Here are the key soft skills that are important for a Product Owner:
1. Communication
The Product Owner must be able to clearly and competently convey information to different participants in the process: the development team, stakeholders and management. It translates business requirements into technical problems, so the ability to tailor your language to your audience is a key skill.
2. Prioritization skills
Since the Product Owner's job is to manage the backlog and prioritize tasks, he must be able to prioritize based on business goals, limited resources and deadlines. It is important to be able to decide which features or tasks will bring the most value to the product and users.
3. Time management
Effectively managing your time and your team's time is a critical skill for a Product Owner. He must balance between short-term and long-term goals, monitor progress and avoid delaying deadlines.
4. Empathy and emotional intelligence
The Product Owner must understand the needs of his team and stakeholders, be able to listen and adapt to everyone’s expectations. Empathy helps resolve conflicts and find compromises, while emotional intelligence helps maintain a positive work environment.
5. Problem solving and critical thinking
Unexpected problems may arise during the development process. The Product Owner must be able to quickly analyze a situation, look for the root cause of the problem and make informed decisions. This also includes the ability to adapt to changing conditions.
6. Negotiation skills
Dealing with multiple stakeholders who may have different and sometimes conflicting interests requires negotiation skills. The Product Owner must make compromises to meet business requirements and team capabilities.
7. Flexibility and adaptability
In an environment of constant changes and adjustments to plans, the Product Owner must be ready to adapt to new conditions, changes in priorities or market needs.
8. Attention to detail
A Product Owner must be meticulous in his work, especially when it comes to documentation, describing requirements (WBS, user stories, DOR. DOD, ACs) and monitoring the completion of tasks. It is important not to overlook little things that can affect the quality of the product.
9. Responsibility and leadership
The Product Owner is responsible for the success or failure of the release. He must be ready to make decisions and take responsibility, and inspire the team with his leadership.
Structure Descriptions of Vacancies
I usually follow a structure like this
Title
Overall Summary
Areas Of Responsibilities
Skills
Test Task (Can go separately)
Overall Summary
This section should briefly describe what the Product Owner role is in your company. Your expectations from the candidate, projects or products on which you will have to work. What teams will the work consist of? Describe certain features of the position or processes, additional wishes.
In general, in this paragraph the candidate should immediately understand where he will end up if he signs the offer. The candidate should immediately have a match or vice versa. So that he immediately understands whether he is wasting his and your time or not.
Areas Of Responsibilities
In this section, you need to describe Product Owner’s areas of responsibility as concisely but succinctly as possible.
A complete list should meet the specific needs of the company and take into account their specific internal processes, team composition, and role expectations. Not necessarily everything that I described in the article will be needed in each specific case.
Skills
A dry list of skills that are important. Maybe just a list.
Test Task
In general, already discussed above.
Ready example
Overall Summary
When we refer to the role of a Product Owner, please don't think of it as a typical Scrum role. Review the list of responsibilities below, and once you join our team, you can choose a title that best suits you 🙂
We are looking for a Product Owner with a minimum of 3 years of experience in the responsibilities and tools listed below.
Experience working in a product company, and not just outsourcing, is a plus, as the processes, goals, and requirements in these environments differ significantly.
It's also a plus if you're familiar with creating and managing BRDs (Business Requirements Documents), WBS (Work Breakdown Structure), as well as DOD (Definition of Done), DOR (Definition of Ready), and AC (Acceptance Criteria) .
A high level of English proficiency (at least C1) is required, as you will frequently communicate with international teams.
Formally, you will be part of the Product Team and report to the Head of Product, but you will regularly collaborate with the IT team.
At present, we have several products already in production, and a few others in active development. You will initially be working on the products that are live (feel free to check our website for more details).
In our view, the Product Owner serves as a vital link between the product and development teams. You will receive detailed business requirements from the product team, and your role will be to: create and manage the product backlog based on requirements from all product managers, describe user stories, add DOR, DOD, and AC to tickets, facilitate grooming sessions, participate in planning meetings, conduct demos for the Product Team, and ensure the timely delivery of features while maintaining the quality of the product backlog, tickets, and features in production. (This is not an exhaustive list of responsibilities, but a high-level overview).
Areas of Responsibility
Manage the Jira Dev board:
Ensure that each ticket is described according to the guidelines;
Custom fields are properly filled in;
Priorities are clearly set;
Each ticket is estimated;
Each ticket is associated with an Epic;
Regularly track Burndown/Burnup charts and IT team velocity;
Provide regular Release Notes and Release Plan reports (export from Jira);
Create, manage, and maintain directories with release reports, release notes, etc.;
Work with BRDs, WBS, and other requirements provided by Product Managers to create, manage, and describe user stories and epics;
Lead grooming sessions with the IT team;
Facilitate planning sessions with the IT team;
Conduct demo sessions for Product Managers;
Gather missing information and ask clarifying questions to Product Managers and other stakeholders;
Ensure the quality of released products and features by checking functionality before the demo and after the QA team's review;
Assist the IT team in following processes defined by the CTO and Operational Product Managers;
Create and describe Epics, User Stories, and Bugs according to the templates, standards, and processes;
Ensure that each user story (if applicable) includes DOR, DOD, and AC.
Required Skills
English proficiency at least at C1 level;
Ability to set and manage DOD, DOR, and AC;
Experience in creating and describing Epics, User Stories, and Bugs;
Proficiency with BurnUp and BurnDown charts;
Ability to create wireframes in Figma or Miro;
Experience creating WBS and BRDs independently;
Expertise in facilitating grooming and planning meetings;
Ability to decompose BRDs into Epics and User Stories;
Presentation skills to showcase product features to stakeholders;
Experience in performing manual testing to ensure that QA and IT teams haven't overlooked any issues;
Be prepared for monthly KPIs, which will be set by your direct manager;
Proficiency in SQL, Postman, and GIT.
Test Task
Prepare a mockup in Figma or Miro of any feature from any marketplace, crypto exchange, or other valuable product of your choice. Please attach the following for the feature:
Additionally, please answer the following questions:
How do you determine when a BRD is ready for grooming, decomposition into user stories, and final estimation?
How would you facilitate the grooming ceremony? What are the expected inputs and outcomes?
Provide a list of APIs you've worked with in the past (include at least a few examples).
Based on the job description, in which areas and initiatives do you feel the most experienced, knowledgeable, and confident?
Provide an example of your favorite product(s) on the market (it could be a marketplace, bank, smartphone, etc.) and explain why.
You can download the PDF here: clack
Conclusion
Finding a good Product Owner means finding someone who both understands business and technology, and also knows how to effectively manage development processes. Such a specialist must have several key skills. Firstly, it is the ability to competently prioritize tasks and manage the backlog, which helps the team achieve goals without unnecessary delays. Secondly, experience working with documents such as the BRD and WBS and using metrics like Burndown and Burnup to track the team's progress are important.
My social networks.
Telegram Channel: https://t.me/mr_ponder
