Feature hydra: how many heads does your product have?

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?

5 Comments

Robbie Clutton says:

I’ve done two similar projects, one tightly coupled on a new code base, the other loosely coupled on an existing codebase. In both cases if a story meant touching a few components the pair delivering the story would go and build the necessary dependencies. This resulted in a coherent set of applications as any member of the team could be in any codebase so the compatibility remained intact. In both cases the projects also had one PM but the tightly coupled project had one backlog and the loosely coupled backlog had a separate one from the web build.

April 30, 2013 at 6:29 am

Matthew Parker says:

On my current project, we have three applications: a shrinkwrap distributed product, a web application, and an API that allows the shrinkwrap to talk to the website. We have a single backlog, a single product owner, and a single team. Stories often cause us to touch all three applications (story X requires shrink wrap to collect and send data Y through a new API endpoint Z so that it can be displayed in the website on a new page). We’ve been at it for four months, and thus far have not needed to break up into seperate teams and products. Yet we only have two pairs (there’s so much product discovery that goes into developing new epics that its so far not yet possible to get a backlog big enough to support more than two pairs).

April 30, 2013 at 10:33 am

Graham Siener says:

Thanks Matt. You make a great point about your backlog only supporting two pairs at the moment — speed of discovery is certainly a factor in how much product you can build at the same time.

April 30, 2013 at 2:43 pm

Larry McKeogh says:

There are a variety of ways to slice a project up. The two more common methods would be either technical/technology or products. In either instance autonomy is desired to eliminate the bottlenecks and dependencies. Otherwise you end up in a 3 legged race.

It sounds like you essentially broke the project along the product lines. That being the case, there are some questions that can help decide which leads and which follows. These mainly are business related. E.g. larger user base, adoption rates, revenue, etc. Having clear answers to some of these questions can clarify and justify task prioritizing. Breaking the tie as you put it. The other nice part of product separation is the team can slice the project vertically through the entire stack and deliver as features are finished.

Alternatively, a technical division could have been attempted. (front end vs. back end) Many of these projects that I have seen got bogged down though. So you are probably heading in the right direction.

Regarding the technology split, I am curious about the API elements and what the plans are for productizing them? Private vs. public. Not knowing the end consumer’s need – might it make sense to focus on the API, get this out to start growing 3rd party apps if the API is public? This would get a decent foundation while the UX elements could be fleshed out and iterated on if not already done.

I agree with you, parallelization is tricky. You need a disciplined team and great communication to pull it off successfully. Thanks for the update and all the best with the project.

May 3, 2013 at 12:43 am

Graham Siener says:

Larry: you’re right, we decided to draw lines on a product level, but didn’t go all the way down the stack. Essentially, we did split front from backend, at the API layer. Since the API is definitely an internal concern, there was no push to productize it vs. optimize for our specific needs.

We are pushing to make those stacks “fuller” to address this, hopefully it helps!