In the PMHQ Slack community, we regularly get thought-provoking questions that we feel should be explored in-depth and documented for future reference. We’re starting a new set of Q&A posts to dive into these kinds of questions, and enable everyone in the community to revisit the answers and contribute further!

---

“For the first time, I’m working on a product that spans multiple platforms (iOS, Android, macOS, Windows, Chrome). What are best practices for organizing teams and maintaining feature parity when targeting multiple platforms?” 

– Neil Littlejohns, Director of Product Management at TunnelBear

Here’s my framework for tackling the problem of feature parity across multiple platforms.

Background

My product at Movoto is organized into three layers – backend, microservices, and applications. Based on that, here’s how we tackled team organization and feature parity, though your mileage may vary. Note that I did not have to develop for either Windows or MacOS, so I only had web, iOS, and Android, but you can apply similar principles.

Team Organization

Note: We were in a unique situation with offshore teams. Our app developers were in China, and our web / services / backend developers were in India. Here’s how I would have organized it if everyone were co-located with me.

1) Have a solution architect who knows features across all three layers, and has experience in how the layers should be communicating with one another. Have them be your technical point person.

2) Have a lead designer who is in charge of UX flow across all platforms (web, iOS, Android). If you have the luxury of having platform-specific UI designers, that’d be awesome to have – we didn’t have that, unfortunately, so all UI design went through our lead designer as well.

3) Have one team for backend, one team for services, one team for web, one team for iOS, and one team for Android. That is, have one team for each layer or front-end platform. Embed QAs / testers into each team, to enable them to specialize. You’d be surprised at how many platform-specific bugs a QA can find!

4) Have one senior engineer / lead engineer per team. They will coordinate with the solution architect when coming up with the technical design for any particular feature.

Priorities and Synchronization

1) Create a quarterly product roadmap that is mostly platform-agnostic, and hence gives you feature parity. Break down your roadmap into sprints, with goals for each sprint. Note that you will need to have at least 3 concurrent sprints at any given time – one for backend, one for services, and one for front-end.

More concretely, if you are using bi-weekly sprints like we did, that means you need to come up with 3 teams X 6 sprints per quarter = 18 sprints worth of sprint goals. It’s doable as long as you’re disciplined!

Each quarter, kick off with the full team across all layers to review features and priorities together – the sprint goals are really crucial here, because that enables the team to push back on whether your goals are too aggressive to be completed on time.

2) Because there are 3 layers involved, handoffs between layers are the most critical breaking point. Have at least 1 weekly meeting between backend / services, and 1 weekly meeting between services / applications. Use the meeting to resolve any cross-layer bugs or as a working session for coordination.

3) When deciding on how to implement particular features, ensure that your engineering leads / solution architects / designers are thinking end-to-end across layers. The goal is to deliver a solution, not what is easiest for any particular layer or platform. Be sure to document the entire end-to-end solution at a high level, then create the individual tickets needed for each layer / team.

Also, you need to decide whether your product is going to be designed mobile-first or web-first. The form factor matters, and I’ve noticed that most designers and engineers usually design for a particular form factor first, then port over those mental models and frameworks to the other form factor. Stating a prioritized form factor up front helps keep the teams on the same page.

Architecture and Tracking

1) It’s crucial to use RESTful APIs, and to keep them documented in a centralized location. Also, JSON is a fantastic platform-agnostic way to deliver information across layers – use it if you can! Be sure to document your payload structure and provide an example payload, so that front-end developers can write mock endpoints if the backend or services teams are not yet ready with their fully implemented endpoints.

2) We use Segment to track user behavior. We document all of the screens and events that we expect to track, and also keep this in a centralized location. This document is split into a web section and a mobile section, since mobile uses the same screens, whereas web has different kinds of screens and flows. Given that you are looking to develop on Windows and MacOS as well, decide whether you need a separate section for desktop flows, or whether a joint web / desktop flow is sufficient.

3) We create a “base ticket” for any front-end feature on web / mobile and clone it into its respective platforms, then link these clones back to the base (using JIRA). Engineering leads should review and close the platform-specific tickets. The PM and lead designer only review and close the base ticket when all of the platform-specific subtickets are done, so that they can ensure feature parity and consistent look-and-feel across platforms.

I can’t tell you how many times I’ve had to look across web / iOS / Android and find that we implemented the UI in 3 different ways – and this is a good thing, because you can then compare the results and implement what is best for each platform. Creativity isn’t bad, as long as you catch it and use it correctly!

Releases

1) We release Backend, Services, and Web every sprint, at the same time. For us, that means once every 2 weeks.

2) We release mobile apps every quarter. Note that our releases take so long because we have lots of regression testing needed when going from version N to version N+1; they may be relying on different services / backend setups, and so backward compatibility and regression tests are crucial.

3) When releasing, be sure to document what you released from a feature perspective, even if it’s in a lightweight manner. Your stakeholders will love you for it, and you will be able to clearly defend any historical decisions you’ve made about the product since you’ll have a running log. This is more helpful than attempting to run back through Git commits and guessing at why you did a particular thing!

 

---

“Do you have a separate JIRA project per team (i.e. one for backend, one for iOS, one for Android, etc.)?” 

– Neil Littlejohns, Director of Product Management at TunnelBear

The way we set up JIRA was with 4 projects:

1. Backend project
2. Services project
3. Web/desktop project
4. Mobile project (iOS and Android)

Our reasoning here was that web (which we called “desktop”) would be viewed on larger screens and therefore have fundamentally different UX flow and use cases vs. mobile. We did not split down to the individual platform, however, since maintaining that many projects is a nightmare (sprints, estimations, loading, etc.). Rather, we split by layer, and then for front-end, we only split by form factor.

I also created a virtual board in JIRA that sits on top of all 4 projects, so that I can stay in the loop. Be warned! This means that I had to stay on top of 200 tickets per set of concurrent sprints – it can be overwhelming if you choose to do it this way.

There’s definitely no “one right way to do it”, but this has worked for us reasonably well.

 

---

“I’m curious how you have your JIRA set up for your Web/Desktop Project vs Mobile Projects. Let’s say there is a single feature that you want to roll out across all platforms. Is there a single initiative/ticket that lives somewhere that has the original story/goals, etc., that then breaks down into each platform? It sounds like that lives in your Web project and you then clone it for the others.” 

– Anonymous

It really depends on how you want to manage feature parity in a way that makes sense to you. Here’s how we did it:

1. Create an epic for Web/Desktop, and an epic for Mobile.
2. In each epic, create platform-specific stories (so Web/Desktop has, for example, MacOS, Windows, and Web stories, whereas Mobile has iOS and Android stories).
3. Only close the epic once PM / Designer have reviewed all of the component tickets within.

If you want to be extremely organized, you can try what we did at Movoto: we created an additional “pre-development” board where we tracked all of the solution design that was required before tickets ever made it to an engineering team. Note that this may be overkill, by the way, as it led to lots of overhead that had only medium ROI.

That is, each ticket on the pre-development board is the parent of multiple epics across boards, because the pre-development board is meant for the full problem statement analysis, which then leads to solution architecture, then to the UX flow, and finally to the UI assets.

What that means is that we expected the PM, solution architect, and designers to actively move tickets through statuses themselves on the pre-development board, and make the appropriate updates to each pre-development ticket. In contrast, on the development boards, we had the PM write the tickets for the developers, with the expectation that the PM / solution architect / designers would only review the development tickets once they were marked “ready for review” by our testers.

Here were the statuses on our pre-development board, in case you’re curious:

1. To consider: problem statements should be fleshed out in this step.
2. In analysis: we analyze both technical requirements and design requirements, and create a proposal to review with our stakeholders.
3. In review: we review our proposal with business stakeholders, and get their buy-in that our proposed solution actually will solve the problem statement that they provided us.
4. In UI design: now that we have the technical design and the UX design, now we need UI assets before handing work off to developers.
5. In grooming: once your pre-development ticket makes it to this status, create the development tickets on your development boards within their respective backlogs, and link them all back to your pre-development ticket. Note that “in grooming” means that you’re still hashing out the fine details for implementation.
6. In development: move your pre-development ticket to this status once all development tickets go into active sprints. This shows stakeholders that development work has begun. Provide estimates on delivery so that stakeholders can prepare accordingly.
7. Delivered: move your ticket here only once all development tickets are done and are released to production for the business to use.

 

---

Have thoughts that you’d like to contribute around maintaining feature parity across platforms? Chat with other product managers around the world in our PMHQ Community!