Design team

Scrum Master vs Product Owner: Can It Be One Person?


mins to read

Product management is a complex field that involves many roles and positions whose duties seem to overlap. This is especially true when it comes to Agile environment, where the pressure to complete product sprints can blur the lines between who is meant to do what. And when it comes to the Scrum Master vs Product Owner dilemma, some business executives are unable to distinguish the two roles and can’t decide whether they need a Product Owner, a Scrum Master, or both in their team.

So, what exactly is the difference between Scrum Master and Product Owner? 

As a UI/UX design agency for SaaS that has had some luck to work with Scrum teams, in this article, we want to help you understand what tasks both people have to perform during the development process, so that you can decide who to hire.

Understanding the Product Owner's role

To start with, the Product Owner (PO) needs to have a strong product vision. They don’t dive into details of how the product is going to perform, but they have to understand why the product is being built, what problems it’s going to solve, and who’s going to use it.

For this purpose, POs communicate with stakeholders (customers, investors) and transform their needs/challenges into user stories, which are then implemented by the team of developers. Unfortunately, it’s impossible to satisfy all the stakeholders’ needs (otherwise the development team will be overloaded with loads of tasks), therefore user stories form a backlog — the list of features a product should contain.

The PO’s task is to collaborate with developers and stakeholders to prioritize the list of features in the backlog and 

  • estimate the value and size of each user story and define which are worth building and which are not
  • decide which features are critical to build first, and which can be developed later
  • define how long the product backlog should be.

So, product ownership is all about communication. POs should make sure everybody understands the product vision, the development team is in direct contact with the stakeholders, and there’s a short feedback loop in terms of frequent deliveries to real users.

Understanding the Scrum Master’s role

The Scrum Master (SM) bridges the development team and the Product Owner and is primarily in charge of empowering the team to accomplish the sprint goals. Their main objective is to make it easier for the development team to deliver the project’s outcomes timely.

SM heads the development team and ensures that everyone there adheres to the Scrum principles. By doing so these guys make sure that the entire team is familiar with the Scrum guide, methodology, and Scrum events and, as a result, can perform at their highest level.

Besides, SM is responsible for coordinating all the project activities aligned with business objectives and

  • acts as a facilitator for both the Scrum Team and the Product Owner, managing them as a unit and removing obstacles that block sprint progress
  • manages the process of information exchange between the team members
  • facilitates meetings by questioning the team “What was done yesterday?”, “What will be done today?”, “Are there any obstacles in your way?”.

Scrum Masters work to increase team efficiency and recommend changes to the product vision, roadmap, and backlog.

To sum up, a Scrum Master has more of a supervisory role. They play their part by ensuring the Scrum approach is implemented during the product development process.

Product Owner responsibilities

Here are typical responsibilities that a product owner job description may include: 

  • Capture and write user stories, explain product vision and user stories to the team to ensure they understand requirements and customer needs.
  • Create, manage, and priotirize product backlog, so that the development team can clearly understand what they are to build.
  • Approve each feature and continuously communicate with the development and business teams to ensure adherence to product vision and to evaluate risks proactively.
  • Collaborate with a product manager to develop the product vision and product roadmap.
  • Work with the Scrum Master to make sure the product's development aligns with the original goal.
  • Work with team members to ensure requirements, pain points, hidden needs, and expected outcomes are properly documented.
  • Decide on project deadlines and determine the release date.

Scrum Master responsibilities

After analyzing the Scrum master job descriptions on Linkedin and Upwork, we formed the following list of responsibilities for SM:

  • Facilitate adoption of the Scrum framework.
  • Assist the Scrum team in meeting sprint goals and delivering software solutions in an iterative manner. 
  • Support the Product Owner in creation, improvement, and prioritizing of the product backlog.
  • Proactively eliminate barriers, instruct team members on optimal practices.
  • Organize Scrum rituals (daily Scrum, sprint planning, sprint retrospectives) and make sure each team member attend them.
  • Protect the team from any kind of distractions and allow them to stay tuned.
  • Deliver activity and progress updates, mentioning all lingering obstacles and problems that influence team productivity and sprint efficiency.
  • Make sure the project is completed on schedule and within the allocated budget.

Main differences between the Scrum Master and Product Owner

There are three key perspectives you need to keep in mind when working on project: build the right product, build the product right, and build the product fast. But, usually, it’s difficult to find the balance between the three. Therefore, there’s a healthy tension between the Scrum roles:

  • The Product Owner focuses on building the right product.
  • The Development Team focuses on building the product right.
  • The Scrum Master focuses on shortening the feedback loop that accelerates learning, so that the team can quickly discover what the right product is and how to build it right.
scrum master vs product owner scheme

So, let’s sum up key differences between the roles of Scrum Master and Product Owner. 

  • Scrum Master is focused on maximizing the value and potential of the Scrum team and extending eventual return on investment (ROI), while the PO is focused almost exclusively on building the best possible product for the customers.
  • Product Owner forms a link between the Scrum Team and the customers. They are responsible for maximizing the value of the product after analyzing and prioritizing product features using sprint reviews and other similar methods. The role of the SM is more of the supervisor that coaches the team to ensure that everyone is aligned with the Agile process. They host daily stand-up meetings to sync with the development team's progress and note any obstacles that may keep the team from completing tasks.
  • Product Owners are accountable for project completion and providing timely updates to clients, while the Scrum Master is accountable for the entire quality of the project, as well as keeping the team on track towards meeting project’s completion timelines.

Scrum Master salary

According to Glassdoor, the Scrum Master in the United States is a highly-paid professional that earns about $108,571/year, while the average salary in the US is $95,831/year. 

scrum master salary according to Glasdoor

Now, let’s take a look at the average SM salary around the world, according to Glassdoor.

scrum master average salary by countries

Product Owner salary

The average salary of a Product Owner in the United States slightly differs from that of an SM and is around $107,478/year.

product owner salary according to Glasdoor

Still, when we look at the average PO salary around the world we see that the situation here is different: while SMs earn the most in the United States, Product Owners are better paid in Singapore.

product owner average salary by countries

Can PO and SM be one person?

If you asked whether a Product Owner and a Scrum Master can be one person the answer would be “Yes”. If you asked if they should be, the answer would be “No!”

Now, let’s get to a more detailed explanation.

In our practical experience of creating UI/UX design for various SaaS companies of different sizes and structures, we’ve encountered cases where one person performed the role of both PO and SM. Such a situation is most common for small startups at the early stages of product development. It works well for them, as usually their team consists of a CEO (who plays the role of PM/PO/SM), a developer, and a designer, so there’s no sense to build a strict organizational structure.

However, for bigger companies, we don’t think it’s right to hire one employee for two positions, unless it's just temporary while working with developers to "groom" someone into a Scrum Master.

This is because a competent SM will encourage the team to go an extra mile in terms of commitments while also ensuring that they are performing their tasks sustainably. While POs can handle this role, there may occasionally be situations when the Product Owner pushes for the maximum features, leading engineers to develop in an unsustainable and brittle way.

Besides, being a Product Owner is about having a vision and goals. It involves collecting information and, eventually, saying “No” to some ideas. Being a Scrum Master, on the other hand, involves identifying opportunities for growth, interacting with others, figuring out effective teamwork techniques, mentoring the Product Owner and the development team, acting as a good host for Scrum events, and setting an example for the rest of the team.

These two jobs call for quite distinct personalities, skills, and attitudes that are seldom found in one individual. It is against the fundamental nature of the roles to try to be both the PO and the SM at the same time.

Okay, seems like we’ve managed to dispel the confusion between PO and SM. However, these two are not the only roles that may cause you headaches when it comes to structuring a product team. Read our next article to learn about Product Owner vs Product Manager vs Project Manager.

Kateryna Mayka


Table of contents

Top Stories

Design team
min read

Hiring a Design Agency? Learn How to Share UX Design Requirements

In July 1938, a small silver plane made a wide turn over a city and started down to the airport. The pilot landed his plane, stepped out, and exclaimed: “Where am I?” 

It was Corrigan Douglas. He took off from New York, with plans to land in California, but the compass had malfunctioned, he lost his direction in the clouds and accidentally flew over the ocean. Due to a navigation mistake, Douglas “Wrong Way” Corrigan made a transatlantic flight from New York to Dublin.


Aviators will tell you that being off course by just one degree, after flying 60 miles, you'll miss your target by a mile. The further your road goes, the more remarkable your mistake gets. And harder to fix.

Designing a product doesn't happen overnight. Like with long-haul flights, going off course even a little will make a huge impact on the final result.

Initial requirements gathering is a preliminary phase of the design process that is crucial to setting the whole project off in the right direction by focusing on the right problems to solve and, consequently, building the right thing.

No other part of the conceptual work is harder than deciding on requirements. No other part of the work cripples the result so much if done wrong. No other part is as difficult to rectify later.

That's not hyperbole — 39% of failed projects fail due to inaccurate requirements gathering.

Seemingly both designers and clients are interested in getting the requirements right. So how is requirement gathering done and why does this process often go painfully wrong?

UI/UX design document fatal error

What makes UX design documentation difficult (and how to fix it) 

So you have an app to build, and you’re looking for designers to help you with the UI/UX part. If you are lucky enough to have in-house design capabilities, you’ll explain to fellow colleagues what you want them to do and they'll be likely to understand. Those people have been sitting on hundreds of your weekly meetings, they’ve read miles and miles of your company’s Slack conversations. In other words, they understand the context. 

But since you’re reading this article, you haven’t got enough in-house design capabilities. You're going to cooperate with a stranger who is a design and user experience expert but doesn’t know much about your context, your market, and your audience. 

It’s like taking a taxi with a driver who has never been to your city and has no navigator on board. Before taking off, this guy will ask you about your destination and the best route. That's the same kind of thing any designer will ask you when getting to work. 

The input information from clients usually sounds something like this:

“We need to design/redesign this MVP/app/website”

That’s not enough to open Figma and start wireframing. The designer needs to gather more information:

  • To understand precisely what is required of the design. What is the idea of the product, its goals and objectives, its future functionality and competitors, its users and their needs;
  • To decide on some basic schedule and roadmap for the design milestones; 
  • To agree on production control to ensure final prototypes satisfy the requirements.

The problem is that we have some obstacles that get in the way of making all the UI/UX requirements clear. The three C’s formula — Communication, Comprehension, Control — captures all the components capable of throwing any design project into chaos.

Communication: breaking barriers and building bridges

When you tell your designer you’re making a breakthrough decentralized P2P ecosystem, it’s quite the same as switching into the language of birds. What sounds just fine for you with your industry expertise sounds like white noise for a designer.

UX design documentation example (the bad one)

Software is complex, abstract, difficult to visualize and explain. That creates communication barriers you and your designers have to eliminate on the road to fruitful communication.

We at Eleken UX design agency believe that the ability to understand each other is key to a successful project. That’s why we literally built our working process around communication with clients.

  • We don’t ask you to fill a brief — because no UX design specification document can explain customer needs better than a real conversation when you can ask what the heck “decentralized P2P ecosystem” is when you hear such kind of white noise. 
  • We arrange calls with clients, a lot of calls. In some cases, they are even meetings and workshops — all to discuss the product and clarify our next steps.
  • We don’t have project managers in our agency — the person you talk to is the person who designs your app. Cutting out the middleman allows us to make sure the message always reaches the right person, and not in a Chinese whispers way. 

What clients can do, for their part, is being responsive. If the designer has questions, try to answer them fast to optimize their time and your investments. A designer that doesn’t get timely feedback can either wait for your reply, thus being blocked, or continue working on assumptions that might lead the project down the wrong way (ending up somewhere in Dublin).

Comprehension: how to define requirements for a project

Maksym, a UI/UX designer at Eleken, provides a typology of projects based on the level of the customer’s comprehension:

  • Smooth projects, when clients know what they want and how they want it to be done. Designers, in such cases, are not involved in any conceptual decisions, but simply work according to specifications given. Not the most creative stuff, but smooth sailing from day one. The result is usually assured and the customer is satisfied.
  • Successful projects, when clients know what they want, and trust designers to define the best ways for things to be done. Clients’ knowledge and designers’ expertise unite for synergy and success.
  • Fun projects, when clients don’t know what they want but trust designers to help them figure things out. Eleken specializes in designing apps for SaaS startups, so we basically specialize in fun projects.

For sure, it’s an ideal scenario when you come to a designer and clearly know how your app is going to work and look like — it just saves your time. However, our experience shows that clients rarely know what they want (until they see it). Not in the detail necessary for design specification, at least. 

And it’s okay. Bring a vision, then let the agency figure out the details. Experienced designers can help you define requirements for a project. It just means that you’ll go all the way carefully testing the waters, and you’ll participate in communicating on a daily basis for the feedback exchange.

A designer will show you various types of products to understand your preferences. They’ll study all the existing written materials on the topic, and check their findings with you. They’ll do user experience research, and validate it with you. They’ll create user journeys, and show them to you to obtain your feedback. They’ll make wireframes and prototypes, and show them to you many, many times until the result satisfies you. 

Deep comprehension can be replaced by the customer’s trust and active cooperation. 

Control: navigating through the fog of uncertainty

The saying was that two things in life are certain: death and taxes. A design project plan is not on the list. Because the product design process is hard. It’s nuanced. It takes months (and sometimes years) to bear fruit.

Yet precision is what designers often asked for. Clients want to know exactly when the project will be done, how much time each step will take, and what the schedule is.

At the beginning of any project, we don’t know how long this is going to take. We can compare it to our previous experiences, but no two projects are the same. They never have the same requirements, the same people, the same priorities, the same UI/UX design tasks. Each is unique. 

At first glance, we can say whether the UX scope of work is going to be large (6+ months), medium (2-5 months), or small (a couple of weeks). 


As more research and development is done, more information is learned about the project, the uncertainty tends to decrease. After a couple of iterations, we can learn and create something, measure how long that takes, and then give you a much better sense of how big this thing is. 

To make gathering customer requirements in the fog of uncertainty easier, we at Eleken provide you a 3-days trial free of charge. On the expiry of the trial week, you can make an informed decision on whether you want to go on working together, and we can make better estimations on the scope and schedule.

Wrapping up our little guide to UX design process & documentation

Product design for SaaS startups is where outsourcing never works, but collaboration always does. Collaboration is especially important at the initial phase of UX requirements gathering. If you give agency money and then sit around waiting for them to impress you, you’re risking ending up in Dublin instead of California.

But the effort is worth it. After all, we seek to create something that people love and have value from — this is the real magic of being either an entrepreneur or a product designer.

Project success

We’ve been talking about business requirements. If you want to read about how we elicit user requirements, read our piece about the UX research process.

And if you’re ready to discuss your design requirements with us, drop us a line.

Design team
min read

Challenges of a Product Owner Working With External Design Teams

The product owner (PO) plays a central role in the product development process. They establish the vision, keep track of the product backlog, foresee user demands, and are responsible for the success of both the team and the product.

On the other side, product designers are aware of the vision (which POs share with them), represent the interests of the users, and are responsible for the product experience. They must collaborate closely with the product owner in order to succeed in their position.

So, it comes as no surprise that such close cooperation may cause certain challenges of a product owner that works with a designer. And these challenges may seem even more dramatic when it comes to working with an external design team.

Being a team of remote product designers that regularly communicate with POs ourselves, we at Eleken believe we have enough experience to say that most issues are often exaggerated and can be eliminated with the right approach.

In this article, we will list the six biggest challenges of a product owner when working with external designers and give you a clue on how to cope with them.

Challenge 1: Getting new designers up to speed

The first product owner vs UX designer challenge usually comes when you have to introduce new employees to the project. Helping new members feel completely prepared to take on their jobs requires ongoing cooperation and a lot of effort, while onboarding a remote design team takes extra attention.

It is essential to make sure that each employee is aware of the product's mission, company’s values, and culture from the outset. In the end, how you integrate new team members will determine how quickly they catch up.

How we deal with it at Eleken

The effective design onboarding stands on two whales: communication, and information. In other words, to get new external designers up to speed successfully, be prepared to answer a lot of questions and give your designers access to as much information as possible.

  • One-on-one conversation. It’s best to start the onboarding process with a one-on-one conversation. The clearer you can communicate your needs and product vision, the quicker external designers will be able to deliver a suitable final result.
  • Communication with other team members. To better understand the essence of the product, and therefore to be able to create effective designs, it’s vital for the designer to get acquainted with each team member involved in the product development process.
  • Share access to additional materials that will be useful for your designer from the first days of work (for example, access to profiles and team workspaces on different apps, content, images, copy texts, data on user feedback, and the like).

Challenge 2: Lack of trust (from the PO’s side) and lack of responsiveness (from the designers’ side)

We’ve decided to put these two issues under one title as we believe they have the same root and very similar solutions.

It often becomes challenging for a PO to communicate and clarify their thoughts with external teams via virtual interaction. As a result, product owners can experience a lack of trust, poor team communication, misalignment, low engagement, and poor progress.

How we deal with it at Eleken

Our head of design, Maksym, says that “prominent design teams are built on trust and autonomy”. Therefore, he empowers Eleken team members to the point where they are capable of making critical design decisions on their own, without his supervision.

However, as for a PO that hires an external team, there’s no time to educate designers from scratch. How to gain trust and ensure new employees will be fully dedicated to the project? 

We believe that product owners have to consider the matter of trust at the stage of hiring.

  • Carefully examine the portfolio to understand if you like the designers’ style and if they have experience working in your industry.
  • Prepare a list of questions beforehand and conduct a video interview to understand if you feel comfortable communicating with designers, like their manner of speaking, and in general feel the connection.
  • Ask to complete a small test task (design one screen, for example) to make sure you like the design approach of the design team and the outcome. At Eleken, we have a three-day free trial for this purpose to help our clients decide if we’re a perfect match.

Challenge 3: Developers and designers don't understand each other

As the one responsible for the team’s productivity and the quality of the outcome, the product owner is highly interested in effective and smooth designer-developer collaboration.

However, there’s a common misconception that developers and designers are from two different planets - tech and creative - which makes the communication between the two tough and disorganized. 

That’s why product owners may worry that designers will overlook developers’ requirements, engineers will misunderstand the design idea they are about to implement, the whole project will go wrong and the deadlines will be missed. 

How we deal with it at Eleken

  • Engineers won’t be able to technically implement a design. 

In fact, both specialists use analytical thinking and creative problem-solving in their work and are able to communicate well together. So the issue described above may become a reality when designers and developers are placed in two different teams isolated from each other.

Our team always asks developers whether they can code this or that part of the interface once they find their idea might be too sophisticated to implement. Thus, our first tip is to let your designers and developers contact each other freely.

  • Designers will create an overcomplicated design or, vice versa, miss some details.

To avoid such situations, we approve each design with the client’s side. And as one of the product owner's responsibilities is to share the product vision with the team, they often act as a middleman between us and the engineers.

So, you can easily overcome this challenge if you dedicate enough time to communicating with your designers and developers.

  • Developers will get the design idea wrong. 

Final mockups can confuse the viewer as they often look pretty similar. Though, to ensure the development team is able to implement each screen correctly our UI/UX designers create separate pages in Figma for different user flows, label each screen, and add notes with descriptions to ensure the design idea is clear.

organising mockups in Figma

Challenge 4: Misaligned expectations

Delivery that doesn't match your expectations is another PO’s challenge, or we can even say PO’s nightmare.

Unlike in-house employees that know their company’s values and understand the product perfectly well, when hiring external designers you can’t be 100 percent sure about the quality of the outcome. 

So, what if the promises of the external designers are high, but the final result is radically different?

How we deal with it at Eleken

Well, actually, we believe such a problem may only occur if you leave the designer alone for the entire product design process, come at the end to review the job done, and realize everything works completely wrong.

And again, the key to resolving this issue is communication, an integral part of the product owner’s role. At Eleken, we have an iterative design process, where the successful outcome is determined by close cooperation and constant communication. We ask POs to approve our design concepts and design process steps so that they are always aware of the project’s progress. 

If you regularly communicate with designers, review their work, and provide timely feedback, you would be able to point out anything we missed, so that we could provide a better solution. And luckily, there are plenty of tools for effective remote collaboration to make your life easier.

Challenge 5: Time zone mismatch

The modern world shows that a 9-to-5 workday isn’t relevant for most of us anymore and Agile teams can be dispersed throughout the country (or even the globe). This new reality causes product owners to be frequently left working separately from their teams. Additionally, even though most businesses have done a good job of adapting to the remote work environment, POs may still face difficulties due to not being able to get in contact with their team members at any time they need.

Don’t worry, after years of working remotely with clients from San Francisco, London, Montreal, Amsterdam, Singapore, New York, and more Eleken team learned that it’s possible for companies of a different scale to be successful even when their employees are working at different continents. 

How we deal with it at Eleken

First of all, wherever your designers are located, there’s always a time overlap that allows to run a productive team meeting. For instance, our work hours extend from 8 am to 8 pm EEST and we adjust our schedules to our client's time zone to be able to communicate regularly even if our client works from Australia.

Here’re several more practical tips to cope with the time zone difference:

  1. Convert time zones. A world clock on your laptop is the greatest method to stay aware of time zones. If you're using Slack for business communication, you may click on a user's name to view their location and determine the optimal time to get in touch with them.
person's local time in Slack

Additionally, to be aware of the time difference between you and your coworkers, you may use timezone meeting planners or online tools like WorldTimeBuddy, EveryTimeZone, World Clock Meeting Planner.

  1. Set tasks as if it was a relay race rather than a rowing team. In a rowing team, everyone has to be in the same boat at the same time. And in such a case you need everyone’s presence at each meeting. Organizing work processes as a relay race you just need individuals to have some overlap to hand over the work from one team member to the other.
  2. Let your team know when it’s better to contact you. Even while you might feel the need to be accessible to your designers 24/7, doing so is unsustainable and may even be an indication that you are micromanaging them. Establish clear rules for your employees on when they may and may not call you.
  3. Hire those who are ready to take responsibility for their duties. When hiring a new employee, look for people that are not afraid of having a lot of autonomy. Our design lead Maksym always says he trusts each of our designers, that’s why he doesn’t have any troubles managing a remote team.

Challenge 6: Cultural differences

Hiring an external design team means that your new employees may work from any part of the world and have their own communication styles and personal frames of reference. For instance, workers from various nations differently share their ideas: some team members freely speak up all their thoughts and opinions without filtering them, while people from hierarchical cultures prefer to take their time to think before saying a word.

Is it possible to work with people with different work ethics, languages, customs, and cultures in a way that doesn’t create friction or tension?

How we deal with it at Eleken

Similarly to the lack of trust issue (see “Challenge 3”), to avoid a problem of misunderstanding based on cultural differences, you have to carefully analyze the designers you are about to work with: study their portfolio, have an audio call before signing the contract, give a small test task to ensure you both understand each other.

What about the challenges designers face when working with product owners?

At this point, we’ve discussed how product owners should be managing a design team to get the most out of this collaboration and eliminate difficulties. But the term “collaboration” means that there are two sides equally responsible for the successful outcome.

Consequently, some issues that negatively affect the coexistence of a product owner and a design team can be easily excluded when the PO is aware of them.

  1. No clear product vision.

When the product owner doesn’t understand their product’s purpose, or can’t give clear directions about further designers’ tasks, they should be ready to wait until the designer finds answers to all the questions by themselves. It would take additional time to conduct user research, and competitor analysis, develop concepts, present them to you, and iterate on a suitable solution. Overall, it’s not always a problem if you don’t mind waiting and don’t have strict deadlines.

To avoid such situations, find time to understand what you want to create and why before hiring UI/UX designers.

  1. Insufficient involvement in the process.

Unfortunately, designers can’t read minds. If the PO doesn’t invest enough time and effort in communication then they risk blocking their designers’ work processes.

Communicate with the designer regularly, be ready to answer any questions, and provide feedback as fast as possible.

  1. No access to all team members.

Each employee that is somehow connected to the product has something useful to tell the UI/UX designer. If, for example, the designer can't reach out to developers they can’t be sure whether the mockups they create are possible to implement technically. Without the ability to talk to a customer support representative, designers can omit some essential users’ pain points that will later affect the overall user experience.

As a PO, you should give the external designer a possibility to talk with the representatives of all the departments that work on the project.

To sum up, after all the years of working as remote product designers, we can say that it’s not the place that determines your success, but the people you work with. You can be as successful working with external designers as with in-house employees if you manage to find a team you can trust.

Need a reliable SaaS design partner? Extend your team with Eleken.

Don't want to miss anything?

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


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.


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

Oops! Something went wrong while submitting the form.