Frontend Platform use case - Creating a roadmap without a Product Manager

How we created a roadmap for the Frontend Platform team without clear expectations.

Photo by Mitch Mckee on Unsplash

August 2022, Hasura changes the internal team's structure from horizontal teams (the "Console team" with all the frontenders, the "Server team", etc.) to vertical, full-stack "Feature teams" ones that cover a Product need (the "Native DB team", the "GraphQL Services team", etc.). Also, a generic "Product Platform team" has been created to cover all the Product features that do not fall under the umbrella of the various Feature teams. The Platform's team scope also included dealing with high-level tasks and problems that would have allowed the Feature teams to move faster while developing product features.

We (N. Beaussart, N. Inchauspé, and I) were the front-end side of the Platform team and we wanted to ease all the other frontenders' lives by removing some of the huge technical debt that prevent them to work effectively and to release features safely and without introducing a lot of bugs and "fix" PRs.

We then tried to:

1. Identify what front-end tasks fall under the umbrella of the Platform teams in other companies

2. Identify the most important activities to work on

Identify what front-end tasks fall under the umbrella of the Platform teams in other companies

Please keep in mind that while Platform teams are very common in a lot of companies, frontenders are not usually included in those teams. As a result, the public resources for front-end Platform activities are limited. Anyway, we found some great resources that it's worth mentioning:

• And if you need more generic info: this is an introduction about Platform teams from Gergely Orosz. The articles are behind a paywall but they are some of the best out there https://blog.pragmaticengineer.com/platform-teams/

• An article about what allows a Platform team to work well or not https://www.microtica.com/blog/why-your-platform-engineering-team-isnt-awesome

• What does it mean to be in a UI Platform team https://yiou.me/blog/posts/thinking-in-platform

• A great article about Hubspot platform team https://product.hubspot.com/blog/frontend-platform

• The Croz experience at building a successful Platform team

• https://teamtopologies.com/industry-examples/building-a-successful-platform-team-at-croz

• A Quora answer about the alignment between Platform teams and Feature teams https://www.quora.com/How-do-product-platform-engineers-keep-in-touch-with-the-needs-of-product-engineers/answer/Alexis-Larry

By reading them, we found confirmations about the tasks covered by frontenders in Platform teams, such as:

1. Fix the most problematic technical debt that slows down the frontenders of the Feature teams

2. Fix the problems that will slow down the Feature teams in the short term by anticipating the new Product features' needs

3. Maintain Design Systems

4. Create some common patterns and best practices and automate getting them respected

5. Improve and stabilise the various application tests

6. Evaluate new solutions and technologies to better solve internal technical problems

7. Manage and optimise the front-end tools and dependencies

8. Mentor other frontenders and spread knowledge

Due to bug technical debt present in Hasura's front-end projects, how could we (the frontenders of the Platform team) ensure our activities were aligned with the short-term Product needs? How to create a sort of roadmap and stick with it regardless of the everyday problems that could arise from such a complex Product and a lot of engineers? Go ahead 😊

Identify the most important activities to work on

We proceeded by:

1. Interviewing all the stakeholders that are directly or indirectly impacted by the Hasura Console (Hasura's main front-end application and the most problematic one), including

   1. All the developers working on it on a daily basis
   2. All the developers working on it time every now and then
   3. All the Engineering Managers of the teams including developers from the previous points
   4. The Documentation team
   5. The Graphic Design team

2. Collecting all the answers in a shared spreadsheet

3. Summarising the most requested area of interventions (the "Engineering priorities") and categorising them

4. Preparing a presentation for the higher-ups that include

   1. A slide for every single activity (15 in total) with a clear explanation of why it was important, what the activity is, how many (in percentage) stakeholders asked for it, and a T-shirt size
   2. A table that acted as the focus of the presentation, where we asked the higher-ups to put a "Product priority" to then mixed with the "Engineering priorities" that we identified

The final goal was to list specific activities with

1. The Engineering "priority"

2. The Product "priority"

3. The T-shirt size

And creating a roadmap out of this list was a breeze! This also helped us to identify what to not work on, something not very straightforward when you deal with a lot of problems and requests on a daily basis.

Here is an example of the table we created with a bunch of activities we identified:

Conclusion

The higher-ups highly appreciated the initiative and we immediately started working on some of the activities.