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

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?

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.

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.

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.

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.

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.

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.

2. 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.
3. 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.
4. 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.

2. 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.

3. 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.