Revolut funds product bets by results, not intuition

Transcript

Transcribed by machine (Whisper) from the episode’s audio, so a word may be off here and there.

1. 20:28

   Okay, so explain setting these little bets up. I mean, to be honest, it's pretty simple because we were always high-velocity for the company when we released a lot of features, a lot of products. And then at a certain point of time, I decided to install a discipline in building bets because we were building a lot of things, but we were not really tracking how they were performing. So we simply build a staging process when first there is a decision to produce a bet.

2. 20:55

   It can be bottom-up or top-down. Then there is a discussion, call it committee, whether it makes sense to produce the bet. And then if a decision is made, we fund the bet. So we separate a team of up to 10 people, front-end developers, back-end developers, designer, product owner, sometimes data scientist, operational manager. And then they build a new product within 9 to 18 months. And then when they launch the product, we simply look at growth of the product in terms of gross profit.

3. 21:24

   And because we've done it for the last 10 years, we already have launched, say, 50 bets. And then we know that our top 10 bets, they grow, say, 10%, 20% month on month, and they produce 1 million GP, 2 million GP, 3 million GP each month consecutively. Then if we release a bet and then we see that this bet is historically in cohort of the bottom 25% of all the bets, we simply sunset it. So we instill discipline when we're not really running businesses which are not growing very fast.

4. 21:58

   And then bets which are growing very fast, we're actually doubling down, right? So we give them more teams. One team becomes second team, three teams, four teams, five teams. Then it becomes department. Then it becomes a major opinion alliance. So I think this process is just, you know, very disciplined to always filter out things that don't work out. Even myself, I kind of, you know, I don't really trust my intuition in terms of which products to build, which probably is not to build, because historically I was wrong so many times.

5. 22:24

   And I think only approach which like completely algorithmic, right? Top bets you've continued to find, bottom bets you just cut, like within 18 months. This is the trader in you. Exactly. There's a lot of what you're saying reminds me of Bezos, and the way he describes this, all these, like, obviously, these disparate bets that he would place inside of Amazon when he was obviously building the company, and he has a great line where he's like, you need to pour gasoline on the promising sparks.

6. 22:49

   So your whole thing is, I'm going to cut the bottom, but then the top performing, do you have a percentage? Is it 10% top? It's usually up to 25% for all of Bezos. Okay, and then you're just, now we know. You just scale it up. Okay, and you're dedicating a lot more money and resources. Why is it important at the very beginning, before it's unproven, to cap the team size at 10? It's not necessarily 10. It can be a bit more.

7. 23:08

   It just depends on how complex the product is. But generally, it should not be more than 10 people. As a rule of thumb, you need probably two, three back-end developers. In our case, because we also produce mobile apps, you need to have two to four front-end developers, So three to four backend developers, one product owner, one designer, that gives you 10 people. Is the way you're structuring these teams changing because of AI now?