Knowing which mobility ideas to build, and which to leave alone.

The challenge

As part of my transition to Principal, I was put in charge of helping drive the mobile roadmap for DCS, Brambles' Digital Customer Solutions portfolio. The question on the table when I started was blunt: does DCS need a mobile strategy?

That framing is a trap. Answer it directly and you end up defending or dismissing a platform before establishing whether mobility actually helps anyone. So I changed the question. Instead of starting from technology, I reframed the work around mobility moments, real situations where a user is away from a desktop, needs data or context, must act quickly, and is doing it within a constrained environment, a warehouse floor, a moving vehicle, a retailer's loading dock. The job stopped being “should we build a mobile app” and became “where, specifically, does DCS have a reason to intervene when someone is on the move.”

This was explicitly exploratory work, not solution design. The goal was to gather informed opinion grounded in the team's existing knowledge of our customers, evidence-based enough to decide whether deeper discovery in the mobility space was worth pursuing at all, including the option that it wasn't.

Mobility is powerful, but only when it removes work, fits end-to-end workflows, and shares value across the ecosystem.

My role

I gathered the stakeholders, evidence and content, then designed, planned and facilitated the workshop that turned that reframed question into a defensible answer.

That covered identifying and briefing sixteen candidate mobility moments across the DCS portfolio, pulling together the stakeholders who actually understood each one, and building the workshop structure itself, four cross-discipline breakout groups, one per DCS product area, so every moment was discussed by people who could speak to product, research, design and delivery at once. I brought Olga, a UX Researcher, and Karen, a UX Lead, in to support the synthesis once the workshop was done, there was a genuinely large amount of qualitative input to work through, and we structured and synthesised it together in Lucid into the themes and recommendations that follow.

A mobility moment, as we defined it for the workshop, was the actual unit of analysis, not a vague sense that “mobile matters here somewhere.”

That definition matters more than it looks like it should, because it rules out a huge amount of what mobile-strategy conversations usually default to: it's not about whether our software looks good on a phone, it's about whether being on a phone, at that specific moment, changes the decision someone can make.

Reframing the brief this way also changed who needed to be in the room. A platform question gets answered by architecture and engineering. A moments question needs the people who actually know what a supplier's warehouse floor, a retailer's dock, or a driver's cab is like day to day, which is why the workshop was built around cross-discipline groups rather than a single mobile-strategy team working in isolation.

I organised the workshop around four cross-discipline breakout groups, one per DCS product area, End-to-End Quality Assurance (E2EQA, split across two groups given its scope), Reusable Asset Management and Connected Pallet Visibility (RAM/CPV), and Retail Promotions. Each group brought together product, UX research, UX design, engineering, content and operations perspectives on the same set of moments, so no single discipline's blind spot went unchallenged.

For every moment discussed, each group worked through the same structure: the task at hand, the underlying user need, the pain points already known about it, and the practical constraints of doing it on a mobile device in that specific environment. That consistency is what made the sixteen moments comparable afterwards, rather than sixteen unrelated conversations that happened to share a workshop room.

Twelve of the sixteen moments were explored in depth in the time available; the remaining four are flagged later as requiring further discovery rather than left to quietly disappear from the record.

The honest headline: most mobility moments are not, on their own, product opportunities. The strongest ones shared a pattern, real-time data, decision-making and operational workflows intersecting at a moment where someone genuinely couldn't reach a desktop. The weakest shared a different pattern: mobility added a step to a process that a physical tool, an integration, or a piece of automation already solved better.

Six of the twelve explored moments are worth walking through individually, three that earned their place on the roadmap, three that didn’t, with the photo used to ground each discussion and the actual findings that came out of it:

Two further moments were flagged as genuinely risky rather than simply weak, cases where a standalone mobile fix could actually make an existing data-accuracy or adoption problem worse, not better. Four moments went undiscussed for lack of time and are logged as needing dedicated discovery rather than assumed away.

Four themes came up often enough, across otherwise unrelated moments, that they stopped being one group's opinion and became the actual conclusions of the workshop: seamless ecosystem integration of data and process is what decides success or failure; the highest value is often upstream of where the effort has to go; partial solutions tend to introduce new problems rather than remove old ones; and more research is still needed before DCS can be confident about customer ROI and product-market fit for mobility specifically.