Picture month three of a project. An external team of five works in two-week sprints and delivers on schedule. The burndown chart looks healthy, the sprint reviews happen on time. At one of them, the VP of Sales, attending for the first time in two months, asks why the discount engine uses last year’s price list and why nobody built the export to the distributor portal: “that was the whole point”. The team pulls up the backlog. The export sat at position twenty because nobody moved it. The vendor’s delivery lead points out that he asked about priorities three times, by email.
Nobody failed here in any obvious way. The developers built what was at the top of the list. The vendor reported progress. The company paid the invoices. And yet for three months the project travelled in a direction that nobody had consciously chosen. That is drift: the team is rowing, but nobody is steering.
This article is for CEOs, founders and heads of product who commission software from an external team, whether a nearshore partner in Central Europe or a vendor in their own country. The argument is simple and, for some readers, uncomfortable: the product owner is the one role in a project that you cannot buy from a vendor. You can buy developers, testers, an analyst, an architect, a project manager, even someone to run the backlog. You cannot buy someone who decides for you what matters more and who accepts finished work in your name. If you do not have a person in the company who will do that, you are better off starting with a smaller team, or waiting, than paying a full team to build in an unknown direction.
What is project drift, and why does it start with an empty seat on the client side?
Drift is the state in which a project gradually moves away from its business goal even though every individual decision looks reasonable. There is no single moment of failure, only a series of small shifts. The team picks the interpretation of a requirement that is simpler to build. The vendor’s analyst fills a gap in the specification as best they can. A feature that one department asked for loudly overtakes a feature that would have earned more, because nobody argued for the second one. After a handful of sprints the sum of those shifts becomes visible, and reversing it is expensive.
Why does this happen more often with an external team than with an in-house one? Because an in-house team has natural access to the company’s context. An employee developer overhears conversations in the kitchen, knows the customers, knows the leadership team has just changed its pricing strategy. A vendor team knows only what somebody has told it. Every decision the client does not make will still be made, just by someone with less information. A team does not stop working when an answer is missing. It does what seems most sensible, or picks up the next ticket from a list nobody has ordered.
Distance makes this worse. If your company sits in Chicago or Toronto and your team works from Warsaw or Kraków, the overlap of working hours is a few hours a day at most. A question raised in the European afternoon gets an answer the next morning in the best case. A product owner who is slow to reply costs a full working day per question, not an hour.
The second cause is economic. A vendor is paid for delivering work, not for the accuracy of product decisions. That is not an accusation, just a description of the model. Under time and materials, a team building the wrong feature sends the same invoice as a team building the right one. Under fixed price, the vendor has an incentive to read scope as narrowly as possible, a dynamic we cover in who really pays for the risk transfer in fixed-price software. In neither model does the vendor have a reason to defend your business result harder than you do.
So drift starts with an empty seat: a role that looks filled in the contract and on the org chart, because someone’s name is next to it, but in practice has neither the time, the authority nor the knowledge to do the job.
What does the Scrum Guide actually say about the product owner, and what does it leave out?
It is worth going back to the source, because a lot of myth has grown around the role. The Scrum Guide, in its November 2020 version by Ken Schwaber and Jeff Sutherland, says the product owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team. They are also accountable for effective product backlog management, which covers four things: developing and explicitly communicating the product goal; creating and clearly communicating product backlog items; ordering those items; and ensuring that the product backlog is transparent, visible and understood.
Three sentences from the same section matter directly when the team is external. First: the product owner may do this work or delegate the responsibility to others, but regardless, the product owner remains accountable. Second: for product owners to succeed, the entire organization must respect their decisions. Third: the product owner is one person, not a committee. They may represent the needs of many stakeholders, and those wanting to change the product backlog can do so by trying to convince the product owner.
These sentences carry more weight than they first appear to. If the work can be delegated but the accountability cannot, a vendor analyst can write user stories, but the decision about whether a story should exist at all, and when, stays with the product owner. If the organisation must respect the product owner’s decisions, then a product owner whose calls can be overturned at any moment by a director from another division is not, in practice, a product owner. If it is one person, then “the steering committee sets priorities” is not a solution but a recipe for decisions that happen once a month.
The guide also gives the product owner specific powers inside the events. In sprint planning, the product owner proposes how the product could increase its value and utility in the current sprint. During the sprint, scope may be clarified and renegotiated with the product owner as more is learned. Only the product owner has the authority to cancel the sprint. At the sprint review, the team presents the results of its work to key stakeholders, and work that does not meet the Definition of Done cannot be released or even presented.
What does the Scrum Guide not say? It gives no number of hours. It does not say the product owner must come from the buying company, because it does not address the client–vendor relationship at all. Nor does it say the product owner must write specifications. That last point matters, because many companies decline to staff the role on the assumption that it means a full-time job writing documents. It does not. It means deciding, explaining and accepting. The writing of detail can be delegated.
One caveat: not every project with an external team runs Scrum. If your team works in Kanban, the role may carry a different name, but the need is identical. Someone has to order the work entering the system and someone has to say when an item is done. We compare the two methods in Kanban vs Scrum: choosing a team workflow by the kind of work. This article uses the term product owner because it is the most recognisable, but the argument concerns the function, not the label.
Which decisions can a vendor not make for the client?
The simplest way to think about it is to split project decisions into three groups. The first is technical: how to build something, which library to use, how to divide the system into modules. The vendor makes these better than the client and should make them, within agreed standards. The second is about how the team is organised: who does what, how code review works, when releases happen. These also belong to the team and its leadership. The third is about value: what we build, in which order, what we do not build, what counts as done. The vendor cannot make these for the client, however good it is.
Why not? For three reasons.
Missing information. Ordering features requires knowledge the vendor does not have and never will: next quarter’s sales targets, which key account is threatening to leave, which regulatory change will hit the process, how much the current manual workaround costs, what the board expects. Some of this is confidential, some of it changes weekly, and some of it exists only in the heads of people the vendor never talks to.
Missing authority. Even if the vendor guesses the right priority, it has no right to impose it on the client’s stakeholders. When the CFO and the VP of Sales want different things in the same sprint, only someone inside their organisation can settle it. The vendor’s project manager can at most gather the arguments and escalate, which means returning to the client with a question the client still has to answer.
Conflict of interest. “We will not build this” is, for a vendor, a decision to earn less or to end the engagement sooner. An honest vendor will suggest it anyway, but you should not build your project on the assumption that every vendor will always defend your budget against its own team.
Concretely, the decisions that must stay with the client are: the product goal and how its achievement is measured; the order of the product backlog; dropping a feature or postponing it; resolving conflicts between stakeholders; accepting an increment as meeting the business need; the business decision to release to production; and any scope change that affects budget or timeline. Everything else can be delegated to a greater or lesser degree.
Why does a vendor-supplied “proxy PO” look like a fix but actually move the risk?
A proxy product owner acts as product owner on behalf of someone who formally holds the role but has no time for it. When the proxy comes from the vendor, the pattern usually looks like this: the client names a person in the contract, the vendor adds an analyst or product consultant to the team, and that person runs the backlog, writes stories, facilitates planning and demos. The client-side person appears every few weeks to approve the direction.
On paper, that is a sensible division. The client saves time, the team gets someone who answers questions quickly, and the backlog is finally in order. The problem is that it treats the symptom, not the cause. The team stops waiting for answers, but the answers now come from someone who does not know all of the company’s constraints and cannot resolve them. A delayed decision becomes a risk of a wrong decision, and the second is more expensive because it surfaces later.
Look at what actually happens. A proxy PO has to make decisions daily, because the team asks daily. When they do not know the answer, they have two options. They can ask the real decision-maker and wait, which brings back the problem they were supposed to solve. Or they can decide on their own best judgment. Then every such decision is a bet that the client will check only at the next review, if they attend, or after go-live, if they do not.
Then there is acceptance. A vendor proxy PO who accepts work from their own team is marking their own homework. Even with the best intentions, that is weak control: the acceptance criteria were written by the same side that meets them, and the only check against the business need happens without the business in the room. The Scrum Guide allows the product owner’s work to be delegated, but not so that a control function passes to the party it is meant to control.
None of this means that a vendor analyst or product consultant is a bad idea. Often it is a very good one. The difference is whether they support the decision-maker or replace them. Support prepares options, collects questions, writes detail, keeps the backlog tidy and comes to the product owner with decisions to make, not decisions already made. Replacement decides alone and informs the client after the fact. The first cuts the product owner’s workload. The second removes the product owner from the project.
| Area | Client-side product owner | Vendor analyst/proxy as support | Vendor proxy as replacement |
|---|---|---|---|
| Product goal | Sets and communicates it | Helps write it down and break it into stages | Infers it from documents, often outdated |
| Backlog order | Decides | Proposes, with reasoning | Decides alone |
| Stories and acceptance criteria | Approves the intent and business criteria | Writes the detail | Writes and approves |
| Answering the team’s questions | Answers business questions within a day or two | Answers detail questions, batches the rest | Answers everything on best judgment |
| Accepting an increment | Accepts or rejects | Checks against criteria before acceptance | Accepts their own team’s work |
| Stakeholder conflicts | Resolves them | Prepares a summary of positions | Escalates or works around them |
| Risk for the client | Delays if the PO is short of time | Low, with a clear split | High, and it surfaces late |
If a vendor offers “we will provide the product owner as well”, ask three direct questions. Who will accept increments? Who will settle a disagreement between two of your executives? Who will decide to drop a feature? If the answer to any of them is “our consultant”, you are being offered a replacement, not support.
How much time does a product owner need to give an external team?
Most companies answer “a few hours a week”, and that is the main reason the seat stays empty. The Scrum Guide gives no number, so the calculation below is an estimate built from the guide’s event timeboxes and the typical activities of the role, not a standard. It does show the order of magnitude you should know before signing a contract.
Assume one team of five developers and a tester working in two-week sprints. The Scrum Guide caps sprint planning at eight hours for a one-month sprint and the sprint review at four hours, noting that for shorter sprints these events are usually shorter. The earlier 2017 edition of the guide said refinement usually consumes no more than 10% of the development team’s capacity; the 2020 edition dropped that figure, but it remains a useful reference point.
| Activity | Estimate per two-week sprint | What drives it |
|---|---|---|
| Sprint planning | 2–4 h | Backlog maturity, number of new topics |
| Sprint review and stakeholder preparation | 2–3 h | Number of stakeholders, need for demos to several departments |
| Backlog refinement with the team | 4–8 h | Scope uncertainty, how well the analyst prepares items |
| Stakeholder conversations, gathering and weighing needs | 6–12 h | Number of departments, internal politics, pace of business change |
| Answering the team’s questions during the sprint | 5–10 h | Whether questions are batched or arrive one by one |
| Accepting increments, acceptance testing | 3–6 h | Feature complexity, need for test data |
| Measuring outcomes and updating the goal | 2–4 h | Data availability, product maturity |
| Total | 24–47 h, roughly 30–60% of a full-time week |
This range is an estimate, not a research finding. You will hit the upper end in the first months of a new product with many stakeholders and fuzzy scope. You will approach the lower end with a mature product and a good analyst preparing the detail. With two teams on the same product, the load does not double, but it does rise noticeably, because both the number of questions and the number of increments to accept go up.
How the hours are spread matters more than how many there are. A product owner who gives the team eight hours on Friday but does not reply to messages from Monday to Thursday is less useful than someone who gives five hours spread across every day. The team needs an answer when the question arises. If it has to wait three days, it either guesses or switches to another task and loses context. The Agile Manifesto, published in 2001, puts it in its fourth principle: business people and developers must work together daily throughout the project. “Daily” is the operative word, and with a transatlantic time difference it means protecting the few overlapping hours for the team.
Now compare that cost with the cost of not deciding. Take an assumed blended rate of €65 an hour for a five-person external team, each working 80 hours per sprint: that is about €26,000 per sprint. If a wrong priority sends even a quarter of one sprint into a feature that has to be reworked or thrown away, that is €6,500 lost, before counting the delay to the things that mattered. Half of a manager’s working week on the client side costs the company less, and above all it is a visible, controlled cost rather than a hidden one.
How can you tell a project is already drifting?
Drift is hard to spot precisely because delivery metrics look fine. Tickets close, sprints end on time, status reports are green. The signals are elsewhere.
Questions wait longer than two days. If the team keeps a list of open questions for the client and the list keeps growing, decisions are not keeping up with the work. Ask the vendor for that list with the date each question was raised. The average age of open questions tells you more than any velocity chart.
The backlog order does not change between sprints. A product under development learns from each increment, so priorities should move. A backlog whose order has not changed in a month usually means nobody is ordering it and the team is simply taking items from the top.
Nobody from the business attends the sprint review. If the demo is watched only by the contact person and the vendor’s project manager, increments are never tested against the users. The team learns about the mismatch at go-live.
Acceptance is postponed to the end of a phase. When increments wait weeks to be accepted and acceptance is planned “in one go before release”, you are back to waterfall with a sign-off at the end, only with a longer backlog of surprises.
The team starts inventing requirements. You hear it in phrases like “we assumed”, “we went with the default”, “we did it the way it works in a similar system”. A single assumption is normal. When it becomes the working method, the team has taken over a role that is not theirs.
Stakeholders bypass the product owner. Executives message developers or the vendor’s project manager directly with “quick” requests. That is a sign the organisation does not respect the product owner’s decisions, which is exactly the condition the Scrum Guide calls necessary.
The product goal is not written down, or nobody remembers it. Ask three team members why they are building this system and how they will know it worked. If you get three different answers, or a feature list instead of a goal, the team has no reference point for its daily choices.
Sprint retrospectives are a good place to surface these signals, provided they end in a decision rather than a wish list. If three retrospectives in a row say “waiting for client answers”, that is not a team problem but a problem in the client’s organisation.
Who in the company should be the product owner, and who should not?
A good client-side product owner combines three things: knowledge of the problem, authority to decide and real time. Missing any one of them is enough to break the role.
Knowledge of the problem means understanding the process the software is meant to change, knowing its users and knowing what the current state costs. It does not mean knowing the technology. It means being able to say whether a feature solves a real problem or only looks like a solution.
Authority to decide means being able to change order and scope without calling a meeting with one’s boss for every change. In practice it helps to write that authority down: up to what impact on budget and timeline the product owner decides alone, and beyond what point they must consult the sponsor. Without that, every disagreement ends in escalation, and escalation takes time.
Real time means that someone in leadership has deliberately taken part of this person’s other work off their plate. Adding the product owner role to a department head’s already full calendar produces a product owner in name only.
These criteria produce predictable good and bad candidates. A good one is usually a manager from the business line that will benefit most: the head of customer service for a customer portal, the logistics manager for a warehouse system, the head of product for software sold to customers. A person hired specifically for the role is also a good choice when the product is strategic and will evolve for years.
The poor candidates are equally predictable. A board member has authority but no time and becomes a bottleneck. Someone from the IT department has time and knows the technology, but often lacks the authority to settle disputes between business units and knows the process second-hand. An assistant or junior specialist has availability but neither knowledge nor authority, and becomes a message relay. A committee of department representatives has knowledge and authority but is not one person, so decisions come slowly and turn into compromises instead of choices.
The analyst is a separate case. The business analyst role sits close to the product owner role and is often confused with it. An analyst discovers needs, models processes and writes requirements. A product owner decides which of those needs the team will meet, and in which order. One person can combine both, but then their time has to account for both. We compare analyst profiles in business analyst or systems analyst: who your project actually needs.
How should work be split between the client’s product owner, the analyst and the vendor team?
Most misunderstandings in projects with an external team come not from missing roles but from blurred boundaries between them. That is why the split is worth writing down before the first sprint, in a single table shown to every stakeholder.
| Activity | Product owner (client) | Analyst (client or vendor) | Vendor team | Vendor leadership |
|---|---|---|---|---|
| Product goal and success measures | Decides | Helps write it down | Knows and applies it | Reports progress against it |
| Backlog order | Decides | Proposes | Flags technical dependencies | Flags budget and timeline impact |
| Story detail | Approves the intent | Writes it | Refines it technically | — |
| Acceptance criteria | Approves | Drafts | Checks feasibility | — |
| Definition of Done | Knows and accepts it | — | Sets and applies it | Keeps it consistent across teams |
| Accepting an increment | Decides | Checks against criteria | Demonstrates | — |
| Change affecting budget | Requests or approves | Describes the impact | Estimates | Prices it and proposes a contract change |
| Team composition and organisation | Informed | — | Self-organises | Decides |
Two columns need a comment. First, the analyst can sit with the client or with the vendor. If with the vendor, this is exactly the support described in the proxy PO section: preparing, not deciding. Second, the Definition of Done belongs to the team and the acceptance criteria to the product owner. They are two different checks. The Definition of Done says the work is technically finished: tested, reviewed, releasable. Acceptance criteria say it solves a specific business problem. More on that distinction in Definition of Done: how one list protects quality better than an extra testing phase and in the glossary entry on acceptance criteria.
The vendor leadership column is deliberately narrow. The vendor’s project or delivery manager is accountable for how the team delivers: composition, continuity, quality, risks, reporting. They are not accountable for what the team delivers in business terms. When those two accountabilities merge into one person on the vendor side, you are back to the replacement problem. The detailed split between the client’s project manager and the vendor’s delivery manager, with a RACI matrix for those roles, is covered in delivery manager vs project manager: who owns what; what matters here is only that neither of them replaces the product owner.
What does acceptance look like when it does not turn into a sign-off at the end?
Acceptance is the moment when the product owner says: what the team built solves the problem we commissioned it for. In iterative projects it should happen at the rhythm of the sprints, continuously, not once before go-live. In practice the opposite is common: increments are shown, but nobody formally accepts them, and the “real sign-off” is scheduled for the end of the phase.
Deferred acceptance has three effects. First, mismatches come to light when there is least time left to fix them. Second, they compound: features built on a wrong assumption become the foundation for the next ones. Third, the sign-off conversation turns into a dispute about what was in scope rather than a conversation about whether the product works.
Continuous acceptance needs a few simple things. Every backlog item has acceptance criteria approved by the product owner before work starts. The team submits an item for acceptance once it meets the Definition of Done. The product owner accepts or rejects it within an agreed time, for example two working days, and a rejection gives a specific reason tied to the criteria. An item rejected because the business changed its mind about the need does not come back as a team defect but as a new backlog item. That last rule is fair to the vendor and protects the relationship.
User acceptance testing is worth planning as part of this flow, not as a separate phase. The product owner does not have to test everything personally, but they must name the users who will check an increment in a realistic scenario, and secure their time. Practical guidance is in our user acceptance testing guide.
What should the contract with the vendor say about the product owner role?
Software development contracts usually describe the vendor’s obligations in detail and the client’s in very general terms. Yet in an iterative project, the outcome depends on both sides. Writing the product owner role into the contract is not bureaucracy. It is a way for both parties to see how much the role demands before the project starts.
Six things are worth writing down.
Who the product owner is and who stands in. A name, the scope of their authority and a named deputy for holidays and sick leave. A missing deputy is the most common reason for sprints without decisions in the summer, or over the end-of-year holidays.
Committed availability. Hours per sprint and the maximum response time to the team’s questions, stated in the time zone the team works in. The point is not to penalise the client for delays but to give both sides a shared reference.
Consequences of a missing decision. What happens when a question waits longer than agreed: the team moves to the next item, and the blocked item is reported as blocked on the client side. Under fixed price, a missed decision deadline should move the schedule; under time and materials, it should show up in reporting as waiting cost.
The acceptance procedure. Who accepts increments, within what time, what silence past the deadline means and what a rejection must contain.
The role of the vendor’s analyst or consultant. If the vendor provides product support, the contract should state explicitly that they prepare decisions but do not make them, and do not accept work on the client’s behalf.
The right to pause. The client should be able to pause or shrink the team if it cannot provide decisions. This protects the client, not the vendor: slowing down deliberately beats paying for work without direction. When choosing a partner for a new product, ask about these clauses at the proposal stage; we cover them in choosing an MVP development partner: selection criteria and contract terms.
A vendor that resists these clauses is signalling that it would rather not have a clear split of accountability. A vendor that raises them unprompted understands that without a decision-maker on the client side its team will perform worse, and that it will carry part of the reputational cost.
What if nobody in the company has the time?
This is the most common situation and the point where the argument of this article matters most. The company needs a system, has the budget for a team, but has nobody it can free up for half of their week. The reflex answer is: the vendor will handle it. This article argues that this is the worst of the available options. There are better ones.
Size the team to your decision capacity. The number of decisions a team needs grows with its size. If the available decision-maker has twelve hours per sprint, they can steer a two-person team but not a six-person one. A smaller team building the right things will deliver more value than a larger one building in drift. It looks slower, but compare the pace of delivered value, not the pace of closed tickets.
Run discovery first, then decide on the team. A short discovery phase lets you write down the product goal, split the scope into stages and establish what decisions each stage will require. At ARDURA, software development projects start with a discovery phase of one to two weeks to define scope and architecture, and the teams then work in two-week sprints. After discovery it is much easier to judge whether someone in the company can carry the role and how much time they will need.
Free someone from part of their job. The best product owner candidate is almost always busy, because they are good at what they do. A leadership decision to hand part of their work to someone else for the duration of the project is cheaper than a project without direction. That decision belongs to the project sponsor, not the vendor.
Hire a product owner. If the product is strategic and will evolve for years, a person hired for the role pays back quickly. What matters is that they are the client’s employee, or at least act exclusively on the client’s behalf, with authority from the client’s leadership.
Strengthen the decision-maker with an analyst, but do not replace them. An analyst on either side can take most of the preparatory work off the product owner: writing stories, batching questions, preparing data for decisions. With a good split, the product owner’s time moves towards the lower end of the estimate. It does not fall to zero.
What not to do? Do not start a full team on the assumption that the decision-maker will “find the time later”. The first sprints set the architecture and foundations on which everything else is built. That is when decisions matter most and cost most to change.
What are the key takeaways?
An external team can build almost anything, but it cannot want things on your behalf. Every value decision the client does not make will still be made, just by someone with less information, less authority and different interests. Hence drift, which does not look like failure until you see the sum of the small shifts.
Remember six things. First, the product owner is one person on the client side whose decisions the whole organisation respects; a committee or a contact person without authority cannot replace them. Second, the vendor can take over the preparatory work but not decisions on priorities, dropping features and acceptance. Third, a vendor proxy PO makes sense only as support that brings decisions to be made, not decisions already made. Fourth, count the real time: for one team in two-week sprints, an estimated 30 to 60% of a working week, spread across every day and protected inside the time-zone overlap, not piled up on Friday. Fifth, write the role into the contract: the person, the deputy, the availability, the acceptance procedure and the consequences of a missing decision. Sixth, if nobody in the company has the time, shrink the team or start with discovery instead of paying a full team for work without direction.
If you are planning a project with an external team and want the split of roles settled before the first sprint, see how we approach custom software development, or book a call. Discovery takes one to two weeks and ends with a scope, an architecture and a clear picture of the decisions the project will need from your side.