How to Design a Product Compliance Review Before Launch

How to Design a Product Compliance Review

A product compliance review works when it connects the legal interpretation to the feature that will actually ship. The review should include the working flow, jurisdictions, affected people, data, exceptions, failure states, controls, test evidence, decision owner, monitoring, and automatic stop conditions.

A legal memo alone cannot do that. Neither can a product checklist completed after the launch decision has already been made. The review is a cross-functional decision process with a durable record.

The practical test is simple: can an accountable reviewer reconstruct what the product did, which facts the advice relied on, who accepted the remaining risk, and what evidence would force the team to pause?

flowchart TD
    A["Freeze proposed scope"] --> B["Walk the working product"]
    B --> C["Map data and affected parties"]
    C --> D["Identify rules and accountable interpretations"]
    D --> E["Test risks, failures, and controls"]
    E --> F["Record dissent and decision"]
    F --> G["Launch, narrow, delay, or stop"]
    G --> H["Monitor the operating state"]
    H --> I{"Material change or stop signal?"}
    I -->|Yes| A
    I -->|No| H

Start before the answer is fixed

The review should begin while the team can still change the design, market, data use, timing, or launch state. A review that starts after contracts are signed and launch communications are scheduled creates pressure to convert every concern into a minor condition.

Name the decision that is still open. The answer may be to approve, approve with limits, delay, test in a controlled environment, redesign, or stop. If the only permitted answer is approval, the meeting is not a review.

The current Justice Department corporate compliance materials organize their evaluation around design, implementation, resources, reporting, investigation, testing, incentives, and remediation. The Justice Manual asks whether a program is well designed, adequately resourced and empowered, and working in practice.

Those are useful governance questions. They are not a universal checklist, legal opinion, or safe harbor.

Freeze the proposed scope

Record the product version, release date, countries, states, cities, user groups, channels, platforms, contracts, and business purpose. Identify what is explicitly out of scope.

Scope should be precise enough that a later change is visible. "Launch the feature in the United States" is usually too broad. A new data source, hidden cohort, administrator override, pricing method, market, or use case may change the legal analysis even when the feature name stays the same.

Assign a product owner and a decision owner. The product owner can explain the system. The decision owner has authority to accept, narrow, delay, or stop the proposal within organizational and legal limits.

Bring the working product into the room

Reviewers should see the actual flow, not only screenshots selected for the meeting. Walk the default experience, alternate experiences, feature flags, risk cohorts, administrator tools, API behavior, notifications, appeals, logs, and failure states.

Ask what an ordinary user sees, what a selected user sees, what a support agent sees, and what an auditor or regulator can observe. If those views differ, record why.

The Greyball record shows why this matters. Uber's March 2017 statement acknowledged technology that could hide the standard city view from an individual rider and show a different version. The governance lesson is not that all alternate experiences are wrong. It is that an alternate experience can be the material fact.

Map data and affected people

For each data element, record its source, purpose, legal basis where applicable, sensitivity, access, retention, transfer, inference, and deletion path. Include derived scores and external enrichment, not only fields shown on a screen.

Name affected people beyond the direct customer. They may include employees, contractors, drivers, merchants, applicants, children, bystanders, regulators, competitors, communities, or people represented by a proxy signal.

Then connect data to product action. Which field or score places someone in a cohort? What does the cohort change? Can a person know, correct, appeal, or exit? What happens when the data is wrong?

Build the authority record

The authority record should identify the jurisdiction, rule, license, order, contract, policy, guidance, and effective date relevant to the decision. It should distinguish binding law from guidance, a regulator statement, a contractual promise, internal policy, and outside commentary.

Record who supplied the interpretation and the facts that person received. If counsel reviewed a prototype without the final cohort logic, the record should say so. If a rule is unsettled, preserve competing interpretations and the trigger for refreshing them.

Legal advice may be privileged and require restricted storage. The ordinary product record can point to an authorized matter identifier and capture the operational boundary without copying sensitive advice into a widely shared note.

Test the risk and the control together

Risk should name the affected party, possible harm, likelihood, detectability, duration, reversibility, and externalized cost. "Regulatory risk" is not specific enough. The team needs to know what could happen and to whom.

Every control should have an owner, implementation location, test method, expected result, evidence, monitor, alert threshold, and response. A policy is not the same as a technical control. Training is not the same as access restriction. A dashboard is not useful if no one must act on it.

Test failure states. Ask what happens when the model is wrong, the flag never expires, the log is missing, an administrator bypasses the rule, the data source changes, or a selected user cannot appeal.

Preserve dissent and conditions

Material objections belong in the decision record in their real meaning. Do not replace them with "stakeholders aligned."

State whether the objection changed scope, timing, controls, monitoring, authority, or the launch decision. If the objection remains unresolved, identify who accepted the remaining risk and whether that person had the authority to do so.

Conditions should be testable. "Monitor closely" is weak. A stronger condition identifies the metric, threshold, owner, review frequency, response, and automatic stop.

Make the release decision

The review should produce one explicit state: approved, approved with conditions, controlled test, delayed, redesign required, or stopped. Record the approver, date, scope, facts, assumptions, dissent, controls, and stop conditions.

Approval should expire when a material fact changes. A new market, data source, cohort, user class, purpose, model, interface, or administrator capability should trigger reapproval.

Monitor what shipped

Compare the operating product with the approved version. Review incidents, complaints, overrides, cohort size, appeals, control failures, market changes, and regulatory developments.

The September 2024 Evaluation of Corporate Compliance Programs emphasizes whether controls work in practice and whether the company learns from problems. A launch record without operating evidence becomes a paper program.

Schedule a near-term outcome review and a longer refresh. Preserve the original decision. Append what changed, what happened, and whether the feature continues, narrows, pauses, or ends.

An Obsidian-ready review record

The following table can serve as the spine of a Markdown note without pretending that every product has the same requirements.

Pair this review with [[How to Build an Accountable Innovation Decision Record]]. Use [[When a Product Exception Becomes a Governance Risk]] when the feature contains hidden cohorts or alternate paths.

Editorial note

This guide was developed with AI assistance from Venture Step E047 and the linked Justice Department materials. Dalton Anderson remains the author. The framework does not replace qualified legal, privacy, security, records, regulatory, or domain advice. Organizational use requires adaptation and review. Publication is not authorized.