You Can Outsource the Code. You Cannot Outsource the Product Decisions

Put the same development team on two projects of similar size and you can get two very different outcomes. On one, the product ships roughly on time and does what the business needs. On the other, the scope drifts, screens are rebuilt three times, and launch keeps moving. Engineers on both projects are equally good. What differs is usually on the client side: on the first project someone makes product decisions quickly and sticks to them; on the second, nobody does, so the vendor guesses.

My position is unpopular with some buyers: you can outsource the code, but you cannot outsource the product decisions, and projects that try usually fail regardless of the vendor's quality. A good vendor builds, advises and challenges. But priorities, trade-offs, business rules and acceptance belong to whoever owns the business outcome. That is the product owner role, and outsourced development cannot do without it: if the buyer does not fill it, it remains empty, because a vendor cannot legitimately fill it for them.

The decisions that cannot be delegated

Some decisions belong to the buyer because only the buyer has the context, the authority or the accountability to make them.

What problem, for whom, and what success looks like. The vendor can help sharpen the goal, but it cannot decide what your business is trying to achieve or which customers matter most.

Priorities and what to cut. Every project runs out of time or money before it runs out of ideas. Deciding which features ship first and which are dropped is a business judgement about value, and it is the decision most often left to drift.

Trade-offs between scope, date and cost. When an estimate changes, someone must choose: cut scope, move the date or increase the budget. A vendor can lay out the options; only the buyer can choose between them.

Business rules and policy. Who can see which records, what happens when a payment fails, how refunds work, what a "verified" user means. These look like technical questions and are actually policy. A developer who answers them is setting your business policy by default.

Acceptance. Whether the work is done and good enough to launch is the buyer's call. That is what user acceptance testing exists for; our guide to UAT for software buyers explains how to do it properly.

Go or no-go. Launch timing, risk tolerance and what is acceptable on day one are business decisions with business consequences.

What a vendor can legitimately decide

This is not an argument that buyers should micromanage engineering. Vendors should own the decisions that require their expertise and where they bear the professional responsibility: architecture, technology choices within agreed constraints, implementation design, code structure, testing strategy, estimates and engineering process.

There is a middle ground where the vendor should strongly advise and the buyer decides: anything with long-term cost or risk, such as hosting, third-party dependencies, security level, or a feature that would be expensive to change later. Here the vendor's job is to make the trade-off visible and to push back when the buyer is about to make an expensive mistake. Our article on what a good technical partner should challenge before development begins covers that duty, and a related article on when an engineer should say no to a feature request covers how to do it well. A partner who challenges you is doing their job. A partner who decides for you is doing yours, without your context or accountability.

How decision vacuums show up

When nobody on the buyer side owns product decisions, the symptoms are predictable, and they are often blamed on the vendor.

Endless revisions. Screens are built, reviewed by several stakeholders with conflicting views, and rebuilt. Nobody has the authority to say "this is the version".

Scope drift. Without a single owner of priorities, every stakeholder's request is treated as equally urgent, and the backlog grows faster than the team can deliver. We looked at the cost of this in change requests and scope creep.

Blocked work. The team asks a question about a business rule and waits a week for an answer. Developers either sit idle or guess, and guesses become rework.

Late surprises. Acceptance testing happens at the end, involves people who were not consulted during the build, and reveals that the product does not match what they expected.

The vendor becomes the product owner by default. The team, wanting to make progress, fills the gaps with its own assumptions. Some of those assumptions are good. Many are not, because the vendor does not know the business, and when they turn out wrong the buyer reasonably feels the vendor got it wrong.

Many of the patterns in our article on why custom software projects fail, especially requirements that were never really requirements, begin as decision vacuums.

The product owner every outsourced development project needs

The fix is a named person on the buyer's side who owns product decisions. Agile methods are explicit about this. The Scrum Guide states that "the Product Owner is one person, not a committee", that they are accountable for maximising the value of the product, and that "for Product Owners to succeed, the entire organization must respect their decisions." The UK government's service manual lists the product manager's responsibilities as including prioritising user stories for each sprint and signing them off when they are done. And one of the principles behind the Agile Manifesto reads: "Business people and developers must work together daily throughout the project."

In practice the minimum product owner needs:

• Authority. They can make decisions without escalating every one. If every choice needs the board, the board is the product owner, and it will be slow.
• Domain knowledge. They understand the business, the users and the rules well enough to answer most questions on the spot.
• Availability. They answer questions within a day and attend the regular review. How much time this takes depends on the project; as a rough illustration, a small build might need a few hours a week, and a larger one closer to half of someone's working week. Treat these as starting assumptions to check against your project, not as benchmarks.
• The willingness to say no to colleagues, including senior ones, whose requests do not fit the priorities.
• Continuity. The same person for the life of the project, or a deliberate handover.

They do not need to be technical. They need to be decisive and present. If you are a non-technical founder taking on this role, our piece on managing developers with a weekly routine gives a practical structure.

When to hire or appoint one

If you are a founder with the time and authority, the role is yours. If you are not available enough, there are three realistic options.

Appoint someone internally and give them real authority, not just responsibility. An operations manager or department head who knows the business is often a better product owner than a senior executive with no time.

Hire a product manager or a fractional product owner who works on your side of the table. They should report to you, not to the vendor.

Use the vendor's business analyst or project manager for support, not ownership. They can run workshops, write user stories and keep the backlog in order, which is genuinely useful. But they work for the vendor, and a vendor-side person cannot be accountable for your priorities without a conflict of interest. They can prepare decisions; they should not make them.

The strongest objections

"I am paying experts precisely so I don't have to make these decisions." It is a fair expectation that a vendor brings product expertise as well as engineering. Good vendors do: they propose, recommend and draw on what they have seen work elsewhere. But a recommendation is not a decision. The vendor does not carry the commercial consequences, does not know your customers as you do and cannot settle disagreements between your own stakeholders. You can delegate the preparation of decisions; you cannot delegate the decisions themselves without also delegating control of your business.

"This blames buyers for bad vendors." It does not. Vendors fail too, through poor engineering, weak estimates and bad communication, and some projects fail no matter how good the client is. My claim is narrower: that an empty product-owner seat is sufficient to sink a project even with an excellent vendor, and that it is one of the few causes entirely within the buyer's control.

What good vendors do to protect the buyer

A vendor cannot fill the product owner role, but it can make that role easier and make gaps visible early:

• Ask for a named product owner in the proposal and treat its absence as a project risk.
• Keep a decision log: what was decided, by whom and when, so decisions are not reopened silently.
• Present options with trade-offs rather than open questions, so decisions are quick.
• Set default decisions with deadlines: "if we do not hear back by Thursday, we will proceed with option A." This keeps work moving while leaving the decision with the buyer.
• Demo working software regularly, so feedback arrives early rather than at acceptance.
• Agree acceptance criteria before building, not after.

This is how we approach custom software development engagements, and these practices are worth asking any vendor about.

The rule for buyers is short. Before you sign, name your product owner, confirm they have the authority and the time, and tell the vendor who they are. If you cannot name that person, delay the project until you can. It is cheaper than paying a good team to guess.

References

• The Scrum Guide (2020)
• Principles behind the Agile Manifesto
• GOV.UK Service Manual — What each role does in a service team