When you start working on your digital product, building the right team is one of the first challenges you face. Due to its popularity, it is very likely that you will follow the Scrum framework or other agile framework/guidelines (we love scrum, but it doesn’t mean that everyone has to, right?). In that scenario, you will need people to fulfill three basic roles:

an infographic presenting 3 roles in a scrum team: product owner, scrum master, development team
  • a product owner who will make sure that the team builds the right product,
  • developers who will make sure to build it in the proper manner,
  • a scrum master who will make sure that it is built efficiently and in accordance with the Scrum process.

It all sounds great… until it does. The problem starts when you don’t have enough time to be a full-time Product Owner or you don’t have relevant knowledge and experience to handle this role.

And that’s when the Product Owner Proxy steps in. 

This role is not a part of a Scrum team, but it often helps manage projects efficiently and reduces the final cost of the development. Wondering if it’s a good option for you? Let’s see!

Read more:  Hybrid agile methodologies

In the following article, we will answer the following questions:

Product Owner Proxy role

Briefly, a Proxy Product Owner is a person who helps the actual Product Owner manage the backlog – an ordered list of everything that is known to be needed in the product. 

The role of a Product Owner Proxy is to support the Product Owner in defining, documenting, and maintaining requirements in the development process.

Product Owner Proxy gathers the requirements and priorities from the Product Owner, forges them into epics (large pieces of work that can be broken down into a number of smaller stories), writes user stories, builds the product backlog and the project roadmap. During the development process, a Proxy Product Owner is up to date with what’s going on in the project, monitors progress, stays in touch with the tech team and with the Product Owner.

Additionally, Product Owner Proxy can facilitate the communication between the Product Owner and the stakeholders, serve as a business advisor, create a demo scenario or even run a demo in front of the stakeholders. Therefore, the final list of responsibilities is rather flexible and is adjusted to the individual needs.

[Our Proxy Product Owner] is both an advocate for business needs, as well as for the team and their capabilities. It’s been incredibly helpful. The people who do the development work can keep as focused as possible on what they need to do, while I can keep informed and be flexible with the day-to-day needs of the business.

Head of Digital, Athletic Training Platform (source: Clutch.co)
Learn more about how we work on software development projects

This booklet will guide you through all the important aspects of collaborating with a software development partner, including work organization, meetings, and everyday communication.

Download the Cooperation Manual

7 signs that you need a Proxy Product Owner

Even though a Product Owner Proxy is not a standard role in a scrum team (or agile teams in general), there are situations when this role is extremely useful. At Neoteric, it is an optional role that may come as a part of any web application development services, but in practice, not all projects require having this role. So let’s see if your project does!

Do any of those sound familiar to you?

When you start a new project:

1. “I don’t have a full-time Product Owner”

This is definitely one of the most common issues. According to Project Management Institute, only 49% of organizations have the resources in place to do requirements management properly. And let’s face it: being a Product Owner is not a part-time job. You won’t squeeze it between your regular tasks.

If you are a CEO or a CTO, you already have a lot of responsibilities. Balancing between two roles won’t do any good to any of them – you will always need to compromise on something, which translates into a literal loss.

But Product Owners have a variety of responsibilities throughout the development of every feature, interacting with internal and external stakeholders, Scrum Teams, subject-matter-experts in the domain, as well as customer representatives and the customers. They are on the hook for the successful development and launch of the product line. The responsibility is sometimes overwhelming. Trying to do it part-time would be setting yourself up for failure.

On average, inefficient requirements management leads to exceeding the budget by 30%. For a 6-months-long project with a small team of 3 software engineers and a scrum master, it’s almost 60K USD!

2. “My schedule as a Product Owner is already full”

This scenario is very similar to the one presented above. You have the skills, you have the knowledge, you have the experience, but you don’t have enough time to handle another project.

It can happen either when you have many products in your portfolio or when your product is very complex and consists of several projects to be managed. In that case, the additional support of someone who can take some of your responsibilities off your shoulder will simply release some of your time and help you focus on your other tasks.

3. “I don’t know how to build and manage the backlog”

In this scenario, you may have enough time to be a Product Owner, but… you’ve never been one. It may be the first time you’re going through the process of building a digital product, and the first time you are using digital product design services. As you don’t have experience in requirements engineering and you don’t know much about effective product backlog management, you may need some guidance – someone to help you handle this job at the beginning, teach you how to do it on your own, and slowly step out as you become more and more independent.

To make it clear: it’s not about the guidance that you would typically get from a Scrum Master. It’s more about having someone to support you in your daily tasks, especially at the beginning of the project. Yes, a Scrum Master can (and will) educate you in backlog management, giving you relevant guidelines and examples. What a Scrum Master won’t do is write acceptance criteria for you, put requirements to Jira (or other project management tool), or create a roadmap. That’s where a Proxy Product Owner steps in, literally taking over some of your tasks and doing them for you.

things can get messy when you are a product owner who doesn't know how to manage the backlog

When the development is already in progress

4. “They don’t understand what I mean!”

So you have this small feature to add, let’s say you want to have discounts for your most loyal customers. You tell that to your team, and after the sprint, you receive something completely different from what you imagined.

It turns out that the discount can be applied whenever the users want to do it (while you wanted it to be possible only during the first checkout), they can use one discount code many times, you can’t choose the products that are eligible for the discount, and you are not even able to track the usage of each discount and measure the effectiveness of your marketing campaigns!

If misunderstandings like this happen in your project, if you feel that your team does not understand what you want to have in your app, or that you don’t know how to explain your vision in a way that’ll make it clear for the developers, it’s a good idea to use some help from a Product Owner Proxy.

A simple functionality of adding a discount code consists of different features. Some of them are not even visible to the end-user. If you have never built a digital product, you may not even think of them, and you don’t include them in your requirements. In the worst-case scenario, when your requirements are not clear to the developers, and you don’t have time to promptly answer questions from the team, they will take some assumptions and build the product according to these assumptions. In that case, you will most likely end up with something different from what you wanted, wasting the whole 2-weeks-long sprint. Assuming that we’re talking about a standard project involving three developers and a scrum master, we’re talking about 15-20K USD spent on something that you won’t even use – only because the requirements are not described in the right way.

5. “I don’t understand why it takes so long to do it!”

Let’s stick to the previous example: you want to have discounts for your most loyal customers. How long should it take to make it possible? It’s a small thing, right? Many apps have it. It can’t be complicated. Yet, you hear that it will take almost two weeks to build it. How is that possible?

As you already know, a simple functionality like that consists of several features, and each of them requires to be designed and developed. Unless someone helps you split this functionality into smaller features, you may not be aware of the amount of work required to deliver these tasks. In this scenario, PO Proxy does not only help you understand the complexity of certain functionalities but also see the impact it may have on the whole project, regarding deadlines and budget. 

6. “I’m exceeding my budget”

According to the research presented at PMI® Global Congress 2014, 51% of project dollars are wasted due to poor requirements management. Moreover, the same reason leads to 47% of unmet project goals.

If you feel that your project is not managed in the right manner, your team suggests you limit the scope of your project over and over again as it’s getting harder to stick to the initial estimates, and yet you need to spend more than you planned, it’s a clear signal it’s the right time for the PO Proxy to step in. And you probably don’t want to wait with getting one – a study published in the Harvard Business Review, which analyzed 1,471 IT projects, found that the average overrun was 27%, but one in six projects had a cost overrun of 200% on average and a schedule overrun of almost 70%.

7. “I’m not sure about the progress”

So the team is doing their job, they deliver some items, some features, you get regular updates, have demos, but… you’re not really sure where you are in terms of the total scope and budget.

It may happen – and it often does – that despite delivering every sprint on time, you will find out that you need more budget than initially estimated. That’s due to requirements changes (e.g., when you act on early feedback from your users) and other factors. Especially at the beginning of the project, the actual budget spending is often different from the ballpark estimates.

If this is the case in your project, a Product Owner Proxy can help you compare the project roadmap with the actual progress, translate the developers’ estimates to the actual budget spending, understand the difference between these two, and put that information in context (number of sprints, project timeline). 

A product owner proxy help developers avoid blockers when a product owner is away

Product Owner Proxy – responsibilities

Does any of the statements listed above sound familiar? If so, read further. In this chapter, you will learn about Product Owner Proxy responsibilities and how this role contributes to a project.

First and foremost: Product Owner Proxy is not a Product Owner!

It’s still your responsibility, as a Product Owner, to define the Stories and set priorities. You are still the decision-maker. And it is your job to introduce a PO Proxy to your business domain.

The role of a Product Owner Proxy is to:

  • help you manage product backlog;
  • support you in the requirements engineering;
  • make sure that the requirements are transparent and clear to the team;
  • build a project roadmap;
  • facilitate the communication between the team and a Product Owner (e.g., when the PO is not available due to other responsibilities or such trivial things as time zone differences);
  • make sure that the whole team is on the same page (which will help them avoid misunderstandings in the future);
  • make sure that you don’t waste time developing the wrong features or functionalities;
  • keep the priorities in line.

Now, you know what a Proxy Product Owner is needed for. What’s the direct output of this work for you as a Product Owner? Easier decision-making, better control of the project timeline, and not wasting time on developing the wrong features or functionalities. Let’s assume that we’re talking about a standard 2-weeks-long sprint involving three developers and a scrum master. In this case, we’re talking about (not) wasting 15-20K USD.

Read also: How adding a PO Proxy to the project has helped a US-based startup develop an AI-powered MVP to empower supply chain risk managers

redhead woman handling responsibilities of a product owner proxy

How much does it cost to have a Product Owner Proxy in a project?

Depending on your needs, you will probably need a Proxy Product Owner only as a part-time role (after all, it’s a support, not a real Product Owner), which will generate an additional cost of:

  • 3000 USD/month for a quarter-time PO Proxy
  • 6000 USD/month for a half-time PO Proxy.

Remember, though, that the average budget overrun caused by inefficient requirements management can reach from 25% up to 50% of an estimated project’s cost (source). In the most optimistic scenario, it means spending an additional sum of approximately 60,000 USD for a typical 6-months-long project involving three software engineers and a scrum master. 

Additional project costs caused by inefficient requirements engineeringAdditional project costs generated by adding a PO Proxy to the team
25% * 240,000 USD = 60,000 USD6000 USD * 2 months + 3000 USD * 4 months = 24,000 USD

“Do I really need a Product Owner Proxy?”

If any of the statements listed above sounds familiar, then YES, you should consider adding a Proxy Product Owner to your team. And no, this role cannot be replaced with other roles. Neither by a scrum master nor by anyone from the development team.

Product Owner Proxy vs. Scrum Master

The goal of an SM is to ensure that the development team doesn’t face blockers, that they are effective, and that they work towards the stated product goal and sprint goals.

The goal of a Product Owner Proxy, on the other hand, is to support a Product Owner in managing the backlog, requirements engineering, and communication with the team.

As you can see, they have different responsibilities that require different knowledge and different skillset. One is responsible for the product vision (making sure that the team builds the right product), while the other is responsible for the development process itself (making sure that it is built efficiently). 

To make it clear: it doesn’t mean that a Scrum Master won’t support a Product Owner. But while a Proxy Product Owner will physically handle some of your tasks, a Scrum Master will focus on educating you on how to perform them. For instance, when setting up the acceptance criteria, a Scrum Master will give you an example of how to do it right. A PO Proxy, on the other hand, will discuss them with you and then write them down, so you don’t have to.

Product Owner Proxy vs. Product Owner

“Ok. So if there is a Proxy Product Owner… do I still need to have a Product Owner?” Yes, you do. Simply put, you can’t add a “proxy” to a role that doesn’t exist. The role of a Proxy PO is to support a Product Owner in managing the backlog, requirements engineering, and communication with the team. There are some key business responsibilities that cannot be delegated to a PO Proxy. These include:

  • a product vision,
  • a product strategy,
  • product decisions (meaning how the product should align with the vision and strategy),
  • business alignment,
  • product delivery validation (checking whether the product meets business criteria).

By introducing a Product Owner Proxy to your product, you will not need to hire a full-time Product Owner. With the relevant support, you should be able to handle that role by yourself without compromising on your other responsibilities. It is important to remember, though, that a Product Owner Proxy can never replace a Product Owner.

a product owner sitting by the computer

The Dangers of introducing a Product Owner Proxy

For sure, we shouldn’t treat a Product Owner Proxy as a pixie-dust that can solve all the project problems. Since you already know the potential benefits that this role can bring to your project, let’s now take a look at some common fears and misconceptions.

Playing Chinese whispers

We always say that communication is the key. So why put a proxy between the Product Owner and the team? Shouldn’t they communicate directly? Actually… they should. And adding PO Proxy to a project doesn’t change it.

A Proxy PO does NOT eliminate the communication between a Product Owner and developers. If we’re talking about a true tech partnership (and we do), the communication should always be direct. What a PO Proxy eliminates is the possible friction caused by time zone differences or a PO being unavailable due to other responsibilities. In that case, whenever developers have a question related to requirements, they can go to PO Proxy. That way, we eliminate blockers that could otherwise cause project delays.

To sum it up: if you’re afraid that adding a Proxy Product Owner to a project may negatively impact the communication in a project, don’t be. Our experience shows that it’s exactly the opposite.

Trust issues

By stepping away from some part of the process, the Product Owner may not be aware of all the work that is being done by the Product Owner Proxy. It may lead to the idea that a Proxy PO does not bring enough value.

Only when we resign from the support of a Proxy Product Owner – and don’t have a full-time, experienced Product Owner to handle all the PO responsibilities – will it become clear that the work that was visible was just a peak of an iceberg. And that’s quite an expensive lesson, considering that the average budget overrun caused by inefficient requirements management can reach from 25% up to 50% of an estimated project’s cost (source).

Product Owner Proxy – key takeaways

Saying that a Proxy Product Owner is needed for all Agile projects is a considerable exaggeration. Let’s put it clearly: Product Owner Proxy role is not even a standard in Agile projects. This role may come useful in certain scenarios that we have already discussed, but it doesn’t mean that it’s necessary to introduce this role to all projects.

But if you don’t have a full-time Product Owner, your daily schedule is already stretched to its limits, you don’t know how to manage the backlog, or you’re having trouble communicating with your development team, introducing a Product Owner Proxy – even for a limited time – will definitely help.

Tell us more about your challenges

It’s time for you to focus on growing your business while we develop your app.

Let's talk