How TPMs’ Involvement in Building a Roadmap Empowered Our Engineers: The Ideal Face of Collaboration From the Perspective of RFS

In October 2021, we launched the RFS (Robust Foundation for Speed) project for the purpose of strengthening Mercari’s foundation for service and feature development. The project was launched to support disruptive growth across the entire Mercari Group and aims to solve complex technical challenges and drastically strengthen the shared foundation of all Mercari Group companies.

A year and a half after the project started, we sat down with key members to talk about the changes that RFS has brought to their organization. This article focuses on the collaboration between engineers and technical product managers (TPMs) working in the transaction area. We invited members with these roles to take a look back from their own perspectives at the changes and impact that have resulted from their collaboration.

Having discussions and formulating a roadmap in the early phases of the project helped lead us to success

——To get started, could you tell me about the kinds of discussions the engineers and TPMs had in the early phases of the project and how you determined your priorities?

@takady：For roughly the first three months, we worked to understand the domain and had “code reading circles” to acquire knowledge; in January 2022, we started our activities for RFS in earnest. First, we defined the transaction domain as an overall design split into detailed subcomponents. Then, we determined the priority for working on each subcomponent, and saw that we needed to create a roadmap for RFS refactoring. This is where we worked with the TPMs, including @Suwen, to consider plans for the development of features planned for the future, and together created a roadmap that would allow RFS activities to contribute to the product.

@eric.j：I think the most valuable part of the collaboration for me was figuring out which subcomponents we should prioritize based on the product roadmaps, which is similar to what @takady mentioned. I also think that hearing about upcoming features gave us an opportunity to have more foresight about how we could proceed with the decoupling work and where the subcomponents were actually located. In that respect, I think our collaboration was a very enjoyable experience.

Eric Jelliffe（@eric.j）

@Suwen：Allow me to explain how things were from the TPMs’ perspective. I actually joined the Transaction Team a couple of months before @takady and @eric.j. Prior to that, there were no TPMs working in the transaction area. After I started working together with the Transaction Team, we suggested a lot of ideas in order to improve the UX of checkout and transactions. Based on VOC (Voice Of Customer) and potential growth areas, we also conducted a variety of research, and the TPMs created a list of ideas.

However, it’s true to say that until @takady and @eric.j were added to the Transaction Team, it was difficult to estimate the scale of our work. For a long time, no teams were taking the initiative to improve the transaction features or code. The design of the transactions were also coupled in a complicated way, and adding new features without sufficiently investigating the impact it would have on the system was too risky, so it took a lot of time to add features.

To address this, the people on the engineering side made a suggestion. They proposed refactoring the transaction code by using a component-based design in order to improve maintainability and productivity. That was the starting point for discussions about RFS for the transaction area.

As was mentioned earlier, we had already done some research and come up with some big ideas based on that. For example, around the checkout area, as well as the integration of the purchase history for Mercari Shops and the C2C Mercari marketplace, we wanted to introduce new features like displaying the points for Mercard. Additionally, we wanted to introduce more flexibility for different types of fees, and we also had some ideas about how to improve the communication experience, such as transaction messages.

By the time I shared a list of ideas and priorities with @takady and @eric.j, they already had an idea of the components we might have. In this way, the cooperation between us was based first on business priority, second on the cost for decoupling, and third on certain dependencies. Based on this information, we decided which components to prioritize.

——How do you think the collaboration between the engineers and TPMs accelerated the project?

@takady：There are some areas where it’s really hard to determine how to proceed with system improvements based only on engineering concerns. This is because if you proceed with decision-making based solely on the engineering involved, it won’t necessarily be tied to improvements to the product that you can actually see.

So, thanks to the TPMs laying out mid-to-long term plans for feature development, we were all able to share our vision, and based on this, we were able to make decisions on the RFS project about which components we thought should be prioritized. As a result, we were able to add new features to what everyone worked on for RFS, and we’re currently working on a few projects to develop new features as well. By having the TPMs and the engineers share the roadmap and think about our priorities together, we were able to forge ahead with the project with confidence.

Yuichi Takada (@takady)

@eric.j：Developing a microservice like the Checkout Fee Calculator was one of the outcomes we achieved using RFS. Without the driving force of RFS, there likely would not have been any momentum to build this microservice. By being involved in the development of microservices, our team members were able to go beyond the area to which they were assigned, and they had the opportunity to get involved with programming languages that they had never touched before, which I think is great.

RFS functions as a business enabler

——So, how exactly did the project move ahead?

@Manesh：I joined the Transaction Team as a TPM at the end of August 2022. That’s when movement to bring together the customer information of Mercari Shops and Mercari JP’s customer information started, which was something mentioned in that year’s roadmap. As part of that, one of our initiatives involved purchase history consolidation which was trying to integrate C2C items as well as B2C (Mercari Shops) items all in one place. For that, we wanted to catch up on the purchase history component of existing systems, and so that’s where we started.

Manesh Patil (@Manesh)

@adachang：Before the project could move ahead, some subcomponents that we had defined and which would provide purchase history existed as concepts, but we still hadn’t written them as code.

We received advance information from the TPMs that we would be starting the purchase history consolidation project and also heard the rough requirements, so the engineering side went ahead and started with the refactoring of the purchase history subcomponent. Some of the tasks we took care of included defining things like the borders between subcomponents as well as the interface and writing these things as code. We also added some test code as well. In this way, we ensured that it would be easy to work on purchase history consolidation when we got started on the project.

As a result, we didn’t have to make a lot of corrections for purchase history consolidation; however, I’m glad we did this work because it allowed us to find bugs in the existing implementation and to improve overall performance.

Yuta Adachi (@adachang)

@Manesh：From my perspective as a TPM, I think that RFS truly functioned as a business enabler. Decoupling the purchase history component was also indispensable to building a highly scalable solution.

Previously, because of the monolithic architecture, it was difficult to estimate how much effort we would need to build a particular feature on top of existing architecture. This is why the decoupled architecture of the purchase history component was very helpful for us to build a solution that would be easily maintainable. You could say that RFS contributed to improving the maintainability and accessibility of the solution.

@adachang：The purchase history consolidation project wasn’t a project that was linked directly to RFS, but I think that it was a great outcome as something borne from collaboration.

I haven’t had the chance to collaborate with @Manesh recently, but working on the same team, we developed such things as a feature that allows users to react to transaction messages using emojis and a template feature for writing transaction messages. In addition, his team was also in charge of the update of the to-do list for listers, the Mercard promotion screen that is displayed with a transaction is complete, the screens displayed for promoting Mercoin, and the feature that displays a congratulatory message to users when the point returns rate of their Mercard increases; they accomplished all of that in the space of the last six months.

The exchange of ideas and knowledge between TPMs and engineers will help evolve Mercari’s systems to the next stage

——I’d like to wrap this interview up with a question for the two TPMs. What outcomes have been achieved and what do you think should be accelerated as a result of collaboration between TPMs and engineers?

@Suwen：Previously, teams working on the business side and the PMs had this impression that the transaction area was really complicated and therefore shouldn’t be changed. But after RFS, that impression changed. A lot of new initiatives came about for the transaction area, which is now able to contribute to Mercari’s growth. So this is a really positive change.

I think that our next step going forward should be not to have everything coming from outside the team, but rather to have more proposals that contribute to the company’s growth created from the perspectives of the checkout and transaction areas. So my future goal is to continue working with engineering teams while sharing our ideas and initiatives in order to maximize growth speed.

Suwen Weng（@Suwen）

@Manesh：Thanks to @takady, @eric.j, and @adachang, I think people’s hesitation is gone. Like right now, inside Marketplace, as well as at Fintech, people submit a lot of requirements to the Checkout & Transaction Team, but Mercari’s systems are very complicated, especially the API architecture. We worked on decoupling several components and transaction systems and checkout systems. It did help me a lot to understand all the features that the checkout and transaction areas provide.

With the purchase history consolidation project, we were able to substantially reduce the number of user inquiries related to purchase history. I think that is a big gain for us in terms of being able to help out our CS teams who are always busy with inquiries. Our systems have helped them reduce the number of inquiries, which is why we built these features, and we have brought value to users, which is probably also helping us contribute to elements of our main business such as improving our GMV and so on.

On top of that, utilizing the checkout fee calculator microservice is essentially going to improve the performance of devices and our frontend systems as well as help mobile app clients to become lighter because we are now able to bring all the business logic back into our backend systems.

I think those are the fruits of our collaboration. We understand our systems better, and from the TPM’s perspective, we can definitely think of ideas that are easy to achieve and work with. It’s been a great experience.

@Suwen：This collaboration between TPMs and engineers was an experience that made me feel that we were working together as a team. The TPMs did not necessarily lead all matters, but rather the engineering side also shared their ideas and various new initiatives; working this way will lead the next stage of Mercari’s systems. I see this as the best form of collaboration.