Technical Project Management for a Multi-Market AI Product

A three-market AI product was shipping features fast but flying blind: no delivery process, no definition of done, an external dev team held to no clear standard, and a production outage that took hours to even surface. Hired to lead growth, I was asked within two weeks to also fix this. As technical project manager I built the operating system - a 12-stage delivery pipeline, weekly commit-and-complete reporting with the CTO, written specs that lock scope before any code, a quality-and-proof KPI framework, and incident response with on-call - and I did it as a matrix PM, driving a team I coordinate but do not manage.

Challenge

Arthur runs as three separate production instances (German, English, Russian) built by an external development agency. Delivery was fast but unaccountable, and the stakeholder holding me responsible for velocity had no lever to pull.

• No process. Tasks moved with no definition of done, work was marked complete with no proof, and there was no shared view of what was in flight.
• No direct authority. The developers report elsewhere - my leverage is influence, escalation, and process, not the org chart.
• Reliability gaps. A production incident took all three instances down and surfaced only after hours, with no monitoring or on-call in place.
• Scope ambiguity. Feature requests arrived without enough detail to estimate, and no one was deciding what fell inside the maintenance contract versus net-new scope.

Approach

A delivery system, not just a task list

• A 12-stage Asana pipeline with a Definition of Done field and automation rules, plus a single live triage doc as the source of truth for everything open.
• Weekly commit-and-complete reporting with the CTO - a Monday commitment and a Friday completion summary - so the week is planned and verifiable, not reactive.
• Daily routines I productized - a morning kickoff, a mentions sweep, a dev-group status post, and an overdue-task monitor - repeatable so nothing slips through.

Specs before build

For every non-trivial feature I write an SRS-style spec - purpose, trigger, flows, edge cases, open questions - before it enters Asana, so the team can quote and build against locked scope instead of a vague request. I did this for the registration flow, image recognition, the onboarding sequence, and post-event messaging.

Accountability without authority

• A consequence-and-recognition ladder in the workflow rules: tiered escalation for overdue work, balanced by named recognition for strong delivery.
• A quality-and-proof KPI framework I authored at the stakeholder's request - a rework-return-rate metric and a proof-of-completion gate (no screenshots, no "done") - with fairness guardrails so genuine spec changes do not count against the team.
• RACI, a risk register, and an on-call map so every workstream has a clear owner and the matrix is explicit.
• The escalation discipline from the Google PM framework: pin every dependency to a dated commitment, make the impact visible to the stakeholder the same day, and escalate a slip as a project risk, in writing, not a personal complaint.

Incident response and reliability

After the outage I stood up the missing guardrails: an incident-response and on-call section in the workflow rules, named primary and backup on-call owners, and a planned-downtime notification rule - turning a painful surprise into a documented process.

Results

This is an active engagement; below is what is in place as of June 2026.

• A documented delivery system the external team now runs against - pipeline, definition of done, weekly reporting, and stage SLAs where there were none.
• Accountability that holds without authority - a proof gate and rework KPI the stakeholder asked me to own, plus a recognition track that keeps the vendor relationship healthy.
• Faster, cleaner intake - specs lock scope up front, so features are estimable and the maintenance-versus-new-scope line is clear.
• Reliability after the incident - monitoring, on-call, and a downtime-notification rule that did not exist before.
• Trusted with more: brought in for growth, the client expanded my role to also run technical PM within two weeks.

Scope of Work

Technical project management of an external dev team across three production instances: delivery process design (Asana pipeline, Definition of Done, automation), SRS-style specification writing, weekly CTO alignment, QA and release close-out, a quality and proof-of-completion KPI framework, RACI and risk register, incident response and on-call, scope and cost triage, and stakeholder reporting.

Tools Used

Asana (with API), Notion, Slack, WhatsApp, Google Workspace; Agile and Kanban, RACI, risk register, stage SLAs, SRS specs