Marketing drafts a transit Product Vision that names a container platform, a specific fare-engine vendor, and a mobile framework. What should the Product Owner do?
Select an answer to reveal the explanation.
Short Explanation
A fare engine and a container cluster are not why a rider misses the bus. Vision talks in rider outcomes — catch the next bus, pay without fumbling. Platforms can sit on the backlog as bets, not as the north star.
Full Explanation
A transit Product Vision should be written in citizen-value language; naming a container platform, fare-engine vendor, and mobile framework locks solution choices that belong as backlog options. The Product Owner should rewrite the marketing draft accordingly. Accepting the draft so engineering constraints cannot be revisited freezes architecture inside vision and blocks empiricism. Adding the platform list as a second vision so both business and technology are represented creates competing north stars. Handing vision writing to the architecture board because the draft is already technical further embeds solution bias. Exam caveat: vision states value; platforms and vendors are decisions under the vision, not the vision itself. Operational check: strip vendor and platform names from the vision, restate rider outcomes, and move technology choices into ordered backlog experiments that Sprint Reviews can reverse if evidence disagrees with the chosen stack. Citizen-value transit vision leaves platforms and vendors as reversible backlog choices; baking them into vision freezes learning. Strip solution names from the vision statement and require Sprint Review evidence before locking any stack decision.