PMF Diagnosis

The Backlog Is Not a Diagnosis

Consider a modeled client-reporting product that has finally found something that looks like pull. Small agencies use it before weekly client meetings. Several have returned without reminders. Some have paid for pilots. When a report fails, support messages arrive before the meeting starts.

The backlog also looks promising. Customers have asked for team permissions, more integrations, faster imports, custom templates, an approval flow, and a polished dashboard. Any one of those requests could occupy the next two weeks.

Which one should the founder build?

The customer requests do not answer that question. Neither does the dashboard. The founder has evidence that some people care, but not yet a clear account of what prevents that care from becoming a repeatable, sustainable business.

That ambiguity is dangerous because construction feels like progress. A feature, refactor, pricing page, or onboarding tour gives uncertainty a visible shape. If it attacks the wrong constraint, however, it merely converts confusion into more software to operate, support, explain, and later unwind.

Before choosing from the backlog, find where the evidence first breaks.

Diagnose One Segment at a Time

An aggregate funnel can make a good product look mediocre and a weak product look busy. A launch may mix freelancers, students, consultants, enterprise evaluators, and the exact customer the product was meant to serve. Their behavior should not be averaged into one diagnosis.

Return to the client-reporting product. Its first launch produced 1,200 visits, 160 signups, 50 connected accounts, 18 sent reports, 12 returned the following week, and seven paid pilots. Those totals suggest many stories: weak positioning, poor onboarding, a narrow use case, pricing friction, or simply low intent from launch traffic.

The segment split is more revealing.

Freelancers sign up quickly and connect a project tool, but few send a second report. Their reporting pain is real and occasional. Small agencies activate more slowly; once they send a report, they tend to send another before the next weekly client meeting, and several accept paid pilots. Multi-office agencies have budget, but each asks for custom roles, templates, and founder-led setup before a pilot can begin.

Now the broad claim—“conversion is weak”—has lost its usefulness. The founder has three different paths:

• freelancers reach value but do not return at a natural weekly cadence;
• small agencies return and pay after a slow first setup;
• larger agencies show buying interest but demand an operating model the founder cannot yet sustain.

The next move should follow the second path. It contains the strongest combination of recurring work, retention, payment, and manageable scope. Improving the average would let two weaker segments outvote it.

Find the First Broken Link

For the chosen segment, walk forward in the order a customer must experience the product. Stop at the first link that evidence cannot support.

1. Reach: Can the founder get in front of qualified customers at all?
2. Comprehension: Do those customers recognize the problem and understand the promise?
3. Commitment: Do they take the meaningful first step—signup, booked call, data connection, or trial—without extraordinary persuasion?
4. Activation: Do they reach the first result that demonstrates value?
5. Retention: Do they return when the underlying job naturally recurs?
6. Payment: Does the appropriate buyer make a real financial commitment?
7. Expansion: Does use deepen through more work, users, volume, or responsibility where expansion belongs in the product model?
8. Repeatable acquisition: Can the founder find another qualified customer without depending on a lucky launch or heroic sale?
9. Sustainable delivery: Can the product serve that demand without turning the founder into a private integration, support, or operations team?

The order prevents convenient diagnoses. If qualified visitors misunderstand the promise, retention is not yet the question. If users never reach first value, their disappearance does not prove the job lacks recurrence. If a founder rescues every account by hand, customer love proves pain and value but not a sustainable product.

Expansion also needs judgment. A narrow product can be healthy without steadily adding seats or modules. Ask whether the customer’s use should deepen under the intended business model, not whether every account can be made larger.

For small agencies, the evidence survives reach, comprehension, and commitment. It also survives retention and early payment once a report has been sent. It weakens at activation: eight of 20 connected small-agency accounts produce a first client-ready report, setup takes as long as two days, and support notes repeatedly mention manual field mapping.

The first broken link is therefore not “the product needs more features.” It is “target agencies struggle to reach first value.”

A Stage Is Not Yet a Cause

Finding the weak stage narrows the investigation; it does not finish it. The same symptom can have several causes.

Low activation might mean setup is too long. It might also mean the founder recruited curious but bad-fit users, the product promise described the wrong result, customers do not have usable source data, or the first report is not valuable enough to justify finishing setup. Building an import wizard before distinguishing those explanations would be another guess.

Look for evidence close to the failed transition:

• event traces showing the last completed step and elapsed time;
• account labels that preserve segment and acquisition source;
• session observation of target users attempting the task;
• support messages tied to the account and workflow;
• interviews with people who stopped and people who continued;
• the founder’s own manual interventions, including time spent and judgment supplied.

For the agency product, events show repeated abandonment during field mapping. Session observation shows that agency owners understand why the first report matters but cannot predict how source fields will appear. Support messages from accounts that later retain ask for help with that same step. Meanwhile, agencies given a founder-made mapping template reach the first report in under an hour.

That evidence makes setup friction a plausible cause. It does not prove that every agency needs a general integration system. The narrow fact is enough: a bounded mapping problem blocks the segment that later retains.

Sometimes the honest result of diagnosis is that the product cannot yet be seen. If accounts are not labeled by segment, first value is not recorded, support notes cannot be connected to behavior, or founder rescues are invisible, the next work is measurement. That may require a handful of events and a weekly account review, not a large analytics platform. The standard is enough visibility to reject a convenient story.

Try to Disprove the Attractive Explanation

Founders naturally prefer causes that match work they already want to do. An engineer sees missing product capability. A strong seller sees a messaging problem. A founder tired of support sees bad customers. Diagnosis improves when it records a competing explanation before choosing an intervention.

In this case, “manual mapping blocks activation” competes with “launch visitors lack a recurring reporting job.” The segment split addresses part of that doubt: small agencies that complete mapping return and pay, while freelancers who complete it often do not return. Setup is therefore a credible constraint for small agencies, but fixing it is unlikely to rescue freelancers. The intervention and its expected result must remain segment-specific.

Other patterns require the same care:

• Traffic without qualified conversations points toward reach or channel fit, not product polish.
• Qualified visitors who describe the promise incorrectly point toward positioning or comprehension.
• Users who reach value but vanish at the natural recurrence point challenge the importance, frequency, or segment fit of the job.
• Enthusiastic sales calls that never close may reveal the wrong buyer, weak urgency, missing proof, or a procurement burden larger than the product can carry.
• Paid pilots that never become rollout may prove budget and curiosity without proving adoption.
• Strong retention in a tiny reachable segment may be real fit inside an opportunity too small for the founder’s aims.
• Demand accompanied by bespoke setup and constant rescue may reveal a service business, a qualification problem, or product work that has not yet been made repeatable.

These are not labels to choose by instinct. Each is a prompt to inspect the transition where claimed intent should become costly behavior.

Write the Diagnostic Note

Keep the diagnosis small enough to challenge. One page is usually more useful than a dashboard review full of possible stories.

PMF DIAGNOSTIC NOTE

Target segment:
Observed symptom:
First weak stage:
Evidence before the break:
Evidence at the break:
Likely cause:
Competing explanation:
Missing evidence:
Founder work currently required:

Next intervention:
Expected behavior change:
Observation window:
Decision rule:

The agency example can now be stated without hiding inside a feature request:

For small agencies with weekly client-reporting work, activation fails during source-field mapping. Agencies that complete a first report tend to return the following week and several pay for pilots, but repeated abandonment, support notes, and observed sessions show that mapping delays first value. Provide one guided mapping template and defaults for this segment, then judge whether more qualified accounts send a first report within one hour and return at the next weekly cycle. If activation improves without increasing founder setup time, continue; if it does not, revisit data readiness and the value of the report itself.

This note names the segment, weak transition, evidence, cause, intervention, observation window, and a result that can contradict the diagnosis. It also protects the product from the larger requested solution. The founder does not need an integration platform to test whether one guided path removes the constraint.

Let the Diagnosis Choose the Verb

A useful diagnosis ends with a decision, not an indefinitely growing backlog.

Iterate when the customer and problem hold up but a bounded step blocks value. Narrow when one segment or recurring job shows stronger pull than the broad audience. Harden when people already depend on the product and failures threaten trust. Simplify when demand is real but custom scope or manual rescue makes delivery uneconomic. Pivot when evidence rejects the current customer, problem, or promise while pointing toward a different one. Stop when the opportunity cannot justify another serious investment of time, money, or credibility.

The verbs can combine over time, but one should govern the next experiment. For the agency product, narrow and iterate are both defensible; narrowing establishes which customer matters, and the immediate experiment iterates on that customer’s activation path. Building team permissions for multi-office agencies would move in the opposite direction.

Stopping deserves the same evidentiary discipline as continuing. Weak retention, weak payment, and hard reachability across serious tests can make stopping a sound allocation decision. One poor launch cannot. Nor should sunk engineering effort keep a product alive after its premise has failed.

Build Only What the Experiment Needs

The next experiment is deliberately smaller than the roadmap item it may resemble.

“Improve onboarding” leaves the founder free to redesign every screen. “Reduce small-agency mapping time so a qualified account can send its first report within one hour” constrains the work. A template, better defaults, one import preview, or concierge observation may be enough. The founder can choose the smallest change that exposes whether the diagnosis is right.

Before beginning, make sure the note can answer four questions in plain language:

• Which segment and transition are being diagnosed?
• What evidence supports this cause over a plausible alternative?
• What behavior should change, and by when?
• What result will cause the founder to continue, narrow, harden, simplify, pivot, or stop?

If one answer is missing, collect evidence before adding surface area. If all four are clear, construction has a job: make the disputed transition observable and easier, then let customer behavior answer.

There is one final complication. The right experiment may depend on a brittle import path, unreliable job, confused billing state, or founder-only procedure. At that point diagnosis has done its work, but the product may not be durable enough to carry the test. The next question is which technical debt now obstructs learning, trust, or sustainable delivery—and which untidy code can safely wait.