3 Skills to Become a Great Product Owner [Role and Responsibilities]

Product Owners are one of the most important roles in a product team. The Product Owner represents the business, customers, and/or users, and guides the team toward building the right product (not just any product).  

In order to be an effective Product Owner, you first and foremost must be willing to put in the time to do the job well. Beyond that, learning how to prioritize effectively, weigh the needs of diverse stakeholders and requirements, and communicate effectively through various mediums are key for a successful product team. 

If you don’t have a PO yet, you’ve recently entered the role, or you’re looking to brush up your skills, this article will help you focus on the key skills to develop.  

Product Owner Role and  Responsibilities

The title “Product Owner” is the term generally used within the Scrum framework, though some teams might instead use titles like “Project Owner”, “Technical Product Manager” or “Customer Advocate.” For the sake of simplicity, we’ll be using Product Owner in this article. 

Who actually fills this role varies: they can be the founder of a startup, a member of the marketing team, or hold a number of roles within their company. Regardless of their official role, however, all Product Owners must have an understanding of the users, as well as the business needs the product fulfills. 

They are the liaison that communicates the product vision to the development team, establishes priorities, and works with product designers to translate the user’s needs into the final product. The following diagram visualizes the key responsibilities of a Product Owner:

Product Owner vs Project Manager: What’s the Difference?

In the context of project implementation, we often find two different roles: the Product Owner and the Project Manager. The former is focused on the overall vision and concept, while the latter is mainly focused on execution. They work closely together, but their role is substantially different. Whereas Product Owners live and breathe the product and are concerned with defining and designing its features, Project Managers are responsible for execution, meaning they take ownership of implementation and managing the given resources. 

Three Key Skills to Becoming a Great Product Owner

As we explored, the core goal of a Product Owner is to understand the users’ needs and pain points, then translate these into design and development decisions that meet these needs. Of course, a Product Owner is weighing several factors into product decisions on this front: cost, resources, prioritization of other features, and overall business objectives all being chief considerations.

As the core liaison between users and product development, a Product Owner must balance competing priorities and multiple stakeholders. While the Product Owner must be well-rounded and adaptable, a great Product Owner will be especially strong in three areas:

• Dedicates Enough Time: A great Product Owner understands the importance of this role, and makes sure they have enough space to do it well. 
• Strategic Prioritization: this role requires the ability to prioritize across diverse stakeholder and department needs, as well as technical requirements and feasibility.
• Communicates effectively: A PO must learn to communicate with stakeholders and team members in multiple modalities, including written, spoken, and diagramming.

We’ll break these down in the following sections. 

#1 Put In the Time

Far and away, the most valuable thing a Product Owner can do is contribute their time.  Translating product vision into reality cannot be rushed: you need time to research approaches, think about the best solutions for your company, and attend meetings. On top of this, preparing user stories and specifications that are thorough and concise take time to do well. At the end of that cycle, explaining your vision, ensuring it’s understood, and being present to answer questions is the only way to make sure that vision becomes a reality. 

While putting in time may seem simple, by no means is it. Your time is the most valuable asset you can give to the Product Owner role. In the end, being thorough and thoughtful in this role will help you attract and retain customers, and possibly even save time on revisiting features later, because you’re ensuring the vision is captured correctly the first time around. 

How much time? There is no one-size, fits-all answer to this, and it varies for every company, product, and project scope. That said, it can be helpful to think about the types of work a Product Owner does. Then, be honest with how much time it takes to do each of these things well. Product Ownership will take at a minimum 25% of your time; in many cases, it’s a full-time job. 

It’s especially important to be present at daily scrums, where the Product Owner can get a regular pulse on what the team is doing, understand whether assumptions are being made, and answer design and development questions. By being available here, Product Owners can unblock their team members and keep projects on track. 

#2 Prioritize Effectively

Product Owners set the priorities for new features and bug fixes for each sprint. This is the most important process a Product Owner will manage. 

In Scrum, we have the concept of the Product Backlog, which is a prioritized list of features the software should have. The Product Owner’s number one job is to make sure that this list has the most important features in it at all times and is prioritized properly so that the software will provide the optimum value to its users.

Use Data to Drive Product Decisions

When deciding which features should be built in what order,  quantitative and qualitative data are a Product Owner’s secret weapon. 

There are a lot of data that a Product Owner can – and should – weigh in making their decisions. Primary data, like user studies, feature estimates, budgets, and constraints all must be considered. But secondary data, (data that is collected by other companies or groups), can also be useful. This can include data sources like surveys, in which problems you hope to solve have already been reviewed, tested, and the best solutions validated. 

Let’s consider an example. Imagine you want to build an exit overlay – a popup or screen to win back a visitor’s interest before leaving your app or site – with the goal of increasing conversions. How might you validate this decision? 

Using secondary data, you could find studies or evidence that demonstrates the impact of an exit overlay on user behavior: is it more likely to make users stay? Are there any caveats to the data, such as whether it’s a new or returning visitor, or if it should only be activated after a certain amount of time spent on the page? If there is no existing data to be found, you might consider running an A/B test to validate whether an exit overlay would have the desired effect. 

Primary data (data you collect yourself) can sometimes be superior to what you find online. Every audience and product is different, and target markets have different needs and desires. So another great option is to gather feedback from real users. Product Owners can recruit their friends and colleagues to give feedback on their product, though this isn’t often advised, as data collected from friends isn’t unbiased (and they may be hesitant to give you negative feedback) 

A more objective, unbiased way of collecting feedback is to leverage services like User Testing, which can help (often quite affordably) gather information from users about their experience with your product. Odaptos is another tool that allows you to test your product while analyzing the live emotions of users. This might be preferable to feedback from friends and family, who may be reluctant to give you constructive feedback. However, if budget is a constraint, friends can definitely fill the gap. 

But what if you’re rethinking a feature that’s already in production and being used by real customers? In that case, products like UserVoice allow real users of your product to report issues or make suggestions about features they would like to see added. 

Of course, this can (and should) be paired with behavioral analytics. If you’re running a web app,  tools like Google Analytics, MixPanel and Inspectlet can help you diagnose issues. For instance, are there screens or pages where users are exiting your site? Are there pages where engagement metrics are low? Is some content not being viewed at all? If you are running a mobile app, there are other behavioral analytics you can use. Mixpanel is one, but other options include Pendo and Clevertap. In both cases, analytics tools can help inform and validate a Product Owner’s feature decisions.    

When data isn’t available from tools like the ones above, there are still options. Your development team may be able to provide server log data to the Product Owner to find information about user behavior and application errors. User studies can also be leveraged here. And even digging into what competitors are doing can be a potential data point. 

I can’t stress the importance of prioritization enough. Particularly for startups, where funding is limited, you don’t want to spend precious money building features you think users want, but don’t actually provide value. Therefore, it is important to do your research and choose the priority of features in the backlog carefully based on the best data available.

Groom the Backlog

Once you’ve conducted your user and market research, you should have a good idea of the features you think your users will want, and how you can differentiate in the market. This information should be turned into a backlog, which now needs to be managed. 

Backlogs are a live artifact, meaning they are in constant change. Features are added and removed as Product Owners refine their understanding of what should come next in terms of feature development, with higher priority being given to those that might deliver a higher value towards their users. 

Due to the nature of this artifact, it’s important for the Product Owner to always stay one step ahead by grooming their stories and epics as much as they can. Focus on understanding pain points and the value behind each user story, then work closely with your UI/UX designer using a Design Thinking approach to land on the perfect set of specifications.

Roadmapping

We mentioned before how user testing can help improve your product. A Product Owner will spend a lot of time with end users, not just to get final acceptance on what has been implemented, but also for conducting interviews to groom further upcoming features and continue to understand remaining pain points. Having a healthy roadmap is a sign of good planning. It helps ensure the necessary resources are readily available, and what direction the product is taking. 

What gets added to the roadmap and what doesn’t can be hard to define. At this stage, diligent work with stakeholders is required. This will help you set the right expectations and put features into the perspective of other teams and individuals, ultimately allowing you to understand the complexity and impact a single feature can have. It’s often helpful to establish a set of criteria and use weighted scores to facilitate the decision making process.

It can be helpful to visualize the different priorities and criteria different stakeholders will have. With a weighted impact framework, you can prioritize your product roadmap using multipliers to score and rank the priority of your features based on their cost vs their impact. For example:

Weigh the Risks

With a roadmap in place, it’s time to run a risk assessment to mitigate what we can. Of course, being adaptable is important and a core pillar of scrum; but part of that comes from understanding potential risks and solutions.  For this reason, designing various scenarios is a mature practice for advanced Product Owners.

 #3 Communicate Effectively

Once  your desired feature set is decided and outlined, the next step is communicating it to your development team. Sounds simple, right? Well, there’s a lot riding on your communication as a Product Owner here: without clearly communicating your vision of these features, you may end up with the wrong one, costing you precious time (and money, and potentially even users). Here are some techniques, both technical and non-technical, to help you better define your features so your developers get things right the first time.

Write Effective User Stories

User stories are short and simple descriptions of a feature that needs to be implemented. They are told from the perspective of a customer or a user of the system. A user story can be written like this: “As a [type of user], I want [to do something] so that [benefits]”. The important thing is to keep it simple so that anyone who is picking up the story understands what’s being delivered. 

An example of a user story for a To-Do app might be:

As an external user, I want to be able to create tasks and add them to my lists so that I can organize my day.

The example above is rather simple, but if you find that your user story is too complicated, you should probably break it down into multiple smaller user stories that can be implemented and tested quickly. A group of related user stories is grouped into an “epic” and may all need to be released together.

For a deeper dive, you can check out an overview of user stories, along with examples, in this article. Often, the most important thing to cover when specifying these is the acceptance criteria. These are a set of conditions that allow you to sign off on the feature implementation. These criteria contribute to product quality and minimize risks as they are meant to remove assumptions on what a completed feature should have to be considered “done”.

Use Annotating Tools

Usually, a simple user story won’t provide enough information for the development team to implement a feature. In this case, annotations are a great way to supplement the user story and provide further definition.

Skitch is an annotation tool that lets you add notes and information to screenshots that you have taken. Tools like this help you get your points across more quickly and make it instantly clear to a developer what it is you’d like them to do.

This becomes crucial when working with a remote team on an asynchronous basis. Regular communication is important to set proper specifications and reduce questions on the person in charge of the implementation. It’s important not to  assume anything is obvious. Features and requirements may be crystal clear to you, but the way you communicate them to your team is what will set up for success or failure. 

Wireframe

When building entirely new, complex functionality, you may need to go to the next level and wireframe features. 

Wireframes are like blueprints; they help communicate the flow and structure of the website or app being built. Wireframes are rough sketches that do not include the final look and feel. Key elements of wireframes include:

• Page layout
• Relative importance of page elements
• Annotations to describe user interactions

There are many wireframing tools available (some of them free) and non-technical individuals can learn to create them. In fact, wireframes can even be drawn by hand with pencil and paper and then scanned or photographed in order to be shared. 

Not all Product Owners will have the time or the ability to wireframe. In this case, they may delegate this work to other team members, like a designer. For additional resources, here’s a helpful tutorial for learning to wireframe and a list of wireframing tools that will support you getting started. 

Let’s face it: it’s no longer enough to make a product look pretty from a UI standpoint. It’s equally important, if not more, to nail the user experience (UX). 

For this reason, it’s highly recommended to partner up with a UI/UX designer. UI/UX Designers typically have a background in design thinking,  a process that sets its foundation on a user-centered design and works well with agile projects because of its iterative nature. The valuable information it generates through its testing phase minimizes risk and provides relevant insights for the next phase of refinement.

Designers can help you communicate everything your wireframe is capturing and more. Usually, UX comes first in what is known as a Lo-Fi wireframe, typically made on a white and black pallet. The intention is to capture experience first, then refine the flow, data entries, and main components. Once its been pinned down, designers will move into the UI,  incorporating branding elements like colors and logos. They will also make sure it responsive enough to ensure a good experience on every device. This is your Hi-Fi wireframe and it’s essentially how your product should look in a pixel-perfect type of implementation.

Lately, tools like Figma have become popular as they are a great combination to work with designers and have a proper handoff of their work to other teams. Figma in particular is a collaboration tool that supports prototyping and provides a great experience on his web and desktop versions. 

Documentation

Along with grooming the backlog and prepping requirements, Product Owners often spend much of their time writing functional documentation, creating flow charts, and designing roll-back plans. As they are the gatekeepers of user behavior, they know the functional aspects of the implementation and the business rules implied in it. Here are some aspects that we recommend you cover in your project documentation:

• Make sure to explain the business rules that are involved in the implementation. Explain why it works the way it does and relate these to your key users and roles.
• Represent processes using flow charts. If you want to go the extra mile, include key actors, tasks and KPIs.
• If you are collecting metrics, relate them to your processes so they become meaningful.  Explain who the stakeholders are that might be interested in them.

If you aren’t currently documenting to this level of detail in your current project, don’t feel bad. The agile approach has taught us that we don’t always need extensive documentation. One-pagers are often enough to communicate ideas. Sometimes it’s just a matter of defining features core to the business that might ease knowledge transfer in the future. 

There is a relevant trade-off to consider when it comes to documentation between time spent on your part, and availability of information for team members. As the Product Owner, focus on finding a sweet spot where you feel comfortable with the documentation level. 

Advanced skills for Product Owners

If you’re a more technical Product Owner, or you have experience already in the role, there are two additional areas we recommend for Product Owners to understand.

Know the Database Schema

If your website or application is more than just marketing information, it likely is powered by a relational database (like MySQL) or some other kind of database. Either way, it’s useful for the Product Owner to understand the structure of this database (often referred to as the “schema”). Understanding your database schema will have the following benefits:

• Easy access to data about your users with queries (typically in SQL)
• A sense of what features will be easy or difficult to implement (major schema changes can be costly)
• Sharing the vocabulary of the development team will allow you to write user stories and specifications in a clear language that they will quickly understand
• Can produce data visualizations charts that can be used for stakeholder reports using tools like PowerBi

Most databases can be set up with a graphical user interface (GUI) so that a non-technical person can click around and learn about it. This, combined with read-only access, is a great tool for Product Owners and is something that your dev team can usually set up fairly easily.

Most importantly, it will allow you to use data visualization tools for better reporting to stakeholders. The more comfortable you feel in your understanding of the data model, the better if you want to be able to conduct some data analysis.

Get to know Chrome DevTools

If your product includes a website, Chrome DevTools are a feature of Google’s Chrome browser that might be quite useful to you. Although typically used by developers, a Product Owner with a basic understanding of HTML and CSS can learn how to use them to test and see how a change would look before asking the development team to actually make the change to the software.

Right-clicking an element on the page, and selecting “inspect element” allows you to view and adjust the element’s CSS properties. With a basic knowledge of CSS, a person can fine-tune things like font size, color, borders and more. There are no more guessing games involved when the Product Owner knows how to communicate the specific CSS attributes they would like a developer to use. 

If you’re unfamiliar with DevTools, here’s a useful tutorial on the subject. And we highly recommend becoming familiar with it! DevTools can help you be more thorough with your bug reports if you participate in QA of the implemented features. What’s more, it empowers you to take the first step if you encounter issues in production: you can cover at least the first step of reporting, simply by checking the console for front-end-related issues. More technical POs can go even further, looking at the Network tab to see what endpoint might be failing. 

In Summary, What Makes a Great Product Owner?

An informed, detail-oriented, and thoughtful Product Owner can have significant impact on a company and its software tools and products. Without one, the best development team can waste precious time and money working on features that don’t address their customer’s needs. Empowering yourself to be an effective Product Owner by dedicating sufficient time, learning how to prioritize your backlog, and clearly communicating how the software should work will alleviate risks and increase the chances that your project will succeed.