Within the PMHQ Slack group, we frequently get thought-provoking questions that we really feel must 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.
Background
My product at Movoto is organized into three layers – backend, microservices, and purposes. Primarily based on that, that is how we tackled staff group and have parity, although your mileage might differ. Be aware that I didn’t must develop for both Home windows or MacOS, so I solely had internet, iOS, and Android, however you’ll be able to apply related rules.
Workforce Group
Be aware: 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 might 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 must be speaking with each other. Have them be your technical level particular person.
2) Have a lead designer who’s in command of UX movement 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 means of our lead designer as properly.
3) Have one staff for backend, one staff for companies, one staff for internet, one staff for iOS, and one staff for Android. That’s, have one staff for every layer or front-end platform.
Embed QAs / testers into every staff, 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 staff. They may coordinate with the answer architect when developing with the technical design for any specific characteristic.
Discover related staff 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 offers you characteristic parity. Break down your roadmap into sprints, with objectives for every dash. Be aware that you will want to have not less than 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 you should 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 complete staff throughout all layers to evaluate options and priorities collectively – the dash objectives are actually essential as a result of that allows the staff 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 essentially the most vital breaking level. Have not 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 tips on how to implement specific options, make sure that your engineering leads/resolution architects/designers are pondering end-to-end throughout layers. The purpose is to ship an answer, not what’s best for any specific layer or platform. Make sure you doc your entire end-to-end resolution at a excessive degree, then create the person tickets wanted for every layer/staff.
Additionally, you should resolve whether or not your product goes to be designed mobile-first or web-first. The shape issue issues and I’ve observed that the majority 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 maintain 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 in case you can! Make 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 aren’t but prepared with their totally applied endpoints.
2) We use Phase to trace consumer habits. We doc all the screens and occasions that we anticipate to trace, and in addition maintain 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 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 internet/desktop movement is adequate.
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 performed, in order that they’ll guarantee characteristic parity and constant look-and-feel throughout platforms.
I can’t inform you what number of instances I’ve needed to look throughout internet / iOS / Android and discover that we applied the UI in 3 other ways – and this can be 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 unhealthy, so long as you catch it and use it accurately!
Releases
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 cell apps each quarter. Be aware that our releases take so lengthy as a result of now we have plenty of regression testing wanted when going from model N to model N+1; they could be counting on totally different companies/backend setups, and so backward compatibility and regression checks 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 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 means of Git commits and guessing at why you probably did a specific factor!
“Do you may have a separate JIRA mission per staff (i.e. one for backend, one for iOS, one for Android, and so forth.)?”
– Neil Littlejohns, Director of Product Administration at TunnelBear
The way in which we arrange JIRA was with 4 tasks:
- Backend mission
- Providers mission
- Net/desktop mission
- Cellular mission (iOS and Android)
Our reasoning was that the online (which we referred to as “desktop”) could be seen on bigger screens and due to this fact have essentially totally different UX movement and use circumstances vs. cell. We didn’t cut up right down to the person platform, nonetheless, since sustaining that many tasks is a nightmare (sprints, estimations, loading, and so forth.). Slightly, 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 prime of all 4 tasks, in order that I can keep within the loop. Be warned! Which means that I needed to keep on prime of 200 tickets per set of concurrent sprints – it may be overwhelming in case you select to do it this manner.
There’s undoubtedly no “one proper strategy to do it”, however this has labored for us fairly properly.
“I’m curious how you may have your JIRA arrange in your Net/Desktop Venture vs Cellular 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/objectives, and so forth., that then breaks down into every platform? It appears like that lives in your Net mission and also you then clone it for the others.”
– Nameless
It actually relies 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 Cellular.
- In every epic, create platform-specific tales (so Net/Desktop has, for instance, MacOS, Home windows, and Net tales, whereas Cellular has iOS and Android tales).
- Solely shut the epic as soon as PM / Designer have reviewed all the element 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 resolution design that was required earlier than tickets ever made it to an engineering staff. Be aware that this can be overkill, by the best way, because it led to plenty of overhead that had solely ROI.
That’s, every ticket on the pre-development board is the guardian 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 resolution structure, then to the UX movement, and at last to the UI belongings.
What which means is that we anticipated the PM, resolution architect, and designers to actively transfer tickets by means 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/resolution architect/designers would solely evaluate the event tickets as soon as they have been marked “prepared for evaluate” by our testers.
Right here have been the statuses on our pre-development board, in case you’re curious:
- To think about: drawback statements must be fleshed out on this step.
- In evaluation: we analyze each technical necessities and design necessities and create a proposal to evaluate with our stakeholders.
- In evaluate: we evaluate our proposal with enterprise stakeholders and get their buy-in that our proposed resolution truly will remedy the issue assertion that they offered us.
- In UI design: now that now we have 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 improvement 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 wonderful 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 wish to contribute round sustaining characteristic parity throughout platforms? Chat with different product managers around the globe in our PMHQ Neighborhood!
