Case study · Nestlé Nespresso · Apr 2021 → Jul 2023
Connected coffee machines people actually finished setting up
Global Digital Product Manager, IoT, Tribe Lead. I owned the connected-machine roadmap end to end and led four Agile squads across app, firmware and cloud.
- −30%
- pairing-flow friction
- +30%
- faster adoption via customer-service enablement
- Role
- Tribe Lead, IoT roadmap owner
- Squads
- 4 Agile squads
- Surface
- App (iOS/Android), machine firmware, cloud
- Stakeholders
- Machine R&D, Markets, CS, executive committee
- Before this
- Product Owner Web & Mobile, same company
A premium machine that was hard to pair and easy to abandon.
Nespresso’s connected machines promised remote brewing, maintenance alerts and capsule reordering. The promise only works once the machine is paired to the app, and a meaningful share of customers never got there: they tried once, failed, and used the machine as a dumb one forever.
The causes were spread across the ecosystem: several machine generations with different firmware, two mobile platforms with different Bluetooth behaviour, a cloud backend, and dozens of markets. Four squads each owned a slice. My job was to own the outcome.
Where pairing could fail
How the tribe was organised
Four squads, one metric.
Connectivity
Pairing flow, BLE reliability, cross-device testing matrix. Owned the headline metric.
Machine experience
Remote brewing, maintenance, capsule reorder. Only counted once pairing worked.
Platform & telemetry
Device registry, adoption and retention dashboards, CSAT instrumentation.
Content & enablement
No-code content packs, CS scripts and playbooks, GTM alignment with markets.
Four decisions that mattered.
1. Reliability before features.
Paused new-feature work in the machine-experience squad for two sprints and pointed everyone at first-attempt pairing. Executive stakeholders had feature dates; I traded them for a number that would make the features matter.
Why: every feature on the roadmap had a pairing-rate ceiling.
2. A cross-device reliability matrix as a release gate.
Machine generation × OS version × app version, tested before each release. Not glamorous; it caught the regressions that had been shipping to customers.
Why: “works on my phone” had been the de facto QA process.
3. Rewrite the pairing journey around the user’s kitchen, not the protocol.
Fewer steps, plain-language states, recovery paths for the three most common failures. Qualitative research with customers who had given up, plus telemetry funnels, drove the order of fixes.
Why: the drop-off points in the funnel were not where engineering assumed.
4. Content packs as a no-code channel to markets and customer service.
A content-pack strategy let markets and CS ship guidance, scripts and campaigns without an app release, aligned to GTM priorities. It also improved competitive positioning on features that were really about education.
Why: half the “pairing problems” reaching CS were solvable by better guidance, faster than by code.
What moved.
- −30%
- pairing-flow friction through UX/journey optimisation and cross-device reliability
- +30%
- faster adoption, with customer-service teams enabled by content packs
- New
- connected machines launched during the period, on the rebuilt connectivity journey
- CSAT
- adoption, retention and satisfaction monitored per release, reported to the executive committee
What I took to JTI.
Almost everything in the Ploom App case is this one, done a second time with the lessons applied from day one: telemetry on the handshake before arguing about it, explicit failure states, reliability as a release gate, and one owner for the outcome. The numbers moved faster the second time because the diagnosis took weeks instead of months.
Stack & practices
- IoT
- BLE
- iOS / Android
- Telemetry & funnels
- User research
- Cross-device test matrix
- Content packs (no-code)
- 4 Scrum squads
- OKRs
- CSAT