Should a web and iOS project have one or two tracks/teams/IPMs?
I posted that question to our internal Q&A forum a few months ago. We were kicking off a client on a large project, building multiple applications for web (incl. mobile) and iOS. We expected some disparities in functionality between the two but assumed the iOS client would be a subset of the website. The client dedicated a PM for each track and there were many shared resources across both projects (designers, UX, backend, other in-house integrations). One interesting wrinkle that would be a driving factor: the web would be a backbone app driven by an API that another team was in the process of developing.
I was fortunate to get a variety of viewpoints from Pivots that had been through similar projects (hat tip to Onsi for his great answer that influenced this post!). My hypothesis was that we should stick to one IPM, one standup, etc. and effectively stay as one team as long as possible. Three months in, I wanted to share an experience report on what has worked and where we’re still improving.
Clear Roles
Having a PM for each platform meant we could effectively manage the user experience specific to the device. Mark Pincus pushes for everyone to be the “CEO of Something” and this structure ensured that the PM was not a bottleneck as our development team ramped up to six pairs. Having one designer meant our UI and UX felt consistent across platforms. Do not take for granted that a user transitioning from one device to another will be disoriented by an inconsistent experience. Be careful to watch out for communication issues between PMs, and make sure they’re both describing mutually compatible products. It’s possible to specify a feature in a way that’s subtly incompatible between web and iOS — try to catch these issues early!
Group Discussion
We started off with one IPM but this grew unwieldy (talking through, and pointing out, six pairs worth of work just takes time). We decided to split into two IPMs but the anchor from iOS joined the Web IPM and vice versa. We also ensured that these anchors were part of a pre-IPM process that delivered the broad themes and saved the larger IPM audience from unimportant decision points.
Own the API
As I mentioned, we started off with the expectation that we’d develop our front ends while another team worked on an API to expose their backend. It only took a few weeks to realize this would create a lot of churn and we absorbed a layer of API that let us iterate quickly and optimize endpoints for iOS.
The web is an agile-friendly platform where rapid deployment is possible. iOS, thanks to Apple’s review process, is not. Tying minor tweaks on the web client to a (potentially non-backward compatible) full deploy of the API will almost certainly land you into trouble. You have to think carefully about backward compatibility with the iOS app; imposing a clear separation between the web client and the Rails API really helps. Have (API-level) integration tests in both your iOS suite and your web suite that hit the API app. These integration tests represent the contract that your API agrees to satisfy.
Parallelization is Hard
Understand that parallelizability will be very difficult at the beginning of the project and at major milestones of each sub-project (iOS and web). Breaking stories into tracks of work helps to highlight this. One consequence of two backlogs is a tight coupling of stories across two Tracker projects. iOS features that rely on additions to the API are necessarily blocked until the API team can deliver them, and the PMs must negotiate the priority of these stories in relation to web-centric features. We opted to separate iOS and Web work, but perhaps a more fluid team could better navigate these dependencies.
Build Product One Screen At a Time
We’re actively trying to improve the story mapping/ideation process for new features. It’s helpful to develop high-level features for all platforms at the same time, but it’s unusual that a web-focused feature can be copied verbatim to iOS. Similarly, who breaks the tie when the web and iOS PMs have a different viewpoint on functionality or user experience? Having one ultimate product owner could potentially address this point, yet it’s unclear how they wouldn’t be a giant bottleneck for both teams.
Closing Thoughts
Building this much (this fast) is fun! We stood up complete experiences across three platforms while rapidly iterating on functionality. With a team of this scale it’s critical that you’re re-Incepting your project and including the whole team in roadmap discussions to create a shared product vision.
What did I miss? What are some best practices you’ve discovered managing products across web and mobile?
