What our mobile team told me about mixed signals from leadership, why parity work ends up looking backwards, and the working model we landed on for features that belong on a phone.
My mobile team asked me a question this week that I’ve been answering badly for a while: how much does the company actually want them to invent? They hear that mobile is how we set ourselves apart, and they also hear that what ships on the web should work on the phone. They’ve gotten very creative inside those limits, and they told me they still can’t tell whether leadership wants them to break out of them.
So I told them I’ve been part of the problem. This team gets direction from me that sounds like, we need something that sets us apart, something that only works well on a phone. We also need parity on the things that make sense, because a clinician’s calendar has to exist on both. I’ve pushed hard on one end, another leader has pushed hard on the other, and the team has been left with confusing messages about which one it is. It’s both, but how much of each one? And the answer has changed month after month, quarter after quarter.
It’s both, but how much of each one? And the answer has changed month after month, quarter after quarter.
The team made the cost of that concrete. A good share of their roadmap is bringing features to the phone that shipped on the web a long time ago, and they can see the end of that list coming within a few quarters. When parity is the only thing that gets prioritized, a mobile team spends its time looking backwards. They don’t want parity everywhere, either: rebuilding every complex web workflow on a phone screen is the wrong goal when a phone could do some of those jobs in a completely different way.
A product leader in the room asked the question I think gets at the root of it. Why do the people who own a feature only own it on the web? A team’s charter promises to take the friction out of some part of a clinician’s day, with an unwritten asterisk that says “on the web.” At some point the next surface will be a watch, and they asked whether we’d start a wearables team when that happens.
The team had examples on both sides. One squad plans for mobile from the first draft of its requirements, because it owns the part of the product clinicians use most, and its launches land on both platforms without friction. Elsewhere the habit is to ship on the web, watch usage, and bring the phone in later, after early testing is done. And when a product team owns a feature and mobile only lends it a few engineers, the phone version loses what the mobile team knows about how people actually use a phone.
So, here’s the working model we landed on.
The squad that owns a feature thinks about every surface. They don’t have to become mobile experts. They do have to flag it early, while it’s still a requirements doc, when an idea could be good on a phone.
The mobile team leads discovery and design from there. Mobile design, usability and engineering are their own disciplines, so once a squad flags an idea, the mobile team takes the lead on what the phone version should be. A recent idea that only works because a phone has a camera came together exactly this way: a product team saw the opportunity, and the mobile team explored it and came back with how it should work.
Crit helps, and a product review closes the gap. Today the mobile team’s best way to learn what other squads are building is our weekly design crit, and they lean on it a lot. I’d add a product review with product, customer support and go-to-market in the room, the same one I wrote about in A Banner Isn’t Good Enough, where someone can ask “have you thought about this on mobile?” before the plan is set.
None of that settles the mix by itself, and that part is on me and the other leaders who’ve been sending the signals. What I’d like the team to be able to say a year from now is that parity happens inside the squads that own each feature, and that their own time goes to phone-first ideas without getting stuck.