Introducing the Setup Absorption Model, and what happens to your organization when nobody decides who owns setup.
One of the most irritating experiences in software happens almost immediately after you log in.
A box appears. Then another. Click here to create something. Click there to update a setting. Here is your dashboard. Here is a feature you have no reason to care about yet.
The product is technically trying to help. But instead of letting you accomplish what you came to do, it begins explaining itself.
I understand why companies build these experiences. Complex software requires some education. When trial conversion is low, adding a walkthrough or checklist feels like the obvious fix. Sometimes it helps. Sometimes it's just an annotation layer over a setup problem the product never actually solved.
The question isn't whether a tooltip, wizard, or checklist is the right format. Those are containers. The real question is:
Who is doing the work required to make the product useful? The user, the product, or whoever gets stuck cleaning up after both of them?
That third option is the one most onboarding conversations skip entirely. And it's the one I actually spend my time on.
Product Tours Teach Users to Operate an Empty Product
A traditional product tour transfers knowledge. It explains where features live before the user has any context for that information. They haven't done the task yet. They haven't hit the problem the feature solves. They're being asked to remember the interface before the interface has done anything for them.
Nielsen Norman Group tested introductory tutorials across four mobile apps with 70 participants. Task success was 91% for the group that saw the tutorial, 94% for the group that skipped it. Not a meaningful difference. More notably, the tutorial group rated the following tasks as harder than the group that skipped it. More explanation didn't produce better performance.
That doesn't mean all guidance is useless. It means timing matters. A tooltip that shows up while someone is actively trying to do an unfamiliar thing helps. Front-loaded education, delivered before anyone has a reason to care, doesn't.
A Wizard Isn't Automatically Better
The instinctive fix is a setup wizard: a sequence of questions instead of an empty screen covered in instructions. Done well, this genuinely helps.
But a wizard is just a container too. A bad one is a long form with a progress bar. It can ask too many questions, force decisions too early, or demand information the company already has. If a user answers seven questions and the product uses those answers to configure something real, the wizard created value. If they answer seven questions and land in the same empty app, it collected data and called it onboarding.
The Standard Isn't Zero Setup. It's Justified Setup.
Some complexity is real. A cybersecurity platform can't guess which production environment to touch. A CRM can't know how your company defines a qualified deal without being told. Zero setup isn't always possible, and it's the wrong standard anyway.
The better standard: the product should absorb every unit of pre-value work that doesn't require uniquely human context, consent, or judgment.
Some friction is necessary. Unexplained friction isn't.
Introducing the Setup Absorption Model
Existing onboarding frameworks have correctly focused on cutting time to value. Wes Bush and Ramli John's Straight-Line Onboarding, for instance, asks teams to map every required step and label which ones can be eliminated, delayed, or kept as mission-critical.
That's useful. But it leaves one question unanswered: once you know which steps remain, who performs them?
The user? The product? An implementation team? Or your Support and Sales teams, quietly absorbing the work nobody assigned to anyone?
That's the actual gap the Setup Absorption Model fills. It's not a UI checklist. It's a way of tracing where pre-value work goes when nobody has explicitly decided who owns it, and naming the six places it can land: eliminated, inferred, defaulted, automated, deferred, or genuinely asked of the user.
The goal isn't fewer screens. It's getting someone to Ready State, the earliest point where the product is configured enough for a meaningful task and a real result. Not every setting configured. Not every integration connected. Just useful enough to begin.
Most onboarding teams measure whether setup was completed. The better question is whether the product became ready, and who did the work to get it there.
The Six Places Setup Work Can Land
Every pre-value step gets one of six treatments, applied in this order.
Eliminate. Does this need to happen at all? Products often ask for information because Marketing wants segmentation, Sales wants enrichment, or Product wants research data. Those can be legitimate business needs. They're not automatically legitimate onboarding requirements. If a step doesn't help the user reach Ready State, it doesn't belong in the pre-value path, regardless of which internal team asked for it.
Infer. Can we determine this safely from what we already know? A domain can suggest industry and size. A job title can suggest role. Behavior in the first session can signal intent. Inference should be visible when it meaningfully affects the outcome, and easy to correct.
Default. Can we prevent a blank-state decision? Some choices can't be inferred but don't require starting from zero: a recommended workflow, a standard set of stages, a starting permission structure. A good default is transparent and reversible. A bad one quietly makes a consequential decision on someone's behalf.
Automate. Can the system complete this safely? If the product has enough information to act, it should. This is where onboarding starts producing something instead of explaining something. The user provides intent. The product turns it into configuration, while the user keeps oversight and control.
Defer. Must this happen before value? Asking for advanced permissions or edge-case configuration before someone has completed one meaningful task forces a decision without context. The question isn't whether the user will ever need it. It's whether they need it yet.
Ask. Why must the user do this? Some decisions genuinely require human context: whether an integration is authorized, who should access sensitive data, how the organization defines success. Ask isn't a failure of onboarding. It's the correct treatment for anything that requires judgment, consent, or accountability the product can't stand in for. But every question should earn its place, and explain why it's being asked.
Why This Is a Coordination Problem, Not a Design Problem
Here's the part that actually determines whether this framework is useful to you.
Setup crosses organizational boundaries whether anyone plans for it or not. Marketing promises an outcome. Sales frames the product around a use case. Product decides what the interface can configure. Security and Legal decide what requires consent. Support sees which setup failures turn into tickets.
If each function only owns its own piece, the customer inherits the gaps between them. That's how onboarding turns into a checklist, a product tour, and a string of emails, layered over a journey nobody actually owns end to end.
A CRM built on this model doesn't open on an empty contact database with a tour explaining where everything lives. It asks what kind of sales motion the company runs, infers the basic company profile from the domain, defaults a pipeline based on the answer, imports and maps the obvious fields, and only asks the user about what's genuinely ambiguous. The user still participates. But their input produces something real, instead of a longer list of things to configure alone.
The difference shows up downstream, not just on the screen. When the product absorbs less than it should, that work doesn't disappear. It shows up as Support tickets asking how to complete setup. As Sales manually explaining configuration during a call that should have been about the product's value. As Marketing's engagement scoring flags a healthy account that never actually reached real value.
That's the actual cost of an unclassified setup step. Not a worse interface. A worse handoff, somewhere downstream, that nobody planned for and everyone quietly absorbs.
Measuring It
Time to value tells you the distance. It doesn't tell you who carried the weight. A few metrics that do:
Product Absorption Rate: how much of the necessary pre-value work is handled through inference, defaults, and automation, versus done manually by the user.
Ready-State Rate: the percentage of new users or accounts that reach a real Ready State within an appropriate window.
Assistance Dependency Rate: the percentage of users who need internal teams or implementation help before reaching Ready State. This is the number that tells you whether your organization is quietly compensating for work the product should be doing. If the same predictable setup task keeps generating tickets or calls, that's not a training gap. That's product-design evidence.
Amplitude's 2025 Product Benchmark Report, covering more than 2,600 companies, found that strong early activation consistently predicted strong three-month retention. The relationship isn't proof that faster onboarding causes retention. But it's one more reason a useful early experience matters more than a well-narrated one.
Where This Actually Gets Applied
Running this properly means defining what Ready State looks like for each real user role, mapping every pre-value action (including the ones that leave the product entirely, like a credential request or an approval), scoring the effort each one actually takes, and applying the six treatments in order before anyone touches the interface.
That last part matters more than it sounds like it should. Most teams start by improving the instructions for a step. The more useful question is whether the step needed to happen at all, and who should have been doing it in the first place.
Where In-App Guidance Still Belongs
None of this means product tours or tooltips should disappear. They just get a narrower job. Guidance earns its place when someone hits an advanced feature for the first time, an action has real consequences, or the product detects they're stuck. It should preserve momentum a user already has. It shouldn't be responsible for creating that momentum in the first place.
The Real Standard
Users don't expect every product to feel like a consumer app. They understand enterprise software can be complex. What they reject is complexity being handed to them without justification.
They don't want a tour explaining where setup lives. They want the product to help complete it. Every unclassified setup step is a decision about who carries the burden, and right now, in most organizations, that decision is being made by default, not on purpose.
Time to value measures the distance. Setup absorption explains who is carrying the weight.