Completing one building-permit citizen journey requires the Product Owner to coordinate six component teams for forms, payments, identity, GIS, notifications, and records. Handoffs stall value every Sprint. What should the Product Owner advocate?
Select an answer to reveal the explanation.
Short Explanation
Six pit crews for one bicycle is not craftsmanship — it is a traffic jam. If one citizen journey needs a parade of handoffs, the org design is the bug. Build a team that can finish the ride, not a prettier relay baton.
Full Explanation
Component-aligned teams optimize for technical layers and create dependencies that a Product Owner then has to heroically coordinate across forms, payments, identity, GIS, notifications, and records. For a building-permit citizen journey, that structure lengthens Time-to-Market and weakens empiricism because no single team can produce a valuable Done Increment of the journey. The Product Owner should advocate redesign toward a cross-functional feature or value-stream team that can finish the citizen journey. That organizational-design intervention is squarely in the Product Owner’s interest because handoff theater is not product value.
Adding a program-management layer to schedule the six handoffs more formally fails because it institutionalizes the dependency tax instead of removing it. Keeping component teams and lengthening Sprints fails by giving the relay more calendar room without creating a Done journey Increment. Splitting the Product Goal into six component goals fails because local component success can still leave the resident without a usable permit path.
Exam caveat: Chronic multi-team handoffs on one citizen journey are an org-design smell, not a coordination talent gap. Operational check: Map the permit journey’s Sprint-blocking dependencies, then propose a value-stream team staffing model that can release a usable journey slice without six sequential queues.