Onboarding a New Starter the Way SaaS Products Onboard Users, Not the Way HR Onboards Employees

# Onboarding

# New Starters

Borrowed, Part 4: What product activation gets right that day-one security onboarding gets wrong

Ant Davis

Borrowed, Part 4: ideas taken from outside security and applied to awareness practice.

The first three pieces in this series covered product design, memory research, and marketing. This one stays in product, but looks at a different moment entirely: the first few minutes after someone signs up, and why security onboarding still looks nothing like it.

A new starter's first week usually goes the same way everywhere. A stack of policies to acknowledge, an information security module to sit through, a signature confirming it's all been read. Nobody checks whether any of it landed. The measure of success is that the box got ticked, not that the person walked away with anything they'd actually use. SaaS products stopped accepting that standard for their own users years ago. Security never got the memo.

The "aha moment" problem

Growth consultant Sean Ellis coined the term aha moment to describe the point where a new user first feels a product's actual value, not when they've finished a tour or read a feature list, but when something clicks and they understand why they need it. Product teams treat getting a user to that moment, fast, as the single most important job in onboarding.

The examples are well known because they've been tested and re-tested against real retention data. Facebook's growth team found that users who added seven friends within their first ten days stuck around at far higher rates than those who didn't, so onboarding got rebuilt around hitting that number quickly. Slack found that teams sending 2,000 messages were dramatically more likely to stay paying customers, and treated that as the threshold to engineer toward. Dropbox found the moment a user synced a file across two devices, not signed up, not opened the app, synced a file, was the point retention took off, and rebuilt their entire first-run experience around getting someone there as fast as possible.

None of these companies left that moment to chance or buried it in a document. They found the specific action that predicted whether someone would actually stick with the product, then built the first few minutes of the experience entirely around reaching it.

I've seen a version of the same principle play out in my own content work. Growing an Instagram audience comes down to the first three seconds of a video, whether the hook lands before someone scrolls past, whether the message actually gets through in that opening moment or gets lost entirely. It's the same problem in miniature: you don't get a second chance to make the value obvious, so the whole thing has to be built around that opening window, not bolted on after the fact.

What a new starter gets instead

Compare that to a new starter's actual first week. There usually isn't a defined moment the security programme is trying to get them to. There's a stack of things to get through: an acceptable use policy, a data protection module, maybe a phishing awareness slide deck, all delivered in the first few days alongside a dozen other onboarding tasks from HR, IT, and their own team. Completion is the only thing measured. Whether any of it changed how the person actually behaves in month two isn't tracked at all, because there was never a specific target behaviour to track against in the first place.

This is the same mistake covered in the second piece in this series, one big pile of content with nothing to make it stick, just crammed into someone's first week instead of spread across a year. It fails for the same reason. Nobody remembers a policy document. People remember doing something and having it work.

Keen, porous, and drowning in it

There's something specific about a new starter's first few weeks that the compliance-document approach wastes completely. They're keen. They want to learn, want to impress, want to get up to speed fast. For a short window, they're more receptive to new information than they'll ever be again in that job.

That window gets spent on a flood of training that's a mix of genuinely useful and deeply forgettable, often delivered exactly the same way regardless of which part it is. Fire safety, health and safety, information security, click-and-next modules stacked one after another. Some of it will actually stick, the parts that are specific to the person's actual role and the way they'll work day to day. Most of it won't, because generic content delivered at volume in someone's first week is exactly the cramming problem covered in this series' second piece, just happening on day one instead of once a year.

If I were building this today, I'd trickle it. Role-based security messaging, released gradually as someone actually grows into the job rather than dumped on them before they've even learned where the toilets are, paced to match what they're realistically going to face at each stage. And I'd use that window to position the security function as a supporter, not a gate to get through. Someone they can go to, not just a policy they had to sign.

What a first security win looks like

The fix is to define a new starter's version of the aha moment, one specific, achievable action in the first week that the whole onboarding experience gets built around, rather than a pile of documents to get through.

A few candidates that would actually work as a first win:

Successfully spotting and reporting a mild, low-stakes simulated phishing email, framed from the outset as a test they're expected to pass, not a trap

Setting up MFA or a password manager themselves, with a same-day confirmation that it's active, rather than a policy telling them they're required to

Finding and using the reporting tool once, for anything, even something that turns out to be nothing, so the tool itself stops being unfamiliar before it's ever actually needed

Any of these gives a new starter one concrete moment of "I did the security thing and it worked," in their first week, rather than a stack of reading material and a signature. That's worth building the whole first week around.

Time to value, not time to completion

SaaS teams track time to value, how long it takes a new user to reach that first meaningful action, and treat a long gap as a problem to be solved, not a natural cost of onboarding. Security onboarding doesn't track this at all. It tracks completion, whether the module got finished, which says nothing about whether the person left with anything they'd actually use under pressure.

Reframe the metric and the whole first week changes shape. Instead of "did they complete the induction module by day five," the question becomes "how long did it take for this person to successfully report something, or lock down their own account, for the first time." That's the number that tells you whether onboarding is actually working, not whether it got finished.

Coming up in Borrowed, Part 5: what decades of anti-smoking campaigns figured out about fear appeals, and why most phishing comms get the fear part right and the rest of it badly wrong.

Comments (0)

Popular