# Product Onboarding Starts Before the First Login

> A practical playbook for getting connected-device customers from unboxing to a working product.

- Author: Rishikesh Ranjan · Published: Sep 16, 2026
- Type: Playbook
- Tags: Onboarding, User Behaviour, Metrics
- Growth levers: Activation (primary), also Retention
- ~2355 words

---

Picture someone opening a smart plug they bought to switch a bedside lamp off from their phone. The insert says to download an app. They search the store, find several similar names, install one, and create an account. Then the app asks which device they own. The model name on the box doesn't match the name in the menu.

This is a hypothetical customer, but it's a useful place to start a product onboarding review: standing beside the socket, holding the packaging. A dashboard that begins at account creation has no view of the work they did to get there.

Product onboarding is the process of helping someone reach a useful result with your product. For a connected device, that process includes the box, the instructions, the phone, and the device itself. Treat them as one journey with a named owner and a finish line you can observe.

This playbook is for product and growth teams selling physical products with an app or a supported smart-home platform. We'll use that smart plug throughout. The proposed changes are experiments to run with your own customers; the company examples establish how particular setup mechanisms work, not how much they will improve your conversion rate.

![Proposed smart-plug setup journey: a box insert routes customers to download or open the app, pair the device, recover from blocked permissions, and send a command to a lamp.](https://www.productgrowth.blog/media/posts/product-onboarding-before-first-login/01-setup-journey.webp)
*Proposed journey for the hypothetical smart plug. The illustrated screens and setup URL are examples; each route still needs to be built and tested.*

## 1. Define the first useful result before changing the flow

Write down what the customer should be able to do when setup ends. For our smart plug, use this: the customer sends a command from their phone and sees the lamp respond. An account, a downloaded app, and a connected plug are intermediate states. The lamp responding is evidence that the intended task works.

Have product and engineering agree on a corresponding event, such as first_command_confirmed. Specify what confirms it: the device reports the requested state after a user command. A tap on an on-screen button only records intent. During usability sessions, also ask the participant to confirm that the physical lamp actually changed state.

Choose a time window before you inspect results. For an initial pilot, you could measure whether a unique device setup reaches that event within 24 hours of its first setup attempt. That's a proposed reporting window, not an industry benchmark. A product requiring professional installation would need a different clock.

Name one product owner for the complete journey. Packaging, mobile engineering, firmware, support, and analytics will still own their parts. Give the product owner responsibility for resolving gaps between them, such as an insert that uses a name the app team has retired.

Leave this step with a written success event, a reporting window, and an owner. If the team disagrees about whether the plug is activated when it connects or when it does something useful, settle that before changing the screens. Otherwise, each team can report success against a different finish line.

## 2. Audit the journey with the retail box in your hand

Start with a sealed unit from the stock a customer could receive, a supported phone, and an account that has never used the product. Use the printed insert, not a newer PDF supplied by the project team. Record the device model, firmware, app version, phone operating system, and packaging revision so you can reproduce failures.

Work through the instructions without help from someone who knows the product. Write down where you hesitate, switch surfaces, or need information you weren't given. At each point, ask what evidence tells the customer that they can continue.

| Customer task | Question to resolve | Responsible team |
| --- | --- | --- |
| Open the box | Which instruction starts setup for this model? | Product and packaging |
| Find the setup route | Manufacturer app or an existing home platform? | Product and mobile |
| Prepare the device | What power, network, hub, or pairing state is required? | Firmware and support |
| Connect it | What happens if a permission or pairing attempt fails? | Mobile and firmware |
| Try the intended task | Does the lamp respond to a command? | Product and analytics |
*Proposed audit worksheet for the hypothetical smart plug. Assign named people to these responsibilities.*

Check prerequisites before treating an obstacle as a writing problem. Does this model need a particular network band? A hub? An update before it supports the advertised setup route? Put the requirements that can block setup where the customer can act on them. A missing piece of hardware cannot be fixed with a shorter tooltip.

A [2024 study of smart-home onboarding](https://www.cs.dartmouth.edu/~kotz/research/wang-onboarding/wang-onboarding.pdf) followed one researcher setting up 12 selected devices. The authors documented differences in app requirements and cases involving extra hub hardware or firmware updates. This was a small observational study, not a consumer failure-rate survey. Its useful lesson for this audit is to test the actual device and software combination rather than assume the advertised compatibility describes the whole setup process.

Turn each observed failure into a task with an owner and a check. For example: 'The insert says Plug Mini; the app says P100. Add the retail name beside the model code, then ask a new tester to select the device.' That is specific enough to implement and verify.

## 3. Give customers a clear route into setup

Decide which setup route the product actually needs. If a supported home platform can complete the customer's intended task, consider directing them there. Requiring a separate manufacturer app needs a reason, such as a feature or update essential to that task. Make the choice explicit before printing a download instruction.

For a product that needs its own app, put the app's exact name and publisher on the insert. Give the main action a useful label, such as 'Set up your plug.' Include a readable support URL and the model identifier so the customer has a route forward if scanning fails.

A tool such as [Uniqode](https://try.uniqode.com/rishikeshranjan) can handle the app-store handoff: its Mobile App QR Codes route Android users to Google Play and iOS users to the App Store, with a web fallback for other devices. Configure the correct store listings and a useful fallback page, then test the printed code on the phones you support.

![Uniqode homepage introducing its QR platform with a physical product and digital destination.](https://www.productgrowth.blog/media/posts/product-onboarding-before-first-login/02-uniqode-home.webp)
*Uniqode’s public homepage, captured September 16, 2026. The figures inside the vendor’s artwork are marketing illustrations, not results used in this playbook.*

![Uniqode Mobile App QR Code setup with separate Google Play, iPhone, iPad and macOS, and fallback web URL fields.](https://www.productgrowth.blog/media/posts/product-onboarding-before-first-login/03-uniqode-app-routing.webp)
*Cropped interface illustration from Uniqode’s official app-download guide, accessed September 16, 2026. It shows the store destinations and web fallback; this is documentation imagery, not a test of a signed-in account.*

Screenshots: [Uniqode homepage](https://try.uniqode.com/rishikeshranjan) and [Mobile App QR Code setup guide](https://try.uniqode.com/rishikeshranjan).

Choose between sending people directly to the store and using a brief setup page first. Direct routing suits a simple product with few prerequisites. A setup page earns the extra step when it helps someone choose a model, check compatibility, or use an app they already have. Keep that page focused on setup; save newsletter invitations and accessory offers for later.

Handle the installed-app path separately. Give returning users an obvious way to open the app and find Add device. Where your app supports links into a specific setup screen, test that route too. The customer should be able to recover using the printed instructions even when the link opens in a browser.

[Apple's universal-link documentation](https://developer.apple.com/documentation/technotes/tn3155-debugging-universal-links) describes links that can open an installed app, with a website fallback when it isn't installed. It also documents cases where Safari keeps a link in the browser. Treat carrying someone into setup after a fresh installation as a separate capability to verify with engineering. A successful trip to an app-store listing doesn't establish that it works.

Before approving the insert, test a fresh install, an existing installation, a manual visit to the fallback URL, and a scan from an unsupported device. Also check the store listing in each market you sell into. Stop here if the customer can reach a download page but has no clear next instruction once the app opens.

## 4. Make device setup recoverable

Once the app opens, keep the customer oriented around the device they are holding. Show the retail product name and an identifying picture. Explain the next physical action and the visible result: plug it in, wait for the documented indicator, then continue. Use the timing and light pattern confirmed by your firmware team rather than a convenient round number.

Ask for permissions in the context of the task they enable. [Sonos documents](https://support.sonos.com/en/article/sonos-app-permissions) that its iOS app needs local-network access to set up or connect to products, and Bluetooth access to detect nearby speakers during setup. That is the kind of concrete explanation a customer can understand before a permission prompt.

For the hypothetical plug, a prompt might explain that Bluetooth helps the phone find the device beside it. Use that explanation only if it describes your implementation. If permission is denied, show which step is blocked, how to restore access, and where the customer will resume. Test the denial path deliberately.

Keep the code used to find your app distinct from any code used to pair a particular device. [Google's Nest Wifi setup instructions](https://support.google.com/googlehome/answer/9548301?hl=en-GB) include scanning the device's QR code and, when scanning fails, entering a setup code. A general download link has a different job. Label each code by the action it performs, and preserve the pairing method your device requires.

Design an error message around the next useful action. 'Connection failed' leaves the customer guessing. If the app can determine that a required permission is disabled, name it and offer the relevant recovery instructions. If it cannot determine the cause, say what it checked and present a short sequence of checks rather than guessing.

Decide what happens when someone closes the app midway through pairing or loses connectivity. Where technically safe, preserve completed steps and explain which step must be repeated. Provide a support route carrying non-sensitive diagnostic details, such as model, app version, and error code. Keep network passwords and pairing secrets out of analytics and support links.

Some [onboarding friction is useful](https://www.productgrowth.blog/p/user-onboarding-how-a-little-friction): confirming the correct device or explaining a required permission can serve the customer. Evaluate each step by what it accomplishes. Remove an optional profile survey from the setup path if it has no bearing on making the lamp work.

## 5. Measure the parts you can actually connect

Create an event plan with analytics and engineering before running the pilot. For the plug, distinguish setup_started, device_connected, and first_command_confirmed. Define when each event fires, how retries are handled, and which identifier represents one eligible device setup. Use the initial setup start to anchor the reporting window so a retry doesn't quietly reset the clock.

Keep events such as setup_failed and permission_denied for diagnosis. Include model, app version, and a controlled error category where appropriate. Verify the event sequence on a test device, including an interrupted attempt. A dashboard is only useful if its events describe the behavior you meant to record.

Use [onboarding completion rate](https://www.productgrowth.blog/calculators/user-onboarding-rate) for the setup process you have defined, then measure the useful action separately. If your process ends at device_connected, calling that completion 'activation' would conceal the remaining work of getting the lamp to respond.

![Illustrative 24-hour cohort: 400 setup starts, 280 connected (70%), and 240 first commands confirmed (60%). Within the window, 120 have not connected and another 40 have connected without confirming a command.](https://www.productgrowth.blog/media/posts/product-onboarding-before-first-login/04-setup-funnel.webp)
*Invented example with a complete 24-hour window for every setup. Bars share a zero baseline and use all 400 starts as the denominator. Exact values follow in the table.*

| Stage within 24 hours of setup start | Unique device setups | Share of the 400 starts |
| --- | --- | --- |
| Setup started | 400 | 100% |
| Device connected | 280 | 70% |
| First command confirmed | 240 | 60% |
*Illustrative cohort, not company results or a benchmark. Count each device setup once per stage; all 400 starts have a complete 24-hour observation window.*

In this invented cohort, 120 of 400 setups haven't reached connection within the window. Another 40 reached connection but haven't confirmed a first command. The connected-to-first-use rate is 240 / 280 = 85.7%. Those are different places to investigate: inspect connection errors for the first group and the path to controlling the lamp for the second. The counts alone don't establish why either group stopped.

Track time from setup_started to first_command_confirmed for successful setups, alongside the share still incomplete. Report a median and a slower percentile, such as the 90th, when the sample supports it. Looking only at successful customers can hide those who couldn't finish; a shorter median doesn't by itself establish a better journey.

Treat scans, store visits, installs, and setup events as separate datasets until you have verified how they join. Someone can scan twice, install later, or use another phone. If you cannot reliably connect a scan to an app event, show aggregate scan activity beside the app funnel and label the gap. Don't divide unrelated totals and call the result a conversion rate.

The same caution applies to delivery. A delivery timestamp records arrival, not the moment a gift recipient opens a box. You can build a delivered-device activation view if you can match eligible devices and define the observation period. Keep it distinct from setup-start activation, and record unmatched units rather than treating them as known failures.

## 6. Pilot the complete journey before changing every box

Run a small usability pilot with people unfamiliar with the product. Ask them to set up the plug and control a lamp using the materials they receive. Let them attempt the task without coaching; note where help becomes necessary. This finds specific problems to fix. It doesn't produce a reliable market-wide conversion estimate.

Use a coverage matrix so a successful test on an employee's phone doesn't end the review. Assign each condition to a tester, record the actual outcome, and keep enough detail to reproduce a failure.

| Condition | Required behavior to verify |
| --- | --- |
| App absent or already installed | Reach the appropriate setup entry point |
| Permission denied | Understand the blocked step and recover |
| Printed QR code cannot be scanned | Use the readable fallback instructions |
| Connection interrupted | Resume safely or receive clear retry instructions |
| Different supported phone or firmware | Complete the same intended customer task |
| Pairing complete | Send a command and observe the lamp respond |
*Suggested test coverage. Add model-specific conditions discovered in your audit; this is not an exhaustive hardware certification checklist.*

Set a release rule before the pilot: each supported path must reach the agreed first-use event, each tested failure must offer a usable recovery route, and the recorded events must match what happened. Assign unresolved failures to owners. Keep a changed insert out of the wider shipment until its destinations and instructions pass these checks.

For a subsequent conversion experiment, change one meaningful part of the journey, such as the insert's setup instructions. Where operations allow, randomly assign eligible shipped units to the old or new insert while keeping other conditions comparable. Record packaging revision at assignment and keep those units in their assigned groups. Repeated scans are not new participants.

Choose the outcome denominator to match the change. If the insert is meant to help people begin setup, setup-start completion alone misses customers who never start. Use first-use activation among assigned eligible devices when that can be measured, with the same observation window and a clear account of missing data. Use the in-app funnel to diagnose what happens after setup begins.

Let the analyst size the experiment from your baseline and the smallest improvement worth acting on. Inspect support contacts and returns as additional outcomes, allowing time for them to appear. If volume or device matching is insufficient, report the usability findings and measurement limits instead of declaring a conversion win.

Keep ownership after release. Assign someone to check setup destinations when app listings, product names, firmware requirements, or packaging change. An insert stays with the customer long after the launch meeting, so include older stock and repeat setup in future reviews.

> **Steal this:** Bring a retail box to your next onboarding review. Ask someone unfamiliar with the product to reach the first useful result using only what's inside. Turn the first place they need help into a task with an owner, a recovery path, and a check that proves the fix works.

For our customer, the job is finished when the lamp responds from the phone. Start your review at the box and keep following that task until it works. You'll leave with a concrete list of product decisions that an account-creation funnel could never show on its own.

**Next job: Define your activation baseline.** Use the calculator for a signup-based activation baseline. For the device cohorts in this playbook, keep the same division but use your explicitly defined eligible-device denominator. [Continue](https://www.productgrowth.blog/calculators/activation-rate)

---

All posts: https://www.productgrowth.blog/archive · Site: https://www.productgrowth.blog