Frontend Platform use case - Creating a roadmap without a Product Manager
Tags: frontendplatform, roadmap
Published: 2023-05-31 06:07:33

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


_Photo by <a href="https://unsplash.com/@mmckee30?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText">Mitch Mckee</a> on <a href="https://unsplash.com/images/things/lighthouse?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText">Unsplash</a>_

---

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](https://github.com/beaussan), [N. Inchauspé](https://github.com/nicoinch), and [I](https://github.com/noriste)) 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

3.  Collecting all the answers in a shared spreadsheet

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

5.  **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:

| Area           | Activity                                                                   | T-shirt size | Eng. ⚠ |
| -------------- | -------------------------------------------------------------------------- | ------------ | ------ |
| Perf+stability | Sentry: Mapping feature directories to teams.                              | 👕👕           | ⚪      |
| Architecture   | Providing tools to respect the libraries strategy in the Console.          | 👕👕👕          | 🔴      |
| Architecture   | Update GraphQL and GraphiQL                                                | 👕👕👕👕         | 🔴      |
| DX             | Better docs and tools to run the Console in all modes/types.               | 👕👕           | ⚪      |
| Regression     | Storybook Tests: Reduce the drag in testing different Console modes/types. | 👕👕           | 🟡      |

## Conclusion

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

<!-- If you are curious about some of the stories behind some activities we worked on, you can find them on -->