The book · Chapter 14 of 16 · Evidence · 6 minutes
Next · 15 What I bring into the room →
By Unnat Patel
Chapter 14 · Explore the idea
The controls fit the product and its risks; the calendar does not replace the gate.
Operating evidence returns the product to the next discovery question.
Inside the decision
Observe operators, interview teams and size bottom-up from actuals.
Discover until you have a number. Sit beside the operator. Interview one stakeholder team at a time, then synthesise. Pull the data yourself — SQL first, dashboards second. Size bottom-up from actuals; a top-down planning number I re-sized this way once came in at a third of the original, before it consumed a roadmap.
Inside the decision
Write value, criteria, scope, non-goals, risks and decision ownership.
Define in writing before anyone schedules anything. The press release and the hard questions. A requirements document with success criteria, non-goals and a risk register, iterated in numbered versions and capped. Every decision classified as a two-way door — decide fast, reverse cheaply — or a one-way door that gets the full review. A work-back plan from the hard date. Alignment by individual deep dives, one synthesised proposal, written sign-off from each team.
Inside the decision
Draw exceptions, specify the data and contracts, and write acceptance criteria before build.
Design the exceptions first. To-be flows. The data model before the screens. Data-mapping specifications — source, target, transformation, default, reject. Interface contracts: REST and JSON, event schemas, file formats. Wireframes reviewed with the people who will live in them. Acceptance criteria written given / when / then. Non-functional requirements — latency, throughput, idempotency, the boundary protected data may not cross — written before build.
Inside the decision
Deliver increments with acceptance criteria and an appropriate path to staged release.
Build in increments with the door open. Scaled agile or two-week sprints; no story enters a sprint without acceptance criteria; feature flags where a staged customer release is appropriate; rescope before you refactor.
Inside the decision
Connect the test ladder, representative evidence, operator acceptance and security review.
Test up a ladder — unit, integration, automated regression on production-shaped data, performance against the budget, user acceptance with real operators, offline replay or shadow mode for parity, security review scheduled from day one — and hold each rung with the decision only a product manager can make.
Inside the decision
Use the relevant approvals, a watched pilot, rollback rehearsal and training.
Launch through gates, then dial up. For safety-sensitive launches, seek the relevant safety, compliance, legal and operations approvals. A small, slow, watched pilot. Staged expansion, with rollback rehearsed. Training delivered through the learning system, standard operating procedures and job aids out the same day, customer and partner onboarding treated as a product with its own metrics, and a launch announcement that reports against the criteria set before building.
Inside the decision
Read outcomes, defects, cost and seam behavior together, then return to discovery.
Operate and measure the defect. Outcome, defect and cost per unit on one dashboard. Alarms on the seams. Use a Correction of Errors when the incident warrants a documented review. Weekly, monthly and quarterly reviews, and a monthly product review that puts outcomes, lowlights and next decisions on one page for leadership. Then back to Discover.
Strip the industries away and one method is left. The documents are in chapter 12 and the operating system in chapter 13; here is the method they serve. This is my preferred approach, with controls selected for the product and its risks.
Discover until you have a number. Sit beside the operator. Interview one stakeholder team at a time, then synthesise. Pull the data yourself — SQL first, dashboards second. Size bottom-up from actuals; a top-down planning number I re-sized this way once came in at a third of the original, before it consumed a roadmap.
Define in writing before anyone schedules anything. The press release and the hard questions. A requirements document with success criteria, non-goals and a risk register, iterated in numbered versions and capped. Every decision classified as a two-way door — decide fast, reverse cheaply — or a one-way door that gets the full review. A work-back plan from the hard date. Alignment by individual deep dives, one synthesised proposal, written sign-off from each team.
Design the exceptions first. To-be flows. The data model before the screens. Data-mapping specifications — source, target, transformation, default, reject. Interface contracts: REST and JSON, event schemas, file formats. Wireframes reviewed with the people who will live in them. Acceptance criteria written given / when / then. Non-functional requirements — latency, throughput, idempotency, the boundary protected data may not cross — written before build.
Build in increments with the door open. Scaled agile or two-week sprints; no story enters a sprint without acceptance criteria; feature flags where a staged customer release is appropriate; rescope before you refactor.
Test up a ladder — unit, integration, automated regression on production-shaped data, performance against the budget, user acceptance with real operators, offline replay or shadow mode for parity, security review scheduled from day one — and hold each rung with the decision only a product manager can make.
Launch through gates, then dial up. For safety-sensitive launches, seek the relevant safety, compliance, legal and operations approvals. A small, slow, watched pilot. Staged expansion, with rollback rehearsed. Training delivered through the learning system, standard operating procedures and job aids out the same day, customer and partner onboarding treated as a product with its own metrics, and a launch announcement that reports against the criteria set before building.
Operate and measure the defect. Outcome, defect and cost per unit on one dashboard. Alarms on the seams. Use a Correction of Errors when the incident warrants a documented review. Weekly, monthly and quarterly reviews, and a monthly product review that puts outcomes, lowlights and next decisions on one page for leadership. Then back to Discover.
None of this is exotic. What makes it work is refusing to skip a step because the calendar says so — and knowing, from seventeen years of the consequences, which steps are the ones that cannot be skipped.