The Pre‑Mortem for Mini‑Features: A 6‑Question Template That Prevents Common Launch Failures

Pre‑mortems are a simple cognitive tool: imagine the feature has failed and work backward to identify what would cause that failure. The method is well documented and effective for short, concentrated sessions that reveal implicit assumptions teams miss in planning. Gary Klein’s work and subsequent HBR guidance frame the technique as an early risk‑discovery ritual you run after planning and before build starts. (gary-klein.com)

Mini‑features are misleadingly low‑risk on paper but high‑risk in practice because they typically: touch shared state, change client behavior, or alter critical flows with little testing. Teams that treat every mini‑feature like a full release (brief pre‑mortem, minimum telemetry, clear rollback plan) reduce firefighting later and save developer time. Industry guidance on incremental release techniques and feature flags explains why lightweight release controls paired with observability are the most reliable approach. (learn.microsoft.com)

Run this as a 15‑minute ritual with 3–6 people: product, an engineer, someone from SRE/ops or a knowledgeable QA, and a designer if the change touches UI. For each question, aim for concrete answers and actions you can complete before the first commit or at least before merging to main.

The six questions (write answers in-line, assign owners, and add an action if the answer isn’t a clear 'safe').

You can’t instrument after the fact. Decide the telemetry contract before code lands: the minimal set is three metrics, one trace span, and one structured log event per critical path. Use stable dimensions (feature_id, user_id hashed, environment) so dashboards and alerting filters are useful. The observability goal is rapid detection and root‑cause narrowing without shipping code changes. This schema‑first approach is advocated in observability literature because adding missing signals often requires a new release. (en.wikipedia.org)

Concrete telemetry hooks to add pre‑merge: 1) a feature_event counter with outcome tags (success/failure/validation_error); 2) a latency histogram for the new code path; 3) a trace span that links user action to backend calls; plus a single structured error log that includes feature_id and a short error_code so you can filter quickly. Also add a synthetic check or RUM probe that exercises the flow in staging or a dark launch slice. Datadog and other observability vendors document dark launch monitoring patterns that align with these hooks. (datadoghq.com)

1) Feature flag toggle (fastest, least intrusive). Use for UI experiments and non‑critical logic where the new code path can be executed and hidden from users. The flag must be runtime‑evaluated and support user cohorts. If an issue appears, flip the flag to off — this is typically immediate and avoids redeploys. Best practice: keep the flag scope narrow and add a rollback owner. Platform docs and vendor guides show this pattern as the default for progressive releases. (devblogs.microsoft.com)

2) Canary by percentage (safest for server/API changes that affect state). Deploy code and route a small percent of traffic. Monitor the telemetry hooks defined above and reverse weight if metrics degrade. Canary rollback requires traffic control but preserves the new code in prod for rapid patching. Industry guides and cloud well‑architected guidance recommend canaries when stateful or dependent services are involved. (newrelic.com)

3) Dark launch with data validation (when you need the code to run but not expose results). Execute the new code path in production, write results to a separate table or shadow pipeline, and validate output without changing user‑visible state. If validation fails, you can stop the pipeline or flip the feature that promotes shadow output to live. Datadog and AWS docs discuss dark launch monitoring as a controlled way to validate behavior under real traffic. (datadoghq.com)

Before you merge, walk the team through this quick checklist. If any item is unanswered or ‘no’, stop and fix it: 1) Telemetry: do we have the three hooks (metric, trace, log)? 2) Rollback: is there a single owner who can disable or reverse the change? 3) UX safety: are any users exposed by default? 4) Load: will any performance‑sensitive path see more work? 5) Data integrity: does the change touch schema or migrations? If the answer to any is uncertain, treat the feature as medium/high risk and prefer canary or dark launch. This structured stop/go decision is what turns a pre‑mortem from theory into an operational control.

Append this to your team’s launch template (AppWispr customers and builders often add a short 'pre‑mortem' field in their ticket or PR description). Keep the pre‑mortem answers attached to the release so post‑mortem analysis can check whether predicted failures were anticipated. A short ritual plus these guardrails prevents most common launch failures and reduces wasteful rollbacks.