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:
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 an Agile 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
Table of Contents
Product Owner Proxy Role
Briefly, a proxy PO 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, a proxy PO 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, proxy product owners 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 adjusted to the individual needs.
[Our proxy PO] 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 business needs.
Head of Digital, Athletic Training Platform (source: Clutch.co)
This booklet will guide you through all the important aspects of collaborating with a software development partner, including work organization, meetings, and everyday communication.
7 signs that you need a Proxy Product Owner
Even though a Product Owner Proxy is not a standard role in scrum teams (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 in my development team”
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 commitments. 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 commitments 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-month-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 have limited operational availability (a.k.a. no 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 tasks off your shoulders 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. Despite your domain knowledge, 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 scrum masters. 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 this person won’t do is define acceptance criteria and success 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.
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 clients. 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 if you don’t know how to explain your vision in a way that will make it clear for the developers, it’s a good idea to use some help from a Product Owner Proxy.
The 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 answer questions from the team promptly, 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 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 to get 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).
Product Owner Proxy – responsibilities in the development process
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!
As a product owner, you write user stories and define priorities. You are still the decision-maker. And it is your job to introduce a PO Proxy to your business domain.
A Proxy Product Owner role 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 commitments 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 proxy product owners are 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.
How much does it cost to have a Proxy PO in a project?
Depending on your needs, you will probably need a proxy PO 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 engineering | Additional costs generated by adding a PO Proxy to the team |
| 25% * 240,000 USD = 60,000 USD | 6000 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 PO 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 team doesn’t face blockers, that they are effective, and that they work towards the stated project’s goals and sprint goals.
The goal of a proxy PO, 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 skills. 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 proxy product owners will physically handle some of your tasks, scrum masters focus on educating you on how to perform them. For instance, when setting up the acceptance criteria, they 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 business vision and strategy),
- business alignment,
- product delivery validation (checking whether the product meets business criteria).
By introducing a proxy PO 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 duties. It is important to remember, though, that a proxy PO can never replace a Product Owner.
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 a PO Proxy to a project doesn’t change that.
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 PO 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 PO—and don’t have a full-time, experienced Product Owner to handle all the PO responsibilities—will it become clear that the visible work 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 25% up to 50% of an estimated project’s cost (source).
Product Owner Proxy – key takeaways
Saying that a proxy PO 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 be 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 PO, your daily schedule is already stretched to its limits, you don’t know how to manage backlog items, or you’re having trouble communicating with your development team, introducing a proxy PO – even for a limited time – will definitely help.
It’s time for you to focus on growing your business while we develop your app.
