Impact Metrics Gate — Measure Before Building

Core Principle

Every project, feature, or solution must define its impact metrics before development begins. The impact of any deliverable should be expressible in a single sentence that a non-technical stakeholder can understand.

If you cannot define impact in one clear sentence, the project is not yet ready to build.

Mandatory Gate Before Build

| Item | What It Is | Example | |---|---|---| | Primary impact metric (quantifiable) | The single, most important measurement of success. Must be a number. | "Reduce average task completion time from 45 min to 20 min" / "Increase monthly recurring revenue by $5k" / "Achieve 80% test coverage" | | Measurement method (source + collection) | Where the data comes from and how it is collected. Be specific about tooling and frequency. | "Timestamp delta in task tracking API, 7-day rolling average" / "Payment processor dashboard, monthly export" / "Code coverage tool CI report" | | Baseline or benchmark (starting point) | The current state or competitive reference point. Do not leave this as "zero" if measurable data exists. | "Current: 45 min (measured week of 2026-01-15)" / "Baseline: $0 MRR" / "Competitor average: 60% coverage" |

Where to Document

• New projects: Include an "Impact Metrics" section in the specification document, README, or charter. Place it before any implementation begins.
• Features in existing projects: Add the metrics section to the feature specification.
• Projects without a spec: Create at least the Impact Metrics section before starting development.

Retroactive application: Projects already in progress without defined metrics should add this section during the next development session. Do not block ongoing work, but make the gap visible in session handoff or progress documents.

Anti-Patterns (Blocked)

| Anti-Pattern | Why It Fails | Fix | |---|---|---| | "Improves user experience" (no number) | Immeasurable. Improves how much? For whom? | Define the metric: "Reduces task time by X%", "Increases satisfaction score from Y to Z" | | Metric without method | Theater. If you cannot measure it, it is not a metric. | Specify exact source, tool, and collection frequency. | | "Baseline: zero" when current state exists | Lazy. Measure the before. | Run a 1-week baseline before build and record it. | | Build without any metric defined | Waste. You cannot verify impact after launch. | Define metric + method + baseline. This is mandatory, not optional. | | Metric that depends on future data you cannot collect | Impossible to validate. | Ensure the metric is observable before you ship. |

Operational Procedure

1. At project kickoff or feature definition:

• Write the primary impact metric in plain language (1 sentence, a number).
• Identify where you will collect this data (API? Dashboard? Manual measurement?).
• Establish the current state (baseline) before you start building.

1. Before you write code:

• Review the metrics section with stakeholders or team leads. Everyone should agree on what "success" looks like.
• Verify the measurement method works (can you actually fetch this data?).

1. During development:

• Keep the metrics visible (in README, in project dashboard, or in your handoff notes).
• Adjust measurement method only if the original is impossible to implement. Document why.

1. After launch:

• Collect and publish the metric within the agreed timeframe.
• Compare against baseline or benchmark.
• Use the gap to validate or redirect the project.

When to Apply This Gate

Always trigger when:

• Starting a new project, product, or service.
• Defining a significant feature.
• Being asked "will this solve the problem?" without a measurable answer.
• Planning a refactor, optimization, or infrastructure change.
• Proposing a new tool, framework, or methodology for adoption.

Do not trigger for:

• Routine bug fixes with obvious local value (e.g., "this crashes on startup; the fix is stability").
• Internal tooling that only you use (document it anyway, but the gate is lighter).
• Pure refactoring of existing, working code (metrics apply to the behavior, not the shape).

Why This Matters

Projects without defined metrics fail silently: you ship, declare victory, and never know if the original problem was solved. Months later, you realize the metric that mattered was the one you forgot to measure.

Metrics also force clarity in communication. If you cannot agree on how to measure success, you do not actually agree on what you are building.

Example: Feature Impact Metrics

Feature: "Bulk export for reports"

| Item | Example | |---|---| | Metric | Reduce report export time from 3 hours (manual gathering + formatting) to 5 minutes (single bulk export). | | Method | Timestamp delta in job queue, sample 10 exports per week. If manual process was ~3 hours, measure the time before automation, measure the auto export time, report the delta. | | Baseline | 3 hours (median of 5 manual exports, measured 2026-06-01 to 2026-06-07). |

Applies to: all projects and teams. Use this gate for any project, any domain, any tech stack.