Stepping in as product owner.

The short version

The squad's product owner was out for weeks, leaving five epics with no target dates. Ten weeks of interim cover at 50%, shared with a second interim PO and alongside the design manager role. The first move was asking the developers where things really stood, then correcting the status in writing before any dates reached a release plan. One overlooked epic turned out to be the most shippable, so it went out on its own instead of waiting on blocked work. Three releases followed: a separate one for the first phase of the tracking-platform integration, then production releases on 11 September and 9 October 2026. All five epics shipped.

The situation

An integrations squad lost its product owner for several weeks. Five epics sat under the squad, none with a target date, and the working assumption upstairs was that two of them were close to finished.

Cover came from the design manager seat, at 50%, shared with a second interim PO. Ten weeks, a full design team still to run, and a release plan that did not exist yet.

The work

Ground truth first. Straight to the developers, before any spreadsheet. One of the “close to finish” epics was mid-rebuild: its stories had been written against orders when the model needed trips, so the whole service was moving from an order-based to a trip-based design. The other was waiting on an external partner’s calendar. Neither was close.

Corrected upward, in writing. The status went back to leadership with the developers’ own words as the basis, before the wrong dates could land in a release plan. Uncomfortable for a day. Much cheaper than a missed release.

Found the shippable one. The epic nobody had a status on (RFP status) turned out to be the closest. One refined story, never pulled into a sprint. A PO-side gap, so a PO-side fix. It went into the next sprint.

Sequenced by dependency. Ready work shipped alone. A combined “two epics” release was on the table and got turned down, because it would have tied a shippable epic to a blocked one.

A separate release, August to September. Phase 1 of the tracking-platform integration went out on its own, without waiting for the rest.

11 September release. RFP status and pinned filters, in the same release as the centralised inbox. On time. Release notes, the release email and the UAT window all ran from this seat.

9 October release. Live tracking pushed to an external visibility platform (reefer temperature included), plus the foundation for direct carrier integrations: the first carrier group live, and exception pages for failed messages.

Who did what

This seat held the interim PO role at 50%: status reconciliation, prioritisation, input to sprint planning, release sequencing, release notes and communication, and UAT. A second interim PO shared the role and ran a client test. The developers built and tested every epic. A product designer owned the design. A release manager drove one of the releases.

Status in a tool is not status. Ask the people building it.

What shifted

Leadership’s picture moved from “close to finish” to a dated, dependency-aware release plan. All five epics released, and the squad’s carrier integration went live with its first carrier.

The cover ended on 8 October 2026, by design. The squad became a POD under the new way of working, with one end-to-end owner per epic. Job done, seat handed back.

What it taught

Status in a tool is not status. An epic can read as in acceptance while the data model underneath it is wrong. The only reliable signal was the people writing the code.

And a designer who has sat in the PO seat writes better handovers to it. Those ten weeks fed straight into the idea-to-release lifecycle that followed, and into where design sits inside it.