More marketing or better activation? Diagnose software signups that go nowhere

This is for consumer apps and self-serve software with starts but little evidence of useful completion. It owns failure before first value. If people get the result but will not pay, or complete an occasional job and leave, you have a different question. For the broader acquisition choice, return to the consumer-app guide.

Brian Balfour treats time to value as a product hypothesis and notes that successful products can sometimes have natural churn.[2] That is a reason to inspect the task and its cadence, not to adopt a universal activation time or retention benchmark. The trace below is an original diagnostic aid.

Give each event a plain-language meaning

These are working definitions for this worksheet. Your product may require different events; write them down before comparing counts. “Clicked generate” is a start. “Received and checked a usable quiz for the intended material” is a possible first-value definition. The definition must include usefulness, not merely an output existing.

Build the trace without collecting private inputs

Start with the exact promise a user saw, then record arrival, workflow start, required input, core action, and usable result. Include prerequisites normally omitted from a demo: file type, account permissions, source quality, hardware, or time available.

First inspect the path yourself with non-sensitive test data. Then, where appropriate and consented, observe a relevant person trying the task. Let them decide whether to participate and stop. Do not ask for a private resume, financial account, health record, client footage, or class document when a safe sample will answer the question.

Write what happened, not the diagnosis you prefer: “Could not locate a supported upload” is an observation. “Users are lazy” is not. If an event is uninstrumented, mark it unknown rather than treating a missing record as failure.

Keep competing explanations alive

Shapiro recommends descriptive explanations and investigating objections.[5] Apply that to the entry promise, but do not rewrite copy to conceal a missing capability. If the advertised result is unavailable, pause that promotion and assign a product owner.

Choose one repair and a recheck

Select the earliest observed meaningful obstacle, not automatically the earliest blank field. State who can fix it and what would count as a successful recheck. Keep the entry context and task stable enough to understand what changed.

Record relevant starters, useful completions, observation method, and missing information within the same defined period. Avoid mixing visits from one period with completions from another. A small consented walkthrough can reveal a specific failure; it cannot estimate how often all users encounter it. Do not declare an uplift from an anecdote.

Worked case A: the study tool needs material first

Illustrative only. Suppose a study app promises a quiz from course notes. Its happy-path demo uses a clean text document, but a new user arrives with a scanned handout. The hypothetical product accepts text, not scans.

Trace: promise → signup → source selection → unsupported input → no quiz. The observed obstacle is the missing supported input. Competing explanations include an unclear prerequisite and the wrong audience for the present product. The first verification task is to show the actual input requirement and ask whether the intended student can supply it legitimately.

A built-in sample could explain the output, if such a sample is actually available; it would not solve processing the student's own scan. Assign input-support decisions to product and wording to the page owner. Pause any “turn any course material into a quiz” promotion. A generated quiz must still be checked for usefulness and accuracy; output existence is not learning progress.

Worked case B: an editor gets through upload but not export

Illustrative only. Suppose an editing tool accepts an owned sample clip and produces a preview, but the export action fails in a supported browser. The promised job was a usable exported clip, not merely viewing a preview.

Trace: relevant visit → upload → preview → export error → no usable file. The initial evidence is one reproducible test, not a measured failure rate. The engineering owner should reproduce and repair it, then verify that a new user on the affected path can obtain and open the result. Check a supported alternative path to distinguish a general failure from a browser-specific one.

Do not replace the export promise with prettier footage or send more traffic into the broken path. If export works but people cannot find it, the next task changes to interface explanation. The trace separates those cases without inventing a conversion benchmark.

Countercase: a successful occasional task

A hypothetical resume helper may be used successfully for one application and then not needed again immediately. That is not the same as failing before useful output. Ask about the next legitimate occasion before imposing daily-return expectations. This is an editorial application of the natural-churn distinction, not evidence about a particular resume product.[2]

Download and decide

Download the promise-to-first-value trace (CSV), or use the blank plain-text version. Copy a blank row per blockage, including an alternative explanation, verification task, owner, and stop-promotion condition. Use unknowns honestly.

If starts fail, do the repair before purchasing more production. Contengine is not analytics, onboarding repair, or output-quality verification. If the promise itself is vague, use software differentiation. If the audience never reaches a relevant start, use views versus user intent. Only a working, accurately explained task should move to a repeatable demo workflow.