3.1 "Working Backwards" from the Model Card
Amazon's "Working Backwards" methodology forces teams to define success before building anything. For AI products, we adapt this by starting with a comprehensive Model Card—a document that defines what the AI will do, for whom, with what limitations, and under what governance constraints. This inverts the typical AI development flow, where governance considerations are tacked on at the end.
Most AI projects fail not because of technical problems, but because teams build the wrong thing, or build the right thing without understanding its risks. By completing a Model Card before writing code, teams force themselves to think through stakeholders, use cases, limitations, fairness requirements, and governance needs upfront—when changes are cheap.
The Amazon "Working Backwards" Process
From Press Release to Product
At Amazon, product development begins with writing a mock press release announcing the finished product. This discipline forces teams to:
- Articulate the customer benefit: What problem does this solve and for whom?
- Define success clearly: What would make this worth announcing?
- Identify key features: What must be true for the press release to be accurate?
- Surface assumptions: What are we assuming that might be wrong?
The press release is accompanied by an FAQ document that anticipates questions from customers, stakeholders, and executives. Together, these documents create alignment before significant investment.
Adapting for AI
For AI products, we extend this concept with the Model Card—a standardized document (originally proposed by Google researchers) that captures everything needed to understand an AI system's purpose, capabilities, and limitations. The Model Card becomes the pod's charter, governance documentation, and success criteria rolled into one.
AI systems have unique characteristics that make upfront planning especially valuable:
- Emergent behaviors: AI can do unexpected things; anticipating risks requires deliberate thought
- Bias amplification: Training decisions made early have lasting impacts on fairness
- Regulatory scrutiny: Documentation created after the fact is less credible in audits
- Stakeholder complexity: AI affects many groups who deserve early input
The AI Innovation Model Card
The AI Innovation Model Card expands on the original Google Model Card concept to serve as a complete "Working Backwards" document for AI products:
Document Purpose
The Model Card serves multiple purposes throughout the AI lifecycle:
| Phase | Model Card Purpose |
|---|---|
| Ideation | Forces structured thinking about the problem, users, and risks before building |
| Development | Provides success criteria and guardrails that guide technical decisions |
| Deployment | Documents capabilities and limitations for users and stakeholders |
| Operations | Defines monitoring requirements and acceptable performance thresholds |
| Governance | Provides audit trail and evidence of responsible AI practices |
Key Model Card Sections
1. Model Overview
- Model Name: Clear identifier for the AI product
- Version: Current version with link to changelog
- Owning Pod: The AI Innovation responsible for this AI
- STO: Single-Threaded Owner name and contact
- Risk Tier: Classification per governance framework
- One-Line Description: What this AI does in plain language
2. Intended Use
- Primary Use Cases: Specific scenarios the AI is designed for
- Intended Users: Who should use this AI and in what context
- Out-of-Scope Uses: Explicit list of prohibited or unsupported uses
- Human Oversight Requirements: When human review is required
- Decision Authority: What decisions the AI can make vs. recommend
3. Training Data
- Data Sources: Where training data comes from
- Collection Methodology: How data was gathered
- Time Period: When data was collected
- Consent & Rights: Legal basis for using the data
- Known Gaps: Populations or scenarios underrepresented
- Preprocessing: Key transformations applied
4. Performance Metrics
- Primary Metrics: Key performance indicators with target thresholds
- Evaluation Data: What data was used for evaluation
- Disaggregated Results: Performance across different subgroups
- Confidence Intervals: Uncertainty in reported metrics
- Comparison Baselines: How performance compares to alternatives
5. Fairness & Bias
- Protected Attributes: What sensitive characteristics were considered
- Fairness Metrics: Specific measures of equitable treatment
- Known Disparities: Documented performance differences across groups
- Mitigation Efforts: Steps taken to address bias
- Residual Risks: Remaining fairness concerns and mitigations
6. Limitations & Risks
- Technical Limitations: What the model cannot do well
- Edge Cases: Known scenarios where performance degrades
- Failure Modes: How the system fails and how to detect it
- Risk Assessment: Potential harms and their likelihood
- Mitigation Controls: Guardrails to prevent or detect problems
7. Governance & Compliance
- Applicable Regulations: Laws and standards that apply
- Compliance Status: Current compliance posture
- Required Reviews: Approvals obtained or needed
- Monitoring Requirements: Ongoing compliance monitoring
- Audit Trail: Links to decision documentation
8. Operational Requirements
- Infrastructure: Compute, storage, networking requirements
- Dependencies: External systems and services
- Monitoring: Required observability and alerting
- Retraining: Schedule and triggers for model updates
- Incident Response: Escalation paths and procedures
The Working Backwards Process
Creating the Model Card is a structured process that involves the entire pod:
Initial Model Card (2-3 days)
The STO creates the first draft, focusing on business context, intended use, and success criteria. This draft is deliberately imperfect—it's meant to provoke discussion, not be complete.
Technical Feasibility & Risk Identification (1 day workshop)
The full pod reviews the draft, with each role contributing their expertise. ML engineers assess technical feasibility. The Ethics Liaison identifies governance gaps. Data engineers evaluate data requirements.
External Review (1 week)
The draft is shared with key stakeholders: business sponsors, affected teams, compliance functions. Feedback is incorporated and conflicts resolved.
Governance Classification (1-2 days)
Based on the Model Card content, the AI product is assigned a risk tier that determines governance requirements. High-risk products require AI Council review.
Commitment to Proceed (Varies by risk tier)
The Model Card is formally approved at the appropriate level. For low-risk products, STO approval suffices. High-risk products require AI Council sign-off.
Living Document
The Model Card is not a one-time artifact. It evolves throughout the product lifecycle:
- Development: Updated as technical decisions are made and real performance data emerges
- Deployment: Finalized with production metrics and operational procedures
- Operations: Continuously updated with monitoring results, incidents, and improvements
- Major Changes: Any significant change triggers Model Card review and potential re-approval
The power of Working Backwards comes from the discipline of writing. Unlike verbal discussions that can skip over hard questions, written documents force clarity. When you can't write a coherent explanation of who will use this AI and how, that's a signal you don't yet understand the problem well enough to build a solution.
Common Pitfalls
Teams new to Working Backwards often fall into these traps:
- Treating it as bureaucracy: The Model Card is a thinking tool, not a compliance checkbox
- Writing it alone: The value comes from collaborative discussion, not solo documentation
- Being vague: "Improve customer experience" is not a use case; specific scenarios are required
- Ignoring limitations: Every AI has limitations; refusing to document them doesn't make them disappear
- Writing once: A Model Card that isn't updated is a lie about the current system