## Prompt Tell me about a project that began with highly ambiguous requirements. How did you turn uncertainty into testable decisions while still making progress? ### Constraints & Assumptions - Identify at least two uncertainties that could have led to materially different implementations. - Explain which questions required stakeholder input and which could be answered with data or a prototype. - Show how you avoided both indefinite analysis and an irreversible guess. - Include the delivered outcome and how requirement changes were handled. ### Clarifying Questions to Ask - Was there a single decision-maker, or did several stakeholders disagree? - Did the ambiguity concern user behavior, technical constraints, or success metrics? - How much reversible experimentation was possible before committing to the architecture? ```hint Build an uncertainty register Rank unknowns by impact and cost of being wrong, then resolve the highest-risk item with the cheapest credible evidence. ``` ### What a Strong Answer Covers - A precise description of the ambiguous goal and why ordinary implementation could not begin safely. - A prioritized set of unknowns rather than an unstructured list of questions. - Concrete artifacts such as examples, prototypes, decision records, or measurable acceptance criteria. - Reversible early steps and explicit checkpoints for decisions that could not yet be finalized. - Communication that gives stakeholders choices and consequences instead of asking them to design the solution. - A result that links the clarification work to less rework, better adoption, or a safer launch. ### Follow-up Questions 1. Which assumption was most expensive if wrong? 2. What did you decide without waiting for consensus? 3. How did you document later changes to the agreed behavior? 4. What would you do if stakeholders continued to disagree after seeing the prototype?