The Post-Mortem: Blameless Analysis

When things go wrong (and they will), the goal isn't to find a "Scapegoat" (someone to blame). The goal is to learn.

The "Five Whys" Technique

Keep asking "Why?" until you hit the root.

1. Why did the site go down? Because the database ran out of disk space.
2. Why did it run out of space? Because a log file grew too large.
3. Why did the log file grow? Because we enabled 'Debug' mode in production.
4. Why was 'Debug' enabled? Because an engineer forgot to toggle it off.
5. Why was it possible to forget? (Root Cause) Because we don't have an automated check to prevent 'Debug' mode in production deploys.

Vocabulary of Incidents

• Outage: Total service failure.
• Degradation: Service is slow or partially broken.
• Detection: When the team first realized there was a problem.
• Mitigation: Temporary fix to stop the "bleeding."
• Resolution: The permanent fix.

Writing Action Items

Action items must be Specific and Verifiable.

• Bad: "Be more careful next time."
• Good: "Implement a linter rule to block 'DEBUG=true' in production config files."

Alex's Tip: A great post-mortem is a sign of a Senior Engineer. It shows you care more about the health of the system than your own ego.

Requirements are testable statements about what the product must do.

• Weak: The app should be fast.
• Strong: The dashboard must load in under 2 seconds for 95% of requests.

A testable requirement can be verified: does it load in under 2 seconds for 95% of requests? If yes, the requirement is met. Vague requirements cannot be tested and lead to disputes.

Use must for requirements and should for nice-to-haves:

• The system must support single sign-on.
• The system should support dark mode.

Scope: in and out

Scope has three buckets:

1. In scope (must-haves): required for launch.
2. Nice-to-haves: desirable but not required.
3. Out of scope: explicitly will NOT be built this iteration.

The out-of-scope list is the most important defense against scope creep. By naming what is excluded, you prevent every stakeholder from adding their request.

• Out of scope: mobile app, multi-currency, advanced reporting. These will be considered in a future iteration.

Success metrics

How will you know the feature worked? Define metrics up front:

• Manual reconciliation time drops from 4 hours to under 1 hour per week.
• Payment error rate falls below 1%.
• NPS for the payments flow increases by 10 points.

Metrics turn the PRD into something measurable. Without them, success is subjective.

A model PRD outline

Problem: SMB owners spend 4 hrs/week on manual reconciliation; errors cost ~$2K/year. Goals: Cut reconciliation time 80%; reduce errors 50%; launch NA by Q3. Requirements (must): Auto-match transactions; support CSV import; daily summary email. Nice-to-haves: Multi-currency; mobile push alerts. Out of scope: Mobile app; advanced reporting. Success metrics: Reconciliation under 1 hr/week; error rate below 1%.

This is scannable in one minute. The whole team understands the what, why, and how-we-measure.

Common mistakes

1. Vague requirements. Fast, great, better cannot be tested. Use numbers.
2. No out-of-scope list. Scope creep follows.
3. No metrics. Without them, success is opinion.

Practice

Write a one-paragraph PRD outline for a feature you would build:

1. Problem: _
2. Goal: _
3. One testable requirement: _
4. One out-of-scope item: _
5. One success metric: _

In the next lesson, you will learn to write an RFC (Request for Comments) for technical decisions.