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

This is for consumer apps and self-serve software that get starts but show little sign of useful completion. It covers failure before first value. If people get the result but will not pay, or finish a one-time job and leave, you have a different question. For the broader acquisition choice, go back 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 look closely at the task and how often it comes up. It is not a reason to adopt one 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 need different events, so write them down before you compare counts. "Clicked generate" is a start. "Received and checked a usable quiz for the intended material" is one possible definition of first value. The definition has to include usefulness, not just that an output exists.

Build the trace without collecting private inputs

Start with the exact promise a user saw. Then record the arrival, the workflow start, the required input, the core action and the usable result. Include the prerequisites a demo usually skips: file type, account permissions, source quality, hardware, or the time needed.

First, walk the path yourself with non-sensitive test data. Then, where it is appropriate and the person agrees, watch a relevant person try the task. Let them decide whether to take part and when to stop. Do not ask for a private resume, a financial account, a health record, client footage or a class document when a safe sample will answer the question.

Write down what happened, not the diagnosis you prefer. "Could not find a supported upload" is an observation. "Users are lazy" is not. If an event is not instrumented, mark it unknown. A missing record is not proof of failure.

Keep competing explanations alive

Julian Shapiro recommends descriptive explanations and investigating objections.[5] Apply that to the promise on your entry page. But do not rewrite copy to hide a missing capability. If the advertised result is not available, pause that promotion and give it to a product owner.

Choose one repair and a recheck

Pick the earliest meaningful obstacle you observed. That is not automatically the earliest empty form field. Say who can fix it and what a successful recheck would look like. Keep the entry context and the task steady enough that you can tell what changed.

In the same fixed period, record the relevant starters, the useful completions, how you observed them, and what you could not see. Do not mix visits from one period with completions from another. A small walkthrough with consenting people can show you a specific failure. It cannot tell you how often all users hit it. Do not call an improvement from a single anecdote.

Worked case A: the study tool needs material first

Illustrative only. 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 obstacle you observed is the missing supported input. Competing explanations include an unclear prerequisite, and a current product that is wrong for this audience. The first verification task is to show the real input requirement and ask whether the student you want can legitimately supply it.

A built-in sample could explain the output, if one really exists. It would not solve processing the student's own scan. Give input-support decisions to product, and the wording to the page owner. Pause any "turn any course material into a quiz" promotion. You still need to check a generated quiz for usefulness and accuracy, because an output existing is not the same as learning progress.

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

Illustrative only. An editing tool accepts the user's own sample clip and makes a preview, but the export action fails in a supported browser. The promised job was a usable exported clip, not just a preview.

Trace: relevant visit, upload, preview, export error, no usable file. The first evidence is one test you can repeat, not a measured failure rate. The engineering owner should reproduce and fix it, then check that a new user on the affected path can get and open the result. Test a supported alternative path, such as a different browser, to tell a general failure from a browser-specific one.

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

Countercase: a successful occasional task

A hypothetical resume helper may be used well for one job application and then not needed again for months. That is not the same as failing before useful output. Ask when the next legitimate occasion would be before you expect daily returns. This is our own editorial use of the natural-churn idea, not evidence about any 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 for each blockage, and include a competing explanation, a verification task, an owner, and a condition for stopping the promotion. Mark what you do not know.

If starts fail, do the repair before you pay for more content. LaunchMax fits at the other end of the problem. Once a task works and you can explain it accurately, paste your app store or landing page link. LaunchMax makes both screen demos that show your app at work and UGC-style videos where a realistic AI creator talks about it on camera, and it posts to your own accounts after you approve each one. It is not analytics, onboarding repair or an output-quality check. If the promise itself is vague, use software differentiation. If the audience never reaches a relevant start, use views versus user intent. Move only a working, accurately explained task into a repeatable demo workflow.