The number that looked like a market problem
Registrations came in below the forecast, and the first explanation on the table was the market. Interest was lower than hoped, the audience needed more time, the launch had not reached the right people. Each is plausible, and none requires anyone to admit that the product has a flaw. That is why most teams reach for it first.
On a platform we worked on, that explanation survived until the question changed from how many people signed up to where the ones who began were stopping. They were not missing. They were leaving partway through the form. The interest was there. The registration flow was turning it away.
Where people actually stopped
Finding your own step three is quick. If you have analytics on the registration flow, look at completions per screen rather than completions overall. The screen with the sharpest fall is where your problem lives, and it is rarely the first one. People give the first screen the benefit of the doubt. They judge the third.
If you have no per screen data, five conversations will do. Ask people who stopped to open the form in front of you and talk while they fill it in. You will hear the moment they hesitate, and the reason is usually that the form asked for something they did not have to hand, or did not see why they should give.
Why step three existed
Somebody had a reason. Step three usually asks the user to describe their organisation: name, type, address, a contact. The platform needed to know where a user belonged, and asking was the simplest way to find out. It also promised segmentation data, and the people who wanted that data were in the room when the flow was agreed.
Nobody tested the user's side. The user is asked to type out an organisation that already exists, because a colleague entered it last month. They are asked for details they do not know, such as a registered address, and they are asked before the platform has done anything for them. A good reason on the inside does not survive that. If you need the data for segmentation, collect it later, from users who stayed.
Join, do not declare
The structural fix is to stop asking users to declare who they are and let them join something that already exists. The user picks the organisation they belong to, and a manager at that organisation approves them.
On the platform we worked on, that replaces two steps of the registration flow. The decision was not to redesign them but to remove them. Two fewer screens beats a better progress indicator. The change is agreed with the client and in build, so this is the reasoning behind a decision, not a measured result.
Approval is a better trust mechanism than a form. A form can only check that its fields are filled in. A manager knows whether this person belongs, so the fields that existed to support that decision can go. It does add work for the manager, but it moves the friction to the person with an incentive to resolve it.
Different paths for internal and external
Internal staff were going through the same approval path as external users, because the flow had one path and everyone took it. The people who should have been seeding the platform with activity were the most obstructed group on it.
Internal roles get a path that bypasses the approval designed for external users. That approval exists to decide whether a stranger belongs, and staff do not need approving, so on a colleague it does nothing but make them wait. If your adoption numbers are low, count how many of your own people are queued behind a process built for strangers, and how much of what a new user comes looking for is theirs to create.
What we did not remove
Not everything went. We did not remove approval. It moves to the organisation's manager, where it leaves a record of who admitted whom. Optional data is not dropped. It moves to first use, where the user has a reason to answer. If your legal team requires a consent step, it stays, and something else goes instead.
For the architect or IT lead: the bypass covers internal roles only. Every external user is still approved, by a manager inside the organisation they are joining, so each admission has a person attached to it. The flow asks for less. It does not decide less.
