The transit Product Owner wants to scale a fare-capping experiment citywide after a two-stop pilot. Finance is ready to fund a full rebuild. Kill criteria were never written. What should the Product Owner do?
Select an answer to reveal the explanation.
Short Explanation
Before you rebuild the whole rail line, write down what would make you stop. A two-stop fare-cap pilot without kill criteria is a hope with a budget. Set the evidence bar first—then scale, pivot, or kill on purpose.
Full Explanation
Scaling an experiment without kill or success criteria converts learning into an unvalidated spend. When a transit Product Owner wants to scale a fare-capping experiment citywide after a two-stop pilot, Finance is ready to fund a full rebuild, and kill criteria were never written, the Product Owner should define evidence thresholds to pivot or persevere before increasing spend. Scaling immediately so the experiment cannot be accused of being timid confuses boldness with empiricism. Keeping the pilot running indefinitely without thresholds avoids a decision. Asking the vendor to declare success in the contract so criteria are unnecessary outsources learning to a sales narrative. Exam caveat: not every pilot needs elaborate statistics, but PSPO II expects clear measures before large civic scale-up. Operational check: set pivot/persevere thresholds on rider outcomes and cost, compare the two-stop evidence against them, fund scale only if thresholds are met, and publish the decision rationale with Finance and transit stakeholders. Write the fare-capping pivot and persevere thresholds in the same artifact Finance sees before any citywide rebuild funding is released. Re-validate the decision after the next Sprint Review using outcome evidence rather than output counts alone.