A five-year smart-city program has a single go-live and no intermediate citizen outcomes for transit, permits, or lighting. What should the Product Owner reframe it as?
Select an answer to reveal the explanation.
Short Explanation
A five-year smart-city switch-flip is a promise that residents will wait five years for the lights to work. Treat it as products — transit, permits, lighting — with goals that can ship this year. Incremental outcomes beat one distant ribbon-cutting.
Full Explanation
Long municipal programs can be recast as a product-oriented portfolio with incremental goals, preserving empiricism and Current Value along the way. A five-year smart-city program with a single go-live and no intermediate citizen outcomes for transit, permits, or lighting asks residents to wait five years for working value. The Product Owner should reframe it as a product portfolio with incremental Product Goals that can release value long before year five. Replacing Product Owners with a program manager, freezing requirements, or imposing a single citywide increment objective all restore predictive control.
Treating it as a fixed-scope capital project with a program manager replacing all Product Owners until year five fails by removing product empiricism. A requirements freeze covering transit, permits, and lighting fails by locking learning for half a decade. A single citywide train with one program increment objective for every department fails by forcing false synchronization across unlike products.
Exam caveat: Reframe multi-year smart-city programs as incremental product portfolios with releasable goals. Operational check: Split the program into transit, permits, and lighting Product Goals with near-term Done Increments, restore Product Owners, and retire the single year-five go-live as the only success definition.