How we created a new product from scratch

Today, I would like to contribute my bit and tell how we’ve created a new product from scratch in Cabify. I do not mean that it is the way to do it but what worked for us.

My name is Beatriz, I worked as a Frontend engineer for my first year and a half in Cabify and, after 8 months working with User Research, I joined the Fleet squad in the Driver group as a Product Manager.

This squad had just been formed, it was the first time that we all worked together within Cabify. The team was highly motivated and eager to apply all the practices that we had always wanted to follow. No to mention the challenging opportunity to create a new product from scratch. We had to make the most of it in every sense and enjoy it too.

Our mission was to “help fleet managers to grow their businesses” and the approach defined to reach it when I joined, was making a huge technical refactor before we could deliver any value to the user. However, with that mission, how could it be possible?

After 2 months of working together, we had to help out in a huge project that was taking place in Cabify. Although this seemed a demotivation for a new team with a clear approach, for me was a breath of fresh air. Since I joined, I had several questions without answers and it was the opportunity to solve them.

• Which user are we targeting? Who are they? What do they need and expect from us? Why do we have to create a product for them? …

• How important is this project and how are we going to impact in Cabify KPIs? Do our competitors have something similar? …

• What technical limitations we had at that time that keep us from delivering value? …

The research

Our users

Our Operations colleagues had been working with our Partners for many years and they had a lot of context about their needs. They helped us to understand the type of fleets we have, their sizes, some of their needs, and the tasks we perform for them. With this information, we segmented our users into Autonomous, Emerging, Large, and Top Partners.

With our Data Analytics colleagues, we analyze the performance of each of these groups.

To get to know them better, we carried out a research with our workmates from User Research, focusing on several topics:

• Understand daily tasks, how are they carried out, the problems they face, and the needs they have.

• What are the tools they use and what do they solve?

• Do they feel that Cabify was helping and supporting them? How would they like the relationship to be?

• Definition of their ideal tool and why.

• How do they imagine the future of their fleet? Would it be different if they had this tool they’ve designed?

This research gave us a very good base to start with, we identified that a fleet manager performs the following tasks:

Management: tasks that the fleet needs to perform before they can operate and throughout its life cycle like data maintenance of a driver. Operations: tasks related to the activity of the fleet on a daily basis, such as knowing how many drivers or journeys are active at the moment. Reports: review data on their fleet performance. Analysis: detailed examination of these reports to identify areas for improvement, patterns, and new strategies.

We agreed that it was necessary to make 2 products depending on our Partners resources:

• **Cabify Partners API: **Product intended for large fleets that have their own developers and need ad-hoc features.

• **Cabify Partners App: **Web product for small and medium fleets to facilitate the management, visualization, and optimization of their operation.

We also worked on building several ‘User personas’ that could use the App, on which we think of when making product and design decisions.

We insisted very much on understanding what are exactly the needs they were trying to solve behind their wishes. When they talked about their ideal tool, they usually tend to list a number of functionalities that they would like to have. But what was really the need to solve?

Eg: ‘The live map’ Our users are obsessed with the idea that the only way to have control over the performance of their drivers is through a map. They dedicate a person 24/7 to look at a screen with this map searching “things that are going wrong”. But, what if I go away for 10 minutes and at that moment something happened? Did I miss something I had to know? The real need was “I have to know what and when something goes wrong” and that was what we had to work on.

Our competitors

An important part of creating something from scratch is getting to know our competitors well, not only direct ride-hailing competitors but also companies that offer fleet management products. That is why we carried out a benchmark, to try to answer the following questions:

• Which companies give support to fleets? How long have they been on the market?

• What products do they provide? designs, features…

• What’s their mission? what do they want to achieve with that product and why? What audience are they targeting?

Not only as inspiration but also to identify which of the functionalities offered by the competitors were decisive when Partners chooses who to partner with.

The situation at that time on Cabify

The reality is that although the perception within Cabify was that we did not offer any product to our partners, we did offer a product built many years ago that hardly solved their needs.

For a better understanding of our partners’ satisfaction regarding the tools we offered, we launched an NPS survey. It was also sent for an additional reason: we wanted to have a starting point with which to compare ourselves in the future and check if we were doing things right.

In the first NPS, we got an average of 3.5 and 80% were detractor users. Terrible. No worries. It’s OK. This just means that we had a big challenge ahead and a lot of room for improvement.

We decided to do the NPS survey every 6 months. Also, we began to measure some metrics that give more visibility about the use and dependency that the platform generates: daily active users and partners that we have, how many of those users come the next day, how long do they stay in the app…

The product development

First explorations

With all this information we had a solid base to start building the product. We held several brainstorming sessions to define architecture and priorities. Our designer started building the first wireframes that could solve all those needs and insights that we discovered in the research. But, before starting to develop or convert those wireframes into definitive designs, we decided to do a second round of user research to validate them.

We realized that some elements were not understandable, other functionalities were not seen as valuable or weren’t even noticed. And on the contrary, some needs weren’t fully covered yet. So, we iterated again.

Development begins

On one hand, we began to have small sessions with our Partners API users. They have a more exhaustive control of their fleet and a technical team dedicated to creating their own platform.

When we deal with a non-visual product, sometimes it is very easy to fall into the “executing role”, especially when we are talking with clients that generate a large percentage of our market share.

Although sometimes we have to take committed solutions, we always try to understand the need behind it. When the user asks for a feature it doesn’t necessarily mean that they need it. It means that they have an issue or problem to solve. With our expertise and knowledge of our technology and business, most likely, we will reach a solution more appropriate to their needs.

On the other hand, the Partners APP was a very long and challenging development. Every initiative we worked on was segmented to the minimum valuable unit and released to production when it was finished. This helped us to keep motivated because we saw results very early and allowed us to analyze the impact or detect improvements while we continue developing.

After 3 months we launched a very basic version to a few partners, and every month we added new ones. These users were not seeing the “ideal tool” they requested us in the interviews, but they did see progress. We earned their trust back.

In addition, we received feedback on initiatives that we already had on the roadmap. It was something very positive since it was a validation of them.

Being able to see results, observe, and listen to their feedback was the way to not become a feature factory but rather the owners of a product.

Not all the product was done coding

There was a quite challenging part that we had not yet managed to solve: reports and analysis.

At that moment, we offer a quite powerful analytic tool to our users to manage their reports, but complex to understand with the consequence that not all our users use it. Over the years, we’ve generated many reports showing the same metrics in different ways and none of them really filled their needs. Not to mention that it was not very user friendly.

We thought about making a custom section within the app with visuals, data, customization… But why reinvent the wheel? We already had a tool, why were we going to spend lots of effort and time developing something that would be just a 10% effective compared to the current one? So we decided to convert this tool into a product for our partners.

This didn’t come without a cost, we needed to:

• Define what data was useful for our partner and make it understandable with the great work of our Data Analytics colleagues.

• Make it an easy-to-use tool, recreate the same look and feel as the Partners app, and make it user-friendly. Impossible without our designer’s help.

Sometimes we become obsessed with the fact that we have to create a new product from 0 to meet the needs of our users. But many times the solution is to give a different approach to the tools that we have at our disposal.

Launching 🚀

Once we had the first version of our Partners app we needed to communicate it correctly, we used to use an extremely polite tone with our partners, and thanks to our Content and Communication colleagues we created newly fresh weekly communications so we could reach more partners.

Finally, we released the first version for all Partners in Spain in June and we are currently launching it globally.

So what’s next? Iterate. Measure and analyze the data that we are obtaining, and of course, keep listening to our Partners to validate and improve what we already have and new upcoming features.

What matters the most: the team

Throughout the article, I have mentioned a large number of disciplines that have participated in the creation of the product and for me, that is the key to everything: the team.

All of us are the owners of the product: designers, engineers, business, researchers, communication, content, data, product management… We all have a mission that is “Help fleet managers to grow their businesses”. It is with the collective intelligence of the entire team how we will get closer and closer to the perfect solution to the needs of our users.

I am lucky and thankful to be part of a great, motivated, and hard-workers team at Cabify, that makes the challenge of creating a product from scratch seem easier than it really is.

Did you feel identified with this text? Check out opportunities to join the Cabify team here.

Thanks to our amazing designer Esperanza Cáceres for helping me with the illustrations.