A legacy mainframe replacement for utility billing has a detailed project plan and no Product Vision. What should the Product Owner do?
Select an answer to reveal the explanation.
Short Explanation
A project plan says how to move the boxes. A vision says why residents should care after the boxes move — accurate bills they can understand, fewer shutoff surprises. Replacement work is still a product.
Full Explanation
A legacy mainframe replacement for utility billing with a detailed project plan but no Product Vision is a project without product direction. The Product Owner should introduce an outcome-oriented Product Vision for the replacement product so backlog order serves citizen and billing outcomes, not only cutover tasks. Treating the project plan as the vision because replacement scope is already known confuses means with ends and freezes learning. Waiting until the mainframe is decommissioned before writing a vision for whatever remains delays the filter needed during the highest-risk build period. Copying the vendor's implementation methodology and labeling it the Product Vision substitutes process for citizen outcomes. Exam caveat: replacements still need Product Vision; plans and methodologies are not visions. Operational check: write a vision such as accurate, understandable bills residents can pay without calling, realign the replacement backlog to that outcome, and inspect bill accuracy and call volume rather than only mainframe decommission milestones. Utility billing mainframe replacements still need outcome vision—accurate understandable bills residents can pay—or the project plan will optimize cutover over citizen value. Inspect bill accuracy and call volume alongside decommission milestones.