Within the PMHQ Slack neighborhood, we commonly get thought-provoking questions that we really feel ought 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 neighborhood 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 greatest practices for organizing groups and sustaining function parity when focusing on a number of platforms?”
– Neil Littlejohns, Director of Product Administration at TunnelBear
That is my framework for tackling the issue of function parity throughout a number of platforms.
Background
My product at Movoto is organized into three layers – backend, microservices, and purposes. Primarily based on that, that is how we tackled crew group and have parity, although your mileage could range. Word that I didn’t should develop for both Home windows or MacOS, so I solely had internet, iOS, and Android, however you may apply related ideas.
Workforce Group
Word: We have been in a novel scenario with offshore groups. Our app builders have been in China, and our internet/companies/backend builders have been in India. Right here’s how I’d have organized it if everybody have 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 ought to be speaking with each other. Have them be your technical level individual.
2) Have a lead designer who’s in command of UX circulate throughout all platforms (internet, iOS, Android). You probably have the luxurious of getting platform-specific UI designers, that’d be superior to have – we didn’t have that, sadly, so all UI design went by our lead designer as properly.
3) Have one crew for backend, one crew for companies, one crew for internet, one crew for iOS, and one crew for Android. That’s, have one crew for every layer or front-end platform.
Embed QAs / testers into every crew, to allow them to specialize. You’d be stunned at what number of platform-specific bugs a QA can discover!
4) Have one senior engineer/lead engineer per crew. They are going to coordinate with the answer architect when developing with the technical design for any specific function.
Discover related crew members amongst product communities just like the PMHQ neighborhood.
Priorities and Synchronization
1) Create a quarterly product roadmap that’s largely platform-agnostic, and therefore provides you function parity. Break down your roadmap into sprints, with targets for every dash. Word that you’ll want to have no less than 3 concurrent sprints at any given time – one for the backend, one for companies, and one for front-end.
Extra concretely, in case you are utilizing bi-weekly sprints as we did, which means you could provide you with 3 groups X 6 sprints per quarter = 18 sprints price of dash targets. It’s doable so long as you’re disciplined!
Every quarter, kick off with the total crew throughout all layers to overview options and priorities collectively – the dash targets are actually essential as a result of that allows the crew to push again on whether or not your targets are too aggressive to be accomplished on time.
2) As a result of there are 3 layers concerned, handoffs between layers are essentially the most important breaking level. Have no less than 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 learn how to implement specific options, make sure that your engineering leads/resolution architects/designers are considering end-to-end throughout layers. The objective is to ship an answer, not what’s best for any specific layer or platform. Remember to doc your entire end-to-end resolution at a excessive stage, then create the person tickets wanted for every layer/crew.
Additionally, you could resolve whether or not your product goes to be designed mobile-first or web-first. The shape issue issues and I’ve observed that almost all designers and engineers often 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 unbelievable platform-agnostic strategy to ship data throughout layers – use it when you can! Remember to 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 aren’t but prepared with their totally carried out endpoints.
2) We use Phase to trace person habits. We doc the entire screens and occasions that we anticipate to trace, and likewise hold this in a centralized location. This doc is cut up into an online 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 want to develop on Home windows and MacOS as properly, resolve whether or not you want a separate part for desktop flows, or whether or not a joint internet/desktop circulate is ample.
3) We create a “base ticket” for any front-end function on internet / cell and clone it into its respective platforms, then hyperlink these clones again to the bottom (utilizing JIRA). Engineering leads ought to overview and shut the platform-specific tickets. The PM and lead designer solely overview and shut the bottom ticket when the entire platform-specific sub tickets are performed, in order that they will guarantee function parity and constant look-and-feel throughout platforms.
I can’t inform you what number of occasions I’ve needed to look throughout internet / iOS / Android and discover that we carried out the UI in 3 other ways – and it is a good factor as a result of you may then examine the outcomes and implement what’s greatest for every platform. Creativity isn’t dangerous, so long as you catch it and use it accurately!
Releases
1) We launch Backend, Companies, and Internet each dash, on the identical time. For us, which means as soon as each 2 weeks.
2) We launch cell apps each quarter. Word that our releases take so lengthy as a result of we’ve got 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 assessments are essential.
3) When releasing, make sure to doc what you launched from a function 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 trying to run again by Git commits and guessing at why you probably did a specific factor!
“Do you’ve gotten a separate JIRA undertaking per crew (i.e. one for backend, one for iOS, one for Android, and so on.)?”
– Neil Littlejohns, Director of Product Administration at TunnelBear
The best way we arrange JIRA was with 4 tasks:
- Backend undertaking
- Companies undertaking
- Internet/desktop undertaking
- Cell undertaking (iOS and Android)
Our reasoning was that the online (which we known as “desktop”) can be seen on bigger screens and due to this fact have basically totally different UX circulate and use instances vs. cell. We didn’t cut up right down to the person platform, nevertheless, since sustaining that many tasks is a nightmare (sprints, estimations, loading, and so on.). Reasonably, we cut up by layer, after which for front-end, we solely cut up by type issue.
I additionally created a digital board in JIRA that sits on high of all 4 tasks, in order that I can keep within the loop. Be warned! Which means that I needed to keep on high of 200 tickets per set of concurrent sprints – it may be overwhelming when you select to do it this fashion.
There’s undoubtedly no “one proper strategy to do it”, however this has labored for us fairly properly.
“I’m curious how you’ve gotten your JIRA arrange in your Internet/Desktop Venture vs Cell Tasks. Let’s say there’s a single function that you just wish to roll out throughout all platforms. Is there a single initiative/ticket that lives someplace that has the unique story/targets, and so on., that then breaks down into every platform? It appears like that lives in your Internet undertaking and also you then clone it for the others.”
– Nameless
It actually relies on the way you wish to handle function parity in a manner that is sensible to you. Right here’s how we did it:
- Create an epic for Internet/Desktop and an epic for Cell.
- In every epic, create platform-specific tales (so Internet/Desktop has, for instance, MacOS, Home windows, and Internet tales, whereas Cell has iOS and Android tales).
- Solely shut the epic as soon as PM / Designer have reviewed the entire element tickets inside.
If you wish to be extraordinarily organized, you may strive what we did at Movoto: we created an extra “pre-development” board the place we tracked the entire resolution design that was required earlier than tickets ever made it to an engineering crew. Word 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 mother or father 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 resolution structure, then to the UX circulate, and at last to the UI property.
What which means is that we anticipated the PM, resolution architect, and designers to actively transfer tickets by 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/resolution architect/designers would solely overview the event tickets as soon as they have been marked “prepared for overview” by our testers.
Right here have been the statuses on our pre-development board, in case you’re curious:
- To contemplate: downside statements ought to be fleshed out on this step.
- In evaluation: we analyze each technical necessities and design necessities and create a proposal to overview with our stakeholders.
- In overview: we overview our proposal with enterprise stakeholders and get their buy-in that our proposed resolution truly will resolve the issue assertion that they offered us.
- In UI design: now that we’ve got the technical design and the UX design, now we’d like UI property earlier than handing work off to builders.
- In grooming: as soon as your pre-development ticket makes it to this standing, create the event tickets in your improvement boards inside their respective backlogs, and hyperlink all of them again to your pre-development ticket. Word that “in grooming” signifies that you’re nonetheless hashing out the effective particulars for implementation.
- In improvement: transfer your pre-development ticket to this standing as soon as all improvement tickets go into lively sprints. This reveals stakeholders that improvement work has begun. Present estimates on supply in order that stakeholders can put together accordingly.
- Delivered: transfer your ticket solely as soon as all improvement tickets are performed and are launched to manufacturing for the enterprise to make use of.
Have ideas that you just’d prefer to contribute round sustaining function parity throughout platforms? Chat with different product managers world wide in our PMHQ Neighborhood!
