Progressive Profiling

Fields on a signup form multiply on their own. Marketing wants to know which channel someone came from so it can decide where to spend more, so it asks for a referral source. Sales wants to call the largest teams first, so it asks for company name and team size. Every request has a reason behind it, and the sum of the reasonable requests is a screen with nine fields on it.

The problem is that the person filling in those fields has not seen the product yet. Being asked for a company name is trivial for someone who has already decided to use the tool and a reason to quit for someone who came to look around. Pass-through rates drop with every field added to the signup flow — the sequence of screens a person crosses to get an account.

The same meeting kept repeating at Pagedeck. Ravi would say the referral source was non-negotiable, and Mia would answer that the field costs three out of four people on the signup screen. Neither was wrong, and the conclusion was always one of two things: keep the field and give up the conversion, or delete the field and give up the data. Progressive profiling is the third answer. Instead of giving up the question, it moves when the question gets asked.

Write down everything you collect, then scatter it across the moments where each piece belongs. Five steps.

1. List every field you ask for today and write next to each one who uses it and when. Two or three fields will come back with nobody's name against them. Those aren't candidates for delay — they're candidates for deletion.
2. Sort what's left into fields the next screen can't render without, and fields that can arrive later. Email goes in the first group: it identifies the account and it's where a password reset has to be sent. Team size and job title go in the second, because a document gets created without either of them.
3. Give every delayed field a place to be asked. The test is the moment the user gains a reason to answer. Team size belongs on the screen where someone first shares a document, because saying how many people they want to invite isn't an interruption there — it's the next action anyway. Job title belongs on the screen where a template gets picked.
4. Put one or two fields in each place, no more. Piling five delayed fields onto a second screen has only relocated the signup form.
5. Store the answers against the individual user and never ask an answered question again. Skipping this step is the most common failure. Someone who gave their team size last week and sees the same prompt again loses all the goodwill a short form earned.

Attach one line saying why you're asking. Something a user gets in exchange — invite options matched to their headcount, a template set that fits their role — changes the response rate measurably. Let people skip, too. Ask a skipper again at the next opportunity, and after a second skip stop asking. Paired with social login, which lets people in with an account they already have, the first screen shrinks to a single button and everything else moves downstream.

This works where the user stays inside the product after signing up. A collaboration tool that someone opens ten times in their first week offers more than ten natural places to ask. Where there's only one touchpoint, it can't be used at all: a lead magnet, which trades a useful document for a contact detail, gets downloaded once and never revisited, so whatever you need has to be collected in that single exchange.

Information that law or billing demands up front also can't wait. A business registration number or an identity check, where the next step is impossible without it, gets collected first. What can move is decided by whether the product runs without the value, not by which team finds it convenient.

There are three limits worth knowing.

First, sales waits. With no company name or team size at signup, there's no basis for deciding which lead to call first, and a team that would have been a large contract sits untouched for days. Guessing size from the corporate email domain is the usual patch.

Second, it costs more to build. You have to persist who answered what and branch each screen on that state, which is far more work than standing nine fields up on one page. For a product with only two or three fields to collect, the cost outweighs what it buys.

Third, asking later doesn't raise the response rate by itself. A question with no stated reason and no skip option is just relocated friction, and dropped into the middle of someone's work it lands worse than it did on the signup screen.

"Let's pull job title and team size out of signup and collect them progressively. Email only to start."

A proposal to shorten the signup form without giving up the data.

"We can't collect this progressively. These people download once and never come back."

A judgment that there's only one touchpoint, so there is no later.

"Someone says they got the team size question twice. The answers aren't being saved."

A report that an answered field is being asked again — step 5 is missing.

Pagedeck cut its signup screen from seven fields to one and scattered the other six across four places in the product. Team size sits on the first share screen, job title on template selection, referral source on a small card during the second visit, and company name on the upgrade screen.

Three weeks later the numbers had split. Signup completion went from 24 percent to 41 percent, while the team size response rate fell from 96 percent to 71 percent. Because more people signed up, the absolute number of users with a known team size went up rather than down. Referral source came back at only 38 percent, so Ravi stopped reading it per user and now uses it only as a per-channel total.

The most common misreading is that this is a way of collecting less. The signup screen gets visibly shorter, so it looks like fewer questions. In practice the total stays the same or grows, because someone who has started using the product has a reason to answer, and fields that were never askable at signup become askable. Left uncorrected, a team adopting this approach starts by trimming the list of fields and permanently loses data it needed.

Assuming that splitting fields always lifts conversion is the second misreading. It comes from treating friction as proportional to field count, but advancing a screen carries a cost of its own. Five fields on one page beating two fields across three pages is not unusual. What wins here isn't moving a field to the next screen — it's moving it out of the signup flow entirely.