Pilot users signed up but stopped coming back: read the drop off

Start with a list of everyone who signed up, record the last step each person reached beside their name, and sort so the earliest drop-offs sit at the top. Sign-up, email check, first action, second visit.

That step is where the story ends. Ten who never finished the profile form are a different problem from ten who finished it and never returned, and an average across all twenty hides that difference. So read the groups.

Without step events you are guessing. Add them to the sign-up flow before drawing any other conclusion, then wait for the next batch of pilot users to pass through each screen.

Confusion means the user wanted the value but could not find it, while missing value means they found it and judged it unworthy of a second visit. Wrong audience means a bad invite.

Confusion shows long pauses, repeated taps and back-and-forth between two screens, whereas missing value shows a clean first run followed by silence in the days after. Wrong audience shows up as sign-ups from channels that have nothing to do with the problem you solve, such as a giveaway post or a friend’s group chat.

Label every lost user with one bucket. Note the evidence beside each label, such as the screen where the pause happened or the invite link the person arrived from.

Numbers say where. They rarely say why. Pick eight to ten lost users, ask each for ten minutes by phone or voice note, and say clearly that you are testing the product rather than them.

They will speak freely. Ask what they were trying to do, what they expected to see and what they did instead when the screen did not match, in their own words. Avoid asking whether they liked it.

People are polite, so a yes tells you little, and the user who liked it but never returned is exactly the case you need to explain. An in-product prompt on exit, or after a day of silence, can add short replies to the interviews, provided it asks only one question. Read every answer yourself.

For confusion, shorten the path by removing a screen, renaming a button or adding a worked example to the empty state of the first screen. For missing value, recheck the assumption.

Check whether the action you offer really solves the problem you named before the build began, because a pilot cannot rescue a wrong assumption. For wrong audience, change where invitations go. A pilot filled by curious friends will always look weak, so invite the people who have the problem through the groups or lists where they already gather.

Change one thing at a time. Two fixes at once leave you unable to say which one worked, and the review window gets wasted on an argument instead of a count.

The urge after weak retention is to add a reminder, a badge or a second module, yet features help only when the cause was a missing feature. That is rarer than it feels.

Run the fix for one review window, then count again at the same step, and keep going only if the number moves towards more returning users. If not, move to the next bucket.

Mixed steps and weeks prove nothing. Write the finding in two lines for your build team and investors: what the data showed, what you changed and what you will test next.