Evaluate · Checklist · Product Plan · Transparency · PTOS

One-Page Evaluation Sheet: The Mandatory Artifact for Honest Evaluation

How to create a single-page 'Evaluation Sheet'—a mandatory Evaluate artifact that captures the goal, metrics, thresholds, facts, guardrails, and the decision made.

One-Page Evaluation Sheet: The Mandatory Artifact for Honest Evaluation

The Evaluate phase is the moment of truth for any product change. But very often, it turns into a chaotic discussion where opinions and emotions drown out data. To avoid this, PTOS uses a simple yet powerful tool—the "One-Page Evaluation Sheet".

If the results of your launch cannot fit on one page, you are probably not evaluating, but justifying.

This artifact serves as a single source of truth that forces the team to be honest with itself and make decisions based on facts, not conjecture.

Why is a "One-Page Evaluation Sheet" Needed?

  1. Discipline: It forces the team to define upfront what success looks like and how it will be measured.
  2. Transparency: The entire team—from developers to stakeholders—sees the same picture, without distortions or "fine print."
  3. Objectivity: By defining criteria beforehand, you protect yourself from "fitting" results to a desired outcome.

Structure of the "One-Page Evaluation Sheet"

Here is a template that can be used to evaluate any launch—from a small feature to a new product.


1. Goal of the Change: What problem were we solving and what behavior did we want to change?

  • Example: "We wanted to increase the percentage of users successfully creating their first report, as we noticed a high drop-off at this step."

2. Target Metric (Outcome Metric): What single metric best reflects the desired change in behavior?

  • Example: "Percentage of new users who created their first report within 24 hours of registration."

3. Measurement Window: Over what period are we evaluating the result?

  • Example: "14 days after 100% rollout of the change."

4. Thresholds (Success / Fail / Grey): What metric values will indicate success, failure, or a "grey area"? (To be defined before launch)

  • Example:
    • Success: Metric growth of 5 percentage points or more.
    • Fail: Metric growth less than 1 percentage point or a decrease.
    • Grey: Metric growth between 1 and 5 percentage points (signal exists, but weak, requires diagnosis).

5. Facts (Data + Observations): What did we actually observe?

  • Example:
    • Data: "Target metric grew by 7 percentage points (from 15% to 22%)."
    • Observations: "From support tickets, we see that questions regarding report creation decreased by 30%."

6. Guardrails (Protective Metrics): What should we not have broken, and what is the actual state of it?

  • Example:
    • Guardrail: "Average report creation time." Fact: No change.
    • Guardrail: "Number of errors during report creation." Fact: Decreased by 15%.

7. Decision: What do we do next: Scale, Iterate, Rollback, or Kill?

  • Example: "Decision: Scale. The change is deemed successful. We are integrating it into the main product flow and moving on to the next hypothesis for improving the report editor."

How Does This Work in Practice?

  • Before Launch: Points 1, 2, 3, 4, and 6 (only names of guardrail metrics) are filled out. This document becomes part of the Launch Brief.
  • After Launch: Within the defined "measurement window" (point 3), the team collects data and fills out points 5 and 6 (actual values).
  • At the Evaluate Session: The team reviews the sheet and makes a decision (point 7) based on the predefined thresholds. No arguments, no "I think." Only facts and the decision made based on them.

The "One-Page Evaluation Sheet" is not bureaucracy. It is a tool for mental hygiene that helps teams learn quickly, make strong decisions, and build products that truly work.