Download CV
← All work

Case study · JTI · Nov 2024 → present

Ploom App: making a connected device pair the first time, in 30+ markets

Global Digital Product Manager, Mobile App & Connected Devices. I own the app end to end: strategy, roadmap, and everything from Bluetooth pairing to regulatory compliance.

+20%
pairing success & connection stability
6
app releases shipped in year one
Role
Global Digital PM, end-to-end owner
Platforms
iOS · Android · PWA
Squads
Mobile, Firmware/HW, QA, Design, Data, CRM
Stakeholders
Device, Commercial, Markets, Compliance
Markets
30+, each with its own regulation

The problem was the first five minutes.

The Ploom App is the only way to set up, update and manage a Ploom Aura device. If pairing fails, the customer has a device that doesn’t do what the box promised, and a support ticket. Pairing failures were the single biggest driver of support contacts across 30+ markets.

The failure wasn’t one bug. It was a Bluetooth handshake that behaved differently across phone models, OS versions and firmware builds, wrapped in a UI that gave the user no idea what had gone wrong or what to do next. Every squad owned a piece; nobody owned the outcome.

Pairing flow, before and after

BEFORE Tap “Connect” Scanning… BLE handshake Connected “Something went wrong” → user restarts from zero, or calls support AFTER Pre-flightBT on? device awake? Scantimeout 15s Handshakeper-OS strategy Firmware checkOTA if needed Connected Not found → guided retry Rejected → forget & re-pair Update failed → resume EVERY STATE EMITS · telemetry event + reason code · in-app diagnostics entry · one next action for the user · a support-visible log
Simplified. Before: one linear path, one generic error, no way back but “start over”. After: explicit states, each with a timeout, a recovery path and a reason code that shows up in telemetry and in the support tooling.

Five decisions that mattered.

In order of impact, not of time. The first one made the other four possible.

  1. 1. Make pairing a product with an owner, not a feature spread across squads.

    One backlog, one success metric (first-attempt pairing rate), one weekly review with Mobile, Firmware and QA in the same room. Before, each squad fixed its own symptom.

    Why: nobody had been accountable for the outcome, only for their layer.

  2. 2. Debug at protocol level before touching the UI.

    Instrumented the BLE handshake per phone model, OS version and firmware build. Most failures clustered in a handful of combinations. Fixed those with firmware first; the UI redesign came after, on a stable base.

    Why: a nicer error screen for a broken handshake is still a broken handshake.

  3. 3. Every failure gets a state, a reason and a next action.

    Replaced the single “something went wrong” with explicit states (not found, rejected, timed out, firmware mismatch), each with a guided recovery. Reason codes flow to telemetry and to the support tooling.

    Why: users don’t need to know what BLE is; they need to know what to press.

  4. 4. OTA firmware and in-app diagnostics as part of pairing, not separate features.

    Firmware check inside the pairing flow, resumable updates, a diagnostics screen the user can share with support in one tap.

    Why: a large share of “won’t pair” was really “old firmware”; fixing it in the flow removes a support loop.

  5. 5. Ship in release trains with phased rollouts and feature flags.

    Six releases in year one through TestFlight / internal testing, phased rollout by market, feature flags to pull a change without a hotfix, Crashlytics on every build. RICE/WSJF against telemetry decides what goes in each train.

    Why: 30+ markets with their own compliance means you cannot ship everything everywhere at once, and you need a way back.

What moved.

+20%
pairing success rate and connection stability, across iOS and Android
6
app releases in the first year, phased by market, none rolled back
30+
markets live with App Store / Play Store compliance and GDPR data governance
DAU/MAU
activation, retention and connectivity-health KPIs defined, tracked and A/B tested on onboarding, push and in-app messaging

What I’d do differently.

Instrument first. We spent the first weeks arguing from anecdotes because the handshake had no telemetry. The moment it did, the argument ended. I now treat “can we see it?” as the first question on any connectivity roadmap, before “can we fix it?”.

Bring Compliance in at discovery, not at release. Regulatory differences between markets shaped what the app could show and store, and learning that at release review cost us a train.

Stack & practices

  • iOS / Android / PWA
  • BLE pairing
  • OTA firmware
  • Crashlytics / Firebase
  • Feature flags
  • Mobile CI/CD
  • TestFlight / phased rollout
  • RICE / WSJF
  • Scrum
  • GDPR
  • GenAI for PRDs & specs