A municipal Product Owner is mixing a citizen-outcome Product Goal with a hoped-for launch Friday. What distinction should the Product Owner make so the team can adapt scope?
Select an answer to reveal the explanation.
Short Explanation
The Product Goal is the destination — residents actually getting the outcome. The Friday is a weather guess about when a useful slice might land. If you worship the Friday, scope cannot move and the destination gets lost in the parade.
Full Explanation
A Product Goal describes a valuable citizen outcome the Product Backlog commits toward; a hoped-for launch Friday is a forecast hypothesis, not the goal itself. Separating the two lets the Scrum Team adapt scope toward the outcome as evidence arrives while keeping the date honest enough to inspect. Treating the date as the Product Goal and letting leftover outcomes wait until after launch elevates the calendar above citizen value and removes the reason the product exists. Treating both the date and every listed feature as equally fixed leaves no room for empiricism when discovery contradicts the plan. Dropping the Product Goal to manage only the date assumes citizens care about calendars more than outcomes and leaves the backlog without directional purpose. Exam caveat: PSPO II repeatedly tests the distinction between goals (outcomes) and forecasts (dates and scope hypotheses). Operational check: write the Product Goal as a citizen outcome without embedding a Friday, label the launch date as a forecast with assumptions, and confirm Sprint Planning can thin features while still advancing the goal. Keeping citizen outcomes as the Product Goal while treating the launch Friday as a hypothesis preserves the team's right to thin features without abandoning purpose. If stakeholders insist the Friday is fixed, reopen the scope conversation explicitly rather than silently weakening Done.