Mercari Local—How We Developed a Same-Day Delivery Service Remotely While Working With a 16 Hour Time Difference

On July 20, 2021, Mercari US announced the launch of Mercari Local, a way for casual sellers and avid collectors to easily exchange must-have items, everyday goods and unique treasures with their neighbors – all from the comfort of their own homes.

Building on the success of rollouts in major cities including San Francisco, New York, and Houston, the local no-meetup offering previously known as Mercari Now launched nationwide as Mercari Local. With no packaging required, Mercari Local makes local buying and selling a breeze, and it’s especially useful for bulkier listings that are expensive and hard to ship, such as household decor, kitchenware, fitness equipment and baby gear.

Mercari US is a unique organization in that we develop features by coordinating our activities between one office in Palo Alto, California and another in Tokyo, Japan. However, in an effort to prevent the spread of COVID-19 infections, the Palo Alto office shifted to remote work starting in March 2020. In February of the same year, the Tokyo office followed suit.

So how did we manage to drive the development of Mercari Local while working across a huge 16 hour time difference without ever being face-to-face in the same meeting?

For this edition of Mercan, we interviewed two Mercari US engineers on the development team based out of our Tokyo Office: Android engineer Tsuyoshi Yoshioka (@tsuyogoro) and backend engineer Anurag Bharadwaj (@anurag). The US@Tokyo Team has been especially involved in developing features for shipping. What were the days prior to the release date of Mercari Local like? We went ahead and asked.

*During this interview, masks were removed only when taking pictures.

The first thing we listed was a kitchen sponge.

ーCongratulations on the US-wide launch of Mercari Local! And great work!! This service started under the name “Mercari Now.” Roughly when did you start working on development?

@tsuyogoro: The project started in 2019 with a market survey. From that time on we had pushed ahead with feasibility studies. We formed a team to be in charge of development once we decided to actually start developing this service as a feature of the app. Palo Alto focused on the business side of things; in Tokyo, we had the lion’s share of knowledge and experience with implementing features related to shipping, so we handled development.

The first step was for the US@Tokyo Team to go to Palo Alto on a 10-day business trip at the beginning of 2020. We met with our US colleagues to get aligned on the specs and to agree on a direction for the feature. After that, we returned to our respective offices and moved ahead with development and other work. To gauge the needs of the market and to perform validation, we released an alpha version of the feature in April 2020. When we entered the growth phase in July, we released a beta version of the feature for select users; we called it Mercari Now.

The thing that characterized this project was that it progressed in minimal steps. There was also the fact that we would not know how the feature would perform until we actually joined forces with our partner to put it to work. To test whether the feature operated well in real-life situations, we first used the alpha version to list a kitchen sponge…

Tsuyoshi Yoshioka (@tsuyogoro)

ーA sponge!?

@tsuyogoro: Yeah (laughs). At the time the feature was only available within San Francisco. In April, Mercari employees acting as seller and buyer performed a test to see if they could use the feature to deliver a sponge from one part of the city to another. After we had finished a rough survey of the market to gauge demand for this feature, we then moved to the next step of working with the beta version.

Now normally, we would have prepared to promote our product from the building phase or what was the alpha version of the feature. This time, however, we first focused on building. Once we were into the growth phase, or beta version, we started promoting the feature by doing things like publishing messages that invited people to use the service for those times when they want their item in a matter of hours. This is when @anurag joined the development team to help us.

@anurag: I’m pretty sure I joined the team sometime around the end of May 2020. Up until then, I had been working on another project. But to tell you the truth, I was intrigued by Mercari Local from the time I first heard about it. I did things like code reviews so that I would be ready to jump in and contribute at any time (laughs). When the team actually contacted me, I couldn’t have been happier!

Agreeing on a direction for the feature was where we were most aware of the roughly 16-hour time difference

ーSo here’s what I would like to ask you about most of all: How were you able to develop the feature while bridging the 16-hour time difference between the US and Japan? Since you were also working with a partner company, I imagine that for this project you had to make a real effort to communicate well, correct?

@tsuyogoro: For this project, it was important that the members involved agree on a direction. As I said earlier, in order for that to happen, first the US@Tokyo Team had to take a business trip to Palo Alto. For 10 days we had in-depth meetings to cement our agreement on a direction, and to narrow down the points that we as developers needed to know to do our work. We spent four or five hours a day in discussion. If we could come to an agreement on a direction to take, each office would be able to work independently. I was of the mind that we had to come to an agreement over the next 10 days, no matter what. So we pushed on through an agenda and document creation the likes of which, normally, I would never recommend (laughs).

A photo of our business trip to the Palo Alto office. At night, we would all get together to make and share pizza!

Here we all are eating the pizza we created.

ーSo the condensed schedule was to narrow down the points that you needed to know to do your work?

@tsuyogoro: That’s right. There was nothing we could do about the time difference or the distance between our offices. To make matters worse, due to the impact of COVID-19, eventually we would not even be able to meet in person. So this is why it was especially important for us to be aligned on a direction to take. By thoroughly simplifying the direction and targets that we should be looking at, it was like we were stamping out problems that could arise with communication even before they occurred.

Development structure diagrammed by Palo Alto and Tokyo

@anurag: What I noticed as we were moving ahead with development amid the time difference and the distance was that a slight miscommunication could easily lead to a big problem. The impact of Mercari Local was huge, and the project demanded that we work fast. If we didn’t communicate well enough, it would easily create extra work later on. There have been times when, because of a miscommunication, development that should have only taken me two days to complete wound up taking five. This is how I came to realize that if you communicate carefully, it saves time. If something happens during development, you simply have to fix it.

I remained constantly vigilant against discrepancies by doing things like succinctly summarizing what I was working on, holding several meetings to generate a lot of discussion when it looked like development would be complicated, and writing specifications. At the end of the day, we would post our notes on Slack so that other teams could pick up where we left off. One team also relayed their hand-off information regarding development by calling it “next event” information, thereby devising an innovation that made an even stronger impression.

Anurag Bharadwaj (@anurag)

@tsuyogoro: Other than the regular twice-a-week (online) meetings we had, we actually held a variety of meetings. I would say that, rather than the meetings being about what we were actually working on, they were discussions held to help simplify what we had to focus on.

The effect of rotating the role of scrum master

ーDid you change anything about the development structure you’ve used so far?

@tsuyogoro: One thing that was a challenge was that we started rotating the scrum master. For the development of this project, we saw that there would potentially be an increased reliance on our members. We incorporated scrum development in order to eliminate this sort of dependency and to ensure that development proceeded smoothly. In addition, rather than me being the sole scrum master, we rotated this role, believing that rotating the role among various members while incorporating differing points of view would produce more solutions.

What surprised me was how well US@Tokyo Team QA engineer @hilary (Chan Man Ying) worked out as the scrum master! After all, QA is usually executed once development is mostly complete. Until that stage, QA doesn’t have much work to take care of. Against this background, having her take the reins as scrum master went really well.

When I’m the scrum master and I want to communicate with the member in charge of a certain task, I have to contact them through the people who are available at the time, but @hilary can contact that same member directly. It was also reassuring to see that she was interested in process work. Currently, 30 to 40 percent of @hilary’s actual work is split with being the scrum master. Through this project I feel like we were able to more or less learn how the scrum master moves things around for the team.

@anurag: Now, the role of scrum master does not rotate. Instead, @hilary has continued to be in this role the whole time (laughs). In this way we can change the development structure to be minutely flexible. For the past year and a half we have been working to improve its efficiency.

@tsuyogoro: Let me tell you something. . . . As far as I’m concerned, I feel that @anurag’s growth has been great! He’s an engineer who joined Mercari as a new graduate in 2020. He has held retrospectives regularly. When he receives feedback from these, he accepts it earnestly, and then applies virtually all of it. I’ve always gotten the feeling from him that he wants to grow even more!

@anurag: You are too kind! My first job was to build the entire offer feature. I had joined a little late, so I had to play catch-up as I worked, but thankfully, I had a really good experience while working through various code reviews. When I joined, there were still a lot of things that were in the research phase, but we were starting to gather data that showed in a high-visibility format that if we were to drop the feature into our service, it would work well.

Just like @tsuyogoro said, at first sharing our progress did not go well, and we received feedback on this. Personally, I paid a lot of attention to the feedback. What’s more, Mercari Local was also the first project I was involved in as a professional. And that’s why I really wanted to do my best!

@tsuyogoro: That’s great! Let’s agree to make Mercari Local even better going forward.

@anurag: Yes, exactly!! I feel that Mercari Local will generate new demand for buying and selling. I want us to refine this feature even more so that it leads to even better things.