Implementation worksheet · 5 min read
A Role-Based Onboarding Branch Specification
Branch onboarding on role only where the first-value action actually differs. Spec it in four parts: the fork point (one early question or an inferred signal — never both), per-branch first-value definitions, the shared trunk every branch returns to, and a branch budget (two to four; each branch is a product you now maintain). If two roles share a first-value action, they share a branch.
Role-based onboarding fails in both directions: one generic flow bores everyone, while a branch per persona rots into six unmaintained mini-products. The spec exists to place the fork exactly where value diverges and nowhere else.
Put it into practice
1. List roles by first-value action, then merge
Write each role's first meaningful action. Admin instals and invites; analyst builds first report; viewer consumes a shared thing. Roles with identical actions merge — the branch count comes from value paths, not the marketing persona deck.
2. Pick one fork signal
Either ask ('What brings you here?' — max one question, max four options) or infer (invited users skip setup; SDK-key holders are developers). Asking AND inferring creates contradictions you'll debug forever.
3. Spec each branch to its first value only
A branch is 2-4 steps to that role's first value, then rejoins the trunk (workspace tour, invite prompt, settings). Branches that never rejoin become parallel products.
4. Handle the wrong-branch case
Users misclick and roles change. Every branch needs a visible 'not you?' escape that reroutes without data loss — and the fork answer must be editable in settings, not a life sentence.
5. Instrument per branch
Branch entry, step completion, first-value rate, escape-hatch usage. High escapes = wrong fork question; low value-rate on one branch = that branch's spec is wrong, not the whole flow.
Branch specification worksheet
Copy this structure into your review document and record your observed result for each row.
| Branch | Fork signal value | First-value action | Steps to value | Rejoins trunk at |
|---|---|---|---|---|
| Admin/owner | ||||
| Builder/creator | ||||
| Invited member | ||||
| Evaluator | ||||
| (budget: max 4) |
A failure worth checking
Over-branching: shipping a branch per marketing persona (six segments, six flows) and updating three of them when the product changes. Two quarters later half of new users onboard through a flow describing removed features. Branch count is a maintenance budget — spend it only where first value genuinely differs.
Common questions
Should the role question be skippable?
Yes, with the default branch being your highest-volume role. A forced question in front of the product is a conversion tax; measure skip-rate — high skips mean the question came too early.
Can the fork use firmographic data instead of asking?
When you have it reliably (enrichment, SSO domain), inferring beats asking. The spec rule stands either way: one signal decides, and the user can correct it.
Basis and scope
This is a proposed implementation method using illustrative examples, not a measured benchmark or a customer case study. Prepared with AI assistance. Validate product-specific behavior against current documentation and your own test environment.