Technical Product Owner / Delivery Manager

Role Description

The person who keeps a five-month pilot on their schedule when the schedule does not belong to them. The platform this role governs is assembled from three third parties, and the critical path runs through other organisations’ approval calendars — a plugin agreement, an information-security questionnaire, a vulnerability scan, a penetration test, and white-label terms. None of those move faster because the engineering is going well.

That is the shape of the job. Engineering risk on this build is comparatively well understood. Dependency risk is not. The most likely way the pilot misses its window is that a partner approval, nobody owned by name, sat unanswered for three weeks. This role makes every external dependency dated, owned, and visible, and escalates it while there is still time for the escalation to matter.

The second half of the role is acceptance. Phase 1 ends with the client accepting production readiness, and this person defines what that means in advance — what is in scope for the pilot, what is deliberately pilot-grade, and what a release demonstration has to show. On a time-and-materials engagement, an unwritten acceptance bar is how a pilot becomes indefinite.

This is a half-time role for its full duration, which is the constraint that shapes everything else. There is no capacity here for a heavy process layer. The person has to know which ceremonies earn their place, run those well, and leave the rest.

About the Project

Client: a UK audience-first programmatic media-activation partner that plans and runs advertising campaigns for brands and agencies on a managed-service basis, engaged through a delivery partner. Phase 1 is a controlled pilot with a small advertiser cohort, operated internally rather than sold as a product.

Product: a Connected TV Measurement Platform that comprises proven third-party engines behind one client-owned layer:

• An affiliate network is the distribution spine and the source of advertiser conversions, captured through a client-branded tag plugin.
• CTV buying platforms (DSPs) supply campaign exposure data.
• A specialist measurement partner performs the household exposure-to-conversion match.

The client owns the layer between them: partner integration and advertiser provisioning, conversion capture, measurement orchestration, reconciliation, and reporting. Delivery is a small team:

• Solution architect who also leads the backend build,
• Frontend engineer,
• SDET,
• DevOps engineer,

Reporting to a weekly delivery review that this role owns.

Delivery shape: four milestones — validation and foundation, platform foundation, an end-to-end measurement pilot, and hardening and launch. Each is gated by a partner dependency rather than by engineering completion, which is why dependency tracking is the primary instrument here rather than velocity.

Scope boundary: Phase 1 is conversion-only, operator-facing, and pilot-grade. Advertiser-facing access, commercial packaging, and productisation are explicitly later-phase decisions. Part of this role is holding that line while capturing what the pilot learns for whoever picks up Phase 2.

Key Responsibilities

Dependency and risk governance (the primary instrument)

• Maintain the partner onboarding critical path as a dated plan with a named owner per item — plugin agreement, integration fee, information-security questionnaire, vulnerability scan, penetration test, exposure-data access, and white-label terms.
• Track partner approvals as delivery blockers with explicit lead times, and escalate early enough that the escalation can still change the outcome.
• Keep a live risk position that distinguishes what the team controls from what it does not, and state the mitigation for each rather than logging the concern.
• Sequence work so the team is never idle waiting on a third party by keeping unblocked workstreams ready to pull forward.

Backlog and delivery planning

• Own the backlog and translate the milestone deliverables into work the team can actually schedule against a half-time governance load.
• Run the weekly delivery review: progress against milestones, dependency status, decisions needed, and what changed since last week.
• Protect the pilot scope from expansion, and make the cost of an accepted change visible in schedule terms before it is agreed rather than after.
• Keep the plan honest about the difference between a milestone being engineering-complete and being partner-validated.

Scope, acceptance, and client coordination

• Define the acceptance criteria for each milestone in advance, including what is deliberately pilot-grade and will not be hardened in Phase 1.
• Coordinate scope, acceptance, and release demonstrations with the client, and run those demonstrations against pre-agreed criteria.
• Act as the single point of coordination between the client’s commercial stakeholders and the delivery team, so that partner conversations and engineering priorities stay in step.
• Capture the decisions, open questions, and learning that the pilot generates in a form Phase 2 can use.

Required Qualifications

Experience

• 6+ years owning delivery of technical products, including at least one engagement whose critical path ran through third-party partners rather than through the team’s own backlog.
• Has run a fixed-window pilot or proof of concept to a defined acceptance bar, and can describe what was deliberately left rough and how that was agreed with the client.
• Has governed a small senior delivery team part-time, without imposing process weight the team could not absorb.
• Has managed a client relationship on time-and-materials, where scope discipline is a service to the client rather than a defence against them.
• English: strong written and spoken, C1+ effectively. The role writes the acceptance criteria, chairs the delivery review, and carries dependency escalations to commercial stakeholders.

Technical Acumen

Technical enough to be a participant rather than a passenger. Not expected to write code or design the pipeline.

• Can read an integration specification and an event schema, and tell whether a partner’s answer actually resolves the question that was asked.
• Understands enough of event pipelines, ingestion, and reconciliation to challenge an estimate and to recognise when a dependency is being described as smaller than it is.
• Can write acceptance criteria for data correctness, not only for features, but also for what evidence proves a measurement flow works end to end.

Judgement & Soft Capabilities

• • Chases a named owner and a date rather than circulating a general concern, and does it the first week the item appears rather than the week it becomes critical.
  • Distinguishes a blocker from a delay and escalates the first while absorbing the second.
  • Says no to scope on behalf of the client’s own timeline, and can explain the trade in schedule terms rather than in process terms.
  • Runs light. Chooses the two or three ceremonies that earn their place at half-time load, and drops the rest without apologising for it.
  • Keeps commercial stakeholders and engineers in one conversation, translating in both directions without diluting either.
  • Writes things down. On an engagement with this many external parties, the undocumented decision is the one that gets relitigated in month four.

Domain Knowledge — required

Domain knowledge gates this role, but not the engagement-specific kind. This person chairs conversations between an affiliate network, a CTV buying platform, and a measurement specialist, and has to know when an answer is evasive, when a dependency is being understated, and what a scope change actually costs. The specifics of this partner set are learnable in weeks by someone who holds the underlying reasoning. Someone without it becomes a scribe in their own delivery review.

Required and portable across adtech engagements:

• The programmatic supply chain in working terms: what a DSP, an SSP, a network, and a measurement provider each do, and where money and data change hands between them.
• Advertising measurement as a commercial mechanism: what a conversion is, what an attribution window does, and why the payment model determines what the data has to prove.
• Why partner integrations in this industry carry long approval paths — security review, commercial terms, data-sharing agreements — and how to plan around calendars owned by someone else.

Specific to this engagement, and expected to be ramped rather than pre-held:

• Affiliate network mechanics and the CPA-on-CTV proposition.
• Household exposure-to-conversion matching, and the identity limits of connected-television inventory.

Depth in one of adtech, affiliate, performance marketing, or media measurement is expected. Breadth across all of them is not. The gap that matters is someone who has only delivered software and has never had to hold a schedule together across organisations that do not report to them.

Nice to Have

• Experience taking a pilot or proof of concept through to a productisation decision, including what evidence the decision required.
• Prior work with an affiliate or performance network, a DSP, or a measurement provider as a delivery counterpart.
• Familiarity with white-label or partner-embedded products, where another company’s engine sits behind an owned surface.
• Comfort writing client-facing documentation — runbooks, acceptance packs, release notes — to a standard that survives handover.
• Experience handing a platform over to a client team to operate.

Ideal Candidate Profile

You have run the kind of project where the engineering was the easy part. Three organisations had to agree. None of them worked for you, and the thing that nearly sank it was a questionnaire sitting in someone’s inbox. You learned to treat that as the actual project and the sprint board as a secondary instrument.

You chase names and dates. When someone says a partner approval will take a few weeks, you want to know who signs it, what they need from us, and what date we should worry about — and you ask in the first week, not the week it goes critical. You would rather be slightly irritating in month one than diplomatic in month four.

You are technical enough to tell when an estimate is optimistic and when a partner is answering a different question from the one you asked, and secure enough not to pretend to be more than that. You write acceptance criteria before the work starts because you have watched an undefined finish line turn a pilot into an open-ended engagement, and you think that serves nobody, least of all the client.

You run light. At half-time, you cannot be a process layer, and you do not want to be one — you pick the two meetings that earn their place, keep the dependency plan genuinely current, write down the decisions, and stay out of the way of a senior team that does not need managing. You measure yourself by whether the pilot landed inside its window and whether the client knew what they were accepting when they accepted it.