Within the PMHQ Slack group, we frequently 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 focusing 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 functions. Based mostly on that, that is how we tackled crew group and have parity, although your mileage could fluctuate. Be aware that I didn’t need to develop for both Home windows or MacOS, so I solely had net, iOS, and Android, however you’ll be able to apply comparable rules.
Be aware: We have been in a novel scenario with offshore groups. Our app builders have been in China, and our net/providers/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 needs to be speaking with each other. Have them be your technical level individual.
2) Have a lead designer who’s in control of UX movement throughout all platforms (net, 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 way of our lead designer as properly.
3) Have one crew for backend, one crew for providers, one crew for net, 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 shocked 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 characteristic.
Discover related crew 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 targets for every dash. Be aware that you’ll want to have at the least 3 concurrent sprints at any given time – one for the backend, one for providers, and one for front-end.
Extra concretely, in case you are utilizing bi-weekly sprints as we did, which means it’s worthwhile to give you 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 complete crew throughout all layers to evaluation 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 crucial breaking level. Have at the least 1 weekly assembly between backend/providers, and 1 weekly assembly between providers/functions. Use the assembly to resolve any cross-layer bugs or as a working session for coordination.
3) When deciding on how you can implement specific options, be sure that your engineering leads/answer architects/designers are considering end-to-end throughout layers. The purpose is to ship an answer, not what’s best for any specific layer or platform. Make sure to doc all the end-to-end answer at a excessive degree, then create the person tickets wanted for every layer/crew.
Additionally, it’s worthwhile to 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 normally design for a specific kind issue first, then port over these psychological fashions and frameworks to the opposite kind issue. Stating a prioritized kind 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 strategy to ship data throughout layers – use it for those who can! Make sure to doc your payload construction and supply an instance payload, in order that front-end builders can write mock endpoints if the backend or providers groups should not but prepared with their totally applied endpoints.
2) We use Section to trace person habits. We doc all the screens and occasions that we anticipate to trace, and in addition hold this in a centralized location. This doc is cut up into an internet part and a cellular part, since cellular makes use of the identical screens, whereas net has totally different sorts of screens and flows. Given that you just wish 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 net/desktop movement is ample.
3) We create a “base ticket” for any front-end characteristic on net / cellular and clone it into its respective platforms, then hyperlink these clones again to the bottom (utilizing JIRA). Engineering leads ought to evaluation and shut the platform-specific tickets. The PM and lead designer solely evaluation and shut the bottom ticket when all the platform-specific sub tickets are completed, in order that they’ll guarantee characteristic parity and constant look-and-feel throughout platforms.
I can’t let you know what number of occasions I’ve needed to look throughout net / iOS / Android and discover that we applied the UI in 3 other ways – and it is a good factor as a result of you’ll be able to 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, Providers, and Net each dash, on the identical time. For us, which means as soon as each 2 weeks.
2) We launch cellular apps each quarter. Be aware that our releases take so lengthy as a result of we have now a number of regression testing wanted when going from model N to model N+1; they might be counting on totally different providers/backend setups, and so backward compatibility and regression assessments are essential.
3) When releasing, you’ll want to 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 choices you’ve made concerning the product because you’ll have a operating log. That is extra useful than making an attempt to run again by way of Git commits and guessing at why you probably did a specific factor!
“Do you could have a separate JIRA challenge per crew (i.e. one for backend, one for iOS, one for Android, and many others.)?”
– Neil Littlejohns, Director of Product Administration at TunnelBear
The way in which we arrange JIRA was with 4 initiatives:
- Backend challenge
- Providers challenge
- Net/desktop challenge
- Cell challenge (iOS and Android)
Our reasoning was that the online (which we referred to as “desktop”) can be considered on bigger screens and due to this fact have essentially totally different UX movement and use instances vs. cellular. We didn’t cut up right down to the person platform, nevertheless, since sustaining that many initiatives is a nightmare (sprints, estimations, loading, and many others.). Somewhat, we cut up by layer, after which for front-end, we solely cut up by kind 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! Which means I needed to keep on prime of 200 tickets per set of concurrent sprints – it may be overwhelming for those who select to do it this fashion.
There’s positively no “one proper strategy to do it”, however this has labored for us fairly properly.
“I’m curious how you could have your JIRA arrange to your Net/Desktop Mission vs Cell Tasks. Let’s say there’s a single characteristic 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 many others., that then breaks down into every platform? It feels like that lives in your Net challenge and also you then clone it for the others.”
It actually will depend on the way you wish to handle characteristic parity in a method that is sensible to you. Right here’s how we did it:
- Create an epic for Net/Desktop and an epic for Cell.
- 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).
- Solely shut the epic as soon as PM / Designer have reviewed all the part tickets inside.
If you wish to be extraordinarily organized, you’ll be able to strive what we did at Movoto: we created a further “pre-development” board the place we tracked all the answer design that was required earlier than tickets ever made it to an engineering crew. 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 mother or father of a number of epics throughout boards as a result of the pre-development board is supposed for the complete drawback assertion evaluation, which then results in answer structure, then to the UX movement, and at last to the UI belongings.
What which means is that we anticipated the PM, answer architect, and designers to actively transfer tickets by way of 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 evaluation the event tickets as soon as they have been marked “prepared for evaluation” by our testers.
Right here have been the statuses on our pre-development board, in case you’re curious:
- To think about: drawback statements needs to be fleshed out on this step.
- In evaluation: we analyze each technical necessities and design necessities and create a proposal to evaluation with our stakeholders.
- In evaluation: we evaluation our proposal with enterprise stakeholders and get their buy-in that our proposed answer truly will remedy the issue assertion that they supplied us.
- In UI design: now that we have now the technical design and the UX design, now we’d like UI belongings 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 growth boards inside their respective backlogs, and hyperlink all of them again to your pre-development ticket. Be aware that “in grooming” signifies that you’re nonetheless hashing out the nice particulars for implementation.
- In growth: transfer your pre-development ticket to this standing as soon as all growth tickets go into lively sprints. This exhibits stakeholders that growth work has begun. Present estimates on supply in order that stakeholders can put together accordingly.
- Delivered: transfer your ticket solely as soon as all growth tickets are completed 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 around the globe in our PMHQ Group!