15 New Feature Releases in Half a Year—A Record of the Web Growth Team’s Efforts

Hello! I’m Shundai Ogawa（@shundai）, technical product manager (TPM) of the Web Growth Team.

Since the creation of the Web Growth Team in June of 2023, we’ve released a total of 15 new features, big and small, contributing substantially to improving the functionality of Mercari on the web. With our team comprising members of over 10 different nationalities, we’ve also taken various creative approaches to collaboration and communication between members and across teams, and achieved great success in this realm, as well.

None of these accomplishments would have been possible without the involvement of all those who worked on the project. In this article, I’d like to introduce the project and our specific accomplishments from my perspective as a TPM. I’ve also invited our project members leading each field—frontend engineer Gary Forster (@gary), backend engineer Jicheng Huang (@tony), QA engineer Theo Paolo Amora Lim (@theo), and designer Mari Kimura (@mura24)—to discuss the details of how we built our team and fostered communication.

Why Mercari created the Web Growth Team

The Web Growth Team was formed in June of 2023 with two important objectives.

The first objective was to enhance the web version of Mercari as a point of entry to our service. While our users had mostly used the Mercari app until now, we were seeing a recent increase in visitors from web searches. We needed to ensure that users visiting Mercari for the first time via our website would have a smooth experience making their first purchase. The Web Growth Team’s goal was to grow the number of Mercari users even further by enhancing the website as a key entry point.

The second objective was to improve features so that existing web users would use our website more frequently. Originally, the UX of our website was almost identical to that of our app. However, through user research and data analysis, we found that users who mainly use our website and those who mainly use our app had different attributes and used our service in distinct ways. We concluded that replicating the UX of the app would not provide an optimal experience for our web users. To address these issues, we worked on adding new features for first-time purchases on the Mercari website, as well as improvements to the UI.

What the Web Growth Team did and the results

We aimed to achieve substantial results within half a year and launched the project with two main goals for the first quarter. The first was to release all relevant features that would allow us to fully test our hypotheses regarding existing users. We noticed that on the web, frequent buyers especially tended to use the “Like” feature to compare different items when considering a purchase. In light of this, we developed the hypothesis that making the “Like” feature more accessible and streamlining the flow from “Like” to purchase would increase the amount of purchases users made.

Our second goal for the first quarter was to break down the issues surrounding the first-purchase feature that so many teams are involved in, and to improve the web UX without adding any unneeded dependencies.In the second quarter, we made use of the foundations we had built in the first quarter and aimed for even greater growth with additional initiatives, such as presenting coupons and other incentives in a clear and timely manner to first-time users and users who are considering a purchase. We also began working with even more teams and preparing for large-scale improvements in the third quarter.

As a result, in the first quarter we released 12 growth hacks and 1 large-scale initiative which produced results that exceeded our target numbers. In the second quarter we were able to grow our numbers even further by incorporating marketing initiatives and made good progress on laying the foundations for the following quarter.

We also made several improvements to the UI that not only provided users with an experience tailored to their browsing environments, but also generated positive results quantitatively. For instance, on the desktop view of the Mercari website, we implemented easy access to frequently visited pages by placing them in the header section and made “Liked” items and items with price drops one click away. These changes allowed us to provide a smoother buying and selling experience to even more of Mercari’s users.

Shundai Ogawa (@shundai)

Collaboration between members and across teams

@shundai: Now, I’d like to have a chat with four of our project members about how we build teams and foster collaboration between members. Thanks for joining me, everyone!

All: Thanks for having us!

@shundai: In working on the web growth project, we had to focus on creating mechanisms and a team structure that would allow a large team to develop large-scale feature improvements with a lean implementation and testing process. In particular, we focused on ensuring quick coordination between the PM, designers, and engineers. What are your thoughts on this as a designer, @mura24?

@mura24: At the beginning of the project, we had made sure that the design phase wouldn’t become a bottleneck for the project. We made sure to evaluate the priority of different features and reach out to other teams to start the collaboration process early. The Web Growth Team often worked on creating different UX for web users on desktop versus on mobile, so it was important to receive reviews from the Design System Team as well as the Design Team. We made sure to build strong relationships across teams from the start that would allow us to reach out and collaborate quickly whenever issues arose. I think that explaining what we wanted to achieve at the beginning helped future communication go a lot smoother.

Mari Kimura (@mura24)

Also, our TPM @shundai often pushed pretty hard with his requests such as wanting to implement three new features by the following week, so it was important to constantly re-evaluate the priority of tasks and to have the courage to postpone the lower priority ones. (laughs)

@shundai: (laughs) True. This was a project that really required a Go Bold spirit! We aimed to ensure smooth coordination constantly so as not to slow things down and block progress.

On the topic of teamwork, @gary, @tony, and @theo, what are your thoughts as professionals in your respective engineering fields?

@gary: The biggest challenge in working on multiple projects as a team was releasing a large number of features quickly while also verifying the results appropriately. Especially when making improvements to the desktop UI, we weren’t able to look at the effects of a single feature and had to verify the cumulative effects of several feature releases on the overall desktop experience.

Gary Forster (@gary)

Recently, we improved our system for testing new ideas. We split users into two groups, 10% without the new features and 90% with the new features, which allowed us to both analyze and compare individual features as well as verify the results of the overall experience with multiple new features. Thanks to this system, we were able to accomplish a staggered release of 12 new features and measure the effects on user behavior while greatly reducing complexity and risk. As the first team to test out this new system, we worked in close communication with the experimental platform team and proactively shared any issues we encountered while using the new system, contributing to improving the developer experience for the company as a whole, as well.

@tony: On the backend, implementing new features involved updating source code, which required cooperation with various teams across the company. In the process, we had to spend quite a lot of time negotiating with backend engineers outside of the project and on various integrations. But the experience was also a valuable opportunity to get a better understanding of the backend structure in other parts of the company, and I’m glad I was able to deepen my knowledge of the system.

Negotiating and coordinating with other backend teams was a big challenge for me. Other teams have their own projects and priorities, as well, and we had to ask them to make time for our requests. But approaching the process with clear communication, a system for collaboration, and an understanding of the constraints of each team allowed us to overcome these challenges successfully and work together in a mutually beneficial way. In that sense, this was the ideal opportunity for me to strengthen my communication skills.

Jicheng Huang (@tony)

@theo: Speaking as a QA engineer, I found that collaboration between the engineers and the TPM was crucial. The larger the team gets, the more difficult it becomes to test and guarantee the quality of all our features. To tackle this challenge, we created a process that allowed everyone to take responsibility for testing new features. Led by the QA Team, we worked on implementing a process that would allow us to uphold our existing guidelines for ensuring feature and service quality when testing our new features and handling bugs that the team encountered. In addition to our efforts around collaboration, we also made sure that the QA Team was involved in the new features from the planning stage so that everyone would be on the same page when it came time to implement and test them.

We also inserted a dogfooding stage before the end of each sprint and had all the developers test the new features before implementing them. This allowed us to ensure both quality and a smooth release.

Maintaining quality while cooperating with the engineers was a big challenge, but I’m grateful that the engineers on the team were open to the new process and took ownership of it.

Focal points for communication between diverse members and teams

@shundai: As a TPM, there are three main things I focus on.

Before all else, when a project is going to be undertaken by a group of diverse members, it is important to define a single source of truth (SSOT) through which all members can understand the newest requirements. When having discussions with the various stakeholders in the project, requirements tend to change frequently. I made sure that we defined the SSOT that would serve as the common understanding for everyone on the project so that if there was any confusion, we could always refer back to it.

The second thing I focus on is the use of written communication. One thing that made our project unique was that our team was made up of members of more than 10 different nationalities. The language that each member was most comfortable using differed, so sometimes it was difficult to convey critical information verbally. That’s why I had the team make use of written communication, especially when members proficient in different languages were involved. This helped ensure everyone was on the same page.

The third thing I focus on is frequent communication. We were in a situation where requirements could change frequently and verbal communication could result in misunderstandings, so I made sure that we communicated without hesitation even if there was the slightest uncertainty.

@theo: We also utilized “Yasashii Eigo” and “Yasashii Nihongo” in our communication. It may have been a little challenging at first, but making a conscious effort to speak in simple English and Japanese that was considerate of the listener in meetings helped ensure that everybody in attendance understood what was going on. We also made sure that important information was documented in the meeting minutes so that it could be translated afterwards. Our daily meetings are conducted in both English and Japanese, so for language learners it’s a great opportunity to improve our language skills, as well.

Theo Paolo Amora Lim (@theo)

@mura24: Through working with the members on this project, I truly experienced how thoughtful and considerate “Yasashii Communication” and other means of communication could be. Personally, my English is not that good, and when members communicated with me they would send Japanese translations of their messages, as well as screenshots or videos when necessary. Our TPM @shundai and a few other project members who were comfortable in both English and Japanese would also step in to help bridge communication, which really helped, as well. Mercari is a company that values diversity, and I feel that the Web Growth Team in particular has many members who are skilled at adapting how they communicate with their counterparts.

Conclusion

In this article, we reflected on the initiatives and results of the Web Growth Team, which played out over roughly six months, and introduced some of our members and how we built our team and fostered communication.

Although working with members of varying nationalities and backgrounds is highly desirable, it can also pose challenges at times. I believe that even if you encounter bumps along the way, continuing to maintain close communication between members and teams and coming up with creative approaches to teamwork will help you discover what works best for your team. I hope that reading about the Web Growth Team’s efforts as an example provides some insight to anyone trying to figure out how to manage their own project!