A parks Product Goal for the next period is 'replace the reservation database,' while the Product Vision is 'families can book a picnic shelter in under five minutes.' What should the Product Owner do?
Select an answer to reveal the explanation.
Short Explanation
Swapping the database is a chore; five-minute picnic bookings is the picnic. Goals should walk toward the vision, not take a side quest into the server room. If the two disagree, fix the goal — don't rewrite the destination to match the errand.
Full Explanation
A Product Goal must advance the Product Vision. When parks vision is families booking a picnic shelter in under five minutes but the current Product Goal is replace the reservation database, the Product Owner should realign the Product Goal to booking-time outcomes rather than a technology swap. Keeping the database replacement as the Product Goal because technical work is more inspectable confuses means with ends. Rewriting the Product Vision to match the database project demotes citizen outcomes to fit an internal project. Running both as equal current goals and letting Developers choose Sprint by Sprint abandons Product Owner ordering. Exam caveat: technology initiatives may support a goal but should not replace an outcome-oriented Product Goal. Operational check: rewrite the Product Goal around measurable booking-time improvement, treat database work as backlog items only where they enable that outcome, and inspect family booking time at Sprint Reviews rather than database cutover checklists alone. Parks Product Goals expressed as database replacements fail the vision test when families still cannot book shelters quickly. Keep technology work subordinate to measurable booking-time improvement and inspect that metric, not only cutover checklists.