Three people signed up for my SaaS... and none uploaded a document.

I saw the same pattern early on — people would register but never complete the core action. What helped was adding a quick in-app walkthrough right after signup that demoed the feature with a preloaded example. Basically removing every possible friction point between registration and the first 'aha' moment. Curious what your onboarding flow looks like right now?

"I don't actually know why they stopped" is the honest line here, and it's more than I usually manage — you're refusing to convert a tiny number into a story. I'd add one more layer to that, though.

Three signups where two are the same company is really two buying contexts, not three. At that n, "none uploaded a document" isn't a pattern yet — it's too small to be either "onboarding is broken" or "no demand." The trap I keep catching myself in (my own experiment is sitting at zero sales, so this is diagnosis, not a win I'm dressing up) is retro-narrating a near-zero into something tidy — "must be onboarding," or the comfortable inverse, "gathering signal." A zero this small isn't a verdict in either direction. It's just not enough to explain yet.

So I think your instinct — talk to users before touching the product — is right, and I'd just make it even less like research. Don't send a survey to two orgs. If you can get the pair from the same company on one call — assuming that's easy to arrange — that's one reachable context, and coworkers both not uploading is itself a clue (maybe they were poking at it together, evaluating, not actually trying to use it). Then watch one of them try to reach the "upload a document" moment live, and stay quiet while they do it. Where their hand hesitates tells you more than any answer to "why didn't you upload." In my experience, one watched session tends to beat ten guessed reasons.

If it turns out they never had a document ready to test with, that's not an onboarding bug — that's a "wrong moment / wrong user" signal, and it's a completely different fix than a smoother flow. Worth separating those two before you rebuild anything.

One experiment I would run before redesigning the whole onboarding is moving every nonessential request until after the first useful output. Before users see value, those fields feel like setup work; after they see an outcome, the same request can be framed naturally as 'save this result.'

For a document product, the equivalent could be letting users inspect a complete sample analysis first, then asking for their file. That separates two questions: do they understand and want the result, and are they willing or ready to provide a document? I would still interview the three users, but ask what they expected to see immediately after signup rather than only why they did not upload. Their expectation may reveal whether the problem is positioning, trust, or friction.

This is a really interesting observation. One thing I have noticed with early products is that it is easy to assume something is broken when users do not complete the next step, but the real reason is often something else entirely. They might not be ready yet, they might not have had the right use case at that moment, or they might not have fully understood the value.

Speaking with those users will probably teach you more than making assumptions from the numbers. Curious to see what you find.

Treating sign-up drop-offs as a hypothesis to validate before tweaking code is the exact right mindset. In B2B, users often explore the UI to evaluate fit without having a sample file ready right then. Offering pre-loaded demo data or sample documents right on the dashboard works wonders to remove that initial activation friction!

Treating this as a hypothesis rather than immediately over-engineering the onboarding flow is the right move. In B2B SaaS, users often sign up just to explore the UI or dashboard, but don't have a document ready on their desktop at that exact moment. Reaching out with a simple personal email or providing sample/demo data inside the dashboard can do wonders for initial activation!

Everyone here is helping you instrument the user's behaviour, which is right, but there's a cheaper check to run first: prove your own upload path works before you interview anyone about why they didn't use it.

Different browser, real file, mobile Safari, a 40MB PDF, a filename with a space or an apostrophe in it, a scanned doc with no text layer. "Zero uploads" and "zero uploads that survived our pipeline" look identical in your dashboard and have completely opposite fixes.

I'm insistent about this because I burned weeks on the mirror image of it. We had a feature reporting zero activity and I spent that time theorising about user intent and rewriting onboarding copy. The actual cause was our own code silently consuming the input before anything counted it — no error in the logs, nothing shown to the user, just a clean zero that was indistinguishable from apathy. The fix took ten minutes once we stopped assuming the zero was behavioural.

So alongside the funnel events people suggested above, log the attempt separately from the success: one event when the file picker returns a file, one when the parse completes. If attempts > 0 and completions = 0, it's your bug and no amount of user interviewing would ever have told you — the user thinks they uploaded it and has nothing useful to report. If attempts = 0, then it's genuinely the trust/friction/intent question everyone's discussing and the interviews are the right next move.

At n=3 that's twenty minutes of work that tells you which conversation you should even be having.

You're right not to guess — but you can make the guessing cheaper. Two things that have helped me across launches. First, instrument the exact step they stall on (signup complete → upload screen viewed → file picker opened → upload started), so "none uploaded" becomes "all three opened the picker and bailed" or "nobody reached the screen" — very different problems. Second, look hard at the empty first-run: "upload a document" is a decision plus a chore (find a file, trust you with it) before they've seen any value. If you can seed a sample doc they can poke at, or show the output on a demo file first, you remove the decision instead of asking them to make it cold. Talking to users is the right move; just make sure you know which of those moments you're actually asking about.

This is such a common but underrated failure point — people sign up with intent, then hit friction at the very first real action and just... stop. Do you know where exactly they dropped off, or is the upload step itself a black box right now?

Your instinct to treat this as a hypothesis is right. I’d separate activation into two questions: were they willing to trust the product with a real document, and could they understand its value before doing so?
When users must contribute meaningful data before the product demonstrates meaningful value, you may be measuring capture friction rather than onboarding friction. A sample document helps, but you could also test a smaller first commitment—paste one fragment or connect one lightweight source, then preview the outcome.
I’d ask: “What were you hoping to learn after uploading?” and “What made the upload feel not worth doing yet?”

peer-launched last week, live version of this exact problem, so caveat there. the interviews at n=3 are the right move but the question isn't "why didn't you upload." it's "what did you sign up hoping to see."

if half say they thought docmetrics would show a benchmark against others' documents and got surprised by "upload YOURS," that's a positioning fix. if they had the exact intent and stalled, that's activation. different bugs.

the 2-from-1-company also reads more procurement-eval than joint-use to me. worth checking their titles.

Three signups are too few to justify rebuilding onboarding, but two people from the same company suggest there may be genuine internal interest. I’d contact them directly and ask what they expected to see before uploading, because the blocker may be trust or unclear value rather than interface friction.

Uploading a document is not a small onboarding step—it is the moment users take the biggest trust and effort risk. Show them exactly what they will receive before asking for the file, provide a safe sample document they can test first, and then see whether the problem is friction or weak perceived value.

This is a textbook activation problem, and your instinct to talk to users before changing anything is the right one. Most founders would've already redesigned the onboarding by now and still not know why it failed.

One pattern I've seen repeatedly: the first meaningful action (in your case, uploading a document) fails not because of UX but because the user doesn't have the right input ready at that moment. They signed up on impulse or during research, and "upload a document" requires them to go find one. That's a context switch they won't come back from.

Two things that tend to help: (1) a sample document already loaded so they can see what the product does before investing effort, and (2) a follow-up email 2–3 hours later with a one-click link back to the upload step — catches people who intended to come back but forgot.

Strong points already here on intent and the trust barrier, so let me add the one nobody has raised: instrument the upload attempt itself, not just the success. At n=3 you are right to interview rather than optimise, but "uploaded a document" as your only event cannot tell "never tried" apart from "tried and it silently broke."

Add events for upload-started, upload-failed with the reason (file too large, wrong type, timeout, CORS or signed-URL error), and upload-succeeded. For a document tool the failure path is easy to underestimate: a 15MB PDF hitting a limit with no visible error, or a slow upload with no progress bar so someone assumes it hung and closes the tab. That shows up in the funnel looking like a motivation problem when it is a bug.

It also sharpens the interviews the others mentioned. If someone started and it failed, you ask about the file and the error message. If they never started, you are back to intent and trust. Same drop-off number, very different fixes.

Machine Arena team here. Our equivalent of your upload is a spectator making a first prediction on a match, and the mistake that kept biting us in our own numbers was counting lookers as failed doers. Most people who arrive at a product this early never came to do the thing; treating all of them as onboarding casualties makes every funnel number look broken and points you at fixes for a problem you may not have.

So beyond the interviews, which are right at n=3, one cheap structural move: label intent at the door. One harmless question at signup, roughly "do you have a document you want analyzed today, or just looking around", turns the next ten silent signups from anecdotes into labeled anecdotes. Lookers who then do nothing are behaving exactly as promised and tell you nothing about onboarding. An intender who stalls is a real signal, and that interview is worth ten cold ones because you already know what they came to do.

It also compounds with the sample-document idea above, but for funnel reasons, not just trust ones: whoever still signs up after seeing the output on a sample is far more likely to be an intender, so the same drop-off number suddenly means something.

And plus one on the two-from-one-company read: joint evaluation is its own cohort, and it usually resolves on the evaluators' timeline, not your onboarding's.

the "two from one company" part might be signal, not just a footnote on the sample size. that reads like someone pulling a colleague in to eval together before either commits real data, a joint-decision pattern rather than a stuck-on-onboarding one. worth watching if that pairing shows up again in future signups

Right call not to optimise off this yet, and worth being blunt about why: at three signups (two from one company, so really two accounts) there's no drop-off rate to read. Each of those is a case study, not a data point. Talk to them, like you said.

The one structural thing I'd flag for a document tool specifically: making the first meaningful action "upload your document" is a trust chicken-and-egg. If the file is anything sensitive, people won't hand it over before they've seen the thing do something useful, and "sign up, now give us your real data" is a big ask on faith. That's why the sample-document path someone mentioned isn't just a diagnostic, it's probably the fix: let them see the output on your data before they risk theirs.

When you do talk to them, the question that splits the causes cleanly is "did you actually have a document you were willing to upload right then" versus "you weren't sure what to do." Very different problems.

Yes, I have seen this exact thing. The fastest diagnostic is to give them a sample document path on the first screen: “try it with our sample” next to “upload yours.” If people use the sample but not their own file, the issue is trust or readiness. If they ignore both, the issue is probably positioning before onboarding.

I like that you're resisting the urge to optimize around a conclusion you haven't earned yet.

What kind of evidence would actually convince you the problem is onboarding rather than something earlier in the decision to sign up?