Transit stakeholders assume residents want push notifications for every service change and want a full notification platform next quarter. The assumption is unvalidated. What should the Product Owner do before a large build?
Select an answer to reveal the explanation.
Short Explanation
"Everybody wants a ping" is a hunch until someone checks. A tiny experiment — maybe one alert type to a slice of riders — is a cheap flashlight. Building the whole notification factory first is like paving a highway to a park nobody visits.
Full Explanation
Unvalidated assumptions about residents wanting push notifications for every transit service change should be tested cheaply before funding a full notification platform next quarter. The Product Owner should design a small experiment that tests whether targeted alerts change rider behavior before the large build. Funding the full platform immediately so the assumption can be tested after launch inverts empiricism and burns budget on a possibly wrong solution. Adding every notification type to the Definition of Done so Developers implement them as quality work misuses Done to smuggle unvalidated scope. Surveying only the transit board and treating their preference as validated resident value confuses stakeholder opinion with rider behavior evidence. Exam caveat: learn before building large when problem or solution uncertainty is high. Operational check: run a thin alert experiment on one high-impact service change, measure rider response, and only then decide whether a platform investment is justified. Cheap experiments on targeted transit alerts should precede platform investment when resident notification demand is unvalidated. Measure rider behavior change on a thin slice before funding every notification type as if Done required them.