Pre-PMF Metrics Tree

Begin With the Decision, Not the Dashboard

A metrics tree is a measurement argument. It says which customer you are trying to serve, what observable behavior would show that the product created value, and which weaker signals can explain why that behavior did or did not happen.

Build one before choosing dashboard software, naming analytics events, or setting targets. Use it when a product has enough real use to produce evidence but not enough repeatable pull to make aggregate growth metrics trustworthy. At this stage, the tree should help answer questions such as:

• Should the founder keep pursuing this segment and problem?
• Is the constraint acquisition, first value, repeated value, willingness to pay, product reliability, or founder labor?
• Which product or engineering change deserves the next bounded investment?
• What evidence would narrow, pause, or end the current direction?

The finished tree should be small. If it cannot be reviewed account by account in a weekly session, it is probably hiding uncertainty beneath measurement work.

Name the Root

Write the root as one sentence:

For [specific segment], when [problem trigger] occurs, the product creates value when [observable customer behavior or outcome] happens.

The last blank is the primary value behavior. Choose an event near the far end of the customer’s promise, not the easiest event inside the product to count. A workspace created, file uploaded, or report generated may be useful diagnostic evidence. A client-ready report sent before its deadline is closer to delivered value.

The behavior must be observable. State where the evidence comes from: a durable product event, database state, payment record, completed artifact, support record, or a founder-maintained account log. Manual observation is acceptable during search. An undefined event is not.

If two segments complete the same product action for different reasons, write two roots. Combining them produces an average without a coherent customer story.

Grow Four Branches

Each branch asks a different question about the root. Define the branch in ordinary language before attaching a number.

Can the right account reach value?

Activation is the first completed primary value behavior, or the nearest honest precursor when the outcome occurs outside the product. Record both the qualified starting population and the accounts that reached first value. Add time-to-value when delay can cause the customer to miss the moment of need.

Keep founder assistance visible. If activation requires data repair, onboarding calls, or manual production, split assisted and unassisted accounts. The assisted result may prove demand while exposing a product or operating constraint.

Useful diagnostics answer a live question about the path: where suitable accounts stop, which failure blocks them, or whether they distrust the output. Signup count has no independent claim to the tree.

Does value repeat when the problem returns?

Retention is repetition of the primary value behavior at the natural frequency of the customer’s job. Define the next eligible opportunity before calculating a rate. Weekly reporting should be judged at the next weekly reporting cycle; annual compliance work should not be called unretained after seven quiet days.

At small sample sizes, list the accounts. For each one, record whether the problem recurred, whether value happened again, and whether a reminder or founder rescue was required. A percentage without these histories can hide a promising segment as easily as it can flatter a weak product.

Does money follow repeatable value?

Revenue quality asks more than whether somebody paid. Record the payment behavior appropriate to the stage—deposit, paid pilot, renewal, or expansion—beside discounts, custom commitments, support work, and delivery time.

A payment can prove that a problem is costly while failing to prove that the current product is viable for one person to deliver. Founder minutes per value event often belong on this branch. So do refund risk, infrastructure cost, or manual review when one of them can reverse the decision.

What explains the behavior?

Qualitative pull and operating evidence help interpret the other branches. Attach customer language to an account and a behavior: an urgent request to repair the core workflow before its next deadline, a colleague invited to own the job, a complaint when repeated use is blocked, or a return despite missing secondary features.

Support and reliability signals belong here when they explain a failure to activate or retain. Do not promote vivid praise into a substitute for repeated behavior. Its job is to suggest causes worth distinguishing.

Copy the Tree

Use this record as a working document. Replace every prompt with a definition that another person could apply to the same account history and reach the same count.

PRE-PMF METRICS TREE

ROOT
Target segment:
Problem trigger and natural frequency:
Primary value behavior:
Evidence source:
Current decision this tree must inform:

FIRST VALUE — can the right account reach value?
Qualified starting population:
Activation event:
Activation numerator / denominator / window:
Time-to-value definition:
Assisted and unassisted split:
Current diagnostic question:
Smallest evidence needed to answer it:
Decision if weak or strong:

REPEATED VALUE — does value recur?
Next eligible opportunity:
Retained behavior:
Retention numerator / denominator / cohort:
Prompting or founder rescue to record:
Current diagnostic question:
Decision if weak or strong:

REVENUE QUALITY — does money follow viable delivery?
Payment behavior that counts:
Discounts or custom commitments to expose:
Founder work per value event:
Other cost, trust, or support boundary:
Decision if weak or strong:

EXPLANATORY EVIDENCE — why might the pattern exist?
Behavior-backed customer language:
Core-workflow support or reliability signal:
Referral, invitation, churn, or expansion behavior:
Explanation being tested:

WEEKLY READING
Accounts that reached first value:
Accounts eligible to repeat value:
Accounts that repeated value:
Accounts that paid, renewed, or expanded:
Accounts whose result depended on founder work:
Strongest disconfirming account:
Decision for the next cycle:
Metric to add, demote, or remove:

Do not fill every line because it exists. If payment is not yet being tested, say so and omit its diagnostics. If referral cannot affect the current decision, leave it outside the tree.

A Worked Tree: Weekly Reports for Small Agencies

Suppose a product turns project notes into weekly client reports. Its launch numbers include visits, signups, reports generated, and paid pilots. The founder suspects that small agencies with recurring client reporting are the best segment.

The root might read:

For small agencies that owe clients a weekly project update, value occurs when the agency sends a client-ready report by its reporting deadline.

The tree can now be read as a causal story:

small agencies with a weekly reporting obligation
└── client-ready report sent by the deadline
    ├── first value
    │   ├── qualified agencies that begin onboarding
    │   ├── first report sent
    │   ├── time from import to send
    │   └── import failure, output distrust, or founder repair
    ├── repeated value
    │   ├── agencies due to report again
    │   ├── next report sent on time
    │   └── reminder or founder rescue required
    ├── revenue quality
    │   ├── paid pilot or renewal after repeated value
    │   ├── discount or custom promise
    │   └── founder review minutes per sent report
    └── explanatory evidence
        ├── export failure blocks a real deadline
        ├── client-delivery colleague invited
        └── request deepens or distracts from weekly reporting

Visits and total signups remain available as context. They are not branches of value unless the current decision concerns the ability to reach qualified agencies. Reports generated help locate a gap between production and customer use; they do not replace reports sent.

The numbers should end in a decision. If qualified agencies begin import but do not send, inspect setup and trust before buying more traffic. If they send once but do not return at the next reporting cycle, investigate recurrence and output usefulness. If they repeat only after extensive founder editing, narrow the promise or test one specific reduction in delivery work. If they repeat, pay, and depend on reliable export, that path has earned engineering priority over unrelated features.

Read It Account by Account

Review the tree at the cadence of the customer problem, weekly unless the natural cycle requires longer. Freeze the definitions for the observation window. Then begin with the account histories, not the chart.

1. Identify which accounts truly matched the segment and were eligible for each step.
2. Mark first value, the next natural opportunity, repeated value, payment, and founder work.
3. Read failures and successes together. Look for the account that most seriously challenges the current explanation.
4. Choose one decision or investigation for the next cycle.
5. Add a metric only when the missing evidence prevents that decision. Remove one when it no longer carries a question.

Do not set universal healthy thresholds from a tiny sample. Write a boundary appropriate to the current commitment: how many qualified accounts, which behavior, what time window, and what work the result may authorize. A sample can be too small to prove a market and still be large enough to refuse another month of feature work.

Prune the Tree

A measure earns its place when it either proves customer value or explains a break in activation, retention, revenue quality, or delivery. Test it with a sentence:

If this changes for [segment], I will decide whether to [action or bounded investigation].

If the sentence cannot be completed, demote the measure to context or remove it. If a branch contains several metrics that would all cause the same action, keep the one closest to the customer outcome and use the others only during diagnosis.

The tree is ready when its root is observable, its retention window matches the real job, founder work is visible, and every active branch can change a decision. Build the event plan and dashboard from that argument. Do not let the instrumentation redefine what value means.