Leader Spotlight: Connecting the corners of the world, with Gabrielle Charnoff

---

To Gabrielle Charnoff, product management is all about listening. As the first product hire at JOKR — a grocery delivery app that primarily serves users in Brazil — Gabrielle was tasked with bridging communication gaps between engineering teams based in New York, Germany, Israel, and Latin America. A former investment analyst with a limited tech background, she worked her way up to VP of Product by discovering not only what her customers want, but also what her far-flung colleagues need to deliver a seamless user experience in all corners of the world.

In our conversation, Gabrielle reveals her strategy for managing change across user segments in different locales, establishing constant (and compassionate) communication with the employees and customers most impacted by those changes, and maintaining operational consistency while allowing each of her teams to follow the processes that work best for them.

---

The importance of communication during an acquisition

In 2021, JOKR acquired Daki, a Brazilian company with a similar business model but a totally different tech stack. That must’ve been a complicated migration. What was that process like?

Both JOKR and Daki, which was founded just a couple of months earlier than JOKR, are quick commerce services — 15-minute grocery delivery. It’s like Gopuff in the US.

The most important thing with projects like that is very good communication. You need to be very clear about the expectations and requirements in different phases of implementation because it’s a huge project and all stakeholders have their eyes on it.

For example, in this business, you have the operational and fulfillment side. We use certain tools for warehouse management and delivering orders and picking orders and supply chain. That’s its own product suite, and it’s a very manual process to do that migration, because you’re literally making sure all the products in a hub are in that system and following that system. The team that managed that had to be sure all the product data was in the right format and in the right location. And that’s just phase one.

You also need to be sensitive to the teams and the people involved because, of course, with a migration like that, you have engineers in Brazil who worked super hard on a mobile app that could be perceived as getting replaced, essentially. On the other hand, many lessons learned from building that mobile app and features built were then included in the new app. In that sense, the hard work was extremely valuable. It was just the code base that was replaced. Having said that, it’s still a difficult process when you have your work being changed. You’re dealing with people who, understandably, have attachments, and that’s always something to be sensitive about. That’s why, again, communication is so important to make sure people feel valued.

That sounds like a lot of moving parts, and we haven’t even talked about the customer side yet. What challenges did you encounter when trying to break into a new market?

We needed to make sure we understood the local market expectations and tweaks that we would have to make to the mobile app. So that was really where my focus was, working closely with the design team in Brazil. Of course, you have different payment methods, so we had to make sure we were integrating all the payment methods we needed in our mobile app, which is a complicated process in itself.

There were smaller things, too. The way people tip is different, for one. And since Daki had a different brand than JOKR, we wanted to make sure we incorporated the important Daki brand elements. But the question is, do we do that all in the first rollout or do we do that in a phased way? And that’s where things can get more complicated.

Keeping teams and stakeholders aligned

How are you thinking about stakeholder management through all of this? Both from the user perspective and the engineering perspective.

We worked with a really good design team in Brazil that had the ability to conduct user experience studies and capture the things that mattered with user groups during the wireframe stage. We also did a lot of friends-and-family testing before rolling out. By the time we actually got to production rollout, we had placed hundreds of orders and knew that if a user ordered a banana, the banana would show up.

In addition, we have more than 1,000 people that work for Daki in Brazil. We gave 200 people the app and let them play with it. We collected a lot of feedback and prioritized what we really felt was necessary for the first launch. We felt pretty good about the customer side by the time we went live.

In terms of the engineering and the design teams, we didn’t have a design team at JOKR, so that was newer for me. I was very used to working with engineering, but trying to figure out the combination of engineering design and product was a new dynamic to adjust to.

Aligning management expectations, both the management in Brazil and the global team, with the timing of things was tricky. If that’s not very aligned at the top, the people underneath can have different expectations on what work is getting done and in what priority or in what timeframe. Being really open with each other about what we have and haven’t heard, where there’s a lack of alignment, and then managing upward to make sure we get that alignment has been a big part of the role.

Being as collaborative and trusting with each other as possible is super important. It’s still ongoing; I would say we’re in the middle. We finished the tech migration, but now we have some teams moving to Brazil, which, similarly, requires a lot of communication with the engineers about how that will impact their roles. We want to make sure performance stays consistent and users have no idea what’s happening behind the scenes.

How do you maintain that trust and a collaborative two-way street, especially given that you’re straddling multiple time zones, languages, etc.?

We had three VPs of engineering at JOKR. One was in New York, one was in Tel Aviv and one was in Berlin. And they each had squads under them with different focus areas. New York is very customer-facing; it’s really the mobile app team. Tel Aviv is a full-stack team with a data science, data engineering focus. And Berlin is more of an infrastructure backend services team.

The VPs of engineering in those markets hired their own teams for the most part. I was involved in the hiring of those VPs, but they hired people mostly within their own network. For better and worse, that led to little subcultures being created in each of those markets where they literally speak different languages and have slightly different ways of using Jira, so they work with me differently.

Rather than product or engineering enforcing one process for all of these squads around the world, they all have their own process. That has also been a hugely important lesson of joining a startup and watching it grow: the process works for the team, the team doesn’t work for the process.

As a result, the leaders are happy with their teams and the teams are happy with their leaders. When you have such a strong foundation and close relationships between the VPs and their engineering teams, you already have a lot of trust and a lot of room for open conversations.

Building a company’s product function from scratch

You were the first product hire at JOKR. What did your first 60–90 days look like?

Besides sometimes needing to jump on a bike myself to deliver cookies in NY — which was a lot of fun — when I started, one of the founders, whom I had worked with before, told me, “Your job is to help me build out a team that will sit between New York, Germany, and Latin America,” (we added Israel later).

In certain ways, we were starting from nothing, which had its challenges, including no org structure. In other ways, we had some foundation because my manager had hired a third-party development agency to build a throwaway app and tech stack to buy us time, both to hire the right team and to build out products that fit our longer-term vision.

We raised money quickly and management wanted to start operating hubs immediately, so we needed a basic app to just deliver an order. It was very raw, but that was intentional. Our founders are pretty experienced and they knew that, typically, the most tech debt accumulates, especially at a new company, within the first six months to a year. So the CPTO didn’t want to get stuck with that and instead said lets build a throw-away.

My biggest concern in my first several months was, how do I communicate what we’re going to do to the business teams? There is a change management piece there; even though the tools were not great, teams were getting used to using them, and we were going to slowly replace all of them. That was essentially the beginning of the product strategy, and it looked pretty unsexy in the beginning.

For example, we didn’t have Slack, so we had to get everyone on Slack. I had to make Slack channels for each of the countries. We had to start writing release notes and explaining why we’re doing something. Even if change management is an unpleasant process, you tend to both build trust and patience with teams to get through the bumpier periods by being open with them.

So that was a big part of the job in the beginning, putting in some processes around communicating releases and building relationships with the stakeholders in each country who I would be working more closely with. The second big thing was hiring.

What did the hiring process look like early on? When did you decide to bring in more executive leadership?

We had to build a team, and we were limited because we didn’t want to spend a lot of money on recruiting firms. Also, because I didn’t come from a tech background, I didn’t know tons of engineers, so it was pretty tricky for me. But we looked for stronger VPs who could then manage their own hiring, and that was really helpful.

Looking back, that was a really good decision. Finding those VPs was challenging and it took a lot of interviews to get there, but we ended up also prioritizing the people we found over the location. That’s how we actually ended up with an Israel hub. We weren’t planning on opening there, but we found someone who we thought could be a good fit to run a team with a certain focus that actually made some sense in Tel Aviv.

I have to give kudos to management for being flexible there. That’s kind of the plus side of not having a rigid org structure: you can slightly tweak things based on the people you find versus sticking to something a little too controllingly.

I wasn’t writing product requirement documents in the first six weeks at all. That started months later — which, again, in retrospect, was the right thing because we had time to observe how the business was operating and learn a lot from that, learn from the throwaway app, learn from the most pressing things happening in these distribution centers that required attention and product help. The short-term focus was on those relationships with the businesses and building out the right team. Longer-term, this set us up for success when it came time to actually build products.

Listening as a component of success

How are you thinking about prioritization? There’s probably so many things you want to do. How do you pick and choose what to really invest in and work on?

A lot of product is about listening. Because I was new to the role, I had to approach it with humility. I didn’t know what exactly I was going to build. I had worked with product and tech teams the two years before at SoftBank, but I hadn’t built anything myself. You have to listen to the people around you. Typically, prioritization is about balancing who you’re listening to and about what.

For example, we just wrapped up a feature called Super Daki, which extends our catalog to be two to three times larger than the current catalog we have for users to order from with scheduled delivery. So it’s a way to get into more grocery shopping and, potentially, to reach people outside of our delivery areas. It went live a week ago, and it’s really increased our average order value a lot. It’s just preliminary data, but it’s still great to see.

That’s an example of a project where you have operations involved, marketing, design, lots of stakeholders moving at the same time to get something live. So you’re really playing your role as a team player and keeping in mind what was agreed upon in the board meeting. It’s a high-visibility project, so that kind of takes the lead.

In terms of the medium-sized tasks, let’s say I wanted to update our location flow. That’s where more of the listening comes in. What am I seeing in our product analytics data? Is there any evidence that there’s room for improvement in the conversion in the location flow? Or has it gone down for some reason? Have we heard from our design team that the user experience there isn’t great? Or do I just not personally like the user experience there when I’m eating my own dog food and trying to put my location on a map? But then there is also just a realistic part of the job that’s like, are the designs ready? And is the engineer who is most efficient to fix it available?

At the end of the day, the practical constraints help prioritize all the listening and the learnings you get in terms of what to do first, second, third, etc.

What’s one thing you or your team has accomplished that you’re particularly proud of?

We’ve had some attention from a third-party company that is interested in our tech stack, which just makes me really proud of our team and what we’ve built. Obviously, the business is great, but it’s cool when the actual tech is getting some recognition and is seen as valuable in itself.

It’ll be interesting to see whether that materializes into us kind of, on the side, helping other companies with tech. Either way, that’s a great shout out for our team, especially given all the changes we’ve gone through over the last couple of years.