Qualitative PMF Signal Log

Keep the Words Attached to What Happened

A praise archive is not a signal log. “Love this” may begin a useful conversation, but it does not show that the product has entered anyone’s work. An unembellished support message can carry more evidence: the scheduled export failed, a meeting starts in an hour, and the customer needs the output restored.

Use this log to preserve that difference. Each record joins exact customer language to the behavior before and after it, the recurring job at stake, and the founder work hidden inside delivery. Review the records as a pattern. The artifact is complete only when that pattern changes a decision or names the next evidence required.

Bound the Review First

Begin with a question and an evidence window. Without them, the log grows into a scrapbook whose happiest entries are easiest to find.

QUALITATIVE PMF REVIEW
Review date:
Decision this review must inform:
Target segment:
Core job or value moment:
Natural value cycle:
Evidence window:
Sources included:
Behavioral and payment data available:
Maximum founder effort allowed per active account:
Next review date:

Choose sources close to customer action: support messages, sales threads, interviews, cancellation notes, referrals, renewal decisions, product events, and payment records. A founder’s recollection is a pointer to evidence, not the evidence itself.

Make One Record per Meaningful Event

Create a record when a customer says or does something that may reveal value, dependency, commitment, spread, rejection, or founder burden. Preserve the raw observation before interpreting it.

QUALITATIVE SIGNAL RECORD
Record ID:
Date and source link:
Account and declared segment:
Speaker, role, and relationship to the job:

Exact customer words:
Prior behavior:
Next behavior:
Core job, cadence, and deadline:
Existing alternative or workaround:

Product event or usage evidence:
Payment, renewal, or expansion context:
Referral or invited-user outcome:
Support and manual founder work required:

Comparable evidence:
Counterevidence:
What this record can support:
What it cannot support yet:
Next observation or decision:

“Prior behavior” and “next behavior” prevent a feature request from acquiring weight it has not earned. A request for an integration means something different after weekly retained use than it does after a demo followed by silence. Record both cases; do not force them into the same conclusion.

Use the smallest amount of customer material needed for the decision. Omit secrets and unnecessary personal information, restrict access to identifiable records, and link to the protected source instead of copying an entire private conversation.

Label the Evidence, Not the Customer’s Enthusiasm

Give each record one primary signal type after the behavior is attached:

• Value: the customer completed the core job or used its output.
• Return: the customer came back across a natural value cycle without a rescue message.
• Dependency: failure threatened work, a deadline, or another person’s decision.
• Commitment: the customer paid, renewed, accepted rollout work, or replaced an old process.
• Spread: a colleague activated, a referred account engaged, or use expanded into another workflow.
• Rejection: the customer abandoned the product, retained the alternative, or declined the next commitment.
• Load: use continued only because the founder supplied recurring manual judgment, cleanup, support, or custom work.

A single event may contain several types. Choose the one that matters to the current review and preserve the rest in the record. Do not turn the labels into a score. Five compliments do not cancel one churn, and one urgent account does not prove a repeatable market.

Read by Segment, Job, and Cycle

At the review date, group records by the segment and recurring job declared in the evidence—not by whichever grouping produces the most flattering story. Count accounts and value cycles separately. Ten messages from one account are still one account, though repetition across ten weekly cycles may establish a different kind of dependency.

PATTERN REVIEW
Segment and recurring job:
Records reviewed:
Distinct accounts:
Natural value cycles observed:

Repeated value, return, or dependency behavior:
Payment, renewal, replacement, or spread behavior:
Rejection and other counterevidence:
Founder minutes and manual steps per active account:
Behavior visible in product data:
Behavior known only from customer report:

Narrowest claim the evidence supports:
Contradiction preventing a stronger claim:
One next action or test:
Result expected by the next value cycle:
Result that would reject this reading:
What will not be built, sold, or scaled yet:

Suppose six trial accounts used a renewal-summary product. Three created one summary and disappeared. Two returned before a weekly account review; one reported a missed scheduled run and invited a regional lead, while the other accepted a paid pilot and asked for source links in its export. The sixth returned only because the founder cleaned its notes by hand every week.

The defensible reading is narrow: teams with a weekly renewal review are showing repeated pull toward a reliable, traceable summary. The three vanished accounts contradict broad demand. The manually rescued account reveals real pain but weak delivery economics. The next work is to test reliable scheduled delivery and source traceability while measuring setup and cleanup time—not to build every integration named during a demo.

Let the Pattern Constrain the Decision

Use the weakest honest action that can resolve the uncertainty.

If the log contains language without consequential behavior, interview or observe; do not expand scope. If comparable target customers return across their natural cycle, protect the path that delivers that value and test it with more of the same segment. If payment, renewal, replacement, or spread joins retained use, test whether the pattern survives without extraordinary founder persuasion. If pull depends on recurring private rescue work, narrow the offer, price the service honestly, automate a bounded step, or refuse the account.

Finish with one sentence:

For [segment], [behavior across accounts or cycles] shows that [workflow] is
becoming dependent on the product. This justifies [next action], while
[counterevidence or founder-load limit] prevents [larger claim or premature
investment].

If the sentence needs praise where behavior should be, the log has done its job: it has shown the founder what is not yet known.