Our product teams pride themselves on working in small, autonomous units.
Each team has their own roadmap, their own weekly goals, and their own ways of collaborating. Traditionally, this has worked really well for each of our products. But when building product that spans mobile and web, this process can quickly break down.
Working across platforms isn’t just a technical challenge, it’s an organizational one too.
For the past few years, our mobile team has been horizontal, moving across teams. This meant that when it came to products such as our messenger, the fundamental part of the Intercom product, we had a separate process for web and mobile.
Most of the time, web wagged the tail and mobile followed. This wasn’t a conscious decision we made; the main reason was because mobile was physically separate from the rest of the team.
With limited contact with the designer and product manager on the web team, by the time the mobile team got around to building feature X, all the decisions had already been made. In some cases, designs were literally handed off from web to mobile – the exact opposite of how we like to build product.
The technologies are different, but the problems being solved are the same
To build a truly world-class, multi-platform product, the first step is to break the silos between web and mobile down. So when we started rebuilding our messenger from the ground up, we tried to rebuild our team from the ground up too. We found the best way to achieve this was to work as one team, across platforms. Sure, there’s implementation differences across iOS, Android and Web. But at a foundational level, we were solving the same problem.
What we didn’t realize was that the logistics of having one team were a lot more difficult than imagined. One of our first mistakes was that even though we had one team, we still had separate product managers – one owned the mobile messenger, and one of them owned the web. This caused the same problem as before – not everyone was on the same wavelength.
A deliberate choice we made early on was to have just one product manager for all three platforms. It meant that if mobile was implementing a feature that the web built two weeks ago, we could learn from the challenges they faced right away, rather than waiting for weeks to run into a similar problem ourselves.
Managing a large group without the bureaucracy
A challenge for any growing product team is keeping more and more people on the same page, but retaining the same speed, efficiency and lightweight process that lets you ship fast. This challenge is particularly true for cross-platform teams. With more voices and more technologies to consider, slowing down seems inevitable.
On paper, our 15 person standup was the antithesis of what a good stand-up should be – a quick, lightweight way for teams to share daily and weekly progress. It also breaks pretty much every rule around team size at Intercom. The last thing anyone needs to start their day is 15 people shouting over one another.
In fact, our 15 person stand-up increased the signal-to-noise ratio. If an engineer is working on a feature for web, and I’m working on a feature for iOS, we can take it offline after the standup and learn from what we’ve accomplished so far.
Surprisingly, when we scaled a 6-person mobile stand-up to a 15-person cross-platform one, the time stayed the same. Time is a forcing function – it forces you to take action and produce a result. So with only five minutes allocated, our standups were kept to quickfire updates of what was absolutely necessary.
Learning from other platforms to build a better product
As a company grows and teams scale, product engineers tend to keep their head deep into platform specialism. Do Mobile engineers really care about what’s going with Web? Do the iOS engineers really need to know what’s going on with Android? In reality, learning from other platforms can help open your eyes to different possibilities you didn’t even know were possible.
We found this out in user testing sessions we held for our messenger. With day sessions across all platforms (a day session for iOS, a day session for Android etc.), product engineers could sit in on sessions that went beyond their respective specialisms. For an iOS engineer to watch people using the product on web forced us to take our heads out of the sand. Things we hadn’t even thought of on mobile were slowly revealed, and vice versa.
For example, a core part of our new messenger was the team and teammate profiles. We spent many, many months designing, building and polishing these in order to make the messenger feel as personal as possible. However, user testing taught us that users simply didn’t discover this new feature, as it was in a collapsed state by default.
This wasn’t just a discoverability problem on mobile. We witnessed users ignoring our new profiles feature across iOS, Android and Web. Being exposed to all three platforms in user testing meant the whole team could confidently proceed towards a solution across platforms.
When most people think about working across platforms they think about the technical implications and the complexity of optimizing for each one. But working across platforms isn’t just a technical challenge, it’s an organizational one too. With so many additional voices and vested interests, the danger for today’s product companies is that you end up shipping product at a glacial pace.
What we found was that having a common objective, a clear sense of ownership and accountability, and a strong culture of learning from one another, working cross-platform was something we could celebrate, not something that slowed us down.
Editor’s note: This is fourth of five posts explaining the thinking behind our new messenger.
コメント