A city Product Owner for resident services can fund either a splashy parks-reservation skin or a shared resident identity-and-payments platform that would later unlock permit fees, transit passes, and clinic copays. Strategy wants several self-service outcomes next year. What should the Product Owner do?
Select an answer to reveal the explanation.
Short Explanation
Think of a city keycard that opens the pool, the permit desk, and the clinic—once. A shared identity-and-payments layer is that keycard: not flashy, but it unlocks a bunch of later doors. Strategy sometimes means sequencing the enabler that makes many outcomes cheap, not the prettiest single feature.
Full Explanation
Platform enablers can be the highest-value near-term bet when strategy depends on multiple unlocked outcomes. When a resident-services Product Owner can fund either a splashy parks-reservation skin or a shared identity-and-payments platform that later unlocks permit fees, transit passes, and clinic copays—and strategy wants several self-service outcomes next year—the Product Owner should order a thin identity-and-payments enabler first. Shipping the parks skin first because visible features prove strategy faster than platforms optimizes for optics over unlock value. Splitting the team so half builds identity and half builds payments as two unrelated products with separate Product Goals fragments a coherent enabler. Asking Finance to treat identity and payments as a multi-year capital project with a frozen feature list before any Increment reintroduces waterfall certainty. Exam caveat: enablers still need thin, inspectable Increments—not a multi-year black box—so value and risk remain empirical. Operational check: define a minimal identity-and-payments Increment that unlocks one follow-on service, order it above the skin, measure unlock readiness, and only then sequence parks and other self-service outcomes on the city Product Backlog.