/
Design team

All You Need to Know to Understand Product Owner Role

0

mins to read

There are two types of people who get paid for owning products: Instagram influencers and product owners (POs). Today, we’ll talk about the latter.

Eleken designers get to work with different product teams, joining them as one more team member. It means getting to work with project managers, product owners, founders… Different organization systems bring different roles. So, let’s take a look at product owners from a designer’s point of view.

product owner vs instagram influencer
Image credit: Photo by Laura Chouette and Bonneval Sebastien on Unsplash

The history of the product owner's profession is easy to track. It didn’t exist before the Agile system was born, in 2001. The system was so revolutionary that it required a new role on the team to help manage the processes.

“Owning” a product, process, or project means taking the responsibility and following the work process (yes, I realize that so far there’s very little difference with an Instagram influencer). And once I’ve mentioned responsibilities… There are a few.

The main goal of the product owner

The major goal of the product owner is to deliver the best product by managing the work of the development team in the most efficient way. And… that’s all there’s to it. Seriously, nothing more to add. That’s why, let’s proceed to responsibilities. 

Key responsibilities of product owner

Managing the backlog

In simple words, a product backlog is a to-do list of the development team. These are the bricks out of which the product is constructed.

Product owner has to break the pieces of work into right-size parts and assign them to the development team. Their job is to turn those often big and abstract ideas of product managers into concrete, doable and measurable tasks.

Defining user stories

User story is a product feature as seen by the user. One of the responsibilities of the product owner is to bring user vision to the product team. They have to explain to the development team what features they have to implement based on studying the customers' needs.

Prioritizing

In Agile, the synonym of flexibility, defining the most important tasks and putting them first is the key to success. This is what differentiates backlog from a to-do list: developers can do all the tasks, but if they are not prioritized, the product will not get to its best.

Connecting the team and the stakeholders

Product owner is the person who is being asked all the questions that people don’t know whom to address. As we’ll see below, syncing between different parts of the team and making sure that the developers don’t exist in their comfortable vacuum is a basic responsibility of a product owner.

Four levels of product owner’s tasks

Of course, this list is not exhaustive. Often product owner has to take on a variety of tasks on a few levels:

  1. Strategic. Defining where the product is going, what it offers to customers, and so on. It is joint work with product manager, CTO, analyst, and others. The product owner’s job is to bring all the ideas to a single vision. Strategic level implies collaboration with different teams: sales, marketing, engineering, and so on.
  2. Working on the solution. When the goals are defined, the product owner has to decide which features the product will have. Together with designers, tech leads, and analysts, they make the vision take real shape. Product owner has to set limits and organize the work so that the output will be a set of tasks for the backlog.
  3. Operational. These tasks are for the stage of realization. The product owner has to plan development iteration, solve the questions that arise during the process, follow the performance of the tasks, check the results, and get the team through all the iterations to the release. This includes the need to adapt the processes of interaction and development.
  4. Communicational. This includes both internal and external communication. The product owner writes release and update notes and stays in touch with customers to ensure that product is responsive to their needs.

A typical day of a product owner

  • Starts with c̶o̶f̶f̶e̶e̶ daily meeting: checking statuses and plans. For team members, it’s just a regular organizational task. For product owners, it is the basis of their work. They take notes, ask questions, and define the day agenda based on the information from the daily meeting.
  • Work with the designer: checking the progress, giving feedback, setting task priorities, and explaining the details when needed.
  • Setting tasks, tracking, and updating the backlog.
  • Syncing with sales, product team, and director.
  • Preparing materials such as release or update notes, checking the documentation
  • Tasks vary depending on the product development stage. At the beginning of a cycle, there are meetings with the tech lead, lead analyst, and designer to discuss features for the next release. If the release is coming to the finish line, the product owner is setting the stage for this final episode: approve the final product, and transfer it to testing. At the same time, the preparation for the next release starts.
  • Client analysis, interviews. Knowing the customers well is one of the key responsibilities of a product owner. This can be different for B2B and customer products.
  • In the end, a large chunk of the day is likely to be filled with short calls/chatting with team members, answering questions about current tasks, checking the progress, and sharing memes (crossed). All of this is accompanied by big amounts of coffee and tea.

What makes a great product owner

We asked a few product owners to complete the phrase “Great product owner does…” and here is what they said.

  • … Knows how to balance orientation on business goals customer tasks, and limitations. 
  • … Formulates and assigns tasks correctly.
  • … Has great communication skills. If you’ve seen the typical day above… You get how much time a product owner spends communicating with other people.
  • … Knows how to manage people while not being a lead officially. That’s a tricky statement. In a horizontal scrum organization, there is no boss, but someone has to be that connecting chain between the team members.
  • … Lets team member do their work and resists the desire to “do it better yourself”.
  • … Possesses structural thinking that is essential to see the process as a whole and know the place of each team member in it.
  • … Has interest in everything new, eager to learn, and trust the opinion of professionals in the sphere where they are not very knowledgeable

Product owner vs product manager vs scrum master

product manager vs scrum master vs product owner meme

Sometimes roles in product teams can be puzzling. One can say that it is a sign of a young industry that is yet to establish clear standards, but there is nothing negative about that. I believe that such a difference in role definition is one of the characteristics of a flexible work environment.

Although many IT teams apply the principles of Agile in their work, most of them don’t follow all the canons relentlessly. They adapt them, taking the parts of scrum, kanban, design sprints, you-name-it methodology, combining, and doing what fits their situation best.

You can think of it as a signal that the system is not universal. On the other hand, the widespread usage of Agile, even modified, is indeed a sign of its docility. Both big and small teams can adapt it to their needs, even if they don’t have the capacity for a product owner and scrum master at the same time.

That is how different roles can merge in one person. Most of our clients work in small or medium-size teams, and often there is just a product manager responsible for most of these tasks.

Let me explain briefly the difference between these three roles, but remember, it’s not carved in stone — Agile has to be responsive to circumstances.

Product manager (PM)

In big teams, the product manager would be responsible for the whole product, while product owners would work with one or more teams inside the product. So, there would few product owners for one product manager.

Naturally, the role is more strategic, and related to all facets of the product. PM has to work along with marketing, sales, CEO, customer success, and, of course, developers and designers.

Product manager’s job is to follow the whole product lifecycle from idea creation to the release and after release, aligning the needs of customers with business goals and overall company strategy.

Product owner vs product manager

While product manager has a more strategic and global vision, product owner is more concrete in their working focus: they take the vision and split it into feasible actions and tasks, creating user stories and backlog.

If you read all the text above, you already know enough about the product owner role. If you are interested in the differences and dynamics between product owner and project manager, you might find interesting our article “Product Owner vs Product Manager vs Project Manager: Who Do You Need to Build a SaaS Product?

Scrum master

If PO or PM are the roles that every team has, scrum master is only for those companies that are serious in their intention to follow all the rules of Agile. Unlike product owners and product managers, scrum masters don’t make decisions about the product itself. Their main job is to help team members to follow the system and facilitate meetings, sprints, and other elements of Scrum.

Final thoughts

Product owner is one of the most peculiar positions. Job title appeared as a fruit of a work organization theory. As our lead designer, Maksym said, “We always work with product owners, even if they don’t call themselves so”. This means that there is always a person who owns a product, even if they don’t even know what the product owner is. In a one-man band, the founder would be the product owner (though of course, they would not need to read a detailed article like this one).

It was a quick introduction to the world of a product owner. If you want to learn more, read our article about product owner challenges.

Masha Panchenko

Author

Table of contents

Top Stories

Design team
/
0
min read

What's the Role of a Product Owner During Daily Scrum? 5 Tips to Remember

Here at Eleken, a SaaS design agency, we are lucky to work with Product Owners (POs) that come directly from our clients’ companies. It’s natural that they are eager to get regular updates on current progress from the whole product team. In some cases, they hold separate meetings for this purpose, while sometimes they choose to attend the Daily Scrum. 

The Daily Scrum is not a place for a PO to receive status updates, however, this event may be valuable for this professional to attend. 

But why should the Product Owner attend the Daily Scrum (if they should at all) and what are they supposed to do there?

Before we discuss the role of the Product Owner during the Daily Scrum, we must, first of all, clarify why this event is important in project management. 

The purpose of the Daily Scrum

Imagine you have two weeks and six workers to build a fence. Using the “Scrum language” that would be a sprint of two weeks with the sprint goal to build a fence with six developers. To successfully cope with the task and meet a deadline, you’ll have to create a plan and daily distribute the work among team members. Every morning, you’ll meet with your workers and discuss what was already done, what is to be done today, and if someone needs help to progress towards reaching the goal. Such a daily meeting can be translated as a Daily Scrum.

The Daily Scrum, also known as daily stand-up meeting, daily stand-up, or simply daily, is a short (up to 15 minutes) event held every day at the same time for a small development team. 

The objective of the Daily Scrum is for the development team to collaborate, plan the work for the day and inspect the progress with the sprint goal. This helps the team to adapt the sprint backlog as necessary, adjust the upcoming work plan, and to identify issues that affect the project progress.

Here’s what Alexandra, our product designer, has to say about the importance of the Daily Scrum based on her experience:

“The developers in one of my recent projects worked in sprints and invited me to attend their daily stand-ups. Since they work as a team, it was important for them to be aware of who is doing what. And I noticed that a great advantage of these daily meetings was the motivation they gave the developers. Everyone wanted to show their progress at the stand-up, and thus they did their best to complete daily tasks in time and successfully.”
Key characteristics of a daily stand-up meeting
Key characteristics of a daily stand-up meeting. Image credit: balasegu.weebly.com

The Daily Scrum has no strict structure or techniques needed to be used, so it’s up to the developers to decide how to hold the meeting and what questions to ask. The main thing is to remember the purpose of the daily stand-up — inspect progress toward completing the Sprint Goal and create a solid plan for the day.

It’s also essential to understand that the daily stand-up is NOT a:

  • status update meeting. The goal is to help the development team collaborate and see how the work proceeds. Participants shouldn’t report either Scrum Master (SM) or PO about status updates.
  • problem-solving meeting. It’s not right to discuss issues and seek possible solutions to those problems during the Daily Scrum. Such discussions are better to hold right after the daily. Remember to keep the event no longer than fifteen minutes.

But what about the Product Owner’s participation in the Daily Scrum? Let’s shed some light on this topic in the next section.

Should the Product Owner attend Daily Scrum?

According to the Scrum Guide

The Daily Scrum is a 15-minute event for the Developers of the Scrum Team…. If the Product Owner or Scrum Master are actively working on items in the Sprint Backlog, they participate as Developers.

Based on this extract, we understand that the Daily Scrum Meeting is, first of all, for developers. The Product Owner is neither encouraged nor forbidden to attend dailies, they are just not required to be present unless they are actively working on items in the sprint backlog like developers.

At the same time, the guide says that “the entire Scrum Team is accountable for creating a valuable, useful Increment every Sprint.” and that “Daily Scrums improve communications, identify impediments, promote quick decision-making, and consequently eliminate the need for other meetings.”

Taking this into account, we may assume that though PO’s presence on a sprint daily stand-up is optional, their attendance will be valuable as they are a part of a Scrum Team (Scrum is effective when there are no sub-teams but a whole-team mindset). 

Below are a few reasons why it might add value to a PO to attend the Daily Scrum:

  1. Presence at a daily stand-up allows PO to receive early feedback from developers. Listening about the sprint progress/challenges the team faces, allows the PO to use this information to refine user stories, modify the backlog, and update the product roadmap.
  2. The Product Owner in the Scrum meeting will get a better understanding of the technical aspect of a product which will help them prioritize the backlog more accurately.
  3. During the Daily Scrum, the team may raise questions about priorities (for example, if someone reports the bug) or user stories in a sprint backlog. As one of the PO's responsibilities is to manage and prioritize the backlog, their presence in dailies allows to bring clarity on the overall product vision and stories in progress, and define which story to omit if the team is falling behind the schedule. Finally, PO’s presence at stand-ups shortens the amount of time a developer has to wait for a response.
  4. At the daily stand-up, the team discusses obstacles and blockages they have and a PO might be able to provide them with helpful information regarding the business context to help developers smooth their way towards overcoming those obstacles.

Now let’s summarize the main points that characterize the role of the Product Owner in the Daily Scrum meeting.

  • The Product Owner can attend the Daily Scrum if they feel it brings value. They shouldn’t be active participants there, but rather attentive listeners. POs can only participate as team members and may only share some really important information that helps developers reach the sprint goal.
  • It’s not the responsibility of a Product Owner to lead or facilitate a Daily Scrum, and developers do not report them on what was done.
  • Product Owners that attend stand-ups should listen about things that require their attention to be able to follow up with team members who have questions for them right after the Daily Scrum (if possible). 

Now that we know that the PO can be present at dailies, let’s discuss how they should behave to support the team and not steer the event in the wrong direction.

5 pieces of advice in case the PO chooses to attend the Daily Scrum

Here are five things to remember to help the team benefit from your presence at stand-up meetings as a PO.

  1. Don’t interfere. The Daily Scrum is not your event, but developers’. They need to be self-managed and feel the ownership of deciding what to do next, and how to implement this or that feature. Stay focused and don’t step in, even if you have a brilliant new idea to share (there are refinement sessions for that) until you are asked a question.
  2. Focus on the outcome metrics and not the output-driven metrics. Very often, during the daily, the PO focuses on the velocity, asking developers why some items are moving to “done” so slowly. It’s not right, as the Product Owner should care about metrics that show if customers got the value they wanted to get, and not what actions were done to achieve this outcome.
  3. Avoid the “me vs they” mentality. Beware not to create a sense of hierarchy by holding the meeting (as you risk killing innovation). As well, during the Daily Scrum don’t stand aside from the whole team and don’t be late. Remember you’re a part of it. Mind that developers talk to the whole team, and not address their speech directly to you. 
  4. Ensure the team is aware of why you attend Daily Scrums. If people begin to question why the Product Owner is present, when they know little about the technical aspect of a product, you may ask a Scrum Master to explain that your presence is advantageous to them and necessary for an efficient and open development process, as you are a part of the team that represents the product to the stakeholders (customers and management).
  5. If anyone in the team wants to raise any issues that require your assistance, leave it to the end of the stand-up to have a breakout discussion. Everyone uninvolved in that discussion can leave at that point. And if you want to receive a regular update on stories from team members, schedule a separate meeting. For instance, to be on track with the product teams, our designers at Eleken usually agree on regular meetings with a PO, that can be held every day, once a week, or at any other convenient time interval. There we can talk about current sprint progress, and roadblocks, or ask some specific questions.

To sum up

A Product Owner is a part of a Scrum team, who is responsible and accountable to deliver a working product at the end of each sprint. Therefore, even if a PO is not currently working on items in the sprint backlog as a developer, they still should join the Daily Scrum for quick decision-making and changing priorities in the sprint backlog.

Everything in the Daily Scrum should help the team collaborate together and move forward in reaching the sprint goal, and the Product Owner’s objectives during the Daily Scrum should also be directed to support this goal.

Design team
/
0
min read

Diversity is Future: Building Diverse Design Teams to Drive Innovation

Design is all about creating something that is not only visually appealing, but also serves its purpose effectively to various people. But here's the question. When you have a diverse audience that includes people of different genders, races, backgrounds, religions, how can you design a product everyone will find valuable? And the answer is, by building a diverse design team.

Of course, diversity is the buzzword you’ve probably heard many times by now. But when it comes to design, we, as a design agency focused on SaaS products, can surely say that a diverse team is the key to creating revolutionary designs. In this article, we’re going to tell you why it is important to build diverse design teams and show you examples of some industry giants that embrace Diversity, Equity and Inclusion (DEI) standards to drive innovation. 

Without further ado, let’s start the ball rolling.

Why is it important to have a diverse design team?

When you start researching and actually talking to your users, it turns out that "normal" people are a myth. So designing a product with a mythical average Joe in mind won’t meet the needs of a huge chunk of your audience. For example, according to the CDC, there are around 61 million adults in the US who live with a disability – roughly 1 in 4. And disability is something we are obliged by law to keep in mind while designing new products. There are many more factors we might not even know, unless we talk to actual users, listen to their perspectives, and design the product accordingly.

Statistics on disability in adults in the US
Source: CDC

What’s more, some technologies, which started as assistive – for example, Siri – now are widely used by everyone. Inclusive technology benefits everyone, and you don't want to miss out on opportunities it brings.

So, what benefits exactly come from a diverse team? 

Diverse teams can bring different perspectives to your product

No matter how much empathy your design team has, they’ll never be able to understand whether the design is accessible for disabled people unless the latter are included in the design process. And it's better to do so from the very start instead of trying to fix accessibility issues later on (although, of course, better late than never.) So when you want your product to be accessible for everyone, you should definitely add disabled people to your team and learn from their experience. 

To prove this point, let’s look at two examples that show how diverse teams helped make their products easy-to-use for everyone.

Pinterest

First case worth mentioning is Pinterest and its experience in making their platform more inclusive for people with visual impairments. The company recognized the need to make their platform more accessible and took action by assembling a team of talented designers and experts with diverse backgrounds and experiences, including individuals with visual impairments. After conducting user research to understand the challenges they faced when using the platform, the Pinterest design team made a number of changes to the platform, including increasing the contrast of text, improving the readability of fonts, and providing alt-text descriptions for images.

Pinterest screenshot before redesign
Pinterest screenshot with accessibiity redesign

Pinterest’s example shows us how diverse design teams can drive innovation and create a better product for all users.

Slack

Slack is another great example of how diversity and innovation can work hand in hand. Among its product designers, Slack has people specifically advocating for accessibility and inclusivity. There's also an "Abilities Employee Resource Group" – community of disabled employees. 

The company created an accessibility toolkit for designers, which included guidelines and best practices for designing accessible features. This toolkit helped to ensure that accessibility was considered at every stage of the design process, from ideation to implementation.

How does that translate into the product itself?

First of all, a variety of keyboard shortcuts are included to ease the navigation. For example, F6 can be used to move between major sections of the app, such as the list of messages and the new message box. Other keyboard commands are included for switching between channels, messages, or changing the text size. 

Slack accessibility options

Slack will automatically read messages in a channel when pressing the Up or Down Arrow keys when one uses a screen reader such as JAWS, NVDA, or Narrator. The iOS and Android apps have been tailored to work well with screen reading and magnification tools. Buttons and controls are labeled, and a variety of low-vision options are included.

Slack's team both includes disabled designers and communicates with its disabled users to learn how they actually use the app and how the process might be made smoother for them. As the result, Slack is accessible and therefore continues to grow in popularity. 

Diverse teams allow avoiding unconscious biases

An important benefit of having a diverse team in product design is the ability to identify and avoid unintentional biases. For example, according to the report by The Verge, heart rate sensors on some devices, including those made by Apple and Fitbit, are less accurate for people with darker skin tones. This happens because the sensors use green light to detect changes in blood flow, and darker skin absorbs more of this light, making it more difficult to get an accurate reading. 

Fitbit smart watch
Image: Fitbit

Had this issue not been discovered, companies would have suffered reputational damage from products that reflect the biases and assumptions of the dominant group. So, when you want to avoid such biases and create a product that is truly inclusive, consider creating a diverse team that includes people from different racial and ethnic backgrounds.

Diverse teams promote cultural sensitivity

A diverse design team ensures a consistent perception of your product across different cultures. If you're working for an international audience, offering your product in languages other than English is the bare minimum you can do. Make sure you're collaborating with native speakers to translate and proofread your copy. But it goes further than the languages.

In 2021, Airbnb changed its paradigm. Now, it automatically translates the listing into the user's native language and shows the button to go back to the original language instead of vice versa. They use machine learning, but also, as they claim, "Every single correction from the localization team improves the machine translation instantly."

Airbnb automated translation

Except for this unique approach to language accessibility, Airbnb provides guidelines for hosts to create a welcoming environment for guests from diverse backgrounds. It also implemented a multicultural training program for their product design and customer service teams. The program focused on cultural awareness, bias, and communication skills. The program was successful in increasing awareness and understanding of cultural differences, and in promoting more inclusive and diverse work environments. 

How you can build a diverse team: tips and best practices

Now that we understand why diversity is important in design, let's move on to the practical issues. Namely, how do you create a diverse innovative team? There are some tips on how to build a design team and increase diversity in your workplace whether you're a small startup or a successful corporation, and we’re just about to discuss them.

Implement inclusive hiring practices

Before the team is even formed, inclusive hiring practices are crucial to building diverse design teams and creating a culture in which everyone is accepted and appreciated. What specifically can you do?

  • Cast a wide net for candidates to ensure that the applicant pool is diverse.
  • You can remove identifying information from resumes to ensure the process is unbiased. Check out the table below: various bits of information from one's name to their hobbies can indicate a person's race, age or religion, and sway the hiring manager one way or another. It might be a good idea to employ special software to ensure these details are edited out of CV before they get on the table of people who make hiring decisions so they are not unconsciously biased. 
Sources of unconcsious bias in CV
Source: SHRM
  • Create diverse interview panels: make sure hiring team consists of people with various backgrounds (for example, includes people of color, LGBTQ+ people, and so on.) 
  • Provide training on unconscious bias for hiring managers. 
  • Use inclusive language in job postings (for example, go for gender-neutral terms and pronouns, such as “they” instead of “he” for genderless positions). 
  • If you fear your locale might stand in the way of diversifying your team, do not hesitate to broaden your geography. With contemporary design collaboration tools you might not even notice you aren't working in the same office or country. If that's something you are willing to try, check our article on how to build productive relationships with external design team.

Provide training and education on diversity and inclusion

Throwing in some training and workshops is always a good idea when you think on how to manage a design team, and training and education on diversity is no exception. This can include workshops and training sessions for employees, as well as leadership training on how to promote diversity and inclusion within the organization. This can help to foster empathy and understanding among employees, which can lead to better collaboration and more innovative solutions. 

Support employee resource groups

Supporting employee resource groups (ERGs) is another way to build diverse design teams. ERGs provide a supportive environment for underrepresented groups within the organization, including women, people of color, LGBTQ+ employees, and more. ERGs can also help to promote diversity and inclusion within the organization by providing feedback and suggestions on company policies and practices.

Our approach to building diverse design teams 

At Eleken, we strongly believe that diversity and inclusion are crucial to building a successful design team and innovative problem solving. Our team is made up of individuals from different backgrounds, and we value the unique perspectives and experiences that each person brings to the table. 

In contrast to the wide-spread prevalence of men in tech, our design team is predominantly female (to the point our HR jokes we need to have quotas for male designers and not vice versa.) The ratio of women to men is approximately five to one. When asked about that, our lead designer shrugs: "Well, women are simply better." 

We provide UI/UX service to people from around the globe and are always trying to better understand and address the needs of our clients and users, especially those from different cultural backgrounds. As a design agency based in Ukraine, we are aware that our cultural context may differ from the countries our clients come from, but we are committed to aligning ourselves with these values and making sure that our team reflects the diversity of the world we live in. 

Final thoughts 

How diversity makes teams more innovative? Well, it simply broadens the horizons and allows you to answer the questions you would not even pose in the first place otherwise. 

Building diverse design teams is essential for creating fresh and inclusive products and services that meet the needs of different people and communities. By implementing inclusive hiring practices, providing training and education on diversity and inclusion, and supporting employee resource groups, companies can attract and retain diverse talent. 

At Eleken, we are aligned with these values. As we continue to grow and expand our team, we remain committed to promoting diversity, equity, and inclusion in everything we do. If you want to diversify your team and bring our unique perspectives to the tables, don't hesitate to drop us a line!

Don't want to miss anything?

Get weekly updates on the newest design stories, case studies and tips right in your mailbox.

Success!

Your email has been submitted successfully. Check your email for first article we’ve sent you.

Oops! Something went wrong while submitting the form.
Don't want to miss anything?

Get weekly updates on the newest design stories, case studies and tips right in your mailbox.

Success!

Your email has been submitted successfully. Check your email for first article we’ve sent you.

Oops! Something went wrong while submitting the form.