This is a summary of a talk I gave about Trello in 2025 at SwiftCraft as an opening keynote, at iOSKonf in North Macedonia, and at Pragma Conf in Bologna. At UX Scotland 2026, I delivered it to designers for the first time as Transit Lines & Touchpoints: A Narrative Framework for Multi-Device UX.
How a conceptual model turned around a mobile org, and got a team its own strategy.
In the years following Atlassian’s acquisition of Trello, the product faced a challenge familiar to maturing SaaS platforms: monthly active users (MAU) had turned negative, and reversing that trend required a coordinated effort across more than ten teams. The recovery program that followed, spanning product, engineering, marketing, and data science, ultimately reversed six months of negative growth and delivered a 7% increase in MAU. Mobile’s contribution to that turnaround was disproportionate to its size: the smallest org in the program accounted for roughly a third of the overall recovery, while also demonstrating that cross-platform users, those who engaged on both mobile and web, showed the highest paid retention rates and lowest churn of any user cohort.
This is the story of how that happened, and the framework that made it possible.
When I took over design for Trello Mobile, the entire organisation was struggling. Monthly active users were in decline; mobile had no strategy of its own, and a web platform many times its size set the agenda every quarter.
Less than a year later, mobile’s customer-satisfaction score reached 91: seven points higher than Trello’s web app, and fourteen points above the work-management industry average. App-store ratings hit their highest level since 2019. Inside the team, effectiveness and work-happiness scores roughly doubled, and the 3 a.m. incidents stopped.
None of it came from a reorg or a bigger budget. It came from a new strategy and a conceptual model which unlocked stakeholder understanding: a new way of seeing the device ecosystem that let mobile stop following and start leading. This is that model, Transit Lines & Touchpoints, and how it changed the conversation.
The problem was never speed. It was visibility.
Trello launched mobile-first, as a native app in 2011. When Atlassian acquired the company in 2017, the focus shifted to web, and mobile became the smaller sibling: forty people to web’s two hundred and fifty, maintaining two codebases (iOS and Android) across both phones and tablets.
The math was brutal. Mobile had roughly fifteen percent of the resources but drove about thirty-five percent of monthly active users and a third of new signups. A tiny team carried an outsized share of the product and they had to match a platform six times its size feature for feature across two mobile platforms.
Years of that had taken a toll. The Mobile org was always chasing parity and always missing it. It was the slowest org to ship. Surprise API changes flowed downstream from web, because mobile didn’t have the people to stay in lockstep, and those surprises turned into incidents that made the team look worse than it was.
But the structural problems were almost secondary to the human ones. Morale was at an all-time low. The relationship with web had curdled into resentment, several small dogs and one big dog fighting over the same bone, and mobile had been losing long enough that the attitude had stopped being anger and started being resignation.
The organisation knew something was wrong. What it didn’t have was a way to talk about it.
Trying to match a platform six times your size feature for feature isn’t a strategy. It’s a trap. And you rarely get parity on the things that actually matter.
The instinct, when you’re behind on parity, is to focus harder on parity. It’s the wrong instinct for most SaaS products. Framing the problem as disparity, a gap to be closed, means every conversation becomes about what’s missing rather than what’s right. Teams end up building the wrong things excellently, or the right things badly, because the metric is coverage rather than quality. This isn’t unique to Trello. Engineers working across native and web SaaS recognise it immediately: the parity framing is how organisations keep themselves stuck.
We weren’t failing because we didn’t understand our users. We had research, usage data, App Store reviews. We knew what people did on mobile and what they wanted.
What we didn’t have was a model that made mobile’s distinct value legible: to leaders, to partner teams, to the people deciding where to invest. We tried the obvious tools. Detailed artefacts — journey maps, prioritisation spreadsheets, hyper-detailed prototypes — are great at generating alignment inside a design team. In a room with engineering leads and product directors, they can produce blank stares or open rabbit holes. Without something simpler, something a non-designer could hold, every feature debate was a negotiation and web could overrule mobile on the grounds of parity. The team was constantly fighting for permission to do what it already knew was right.
This isn’t unique to Trello, or to enterprise scale. It shows up the moment a product crosses the complexity inflection point: shipping across multiple surfaces, parity disputes that never quite resolve, a strategy that lives in a doc but doesn’t survive contact with how decisions actually get made. The problem presents as speed. It’s almost always visibility.
We didn’t need more data. We needed a better way to see the system, and better questions to ask of it.
We didn’t lack user insight. We lacked a model that made mobile’s distinct value legible to the people making decisions.
It started in a one-on-one with my engineering partner. We were describing the state of the org, and I said it felt like we were the neglected caboose at the end of a very long release train.
It was the right feeling, but the wrong frame. A caboose is defined entirely by the train in front of it. And then it clicked: we weren’t a train at all. Web was a train. We were light rail. A different transit line, with its own logic and its own purpose, inside one connected network.
That’s the whole idea. A city’s transit network isn’t a single thing. It’s a set of distinct lines, each with its own purpose, speed, and infrastructure, that together move people where they need to go. The goal was never for every line to do the same thing. It’s for the system to work as a whole. A multi-platform product is exactly that. A conceptual model like this doesn’t describe how the product works mechanically. It answers a more useful question: what exists, and how does it relate? And that question pointed every conversation in a new direction.
