This is 20 Product with me Harry Stebbings.
Now 20.
Product is the monthly show where we sit down with the best product and design leaders of our time.
Today is a very special show.
Bending Spoons is on an absolute tear.
Last month they acquired Vimeo for a billion dollars.
Just this week they acquired Eventbrite for 500 million dollars.
They are famed for buying the beloved Evernote previously.
And today we're joined by one of their product leads, Federico Simeonato.
It was such a joy to have him in the studio and I think this is one of the best product episodes that we have ever done.
But before we dive into the show today, on this show we care about velocity.
Most teams lose it in code review, not in writing code.
Now CodeRabbit fixes that.
The second, a PR opens.
It leaves clear line-by-line comments, calls out what the change might touch and offers one-click fixes.
You can teach your organizational standards using your own custom instructions, such as cursor or clawed rules, and enforce them on every PR.
CodeRabbit has so far reviewed more than 13 million PRs and installed on 2 million repositories used by over 100000 OSS projects.
If you want to cut code review time and bugs in half, try a free month at coderabbitai with the code 20VC.
And while Code Rabbit keeps your code clean, Warp Dev makes it fly.
AI coding is everywhere, but most of it, honestly, it's pretty chaotic.
Code that is almost right, but you don't really understand?
Well, that's why Warp exists.
With Warp, the old lines between terminal and IDE disappear.
It's a seamless environment for coding with agents, where you can prompt plan review and ship production-ready code, edit files, in-app review diffs as you go and deploy straight to production without switching tools.
Warp tops the benchmarks, literally number one on terminal bench, top five on software engineering bench, verified and is trusted by over 600000 developers and used by 56 of the Fortune 500 engineering teams, making it one of the fastest growing AI companies, with revenue growing 30x this year.
With Warp, you don't just get speed, you get code you can trust.
The average developer saves five hours a week with Warp.
That's almost half a day.
Try Warp for free at warp.dev forward slash 20VC.
And to get Pro for only $5 for your first month, use the code 20VC.
That's 20VC.
You have now arrived at your destination.
Fede, I am so excited for this, dude.
You've worked on some of my favorite products.
So I'm thrilled to have you in the studio and thank you so much for joining me.
Thank you.
I'm a huge fan of the show, actually.
My favorite episode, I think, is the one with Nick from Revolut.
I learned a lot from that episode.
Nick is phenomenal.
My biggest takeaway from that episode actually was the fact that they run 26 experiments within the company and then allocate accordingly to who's winning and who's not winning.
I thought it was incredible.
Now, I want to start a little bit on you.
Dentist games for kids.
How did that lead to Bending Spoons and a core role in one of the most coveted companies in Europe?
Yeah.
So when I was at university, I knew that I wanted to start a startup.
And so I just jumped at the first opportunity I got.
I met a friend who was thinking about starting a startup.
We were in Rome for a startup event and he had this idea.
He used to be the administrator for his parents' dentistry study.
And he just saw that if you have to cure a child instead of an adult, you need twice the time.
And so he was like, if we can reduce that, it's probably better, right?
And so he thought, can we just gamify the experience a little bit?
And the insight was good, but the way we implemented the result, I don't think it was great.
And so I learned that you should care about what you're thinking of building.
And yeah, and so that failed, or I mean, it's still alive, but it didn't scale in a hypergrowth way.
And then I just like I wanted this hyper growth feeling and the way I discovered Bending Spoons was on the internet.
And I just read the things that were written on their website and they were so ambitious, so clear so, like we know what we are.
We are having great results, but we are not satisfied.
We are at the scale of downloads of like Twitter or Spotify or stuff like that.
And they are unknown, right?
And I was like who are these people who are getting these results while being unsatisfied by the scale they're at?
And so I started studying.
I just applied as you normally do.
And yeah, I brought some liquor to Matteo, one of the co-founders for my first interview.
And I like to think that that's what got me the job.
And yeah, and that was almost eight years ago now.
Fantastic.
Love that.
We're going to dig into the processes with which Bending Spoons build different products across different lines.
I do just want to start, though.
You started a company there and that led into the product role.
A lot of people today want to become PMs.
What do you find is the best background before entering as a PM?
I think the best background to enter as a PM is either being an entrepreneur, which teaches you to think about things that matter, or being a very good analyst of some kind, like somebody who's done very deep, thoughtful analysis over how something works.
At McKinsey, for instance, like Luca did.
But even in an academic career, it can be.
But just something who's very thoughtful and looks at the root causes of some behaviors or some things that happen.
I think those are both things that matter a lot for a PM.
And so that's what matters a lot as a PM.
We said there about kind of Bending Spoons creating this incredibly coveted brand.
Everyone wants to work at Bending Spoons in Italy if you're in tech.
What would you advise someone to get ahead to get a job at Bending Spoons?
I think people generally try to follow the steps that are supposed to lend you a job.
So like you have a great CV, you're very polite and professional, and that's certainly necessary.
But I think that few people try to go the extra mile and try to do something surprising.
You know something creative?
I really love when people come up with something new.
I think there are great touches that you can invent.
I mean, I just brought a bottle of liquor and it.
I mean it wasn't the only thing, for sure, but I like to think that it helped make an impression, you know, and I like to think that it was a touch of something creative that not everybody thinks about.
The importance of being surprising is very significant.
I always actually say, like, you want to be the purple cow, which is Seth Godin.
You know, you drive past a cow, no one bothers looking, but then you drive past a purple cow.
Wow, that's a big thing.
Yeah.
I think maybe people out of a lack of confidence, they believe I need to look like I'm standard.
I need to look like I don't have any rough edge.
And I would say try to show your rough edges a bit and try to show off a few of your characteristics.
How's what it takes to be good at product changed over the last seven or eight years?
I think that the underlying principle is the same.
You have to find out what matters and you have to make it good.
The way you do that evolves in time.
I think with AI you can build prototypes faster, and so that allows you to test easily, which is something you couldn't do in the past.
But the underlying principle of you need to focus on what matters is still very true today.
I had this wonderful schedule and I'm just kind of blowing it up.
Sorry, as I said to you, I like real conversations.
I do want to go through that, but kind of start at the beginning before that testing element which starts with an idea.
How do you determine which ideas to take and run with versus which to discard within Bending Spoons?
Two ways.
We try to find the best ideas by one, analyzing the top line.
So how valuable is this idea?
How much revenue is it going to bring?
How many more customers is it going to bring?
And we try to be very qualitative about it.
Is it a step change compared to the previous way you do things?
And these things are generally an alternative, because you cannot analyze how much of a step change it is if you don't have a prototype.
So, for instance, on Evernote, I think building things that are useful is the most important thing, but you can never quantify useful.
It's very hard to say this feature is more useful than the other.
So generally the way we try to do it is we see how many people might need it.
Surely you can quantify useful.
Useful might be DAU over MAU as a metric.
But you can't do it in beforehand.
You can't do it before you release it.
You can estimate how many people are going to use a specific thing that you're building, and that is a good proxy for it, but you are not sure.
Could you not look at comparables in other products, look at the metrics they have and then take a bet from there?
Yes, that's the way we try to do it.
I'm just saying that sometimes it's more of an estimate game and a gut feeling like I think this is going to be more useful.
I think that this feature looks a lot like this other feature that we've built, and so it's going to be equally successful, but there's still an element of uncertainty.
Some other times you have literally a business case built for a feature.
For instance, on WeTransfer, we built a feature that allows you to recover expired transfers, which wasn't available before.
We noticed that many people were hitting this page where basically, would tell you the transfer has expired.
You cannot download anymore because, of course, if we had to keep all transfers forever, it would just make costs skyrocket.
And so it's not feasible.
And so we thought well, but if we only allow paying customers to download files after they are expired, then we increase the number of paying customers and we just benefit from it.
And so we can afford to keep the files in storage for longer, right?
And so we were able to model this very accurately in numbers.
Like.
We had a spreadsheet with a couple of different scenarios and we saw what the impact of this feature could be based on how many people were hitting that page daily.
The page of expiration right.
So when you build instead an exploratory AI feature on Evernote, you don't have a business case because you don't know how many people will use it.
You can guess, but it's different.
You said there about modeling what it could be outcome scenario planning.
What have you most miss modeled in the downside or the upside?
Well, I think when you try to launch something new, you always want to look like you're being analytical.
And so you try to make it look like yeah, I've built a business case for this and there is a scenario in which it works.
But then when you launch this kind of projects that are like greenfield, they rarely work.
And so it's kind of hard because yeah, I saw a scenario where it could work, but it didn't.
So, for instance, we tried to launch during COVID.
I had a small team and we were trying to launch a fitness product for people that were training at home.
And we were like, yeah, let's build a business case for it.
And the business case was good.
But then of course you just have to look at the reality of.
Do people actually want to use this product?
They wanted, but it was very hard to convince them.
Why did you decide that was a good idea?
Just out of interest, like fitness products.
There's so many kind of freemium where you then hit a hard paywall such a saturated market.
Why did you decide that was a good idea?
Yeah.
A few years ago, one of our biggest apps was called 30 Day Fitness.
It's still there.
It still works.
It's still a very good business.
But at the time, it was one of our biggest apps.
And one of the things that we noticed is that 30 Day Fitness is a good product because people want it, but it's not great at retaining people, meaning that after a while, people lose the motivation that they need to show up every day.
You know, when you're training, it's hard to every day remake the decision of a workout today.
And so we wanted to solve this and we were like, can we find a way to get people to be motivated?
And the best way to do it is if you have a personal trainer, right?
But a personal trainer is expensive.
And so we thought, can we make having a personal trainer inexpensive?
And since during COVID, people were used to doing things on Zoom or on video calls, we were like yeah, let's put a few people in a WhatsApp group and have a personal trainer that is paid by all of them.
So they just need to pay 1 20th of a personal trainer, but the personal trainer is in charge of keeping each of them accountable.
The idea is good, but it turns out that it's not enough.
You need somebody who calls you out directly, like, Harry, you're not working out today.
Why are you not here today?
30-day fitness, you mentioned there, still being like a business.
How much of a money does a business like that make years afterwards?
I'm not sure what it makes today.
I think it's still in the several millions a year.
Is that a paid marketing machine?
There's also a lot of organic traffic going to it because people do look for this kind of product.
There is a push that people want to be fit, you know, and so they do things organically.
But yes, I think that most of the traffic for 30 Day Fitness was paid.
Yes.
Got it.
Totally.
We're going to get to kind of paid and how we think about that.
I do just want to go back to, we were talking about ideas, testing new ideas internally.
When we think about, like okay, impact on top line.
Can you take me to a product decision where the impact on top line has not been significant, but it was still important for you to do?
And how did you think about that?
I think Evernote is the best example of this.
Many of the things that we do on Evernote are not because we want to increase revenue, but it's because we want to make the product more useful.
And in a very unquantifiable way.
We just trust that, by making the product more useful, people will keep choosing to stay on Evernote.
Evernote is an archetype, is a kind of a product that has great inherent retention because people pour their working hours into it.
And so they build their content, they get familiar with the product.
But really what we do is we try to make Evernote more useful every day, even though we cannot, for each individual feature that we build, analyze its financial performance.
But it's still something that I would still choose to do every day, because it's just so important to people.
Even though we can't demonstrate that the ability to collapse sections on a note, for instance, leads to higher retention, the bulk of it, the long tail of features that you build that make the product more useful, have to matter in your choice to keep using Evernote every day.
How many people still use Evernote?
Millions.
Millions?
Millions.
How many million?
I'm not sure I can share, but millions of people, yes.
Wow.
Yes, yes.
And every day, hours a day.
There are people who run their business on Evernote.
It's just that for us working in tech, this looks weird, because Evernote was popular once and it's not as relevant today in tech pop culture.
But if you run a real estate agency, you might have everything on Evernote.
What metric do you use to guide product success in Evernote?
Is it DAU to MAU?
Is it hours spent in Evernote?
Retention.
Subscriber retention is the most important thing on Evernote.
Making sure that everything we are doing is either not touching or improving the churn rate and especially the level at which you are retained as a customer.
The way I think about retention is it's the percentage of your life that you choose to spend together with a product right.
So, for instance, I am subscribed to Spotify and I've been for I don't know 10, 12 years, something like that.
And I plan on being a subscriber for as many years or even more.
And so it means that Spotify is very useful to me because I spend I choose to spend decades of my life, so like half my life, on Spotify.
And there are people for which Evernote is as useful as Spotify is to me.
And so they choose to be subscribed to that product for decades of their life.
And we absolutely must do everything we can to not mess it up.
I love that in terms of like the commitment attached to periods of your life.
What product decision has led to the greatest churn and what did you learn from that?
The thing we did on Evernote that produced the biggest churn was when we raised prices in 2023, which is something that we thoroughly analyzed and we ultimately made the decision to do it nonetheless.
The reason being we believed, and we still believe it, that Evernote provides a great deal of value to people that use it and that we could optimize pricing.
At the time, we thought we could increase prices and people would still consider it a great deal.
Not all of them, of course.
There is a small amount of people who thought Evernote was either already too expensive or kind of at their threshold.
It's like when you are subscribed to Netflix and you see that every year or two they increase your subscription.
And when you receive the email, you're like, is this still a good deal for me?
It's either yes or no.
And then you make a decision based on am I getting enough out of this product and subscription that I'm accepting to stay subscribed to it?
And similarly on Evernote.
We thought let's increase prices in a way that still it's a no-brainer for the vast vast majority of people, accepting that some people will.
This will be over their threshold and we'll have to let them go.
The most unmotivated people, the least advanced ones, maybe the ones that maybe were already thinking about unsubscribing.
How much did you increase prices by?
I think 50% or 60%, something like that.
Okay, that's quite a lot.
That is different to a Netflix at like a dollar difference where you're like, oh, fuck it.
But what's interesting is that, proportionally to the churn numbers, you increase prices by 50 or 60 and people go whoa, you're making a lot more money in that case.
Yes.
And on one hand, it's like economic play.
It's a financial play where you're making more money.
The thing I like about it is that it all boils down to how useful the product is for you.
And if it's more useful than what you're paying for it, it's a no brainer decision to stay retained, to stay subscribed.
Absolutely.
It also, as you said, it separates the flexi user who just switched to another tool very willingly, versus something different.
Yes.
Do you have any lessons on pricing communication in terms of how to let users know a price is changing?
The right words to use is email.
The best way is it push notification.
Any lessons?
I think what you want to do is you want to be confident about what you're doing, so that you don't fear communication.
If I'm confident that the price I'm asking you to pay is fair, then I can tell you 10 times and you will still make the decision of staying retained.
If you're trying to like shy away and like should we like use bullshit language and not really tell people that we are increasing their prices?
That's a bad move and I wouldn't...
It means that you're not confident that your product is delivering value to people.
You just need to accept the fact that some people this new price is going to be over their threshold for usefulness and just be confident that what you're asking is best for most people.
Do you think you make it easy enough for people to unsubscribe from your products?
Yeah, yeah.
We invest a lot.
I mean, at the end of the day, being here for the long run, it's not just about Evernote, right?
It's about bending spoons, all of our products.
We are acquiring bigger and bigger products.
Instead of making a 2 more revenue on Evernote, it's much more important to build a reputation of a company that you can trust.
And so, instead of like some newspaper, I think famously asked you to call a phone number to unsubscribe.
And that was the only way to unsubscribe.
Then you had to wait half an hour to unsubscribe.
Instead, we review the unsubscription process regularly so that it's not too cumbersome, too frictionful.
That's fascinating.
So we have the idea process and then we have the ooh, we've got something that could be a good idea.
How do we go from idea to early testing and MVP?
What does that look like?
Yeah, it depends a lot product by product.
So on Evernote, it's more about sitting down with customers, having conversations with them, showing them prototypes on Figma, for instance.
Does this look like something that you think is useful for you for your use case?
And then over time, we've started knowing our customers better.
We have a panel of Evernote experts that we know well, and we know their use cases.
And so we know that we can always count on them on providing feedback on advanced features.
When it's a more casual feature, maybe we will want to talk to a more average customer.
So the way we identify the feature that works on Evernote is we just sit down with people and we show it to them.
We show the prototype to them.
We show the Figma to them.
And based on their feedback, we just tweak it or maybe even discard it.
How do you know when to ingest advice and change versus discard it with customer feedback?
It's especially important to realize when people are telling you, I don't need this.
And people never tell you, I don't need this.
They generally tell you, yeah, it looks fine.
It looks okay.
And so you have to be, there's a great book, it's called The Mom Test that you can read.
And it tells you, if you ask your mother, did I do okay?
She's always going to tell you that you did okay, right?
She's never going to tell you yeah, you did poorly or.
This is not good.
You should ask questions in a way that forces people to tell you yeah, I would actually not use this.
So for instance, instead of asking you, how often do you work out?
You will come up with an ideal version of you that says like, yeah, I work out three times a week.
But then I ask you, how many times have you worked out last week?
And you're like, only one, but actually it's because I had a meeting and it was a way.
Okay, well, how many times did you work out the previous week?
Still one because of this other thing.
The previous week, still one.
And so after a while, you notice that the things that people actually do are different from the things that they say.
And so you should ask people, instead of, do you like this feature or would you use it?
You should ask them what's a use case that you had in the last month for which this would have been useful.
And if they can't come up with any, it's a red flag, right?
Any other questions that are very helpful in identifying that?
I love that.
What's the use case in the last month?
Any others?
It depends a lot on who you ask.
If we select a user that we know is very active, then what we can ask is more like how have you organized your system on Evernote, your hierarchy of information on Evernote, your notebooks, your notes, in a way that powers your business or powers your professional life, for instance?
Instead, if you are selecting a user that is maybe a bit more casual or newer, then we should ask more specific questions about, like recently what did you do recently on Evernote?
What reasons did you have for taking notes?
It's very difficult when you have a broad set of customers, ones which are incredibly advanced power users and ones which are much more casual.
How do you advise people on building products for both without alienating either?
It's not easy.
There's no silver bullet that you can pull that makes both happy.
Sometimes you can find things that are useful to both groups.
You should think about your product very specifically, like Evernote.
Should we build Evernote for casual users?
What would casual users do?
They wouldn't pay because they are casual.
And so they wouldn't invest much on a product that just gives them basic functionality.
They have loads of competing products that they can choose from Apple Notes, Google Keep and stuff like that.
And so it doesn't look like it's a great arena to fight great competition.
That's free and that's pre-installed on your device.
How can you win that battle?
Instead, advanced users, you cannot use Apple Notes if you're very advanced.
You cannot use Google Keep if you're very advanced.
So that's a battle that we can win.
So it's very important to realize what arena you choose before you start.
It's very much the same for content, by the way.
I mean, you're very kind in saying that you like the show.
You know, we very much have this question often of do we go deep for fewer or broad for many?
And it's very tempting to go broad for many because it's nice and ego flattering in some ways.
But actually we always choose to go deep for fewer and you get much more product love from a fewer number of people.
Yeah, I like to think that Evernote is never going to be as popular as Apple Notes.
But at the end of one's life I think an Evernote user will remember their experience on Evernote if we've made it delightful enough.
And I don't think an Apple Notes user will care much about it.
Not because it's a bad product, it's just not as relevant.
Do you compare yourself to others?
And how do you advise product leaders to think about competition?
I think you should focus on your customers, to be honest.
Unless you're like getting started, so you don't have a customer base and you need to win people's hearts and you need to win them over.
If you already have an existing customer base, I think your number one job is just to make sure that they love being on that product.
Unless you have some crazy insight for, by doing this, I could 10x my user base.
It's very hard.
It's very rare.
I think you should focus a lot on your customers.
You said, hey, we get Figma mockups and then we'll show them to customers.
Is the way that you're doing design, testing, changing in a world of AI?
And if so, how?
When I was working on Evernote I still am a lot, but when I was focusing only on Evernote, we didn't have lovable cursor and these tools.
And so we were building designs and we were showing them to people and we were asking questions like by looking at this, how would you use it?
Now we can build prototypes and even if they are rough, we can put them in the hands of people and we can just like, ask and use it and we'll observe.
It's kind of different.
Like people tell you that they would do something and then, in reality, when they have a prototype on their computer, they will do something different.
So it's closer to the truth.
I'm intrigued.
Do you do Figma and Figma make?
Do you replace that with a lovable build?
Do you actually just go straight to Cursor and Anthropic and Claw code?
What does that usage on stack look like?
It depends a lot on the team and the project.
Each team decides their own stack, and we don't impose anything.
What do they look like that's different then?
If you take one that's, say, Evernote, what is Evernote?
And then take a WeTransfer, what is a WeTransfer?
So on WeTransfer, we have used Lovable quite a bit.
We use Cloud Code a lot to build prototypes.
On Evernote.
I think we use Figma a lot still just because it's easier to use the components that we already have to make it look like it's actually the same app.
It's a bit of a complex product so it's harder to give the context to an LLM to build things that look very close to the original one.
Do you think we are going to skip the design phase in the future of product build outs and move straight to prototyping in these more vibe code tools?
I think so, to be honest.
I think that the role of a designer will be as important as it is today, maybe even more.
But I think that the tools that we use will evolve.
And so you won't work on pixels and then code, but you will likely merge the two things.
I remember that when I got started with web development very early when I was in high school, I wouldn't have a design that I would try to implement.
I just have like HTML code and CSS and I will try to tweak it to reach my results.
It was a very manual process, but it was all contained inside the code editor, right?
I think that in the future it's going to look like that, where you are acting on the code and tweaking the code because it's so cheap and fast that you're just like tweaking the actual thing, instead of creating an abstraction and then trying to apply it in the code.
How does the proportion of designers to engineers change over time with AI?
It's evolving so rapidly that I don't know how it plays out in terms of team organization.
If I had to come up with an answer right now, I would say that it's going to make designers faster and you can try more things.
So today we have a backlog of 100 ideas and we know that we can only try 10 of them in a few months.
I think that we'll reach a point where we can actually try 20 30 40 50, both because people will be faster but also because the manual work to actually implement those prototypes will be much shorter.
So yeah, I think this means that the designer, who won't work necessarily on Figma as they do today, in the future will work on building these prototypes and coming up with these ideas, and they'll do it more and faster.
That's fascinating to hear actually how you use different tools across different teams.
If we progress that along one stage, we have the idea, we have the prototyping and the putting in the hands of customers.
We then have the, I'm actually going to build it.
How does the build process look for you internally?
Usually is let's try to close the gap between the prototype and something that is production ready.
Because the prototype, if you did it well, it's inexpensive.
And so it means that it lacks a lot of the things that make it production ready.
It's basically a probe to some extent.
We call it a probe.
It's a piece of software that is built to demonstrate that one metric is X or Y, And that's its only job.
And so when people interact with it, They give you the answer, but it's not ready to be plugged into the broader product.
And so this way you can get your answer, but then, in order to be able to plug it to the broader product, you need to do some work.
Do you think it's important to ship fast and be imperfect, or to make sure that that gap between prototype, which is a probe, to fully beautiful product is seamless and complete?
I don't adhere to one of the two schools of thought.
I think speed matters when you're trying things and you're trying to find your way and you're probing the area around you.
But then it's all about polish when you actually need to build something that millions of people use.
You cannot half-ass an experience.
Do you feel that product difference in terms of behavior very much when you are working on a product like Evernote millions every day versus a much smaller user base with maybe a less frequent usage?
Well, for sure.
You feel more responsibility.
You also feel like you stand on the shoulders of giants in some sense.
Sometimes.
I talked to Phil Libin, who was leading Evernote a few years ago, and I don't feel like shipping bad stuff on Evernote just because it's always been such an important product and built in such a caring way that, just by comparison, i don't want to be.
I want bending spoons to have the name of those who are releasing subpar experiences.
I want us to have a good threshold for quality, so when we have that quality and then we decide launch time okay, got to release this.
What have been your biggest lessons on how to do product launches or feature launch as well?
When you want to deliver a lot of things to people who need them, I think it's important to show that you are every week, delivering useful improvements.
So instead of doing a large and fancy launch, you try to do it in a way that feels like every week I'm getting something new.
You know, it really convinces people that you're in for the long run, that you are doing stuff that matters.
And especially that, even if this week nothing gets built, that's specifically useful to me.
Since I've been here for a while, I know that Evernote updates every week.
And so I know that at some point something will be built that is for me, that I need and I use.
Instead, when you want to innovate and you want to try to do a step change in the way people use the product, then it's important to be very considerate and very clear with communications.
So for instance, let's talk about examples.
When we built collapsible sections on Evernote or the slash command menu.
These are utility tools that make your product more ergonomic, more polished, more useful.
You don't need to be flashy about this.
You don't need to do a huge launch and to merge them together and to wait six months.
You need them, to put them in the hands of customers as soon as possible so that they can start getting utility out of it.
Next week we are announcing Evernote v11 and it's going to be a significant change compared to what Evernote is today.
It's mostly a reflection of all the work that went through in the last three years, but it's also containing three advanced AI features that are not available on Evernote today.
And when you do that, it's important instead to like kind of make a mess a little bit.
Not necessarily they should even be unpolished, but like try to be noisy about it so that as many people as possible see that some drastically new functionality is landing on the product.
Totally agree with you there.
And I love that you say that hey, it's better to do small weekly improvements, communicated well, than like don't hear from us and then a big splash every six months.
You do Evernote monthly updates.
Can you just talk to me about that, the process of that, what you learn and how you'd advise other product people from doing that?
This was born out of necessity, meaning that when we acquired Evernote, there were a few months in which we made the decision to work very deeply on the technological foundations of Evernote.
Evernote was launched in 2007, I think, so it's almost 20 years old.
And so it's not full of bad code necessarily, but it's full of old code.
And it's very important that we innovate that and we make it modern if we want to work on Evernote for the next 10 or 20 years, right?
We made the conscious decision of working on tech foundations, but as we were doing that, we were also communicating the acquisition and we were raising prices, as we discussed earlier.
These three things combined for a customer are a lot. a lot to take in.
And so I think that we should have instead started allocating some percentage of our time improving the product in very visible ways that basically reassured people.
Look, we are here for the long run.
Yes, we are making drastic changes.
Some of them are uncomfortable right now.
We truly believe it's the best outlook in the long run.
We need to do them right now, but we are also investing a lot on your user experience.
We didn't do it.
And so people were either skeptical, some were pissed, some were fine with it, they understood.
But I started doing monthly updates exactly because we saw that it was important to communicate to people what was changing in the product.
Putting a face behind the product, I think is important.
It's not like bending spoons as a vague entity that is working on Evernote.
It's Federico and his team who are working on Evernote.
What have you learned from doing those monthly updates and how would you advise other product owners or CEOs on doing monthly updates to customers?
I learned that user feedback matches reality and substance very directly.
So when you issue a monthly update full of content that nobody needs, they'll just tell you this is irrelevant.
I don't need this.
Why are you working on this?
They're very direct in a way that I find motivating, meaning that they're not trying to be kind.
They're trying to be truthful.
And so they just tell you if you're working on stuff that doesn't matter to them.
You can do something very easy.
You can look at our YouTube videos and look at the comments under the videos and see that when we started, we were learning and so we didn't get every update right all the time.
And people will just tell us, I'm pissed.
You raised prices and now you're bringing this stuff that I don't need.
Why?
I don't understand.
Lately.
Instead, we've become much better at understanding what people actually need, what they're asking us.
And so comments are much more either neutral and like, yeah, good.
Now I need this other thing.
Or yeah, this is finally, I've been waiting for this for years.
It's exactly what I needed.
Thank you.
So it's.
The learning is, if you do the substance right and you communicate it decently, people will tell you.
If you don't get the substance right, people will also tell you.
People literally sit down and take notes with these podcasts, which is great.
And it's a real compliment to me that we're doing good and valuable things as granular as possible.
How do you record them?
How long should they be?
Should they include everything or just like the big highlight?
How transparent should you be?
Like, should you really talk about things that are bad?
How do you advise me on those?
Yeah, I sit down once a month.
I think it's a decent frequency.
I think it's enough that people feel like a lot is going on and not like too frequent where you need to be in front of a camera every day or every week.
It should talk about what you're actually doing.
One thing that that we decided early on when we started doing this is we talk about stuff that either we already shipped or that we are launching right now.
We shouldn't talk about plans that we have for the future.
Sometime we break that rule.
But it's not like written in granite.
But it's important that you don't just entice people with promises.
You just tell people what they can do today with the product, so that you build a sense of practicality and trust.
You just tell them, look, slash comments are available on Evernote today.
Just update your app and you will be able to use it.
Here's how it works.
The other side is you also need to teach people how to use this stuff.
It's a complex product.
It's not a shallow product by any means.
So you need to take a couple of minutes to show them if something is very new, here is how it works.
So come with me through the experience.
Yeah.
I mean, tell people what you've done, tell them how it works, tell them decently frequently and be upfront about negative stuff as well.
We were talking about kind of the launch itself and lessons from them.
What launch was the worst where you expected amazing and it didn't meet expectations?
And what did you learn from that?
It wasn't on Evernote.
It's a product that we launched at Benning Spoons that we were really hopeful for.
It was called Playond.
It was Apple Arcade before Apple Arcade.
It's almost exactly the same product, right?
So a subscription, you can play high quality games as much as you want.
You don't need to pay for each individually.
You don't need to pay to win.
You don't need to unlock in-app purchases.
You just pay a subscription like Netflix, but for mobile games, right?
We believed that people would love this and it failed.
We spent, I think like five or $7 million on licensing and eventually it didn't work.
Was it immediately apparent that it wasn't working?
And do you think when you have a product that isn't working, you can tell very quickly?
It depends on how much you're lying to yourself.
If you're very truthful and you have a plan for how do I validate that it's working with metrics, then it's easy.
If you're like...
Let's put it out there and see what people do.
It's a bit harder because then you'll be hopeful, you invested a lot in it and you'll try to find signals of usefulness and signals of retention.
And so yeah, you should be very ruthless with yourself before you start and say these are the metrics that we'll look at when we launch to determine if it's a good product.
And like, I'm the first one who's guilty.
I often lay too much hope behind the product launch.
Okay.
So when we look at play on this like Netflix, but for games what did we not see that we should have seen?
What's our takeaway from that to prevent that happening again?
I think a big part of it that we learned is that when you watch a movie, you watch it two hours and then you're done and the next day you want to watch another movie.
And so it makes sense for Netflix to exist because people want to consume different content.
When you're playing a game, you get passionate about it and generally games have a much longer lifespan.
And so you can definitely play for a game for a month, two months, six months, even a year.
I have a mobile version of Risk, the board game, on my iPhone.
I downloaded it when I was in high school.
I paid for it, and I still play it.
Like yesterday, I was in an airplane, and I played it.
It's been 15 years.
And you paid once?
I paid once.
Yes, it was a single time purchase.
Wow.
Yeah.
The lifespan of that experience is much longer in time.
And so it doesn't make sense to pay a subscription for something that gives you that much runway.
As someone who's invested in gaming before, there is this beautiful retention flatlining.
Actually, when you get to a three to five year line, which is insane to say, but when you look at your games like Candy Crush, they still have this insane flat line three to five years in where it almost becomes like habitual usage every single day.
Yeah.
I've never worked on a game.
I worked on an entertainment app that was very close to a game.
It was called Live Quiz.
Do you remember HQ Trivia?
Yeah.
Dude, do I remember HQ Trivia?
I'm not that young.
Yeah, I absolutely do.
It's one of my hottest rounds.
It was a few years ago.
Yeah.
Smart mechanic, getting everyone together, same time.
I think any behavioral change in product is exciting.
I worked on a clone of HQ Trivia as my first project at Bending Spoons when I joined.
It went hyper viral in Italy.
We did 2 million registered users in Italy only.
Italy is 60 million people in total.
So one in 30 people used to play that game. hyper viral, incredible virality.
And it was so fun.
It wasn't a good business.
I think HQ Trivia wasn't a good business either, but super viral mechanic.
But I'm a bit scared of games.
It's very hard to make them work.
It's even harder than a product, in my opinion, because it's about taste and it's about feelings and emotions and experience.
Utility, as we were saying earlier, you can somehow proxy utility.
You can try to guess how useful a change is going to be in the future.
With games, it's about the experience and the emotions that it gives you.
It's completely qualitative.
Of course you can look at metrics and analyze them, but beforehand, before you launch, it's very hard to say if you're working on a good game or a bad game.
What did you learn from doing the HQ Trivia clone?
How intoxicating working on a successful product can be?
It's just the experience of a lifetime to work on something that goes hyper viral.
We literally launched as a beta test with friends and family.
I remember literally telling people don't tell others, because we can only support I don't know 50 users simultaneously.
100 users.
I don't remember the number, but I literally remember asking people not to tell others.
And we never, never, never did anything else to make it grow.
It just from that moment when I told my family my friends, don't tell others.
It just went viral from there.
We even set aside some money, I think a few tens of thousands of euros to do marketing.
We never touched them.
It just took off.
Sometimes you can see when a product works immediately.
Does Bending Spoons do clones today?
No, we don't launch new products.
I mean, we probably would if we were decently convinced that we have a good shot at making something very good, very useful successful, impactful.
I'm not saying that we wouldn't, but no, it's been a while since the last time we did.
Play on was one big project didn't hit in the way that you thought it would.
What did you not expect to hit that suddenly did hit?
And what did you learn from that?
We were chatting earlier about never studying your successes, which is why we don't actually attribute lessons to them often.
Yeah.
Can you take me to what you didn't expect to hit that did in the lessons?
Sometimes there are things that look a bit boring and instead they just work.
So for instance, I think audio transcription on Evernote is one such example.
We were almost about not to launch it because people weren't recording audio on Evernote.
And so, I mean, chicken and egg problem, right?
They're not recording audio, maybe because they don't want to record audio?
Maybe because there's nothing to do with the audio once you record it.
We still decided to launch it because it was just like qualitatively so good.
It's basically state of the art.
It's perfect.
You just talk and it transcribes it.
It's literally perfect.
And so we decided, okay, let's build it and launch it and see what people do with it.
We just observed people tweeting images of the transcription just because it was so accurate.
And they were like, I'm blown away by how good it is.
So that's one example of something that I didn't expect.
What did you learn from that?
That you should be very careful with your opinions.
You should always try to resort to some piece of evidence instead of saying I think it won't work or I think it will work.
Do you have evidence that it's working or not?
And so, if you don't, you should try and build evidence and then you should follow that, instead of saying I think it won't work or it will work.
We've covered quite a few different products, from your WeTransfers to Evernotes, to HQ Trivia Clones to your Play-Ons.
How is the team structured?
I think people have this conceptual idea that basically Bending Spoons acquires companies, fires the team and centralizes engineering the product.
You can think of Banding Spoons as a horizontal platform to which we plug individual products.
The platform is basically everything that you don't need to have at the product level.
For instance, let's make an example, talent and recruiting or accounting, finance, legal.
But not only that, also deep technological teams that power data pipelines, monetization libraries, stuff that can be adopted by each product.
This way, you don't need an Evernote recruiting team.
You don't need a Komoot monetization technology team.
You just need to have these pieces at the platform level.
And then to this platform where we invest a lot, you can plug new products all the time.
And so this means that the individual product team can be much, much leaner than it could be as a standalone company.
And often we see the difference that it makes.
We can acquire companies that are very large and run them with very few people in comparison.
What's the biggest change?
So you acquire a company with 500 people and it now runs with 50?
Yeah, the orders of magnitude are around.
It's very case-specific.
It's very hard to... There's no, like... What was Evernote and what is it now?
Evernote was a few hundred people and now it's less than a hundred.
Got you.
Where are those hundred people?
That still feels like quite a lot if you actually think about the horizontal platform that's legal accounting recruiting, data pipeline.
I mean, at the product level.
So just on the specific product.
Does that not feel quite a lot in product?
I mean, it's not on product measure.
I'm just talking about the business unit.
It contains technology, product, design, data science, monetization, growth, even management.
You know, like all those people are, yeah, a few tens.
Totally get you.
Can I ask you?
You mentioned monetization there and you've mastered across different products, paywalls and moving from freemium to premium.
What have been your biggest lessons in scaling from freemium to premium in product?
Again, that it's very case specific.
You don't have a playbook that you then apply to each product.
Let's take Evernote as an example.
On Evernote, we inherited a monetization structure that was based on basically unlocking advanced features.
As a user, you would pay to unlock business card scanning, for instance, or PDF annotation.
This creates a mismatch between the experience of a free user and advanced user, right?
Because you literally have access to a different feature set.
The way we approached it instead was let's try to make it so that every user sees the power, the full power, of Evernote.
And so we literally made many features that were previously paid free.
Offline is a big one, like offline availability of notes and notebooks used to be a premium feature and now it's free.
Instead, we monetize based on content, so based on how much you have on the product, and so if you want to create a lot, then you pay more, if you don't create much, then you can use it for free.
So this basically aligns the incentives of an advanced user.
I use it hours a day.
I create tons of notes.
I pay more and I'm perfectly fine with it.
I'm a very casual user.
I don't use it much.
I have a few notes and just trying it out.
You can try the full product without any constraint and you just like reflect the number of notes that you actually have.
How do you feel about the quite aggressive paywalls?
I quite often download consumer apps.
And instead of the, I'm using it very simply, but age your faces.
Instead of like the do three and then you pay more, it's like pay more straight away.
It's a very aggressive paywall strategy.
How do you feel about how aggressive a paywall strategy should be and any lessons on that?
The best way to monetize a product is always based on what works on that product.
So you just try different setups and you see what works.
It has been the case often where we've made the paywall more visible than in the past, just because acquiring products that have already grown and that already have a large user base, then you have more to unlock by monetizing people who are already there.
Instead, if you are growing a product, then you might want to be a bit less aggressive and just get people to try more of the product for free, because maybe it will improve your K factor.
It would increase the amount of people that they refer, basically if they have a deeper experience with the product without interruption.
It's very case specific.
Another element that I also just find fascinating from a behavioral kind of psychology perspective is push notifications.
Do you have any lessons on what works, what doesn't work, and how you'd advise product owners?
Yeah, we're not big on push notifications.
We have used them in some products differently.
So on Evernote, I think we don't use them at all.
I mean, we use them for reminders, for people who set a reminder, for a note or for calendar events, but we don't like use them as a marketing strategy just because we think it would decrease the user experience.
People will be pissed about it and they would turn them off.
And so that would reduce the usefulness of the product.
So we don't do it.
On the other hand, when working on LiveQuiz, the HQ trivia clone, push notifications were literally the trigger to use the product.
Because of course, it's happening a couple of times a day, always at the same time.
But if you don't receive the notification, there are fewer chances that you actually remember to play.
And so in that case, it was a core part of the experience.
Going back to the structure, when you acquire a new business, a Vimeo, an AOL, What happens then?
I know it sounds stupid, but, like, does Luca say, hey, everyone, we're acquiring this.
Who wants to work on it?
Is that how it works?
We take into account people's preferences.
Like, if somebody comes to me and tells me, I like to work on Vimeo, I'm like, That's great.
It's great to know that some people are passionate about one or the other product.
I mean at the end of the day, I think people perform better when they are working on something they're passionate about.
To the extent that it is possible, we always try to make it, so people are working on stuff that they care about and they're passionate about.
So we definitely encourage people to tell us.
But it's not like we find volunteers to work on a product.
It's more about functional leads.
So our CTO Matteo, our co-founder myself, other people we have in mind the structure of the product teams and we try to see where we can find people that are best suited to work on new acquisitions.
And you're like a Jedi ninja that kind of jumps from new product to new product.
Yeah, lately I've done that quite a bit.
It's a bit uncomfortable because you have to start fresh very often, but you learn a lot.
You learn both about the specific characteristics of that product but also about You start seeing some patterns about how companies are run and these things.
Do you get nervous?
It's a big transition moving from, respectfully, the 30-day fitness to Evernote.
That's a big transition.
And then from Evernote to fucking Vimeo and AOL.
Yeah.
I remember I was on a plane.
We were about to take off.
I was in my pants, I think.
I was leaving to California to meet the Evernote team.
And I was like, what am I going to tell these people?
Like, they are true professionals and instead I'm just a guy with some startup experience.
And what am I going to tell them?
And so I lacked a bit of confidence.
What I realized is that they are people.
I was intimidated by the fact that many of them had 20 years of experience being a VP at Yahoo or stuff like that.
And they're smart professionals, but it's not like if they are and they have experience, then it means that you cannot talk to them.
You can just have a very rational conversation with people and you just try to do your best.
Which quality code base was the best when inheriting it?
I don't dive as deep into the code as my colleagues, so I'm not sure.
I heard that the WeTransfer codebase was very good.
Which was the worst or most difficult to inherit?
It doesn't have to be codebase, but just like when you went into it as a product lead, you're like oh.
Well, Evernote, I'm not sure it was bad.
I actually don't think it was necessarily bad, but it was complex.
Like just compare WeTransfer to Evernote.
WeTransfer, in terms of complexity, could be one feature of Evernote, and Evernote has like, literally hundreds of features.
So I mean maybe not the simplest one, but it's easier as product surface to conceive and to think about.
Evernote just has this long tail of small features and it's 20 years old.
When we transfer.
If you fail an upload, people are going to be frustrated, but it's not going to be the end of the world.
If you lose a note on Evernote, you will receive phone calls and rightfully like understandably, it's what should happen.
And so it's just critical that you do it well.
Not only it's more complex, but it's also more critical, and you should like triple check everything you're doing.
So yeah, it was difficult.
Do you have horizontal paid marketing machines at Bending Spoons?
And what I mean by that is does the marketing sit as a function on top of the product teams and they are a paid marketing engine for WeTransfer, for Evernote, for Vimeo, for AOL or do you have individual paid marketing machines for each entity?
It's generally individual.
You can think of the function versus team as a matrix, right?
Each person belongs both to a function and the team.
So I'm a product manager inside the Evernote team, for instance.
So I'm inside the product function inside the Evernote team.
And so there are people who are inside the growth and marketing function.
They work on Remedy, for instance.
Almost all people who do this are deployed inside business units.
In terms of their actual location, how do you think about effectiveness of remote in product teams?
I don't have a strong opinion on it, meaning that one.
I see that some of our best contributors work remotely or almost only remotely.
And it's almost as if having the ability to craft an environment where you are almost cocooned inside your own habits and environment, you can just deliver your best work without distractions.
Probably for me.
I'm most effective when I'm at the office, but I do love having the flexibility to be able to I don't know meet my parents for a long weekend and just work from their place.
I don't think that there's a clear winner between remote and in-person.
I think hybrid is a very good mix of both.
When you need to attract this level of talent, it's an extra requirement to ask them you should also be physically in Milan.
If it's not necessary, you just drop it.
It's a false requirement.
You work with American teams that you often inherit and European teams that you sit with day to day.
How do they differ in terms of work ethic, psychology, mentality?
Honestly, I don't see that big of a difference.
You don't?
No.
It's not like I spot a trend in how I don't know the WeTransfer team versus the Evernote team, just to name two that I worked very closely with.
WeTransfer was based mostly in Amsterdam.
Some people in London too.
Evernote in the US, mostly in the Valley.
I don't see a direct difference in culture.
Was the StreamYard acquisition successful?
Yes.
I mean, I'm thinking about ways it could be defined as not successful, but none come to mind.
It was a success financially speaking.
We were able to increase revenue a lot.
It was a success in terms of how much we were able to improve the product.
Yeah, I would say it's definitely a success.
Dude, I want to do a quick fire round with you.
So I say a short statement.
You give me your immediate thoughts.
Which company has bending spoons not acquired that you would most like to acquire, because it would be great to work on?
I mean, I don't want to sound arrogant, but I think I would love to work on Google.
It would be... Why?
It's just one of the best products in history.
Google Search?
Google Search, but in general, the Google ecosystem.
Like they just have so much surface, so much intellectually stimulating stuff that you could work on.
One of my favorite products is Google Maps, just because of how useful it is every day, you know?
And just even working on Google Maps would be great, just as my like, literally my personal taste it would be great.
But YouTube Android, Google Search, all the AI stuff that they're doing, it's just like theme park world for OPM, I think.
What is the most non-obvious app on your home screen that you love?
Let's check.
Yeah, let's do it.
Polytopia.
It's a mobile game.
And I actually discovered it because apparently Elon Musk is a big Polytopia player.
It's a turn-based strategy.
It looks like Civilization, the game, but it's mobile.
It's a bit simpler.
When you have 15 minutes, you just play a match there.
It's nice.
Another one is Napper.
I had a baby in April and Napper is the app in which I log every time we feed her, every time she takes a nap.
And it's good at predictions too.
It literally is able to tell you when she's going to fall asleep with an accuracy of minutes.
That feels like a bending spoons company.
Yeah, it might be, yeah.
Tough retention.
The retention there is like, fuck it, they're four years old, they don't nap anymore.
Depends on how many babies you have, but yeah.
It's true, but you're going to get some churn in between, dude.
What is the most non-obvious skill that a PM needs to be successful?
I think great PMs are entrepreneurs at heart, at least.
Like people who can come up with valuable ideas.
Find a way to implement those ideas well.
Focus on what matters, meaning that the idea needs to be relevant for a goal.
Being successful financially is one, but also like doing stuff that goes viral and gets a lot of coverage.
I mean, it depends on the goal, but you need to be very focused on what matters.
The best entrepreneurs are great creative people coming up with ideas.
Designers thinking what the UX should look like, project managers that get the team to ship fast and they ship fast with the team.
So I think being an entrepreneurial is a hell of a skill for a PM.
Replit or lovable?
You can only choose one.
I don't know.
I think our teams use lovable more than replit.
I personally use replit more than lovable though.
Why?
I prefer the UX.
It's just that.
Claude Code or Casa.
So I tweeted about the AOL acquisition and the tweet went viral and I noticed randomly a few large accounts followed me.
It's not like I saw all of the followers and I went through the list and I didn't have time to do it.
And so I said let's see if I can rank my followers by how large their accounts are.
But there's no tool that does that.
And so I was like, yeah, let's see if I can build a little tool to do that.
I'd pay a lot of money for this if you have that.
No, seriously, do you have that?
I have it.
It doesn't work super well, but it works.
I built it with Cursor initially and then it didn't work, and then I built it with Cloud Code and it didn't one-shot it, but I saw that it was improving the things that were broken faster, and so I went with Cloud Code in the end.
Wow.
Love that.
Which wins, ultimately?
I think, at the end of the day, what we want to do is to have the preview on the right and the chat on the left, or vice versa.
But I think the code will become irrelevant.
I'm biased, I'm a PM, so I care about the prompt and the result.
But I think that ultimately, what we want to do is to deliver a great UX by giving the right commands.
So I think that the cloud code is the way to go.
But I think that cursor is a better UX today, when manually looking at code and knowing the code still matters a lot.
Seven and a half years at Bending Spoons.
You can call up Fede the night before your first day and say ah, I've done this before and you should know this.
What would you tell yourself on that night before?
Be bolder.
I think sometimes I waited for somebody to give me permission to do stuff as if I was in school.
And instead, when you start doing stuff autonomously and it looks like it's something smart and it can work, people will just cheer for you.
It's not like anybody's going to stop you, at least not at Bentley Spoons.
If you have an idea for something that works, we're just going to be enthusiastic about you trying it.
So I tend to be high agency, but I didn't have the confidence to just start doing stuff.
And I'm glad that they pushed me to do it.
But I would just tell myself be bolder, start more things.
If I wasn't afraid, I would do dot, dot, dot.
I love Neuralink.
I think Neuralink is the product, like the thing, that can change the world the most in 50 years, including AI, in my opinion.
So I know people love AI.
I love AI.
I use it every day.
But I think that ultimately, the way you perceive reality and the way it changes through Neuralink is going to be a bigger difference compared to having hypersmart computers.
So yeah, so Neuralink.
If I wasn't afraid to fail, I would start a Neuralink competitor or find a way to work on Neuralink or, even better, start a Neuralink product inside BendingSpoons.
Fede, this has been so much fun, Stu.
Thank you so much for joining me and I so appreciate you taking the time.
I loved it.
Thank you very much.
But before we leave you today, on this show, we care about velocity.
Most teams lose it in code review, not in writing code.
Now CodeRabbit fixes that.
The second, a PR opens.
It leaves clear line-by-line comments, calls out what the change might touch and offers one-click fixes.
You can teach your organizational standards using your own custom instructions, such as cursor or clawed rules, and enforce them on every PR.
CodeRabbit has so far reviewed more than 13 million PRs and installed on 2 million repositories used by over 100000 OSS projects.
If you want to cut code review time and bugs in half, try a free month at coderabbitai with the code 20VC.
And while CodeRabbit keeps your code clean, Warp Dev makes it fly.
Ai coding is everywhere, but most of it honestly, it's pretty chaotic code.
That is almost right, but you don't really understand.
Well, that's why warp exists.
With warp, the old lines between terminal and ide disappear.
It's a seamless environment for coding with agents where you can prompt plan review and ship production ready code, edit files in app review diffs as you go and deploy straight to production without switching tools.
Warp tops the benchmarks, literally number one on terminal bench, top five on software engineering bench, verified and is trusted by over 600 000 developers and used by 56 of the fortune 500 engineering teams, making it one of the fastest growing AI companies, with revenue growing 30x this year.
With Warp, you don't just get speed, you get code you can trust.
The average developer saves five hours a week with Warp.
That's almost half a day.
Try Warp for free at warpdev forward slash 20VC.
And to get pro for only 5 for your first month, use the code 20VC.
That's 20VC.
