Sustaining Function Parity Throughout Platforms

Within the PMHQ Slack group, we often get thought-provoking questions that we really feel needs to be explored in-depth and documented for future reference. We’re beginning a brand new set of Q&A posts to dive into these sorts of questions, and allow everybody within the group to revisit the solutions and contribute additional!

“For the primary time, I’m engaged on a product that spans a number of platforms (iOS, Android, macOS, Home windows, Chrome). What are finest practices for organizing groups and sustaining characteristic parity when concentrating on a number of platforms?” 
Neil Littlejohns, Director of Product Administration at TunnelBear

That is my framework for tackling the issue of characteristic parity throughout a number of platforms.


My product at Movoto is organized into three layers – backend, microservices, and purposes. Based mostly on that, that is how we tackled group group and have parity, although your mileage could range. Be aware that I didn’t must develop for both Home windows or MacOS, so I solely had internet, iOS, and Android, however you possibly can apply related ideas.

Crew Group

Be aware: We had been in a novel scenario with offshore groups. Our app builders had been in China, and our internet/companies/backend builders had been in India. Right here’s how I might have organized it if everybody had been co-located with me.

1) Have an answer architect who is aware of options throughout all three layers, and has expertise in how the layers needs to be speaking with each other. Have them be your technical level particular person.

2) Have a lead designer who’s answerable for UX move throughout all platforms (internet, iOS, Android). When you have the posh of getting platform-specific UI designers, that’d be superior to have – we didn’t have that, sadly, so all UI design went via our lead designer as nicely.

3) Have one group for backend, one group for companies, one group for internet, one group for iOS, and one group for Android. That’s, have one group for every layer or front-end platform.

Embed QAs / testers into every group, to allow them to specialize. You’d be shocked at what number of platform-specific bugs a QA can discover!

4) Have one senior engineer/lead engineer per group. They are going to coordinate with the answer architect when developing with the technical design for any explicit characteristic.
Discover related group members amongst product communities just like the PMHQ group.

Priorities and Synchronization

1) Create a quarterly product roadmap that’s principally platform-agnostic, and therefore provides you characteristic parity. Break down your roadmap into sprints, with objectives for every dash. Be aware that you will want to have a minimum of 3 concurrent sprints at any given time – one for the backend, one for companies, and one for front-end.

Extra concretely, if you’re utilizing bi-weekly sprints as we did, which means it is advisable to provide you with 3 groups X 6 sprints per quarter = 18 sprints price of dash objectives. It’s doable so long as you’re disciplined!

Every quarter, kick off with the total group throughout all layers to evaluate options and priorities collectively – the dash objectives are actually essential as a result of that permits the group to push again on whether or not your objectives are too aggressive to be accomplished on time.

2) As a result of there are 3 layers concerned, handoffs between layers are probably the most vital breaking level. Have a minimum of 1 weekly assembly between backend/companies, and 1 weekly assembly between companies/purposes. Use the assembly to resolve any cross-layer bugs or as a working session for coordination.

3) When deciding on the best way to implement explicit options, be certain that your engineering leads/answer architects/designers are pondering end-to-end throughout layers. The aim is to ship an answer, not what’s best for any explicit layer or platform. Be sure you doc all the end-to-end answer at a excessive degree, then create the person tickets wanted for every layer/group.

Additionally, it is advisable to resolve whether or not your product goes to be designed mobile-first or web-first. The shape issue issues and I’ve seen that the majority designers and engineers normally design for a specific type issue first, then port over these psychological fashions and frameworks to the opposite type issue. Stating a prioritized type issue upfront helps hold the groups on the identical web page.

Structure and Monitoring

1) It’s essential to make use of RESTful APIs, and to maintain them documented in a centralized location. Additionally, JSON is a improbable platform-agnostic method to ship info throughout layers – use it in the event you can! Be sure you doc your payload construction and supply an instance payload, in order that front-end builders can write mock endpoints if the backend or companies groups usually are not but prepared with their absolutely carried out endpoints.

2) We use Phase to trace person conduct. We doc all the screens and occasions that we anticipate to trace, and likewise hold this in a centralized location. This doc is break up into an internet part and a cell part, since cell makes use of the identical screens, whereas internet has totally different sorts of screens and flows. Given that you just wish to develop on Home windows and MacOS as nicely, resolve whether or not you want a separate part for desktop flows, or whether or not a joint internet/desktop move is enough.

3) We create a “base ticket” for any front-end characteristic on internet / cell and clone it into its respective platforms, then hyperlink these clones again to the bottom (utilizing JIRA). Engineering leads ought to evaluate and shut the platform-specific tickets. The PM and lead designer solely evaluate and shut the bottom ticket when all the platform-specific sub tickets are finished, in order that they’ll guarantee characteristic parity and constant look-and-feel throughout platforms.

I can’t let you know what number of instances I’ve needed to look throughout internet / iOS / Android and discover that we carried out the UI in 3 alternative ways – and this can be a good factor as a result of you possibly can then evaluate the outcomes and implement what’s finest for every platform. Creativity isn’t dangerous, so long as you catch it and use it appropriately!


1) We launch Backend, Companies, and Net each dash, on the similar time. For us, which means as soon as each 2 weeks.

2) We launch cell apps each quarter. Be aware that our releases take so lengthy as a result of we’ve a number of regression testing wanted when going from model N to model N+1; they might be counting on totally different companies/backend setups, and so backward compatibility and regression checks are essential.

3) When releasing, be sure you doc what you launched from a characteristic perspective, even when it’s in a light-weight method. Your stakeholders will love you for it, and it is possible for you to to obviously defend any historic selections you’ve made in regards to the product because you’ll have a operating log. That is extra useful than making an attempt to run again via Git commits and guessing at why you probably did a specific factor!

“Do you could have a separate JIRA undertaking per group (i.e. one for backend, one for iOS, one for Android, and so on.)?” 
Neil Littlejohns, Director of Product Administration at TunnelBear

The way in which we arrange JIRA was with 4 initiatives:

  1. Backend undertaking
  2. Companies undertaking
  3. Net/desktop undertaking
  4. Cell undertaking (iOS and Android)

Our reasoning was that the online (which we referred to as “desktop”) can be considered on bigger screens and subsequently have essentially totally different UX move and use instances vs. cell. We didn’t break up all the way down to the person platform, nevertheless, since sustaining that many initiatives is a nightmare (sprints, estimations, loading, and so on.). Relatively, we break up by layer, after which for front-end, we solely break up by type issue.

I additionally created a digital board in JIRA that sits on prime of all 4 initiatives, in order that I can keep within the loop. Be warned! Because of this I needed to keep on prime of 200 tickets per set of concurrent sprints – it may be overwhelming in the event you select to do it this fashion.

There’s positively no “one proper method to do it”, however this has labored for us moderately nicely.


I’m curious how you could have your JIRA arrange to your Net/Desktop Undertaking vs Cell Tasks. Let’s say there’s a single characteristic that you just need to roll out throughout all platforms. Is there a single initiative/ticket that lives someplace that has the unique story/objectives, and so on., that then breaks down into every platform? It feels like that lives in your Net undertaking and also you then clone it for the others.” 
– Nameless

It actually relies on the way you need to handle characteristic parity in a approach that is smart to you. Right here’s how we did it:

  1. Create an epic for Net/Desktop and an epic for Cell.
  2. In every epic, create platform-specific tales (so Net/Desktop has, for instance, MacOS, Home windows, and Net tales, whereas Cell has iOS and Android tales).
  3. Solely shut the epic as soon as PM / Designer have reviewed all the part tickets inside.

If you wish to be extraordinarily organized, you possibly can attempt what we did at Movoto: we created an extra “pre-development” board the place we tracked all the answer design that was required earlier than tickets ever made it to an engineering group. Be aware that this can be overkill, by the way in which, because it led to a number of overhead that had solely ROI.

That’s, every ticket on the pre-development board is the mum or dad of a number of epics throughout boards as a result of the pre-development board is supposed for the total downside assertion evaluation, which then results in answer structure, then to the UX move, and at last to the UI property.

What which means is that we anticipated the PM, answer architect, and designers to actively transfer tickets via statuses themselves on the pre-development board, and make the suitable updates to every pre-development ticket. In distinction, on the event boards, we had the PM write the tickets for the builders, with the expectation that the PM/answer architect/designers would solely evaluate the event tickets as soon as they had been marked “prepared for evaluate” by our testers.
Right here had been the statuses on our pre-development board, in case you’re curious:

  1. To contemplate: downside statements needs to be fleshed out on this step.
  2. In evaluation: we analyze each technical necessities and design necessities and create a proposal to evaluate with our stakeholders.
  3. In evaluate: we evaluate our proposal with enterprise stakeholders and get their buy-in that our proposed answer really will resolve the issue assertion that they supplied us.
  4. In UI design: now that we’ve the technical design and the UX design, now we’d like UI property earlier than handing work off to builders.
  5. In grooming: as soon as your pre-development ticket makes it to this standing, create the event tickets in your growth boards inside their respective backlogs, and hyperlink all of them again to your pre-development ticket. Be aware that “in grooming” implies that you’re nonetheless hashing out the high quality particulars for implementation.
  6. In growth: transfer your pre-development ticket to this standing as soon as all growth tickets go into energetic sprints. This exhibits stakeholders that growth work has begun. Present estimates on supply in order that stakeholders can put together accordingly.
  7. Delivered: transfer your ticket solely as soon as all growth tickets are finished and are launched to manufacturing for the enterprise to make use of.

Have ideas that you just’d prefer to contribute round sustaining characteristic parity throughout platforms? Chat with different product managers world wide in our PMHQ Group!

Clement Kao

Clement Kao is Co-Founding father of Product Supervisor HQ. He was beforehand a Principal Product Supervisor at Mix, an enterprise expertise firm that’s inventing a less complicated and extra clear client lending expertise whereas making certain broader entry for all sorts of debtors.

Leave a Reply

Your email address will not be published. Required fields are marked *