Streamlining Success: A Deep Dive into Cooltra's Product Workflow

Oriol Marimon-Clos at UXDX EMEA. Video: https://youtu.be/SlONeAsxKj8

Readable transcript: edited from the recording's captions for readability (fillers and false starts removed, punctuation and section headings added). Wording is the speaker's own. Timestamps are positions in the video. Names marked [?] could not be verified against the audio.

Do you believe?

[00:00:00] Good morning Dublin, good morning everyone following online. Well, you've seen I've gone to the barber shop. It's actually the same one, but shorter.

[00:00:14] To believe: to accept that something is true, especially without proof. Do you believe? I'm not going to talk about religion, I'm not going to talk about gods, it's not a theological speech. I'm going to talk about product, product at Cooltra, what we do. It's going to be a presentation which is based on our real experience. But to begin with, I'd like to explain what we do at Cooltra, what the service is. This is chapter one.

This is Cooltra

[00:00:51] This is Cooltra. Cooltra is the European leader in sustainable mobility solutions on two wheels. The company has been running since 2006, 17 years old. This is even before some of the smartphones you are all using right now even existed. The company was born in Barcelona, city of mopeds, city of technology. It expanded and it's now running in eight European countries, with 450 employees, more than 20,000 vehicles, mainly electrical. This is very important: electrical mobility.

[00:01:32] We have more than 2 million users and we have a daily average of 20,000 sharing rentals. This is lots of rentals, just for you to know, because probably this is a very niche industry. Our follower competitor is doing half of the number of daily average rentals. So two very important things in our service: sustainable mobility, and sharing. And at Cooltra we believe in our service to improve quality of life.

How the team got here

[00:02:05] But this has nothing to do with product. This has nothing to do with what we are talking about today, which is UXDX. So let's then talk about the team. As I said before, the company was born in 2006. By that time we had shops, real life shops, nothing online. Mechanics. Everything was managed on Excel. You've been there already. We had no IT team, only mechanics.

[00:02:36] It was only ten years later when we launched the sharing service, and then we decided that for a time-to-market purpose the best strategy was to work with an external company, with a software-as-a-service company, a SaaS. And we still didn't have any IT team. By the way, I joined the company right here, in 2016.

[00:03:04] In 2019 something happened in the company, because we started to have an IT team of ten people, and then we had a big fight, a big cultural fight, because there were lots of people coming from the old company who were more based on the mechanics, on the scooters, on maintaining the vehicles, and then some other people that were more tech lovers, that joined in 2016. So we had a cultural clash, and this was probably the trigger of what happened next.

[00:03:41] It was when we decided that it was strategic for us to build all the technology in house. And it has only been today, this year, in 2023, when we got rid of this external SaaS company, and we have a team of 43 people doing product and IT. We have it split into product and IT in the org chart. I will explain afterwards, that is exactly not like this.

Setting up a product mindset team

[00:04:13] But how did we set up a product mindset team? The first decision we made is that we needed help, because as you've seen, technology was not part of our DNA. So we needed to find outside some people that could help us. Just to share with you, I have in common 351 groups with my boss. Actually it's 354 this morning, not kidding.

[00:04:42] And we had a lot of HiPPO, highest paid person's opinion, in the company. "I want this to be done," everyone was doing this. "I want that to be done," everyone was doing that. So we needed help to change this mindset. We also had huge time pressure to switch from this software-as-a-service company to an internal solution, because every month paying this SaaS company was a lot of money for us.

[00:05:12] And as I said before, we had this cultural clash of people more close to the real world and people that were more close to the technological world. So we needed someone from outside that could help us with this cultural change. So the decision was to start with an external company that would then feed in more and more and more internal people, till one last step where we are only going to be internal and we will be able to work without these external people.

[00:05:52] And the third decision, and probably one of the most important ones, because it was very challenging in our company, was team empowerment. So no boss. The team takes one step beyond and is the one managing everything. The result is flat. So it is a flat, autonomous team. It is flat because the decision making is decentralized and there is no hierarchy. It is autonomous because they take care of everything that happens in the team, so from asking for new resources, doing all the hiring process, taking care of the team itself, is being done by the team. And it is a team because it is a team by definition. They all have the same common goal. So we believe in our team to take the company to the next level.

A deep dive into the product flow

[00:06:56] And chapter three, probably the most important one, because that was the title of the presentation, which is this deep dive into our product flow. This is the process. The purpose I chose this picture of the sky is because it represents part of my message, which is: the sky is the limit. And why is the sky the limit? Because you can adapt the process the way it fits better in your company, the way it fits better in your team, the way it will better help everyone in the company to launch better products. And that's what we did.

[00:07:34] And here, this is our product Kanban. We are not using any of the standard tools that are in the market. We are using Miro, which is most commonly used for the designing process, the thinking process, but we found out that this gave us the highest flexibility to make sure that everything that is happening is being accordingly represented in the board. So in the previous talk we've learned about data visualization. This is about process visualization.

[00:08:13] So it all starts, and this is real, I didn't make it up for this presentation, I just took our board as it is. So we always have on top of the board our product vision, our objectives, which are our values, and the way we prioritize. Because it's very important for everyone to make sure that this information is accessible at any time. There's no need to tell you, you have to click here or go there to find the values or to find how to prioritize. It's important to have it there, so anyone can challenge any decision by saying, no, our prioritization is not defined like this, we need to change the order for this initiative or the other.

[00:09:01] If we go to the right side of the board, we can see which are the things that we do. It's a bit blurry, I totally understand it's a bit blurry, just because of what I said before, it's real information, so some of these things cannot be shared. I'm sorry about that, but it's about the structure of the board. So here on the right side we write down, we post, what do we like in our day to day, in the way we manage the team, in the way we manage the process. It's important for us because if it's written there it means that it has worked in the past. So if we are not acting as it's written there, we need to challenge why we are not following these things that we like, and this means that we need to review whether this is the way we want to work or not.

[00:09:54] Then we have all the initiatives done, and this is a timeline of done. This is our calendar. This is very nice to see how we've been progressing and launching features or ending initiatives. This is very helpful when you need to do a yearly report: then you come here and in five minutes you can do the slides, otherwise it can take ages.

[00:10:21] Then one of the other parts of the board, and probably I would say that nowadays it is one of the most challenging ones, is the dashboard. Again, this is super blurry, it's on purpose, this is real data, I cannot disclose some of these KPIs, sorry about that. But I said that this is one of the most challenging parts of our Kanban because, as I said, the technology we are using is Miro and it's not that easy to link Miro with all these charts.

[00:10:52] Nevertheless, a couple of days per week there is one person in the product area that is in charge of copy pasting all these KPIs, going through them, trying to find out whether there is something that needs to be shared with the team, that needs to be highlighted in our daily meetings. And these two days of the week we spend some time during this standup meeting every day to go through the KPIs, and anyone can ask, and then the team will review whether things are performing as expected or not.

The hall, prioritization and what we are not going to do

[00:11:28] Then, sorry, this is what I said before, the confidentiality disclaimer. If we go to the other side of the board we have what we call the hall. This is the entry door of our product department, where anything that we've heard in the company, it can be a WhatsApp, Slack, in the coffee machine, is written down. So every single idea, need, pain, is written in our Kanban so we can take care of it.

[00:11:57] We also have some sort of ICE prioritization depending on the objectives we have: this cost reduction, increased revenue. And then I don't know if you can see it, but we have an area for all the initiatives that we are challenging. These are things that we are really putting a big question mark on, whether this needs to be done or not. And this is what we are not going to do.

[00:12:21] This is part of our celebration process. Whenever we find something that we say, okay, we are not going to do this, this is super powerful. We've learned before that it's not about what you do, but sometimes it's about what you don't do. It's also very important not to say yes to everything, but to challenge and say no, this is not important, we are not going to do this because it's not bringing the value we are expecting.

Our values

[00:12:46] And this is the core of the Kanban. This is where, whenever we jump into the Kanban, we spend 90% of our time discussing, making decisions, prioritizing. And just a very short theory break, because I've gone through our values before, which are these ones. So our values are outcome over output, pragmatism, and then lean. Lean is very important because it's the umbrella of the seven lean principles, and these are also part of our values, and the way we manage the board is also according to these principles.

[00:13:33] The two final values are very powerful, because this is product shared ownership, meaning that everyone in the team, it doesn't matter if they are doing delivery, discovery, if they are in the data, if they are designers, everyone is owner of the product. There isn't a boss, even if there is someone with a title of chief product officer, but there isn't a boss. We are all owning the product. And the transparency with the rest of Cooltra, this is that we invite people to enter into our board. This is not our secret land. Everyone can go into our board, can check what is going on, can try to understand whether something is progressing faster than other things.

Discovery

[00:14:22] And if we dive into this section of the board, we can see we have it divided with what is traditionally called discovery and then delivery. But at the end of the day what we've got is this caliber, because everything starts and ends in the hands of developers, in the hands of product managers. It's not that we're saying, no, you are a developer, you cannot go there, this is only for product managers. No. We need developers as product managers to make great discoveries, we need data to do perfect framings, and at the end of the process to measure whether the estimated impact has been the one that we estimated.

[00:15:14] So this is how our discovery section looks like. So we have a backlog of initiatives, then we do the traditional framing, we do the discovery of the initiatives, and then everything will jump into the delivery side.

Initiatives, WIP limits and waste

[00:15:35] And this is how an initiative looks like. Because we have this flexibility of Miro, we can paint whatever we want, we can use the colors whatever we want. Sorry designers, I know it's not the nicest color combination, but this is the way we are managing it. So it's very easy to identify who will be in charge of it, it's very easy to highlight and know the impact that we are expecting for this initiative, so that for everyone it is super easy and clear to understand why this is progressing faster than another one.

[00:16:06] Then we have this big initiative that is finance management, which is split down into small user stories. These user stories are written in GitHub, they are all linked, so it's very easy to jump from this card to GitHub to go into the details. We use, for instance, these red labels to highlight there is a blocker here, we need to make sure that we get rid of this blocker to progress with this user story. So very easy visualization for everyone, very powerful.

[00:16:41] There is a convention here that tech tasks, the blue ones, user stories and bugs have to be written for a work estimation of equal or less than three days. Then we have short tasks for only hours. We do not need pairs or the Three Amigos meeting for these short tasks.

[00:17:03] But this is not the perfect world, and we know. We use WIP, so we decide whether we can open or close the bandwidth of the framing step and the discovery step. But we also have waste. For every initiative progressing from one step to another we had to create these waiting rooms, because unfortunately we have not yet streamlined the process where an initiative goes from the beginning to an end super quick, super fast, without these waiting times. And this is inventory. If you have heard about the seven wastes, this has to do with inventory.

[00:17:55] And here we have chaos. This is all these sort of things that are requested and that really make sense to be done but cannot be grouped down as an initiative. So where do you put them? So we now have them here, and this is chaos.

[00:18:12] Today, probably while I'm speaking, the team is already changing this, but not moving cards around, of course, the pulling is something that happens on an hourly basis. But probably they are already challenging whether this is the correct structure or not, because the team is taking care of the process and the team is redefining the process every day, every time. We have a channel on Slack where we are saying, is this the way we want to really represent visually that these small tasks need to be grouped? Do we have a problem here, do we have a problem there? We open the WIP, we close the WIP, we are taking care of this.

Delivery, and believing

[00:18:51] And then if we jump into the delivery space, we have everything divided into swim lanes, which are these green lines dividing the area. And we do pairing, but we do real pairing. We are not sharing a Spotify playlist while coding, we do real pairing. The team has convinced me that pairing is the best way to do coding, to do the development, and I'm totally convinced because I believe in them that it's the best and most efficient way to launch the products.

[00:19:37] Anytime an initiative enters into the delivery, we do our kickoff meetings. They are recorded, they are then shared by anyone that could not attend, and because we also believe in asynchronous management and asynchronous sharing of information, that's also why we save these kickoffs. And well, this is the delivery section of the board.

[00:20:08] And we believe in our process to launch better products, and we really believe that the way of managing the process of product building is very important. So I asked at the very beginning: if you believe, or you don't believe? I don't know. But I'm sure that if you believe in your service, and if you believe in your team, and if you believe in your process, then you will be unstoppable.

Q&A

[00:20:50] Host: How do you convince the HiPPOs, the highest paid employees' opinions, to take a step back and not dominate the direction?

[00:21:02] Oriol: I'm sorry, how do you convince the HiPPOs to take a step back and not dominate the direction? Ah, okay. Yeah, so I was part of the HiPPOs before becoming the CPO. I was a general manager. I have a CEO and founder on top of me. So because I've been working for many years with the founder there is a lot of trust, and because I also was doing this HiPPO and now I really believe in the team, I can convince the big boss that what we are doing is the best way. And I always have to tell him, don't worry, it's going to work, I'm taking care of it. As simple as this.

[00:21:39] Host: So you're using your trust.

[00:21:41] Oriol: Yes, absolutely.

[00:21:43] Host: Okay, fantastic. We have an anonymous one. How much time do you spend on maintaining the process board? Why not use some tools that do this already?

[00:21:51] Oriol: The reason why we chose to go this direction, whether going with Jira, with Kanbanize, with other tools that exist in the market, is because most of the team members have not had the perfect experience with these out-of-the-box tools. So we needed much more flexibility, that's why we went this direction. And because we also feel that investing time into maintaining the board, which I cannot say whether it's one hour per week or three hours per week, it all depends on when there is a pain point that has been identified, which is mostly once per week more or less, and then we can bring our soul into the board. We can make it ours. We really feel it's our board. It's not like every single company working with that tool or the other tool. It is our board. There is a high identity in it, in everything that we have there.

[00:22:54] Host: Okay, nice. It's personalized, it's a bit of an asset. All right, this is a fun question. Why isn't UX or CX goals mentioned in your objectives?

[00:23:03] Oriol: Well, because there is something I didn't mention. Well, I mentioned, but very quick. Probably we only started doing product six months ago. So we switched from the software-as-a-service company into our internal solution by the end of 2022, 19 December, we'll never forget that date. And by that time we still had to bring back some of the features that we had missed, and only in March is when we kicked off with product. So there are lots of things that we still need to learn and need to improve, and because this is a live process I can take this feedback with me, and well, the team is also watching, and then we can try to put objectives into the board. Thanks for asking.

[00:23:51] Host: Nice, bit of a give and take here. One thing, so who is maintaining this board? This is from Romina. Do you spend a lot of time discussing what goes on the board?

[00:24:01] Oriol: So the board is mainly maintained by one of the team members, David. He loves doing it. But he is not doing whatever he wants, "I wake up in the morning so I'm going to change the board." Any time there is a structural change in the board it is being shared in a Slack group, we all vote, we decide whether it makes sense or not. If there isn't any strong opinion against, then we go forward. But decisions are made very, very simple, by voting in this Slack. Very quick.

[00:24:33] Host: Okay, nice. You said he loves doing it. How do you know that?

[00:24:36] Oriol: Sorry?

[00:24:36] Host: He said he loves maintaining the board. How do you...

[00:24:40] Oriol: Well, he loves it.

[00:24:43] Host: Okay, he loves it. I love maintaining these boards. But all right, have you tried other tools to implement a similar process, such as Jira and project boards?

[00:24:51] Oriol: Yeah, I mean, out of these 43 product and IT members there are 32 working with this board, and the rest are not working with this board. It's the app team that is still working with Jira. And what I can say is that, probably because I have some bias because I have already spent lots of time with the board, as I shared here, when I go into Jira it's cold. It's simply cold. I don't see flexibility there. I get into my board, it's so colorful, it's so lovely, it's cosy. It's very nice. And I love changing things, having the flexibility of, no, we have a pain here, so we represent this pain with this sticker, with this color. Super clear for everyone, super easy.

[00:25:45] Host: Nice. So personalize it, it feels a little bit more tailored to you. Okay, let's go, last question. Or not last question. How often do you review initiatives, and what does the review look like?

[00:26:01] Oriol: So whenever something is already into framing, and depending on the results of the framing, this initiative will progress towards delivery or not, depending on the impact that we have estimated that we'll have in the company. And only when there is this WIP limit that we've set up in framing, only when it is empty, it's time to say, okay, let's go for the next initiative.

[00:26:33] Oriol: At the end, when the initiative has already been closed, they are all in the "in review" space, and also depending on how often the KPI is being updated, some of them are daily, some others are monthly, and depending on this time frame we review the impact of the initiative. So it's not a defined number.

[00:27:00] Host: Noted. Okay, wonderful. Let's give a round of applause to Oriol.