Setting Exit Criteria and Sign-offs for Closing a Design Review

As the PM on a product team, how do you decide that a design review is complete and the team can move forward? Explain the criteria you use and how you would confirm each one has been met. ```hint Start from the review's purpose Ask what risk a design review exists to remove before building starts, and what evidence would show that risk is gone. Let that, not the calendar, define done. ``` ### Clarifying Questions - Is this a review of the product and UX design (flows and mocks), an engineering design document, or should the criteria cover both? - Which reviewers are mandatory here: only the engineering and design leads, or also functions such as privacy, security, legal and accessibility that can block a launch? - Does complete mean approved to start building, or is the design expected to keep changing during implementation? - Is this a small, easily reversed feature change or a decision that is expensive to undo, such as a new data model or a public API? ### What a Strong Answer Covers - What the review is for and what a completed review allows the team to do next - Concrete, checkable exit criteria covering the problem, the chosen design, open comments and required sign-offs - How the bar scales with the size and reversibility of the decision - How unresolved disagreements are closed, escalated or deferred with an owner - How the decision is recorded and what would reopen an approved design ### Follow-up Questions - A senior engineer still objects to the approach two days before development is due to start. Do you close the review, and how? - What signals would tell you that your team's reviews are closing too early, or dragging on too long? - Which changes during implementation would make you reopen a review that was already marked complete?