Improving Activation Through Onboarding

Role: GTM Product Lead / Growth PM · Scope: B2C Candidate Platform

The problem

CloudHire's candidate platform has a clear value proposition: complete your preferences, get matched to relevant jobs. But a significant share of candidates who signed up were never reaching that moment. I ran a full activation audit to understand where the journey was breaking down, why, and what to build to fix it.

What the data said

The top-line finding: 49% of candidates who logged in reached the Aha moment — the point where preferences are complete and matching jobs are shown (3,817 login events → 1,860 Aha users).

The Aha moment itself was worth protecting. Of the 1,860 candidates who reached it:

Downstream action	Users	Rate
Reached Job Board	925	50%
Applied to a job	612	33%

The core loop was working once candidates got there. The drop was happening upstream.

The device breakdown reframed the entire problem

When I cut activation by device, the picture shifted from "we have an onboarding problem" to something more specific:

Device	Aha users	→ Job Board	→ Applied
Desktop	1,468	60%	41%
Mobile	384	12%	2%
Overall	1,860	50%	33%

Desktop candidates were activating and converting at healthy rates. Mobile candidates were reaching the Aha and then stalling — a 48-point gap in Job Board reach and a 39-point gap in application rate.

Mixpanel alone couldn't tell me whether this was a mobile UX problem or an instrumentation gap. I flagged both as hypotheses requiring manual QA and event verification, and treated it as a parallel workstream separate from the onboarding redesign.

Why the funnel looked worse than it was

The standard read would have been to build an ordered funnel and treat every step-drop as abandonment. That would have been the wrong call.

CloudHire had three legitimate paths through profile creation:

• Path A — Resume upload in CloudHire: Email → OTP → Resume Upload → Terms → Preferences → Matching Jobs
• Path B — Resume already on file: Candidates arriving from another CloudHire funnel (Blue Funnel) had their resume collected upstream. The resume step was skipped.
• Path C — Manual entry: Email → OTP → Manual Profile Details → Preferences → Matching Jobs

The data confirmed why this mattered. An ordered funnel showed only 1,376 candidates reaching Resume Upload — but 1,860 candidates reached Preferences. More users completed the profile than touched the resume step. Resume upload wasn't a mandatory gate; it was one of three valid paths.

The OTP → Resume drop that looked like abandonment was largely candidates routing through a different legitimate path. Treating it as friction would have pointed the team at the wrong problem.

Where friction actually lived:

• Login → OTP — ~26% of users who logged in didn't complete OTP verification. The root cause needed further segmentation by new vs. returning users and OTP-requested vs. OTP-verified, but it was a real signal.
• Profile setup → Aha — A meaningful gap existed here, but it couldn't be attributed cleanly without path-tagged instrumentation. The existing events didn't distinguish which path a candidate was on.
• Aha → Job Board on mobile — The largest confirmed and concentrated drop, with downstream application rate at 2%.

One thing I was deliberate about not touching: the back half of onboarding was healthy. Terms → Preferences → Trial Screen was converting at 88–99% per step. The redesign didn't need to go near any of that.

The product strategy

The diagnosis pointed clearly at where effort was being wasted: candidates were being asked to manually provide information that was already sitting in their resume. Every redundant field was friction inserted before they'd seen a single job match.

Hypothesis: If Aria uses information already available from the resume and asks only for what's genuinely missing, we can reduce onboarding effort and get candidates to matching jobs faster — without degrading match quality.

This shaped three product decisions:

1. Use existing information first. Before asking anything, Aria reads the resume and extracts what it can — role, experience level, skills, location. Candidates don't re-enter what they've already provided.
2. Ask only what's required. Aria identifies the specific gaps between what the resume contains and what's needed to generate a match. It asks only those questions — nothing pre-emptive, nothing speculative.
3. Replace forms with conversation. Instead of stepping candidates through a sequence of onboarding screens, Aria collects the missing information through a guided exchange. The experience is closer to a smart intake conversation than a form.

New flow:

Email → OTP
  ↓
Resume upload or manual entry
  ↓
Aria reads available information
  ↓
Aria asks only required missing questions
  ↓
Profile + preferences built progressively
  ↓
Matching Jobs

Design and build

I built the redesigned onboarding directly in the product using Cursor.

Working this way — moving between design, logic, and implementation in one loop — let me move faster and stay closer to what was actually shippable. The decisions I made in design were tested immediately against what the code could do, and vice versa.

The implementation covered:

• Conversational interaction layer — Aria guides candidates through profile and preference collection in a chat-style interface embedded within the existing platform
• Resume-aware logic — Existing resume data is parsed before any questions are asked; the model only surfaces gaps
• Required-information routing — The system dynamically identifies what's missing per candidate and routes accordingly
• Progressive profile construction — Candidate data is built up through conversation, not a sequence of forms
• Design system compliance — I reused established Figma design tokens throughout to ensure the new interface is visually consistent with the rest of the platform
• Instrumentation fix — I defined a new path-agnostic profile_completed event with a method property (upload / skip / manual) so all three onboarding paths could be measured correctly for the first time

The measurement work was as important as the UX work. Without path-tagged events, the experiment would have been unreadable.

BEFORE — the original multi-step flow. Candidates clicked through a separate screen for every piece of information, even when it was already sitting in their resume.

AFTER — Aria's conversational onboarding. The same information, collected through one continuous conversation that reads the resume first and only asks about what's missing.

Making the applying visible, not just automated

The applying itself wasn't new — an AI bot was already applying to matched jobs on the candidate's behalf in the backend. What was missing was the candidate's experience of it. They'd see a ranked list of matches and nothing else; the applications were happening, but invisibly, with no sense that anything was actually being done for them.

The redesign didn't change what happens in the backend — Aria still does the work. What changed is that the candidate now experiences it: they choose the roles they want, see the tailored resume and email drafted for each one, and get a clear confirmation once it's sent. Same automation, but now the candidate feels like they're the one applying.

BEFORE — matches shown, applying invisible. Candidates saw a ranked list of jobs. The bot was applying behind the scenes, but nothing in the product showed it, so the candidate had no sense of progress or involvement.

AFTER — the candidate selects, reviews, and sees it happen. The same matches now come with a role-by-role choice, a visible draft for each application, and a confirmation that shows exactly what was sent and where.

Reflections

Reading the funnel correctly mattered more than the build. The OTP → Resume drop looked like abandonment. It wasn't — it was path diversity. Getting that diagnosis right was the most important decision in the project, because everything downstream depended on it.

Separating concerns kept the project scoped. The mobile post-Aha gap was significant, but it needed QA and instrumentation validation — not an onboarding redesign. I kept those as parallel workstreams so neither blocked the other.

Fixing measurement was part of the feature. The profile_completed event with path tagging shipped with the redesign, not after it. The old event schema had a structural blind spot that would have made any future experiment results ambiguous.