Why Most Founders Build the Wrong Product (And How Focus Fixes It) | Martin Thoma (Bliro)

Hi, and welcome to Beyond the First Wins, the podcast about what happens after the plateau, when early wins are no longer enough in business, product, and design. I'm Daniel, founder of Duran, and today I'm joined by Martin, co-founder and CTO of Pleero. Hi, Martin, really glad to have you here. Please take a few seconds to explain who you are, what you're doing, and kind of what you're building these days.

Thanks so much, Daniel. A pleasure joining you here today. Yeah, I'm the CTO of Pleero. We're doing a conversation intelligence tool for the European market for enterprise salespeople. So we're helping those folks on their journey when they're talking to customers, when they're having meetings, when they're preparing for their day, and we help them throughout their day post-processing their meetings, writing up their notes, creating calendar and follow-up events, creating follow-up emails for them using AI. So we're joining the AI workforce of the companies that we're dealing with and supporting the humans to get rid of all the manual busywork so that they can focus on the relationship building and actually the part of their work that is fun for them.

Awesome. Sounds like a lot of stuff there. If you are just taking like a brief moment to think about when you started, how you started, can you remember how things were around those early days? Who was around you? How you ended up with the idea to build something like this?

That's a great question. We just talked before and I said it's very hard for me to think back and to lift your head out of the mud, the everyday mud, and to think back. I founded the company together with Maurice, my co-founder and long-year friend. We were studying together. And while doing our bachelor's studies in engineering, we were always trying to solve problems and to build tools and bring them out in the world and try to help people. But unfortunately, we built those tools for problems that we thought that exist, but in the real world, they never existed. So at some point when we were starting with Pleero, we flipped the coin and we said, okay, maybe we should ask the people first, what are your problems before we're trying to build something for them? And this worked then much better than what we did before.

Okay, that's an interesting take. How you ended up switching from that building mindset in a way that I think this might be helpful, let's build it, to actually talking to customers? Because from my experience talking and working with a lot of engineers, developers, and so on, they usually end up building stuff and less about talking to customers about what they should actually build.

Yeah, good question. I think it's, you know, you're young, you're learning the skills of how to build things, and then the first thing that you're doing is to build things and not going out, ask what other people want from you, but you just want to showcase your skills to the world, maybe. And you're also very idealistic. Maurice and I, we both were sitting in cafes and thinking of how can we make the world better? And I think this is a valid approach where you can build something very visionary and something that is not there yet on the market. But maybe this is too far into the future for people, right? So we were very idealistic when we started, which might not reflect the actual real-world problems of people that they're having right now.

Yeah, that makes sense. Especially like your market, it's in a way less tech savvy, let's put it that way, right? I wouldn't say that these are the most innovators or—

That's true. Yes, they have to follow up, I think, on all those matters, though, in the market of conversational intelligence, of course, it's very fractured, right? So there are those Very big players that were also there in the very beginning, in the early days, Fathom, Fireflies. Now Granola is there also, which build beautiful and great products for consumers, for early adopters. We started with this as well and had this motion of putting the product first and letting the product sell itself. But then we noticed that there's a much bigger and obviously harder to get market, but a more attractive market for our case, which is then actually the offline market. Offline can salespeople that are working in manufacturing. And they need this much more because somebody that already works in a startup or already is an early adopter of technology, usually their processes are very straightened up and they're fast and agile already. So the value that you add with such a tool is smaller than when you can really disrupt an industry and help them from the ground up with a technology like that.

Yeah, it makes sense. And now, if we are still Keeping in a way that timeframe in the beginning of what you were building and doing stuff, how or who was more in charge of the product and the UX side and kind of how things happened on that side?

Yeah, so interestingly, Maurice and I, as I said, we studied together. So we have kind of a similar background from an engineering perspective. And then at one point, we— the other thing is that on a personal level, we really like each other to have our own playground, right? So I doesn't like too much if he's taking too much ownership of things that I'm in charge with and the other way around. So we flipped the coin and we said, okay, one has to do the product and the other person has to do the business. And so I ended up getting the product coin, none being better or worse, right? But this is just how we developed. And then our career paths kind of were decided by the fate of this flip of a coin. So I was always the person doing the tech and doing the product a bit more, while product is still done by both of us, and we're always sitting together defining the roadmap because it's so central to our business.

I always thought that Maurice was some kind of sales guy for some reason. I'm not sure why, but my feeling was, okay, he's a sales guy. He definitely did something in sales for some reason.

So the coin flip was destiny, maybe.

Yeah, you never know. But what I really like working with you guys is that both of you take stake in building and shaping the product. Each of feel in a way taking and adding their own insights, ideas, and strengths into this. He usually comes with the more customer voice in a way because he talks with a lot of the customers and you mostly, I assume, with the technical part up to a point like later, I wouldn't say it's like big of that big of a difference anymore, but at least that was my feeling in the beginning.

Yes, definitely. As said, when you're 2 people in the founding team, And one, of course, has to do the administrative stuff, company building, investor relations, customer relations. And the other person needs to dig into the technical depths of creating a desktop app, looking into different programming languages, creating an architecture and infrastructure for this. Then you're very busy on both ends. And then somehow what comes a bit short, at least in our case, was always the product. So No, there was not really a responsible person for it, but we both were responsible, which kind of, I think, was a good thing because this always created some friction and we had a lot of discussions on it, which I think is important to come up to bring both views together and come up with a solution that is then in the end very helpful for the people.

And if you're thinking like we're still in a way on those early days, which part of the user journey got most of either your or Maurice's attention in the beginning where you focused most of the resources that you had at that time? Yeah.

First of all, when I reflect the first— the decisions that we made in the maybe first year that we were building on this, I would say all of them were wrong and there was not really much that we did right. So it was really a period of learning. I'd say we were much too drawn to— there was some person that we wanted to build this product for, and then we were much too overtraining on this person's case and not generalizing enough. Maybe then there was another person or another customer potential a customer, that we were building stuff for them. And it was very hard for us to say no. I think this was one of the biggest learnings. Then we focused way too early on the top of the funnel where we thought about, okay, do we need marketing? Do we need to put more people into the product? While actually our retention was very low, right? So now if I would do it again, always focus on the retention because you can pour as much water as you want into a leaking bucket. If the bucket is leaking, the water flows out again. So first you have to have a proper bucket and then put more and more water in it so that it gets—

Yeah, that's true. I guess it's just an idea and maybe you can say it from your side, but in the beginning it's really challenging to say what's a good enough bucket and where you should pour or how much water you should pour in it.

I think it comes— there's a very important ingredient that we didn't have back in the days. So we were like greenhorns from university, right? We never had industry knowledge and we never had domain knowledge about the actual problem that we are trying to solve. So even though we did a lot of interviews with analysts and salespeople from multiple industries, it's this notion of knowing what is actually needed, what is the core of what we're building, what is actually needed, what can become our bread and butter business, and what is the main problem that we're solving. This is something which is, if you know this and if you're straight on this and focus on this and execute this through, I think this is the most valuable thing that you can have clarity on what you actually want to solve. Because for us, it was, we were like building this product while at the same time we were learning about our customers. We were learning about who might be the actual user or our ICP. And so we did a lot of turns left and right. And I know that we did this, you know, some opportunity trees and we span them out. Okay, we have to go there, but we have to go there also. We got a lot of mentors that tried to support us and we were always too broad with those decisions and didn't focus enough. That was a big learning that we have to focus stronger.

And kind of when or how did that shift happen?

I think this shift happened So first, in the situation that we are, kind of the conversational intelligence tool can be used by anyone, right? In theory, a schoolteacher could use Bliro as much as a salesperson, as much as somebody completely different, right? So our customer base was always pretty much scattered.

Mm-hmm.

This makes it very hard to find, you know, the signal in the noise, so to say. And we had to come— this had to be an internal change where we had to internally decide okay, where are our strengths in the product? What are our technology advantages and USPs against maybe other products that are in the market? And how can we leverage them the best? Which is the ideal customer profile for us? And when we did this turn and when we said this was very painful, right? Because deciding for one customer segment means that we're not building for anyone else.

Mm-hmm.

So at one point we said, okay, we're building for customer group X. But we're selling to anyone if they want it and if they need it and if it also fulfills their use case, that's completely fine. But we're not going to build for them. And this clarity, saying this to us every time and every time when we're iterating on the product, we're like, okay, is this important for the exact customer group that we want to build for? Or is it noise that comes from the side which distracts us maybe from the way that we want to go? And this question you always need to ask yourself. So it was rather an intrinsic decision that we said, okay, we have to focus now. Because we could sell to anyone, we could build for anyone, but we have to focus for one specific part rather than the market is defining it, rather than, okay, there's a clear customer group which likes the tool much more than others. Unfortunately, we never had the situation. Otherwise, it would have been easier because you don't have to decide hard yourself.

So it was more like a decision on your side than seeing any kind of traction in the product or how people are using or who are the people that are using the product at that stage?

It was more of an informed decision at one point because the market that we're currently looking at, and which is very interesting, European enterprises, actually now global enterprises, the sales cycle and the feedback cycles are very long, right? It's easier to iterate with startups where sometimes we make a sale from the first demo to the sale in a couple of hours, and it's much easier to get feedback from them where it's very agile, where they're very involved, than when you're selling to a large construct where the sales cycles are 6 months when it's a very short one, right? And we have sales cycles that they're going on for forever and we're doing progress, but it just takes forever until everybody is up to date and all discussions are made on that.

Okay, I have a follow-up question here and it's one of the things that I'm really curious to hear. Like when you started to give more importance, if you want, to the UX and product side, obviously you started building the product right in the beginning. And then when was the shift in a way happening in your mind that, okay, we need to improve this or we need somebody to help us with this?

A good question. I remember that at one point we were looking at the product and it was just, we were really ashamed on how it looks like because I was not a— I come from data space, right? So by training I'm a data scientist and first thing that I did was creating this algorithm of how we are processing data, making this privacy compliant and having this interdisciplinary role was amazing for me. but I never ever built an app before, like a desktop application or something like this, right? I never really designed a website well or something like that. Our skill set on design, on design implementation even, was very, very low. So the first apps, and it was pre-GPT, right? You couldn't just ask a chatbot to beautify something. You had to do it yourself, and therefore it was very, very ugly. So if I remember the first apps that we had, it really looked like in the '80s, super super rough UI, very buggy, whatnot. So we said, okay, we need somebody that we really can— or let's say it like this. There was this point where we thought that the design inconsistencies and unprofessionalities of our design is actually harming our business, right?

Okay.

Where we came to the conclusion and we said, if we hire someone to polish this thing, to create a design system, whatnot, First of all, we can significantly speed up in development because we can have standardized components in the code repository that we can then reuse later. We have more confidence in our product from a selling perspective because the salespeople were like, okay, what am I selling here? This looks like shit. And then, I mean, that's the point. And then actually what you also want is you want to work professionally, but then you have also to have this appearance. You have to have a professional appearance. And this is something which is very important to us, excellence in what is the first and the second impression, right? So our sales decks are super polished. Our sales process is super smooth. So if we're approaching a customer from the first contact point to our customer success people, everything must be very professional and everything must signal— because we must signal trust.

Exactly.

The main thing that we're selling is trust, right? A word has been spoken once and then it's gone. So our whole product builds on trust that the person trusts us. He doesn't need to write the notes himself anymore. The app is doing it, and we're doing it in a privacy-compliant way. There are legal risks. There are risks of being blamed when the notes are not there and you write a shitty follow-up. So there's a lot of trust involved here, and we must be trustworthy from the beginning. And this comes, of course, with design.

So in a way, you would say that design helps once building the trust, then helping you speed up development and professionalizing what you have there, even smoothing out parts of the sales process.

Definitely. It comes hand in hand, right? I think this is when you have something which is nice and polished and when you go to a friend's place and the friend's place is very cleaned up, then you behave different than when you go to a friend's place and it's very untidy, right? That's also what we want, the spirit that we want to have in the company, because the people that are working here, they have to convey their trust to the users, right? They are using Vliro, of course, every day. So they have to trust in the product, and then they have to convey this trust that they have to their customers as well. And they have to be convinced if they say, hey, this is a great tool, I really advise you buying it. And this comes with, of course, technical excellence. This comes with smooth processes. and well-thought processes, but of course, the first thing that you're going to see and the first impression that you're always going to make is design.

Awesome. Well, moving a bit back to the product side and building the product, like obviously being a startup, you have a lot of ideas that you want to maybe try out, feature ideas, feedback from your customers, and so on. What you don't have necessarily is like resources to build all those stuff, and what you end up probably doing is like you place some bets, right? You maybe create a roadmap and you try to execute Back in the days, or even, like, even nowadays, what are those, in a way, bets, or what are those features that felt almost like a bet, you know, that you weren't sure that it will work out, but it felt like something that you have to try out, you have to build it because, I don't know, you have a hunch for that or something?

Good question. There are multiple angles that I can approach this. I think in general, we didn't have a big bets to be mentioned here in a feature-wise, because we were, as I said, I think there are two— there's a big spectrum. There's a spectrum between being very granular in iterating and doing small iterations of things that you know that are needed next. And there's the other thing where you're very visionary and you build something that could fly to the moon, but maybe not. And especially in the— or most of the cases, probably not. And as I said, we began when we first built products, we began very much on the visionary side. We wanted to make the world a better place, which we still want to do, of course. But we did these crazy moonshots where we just did something. We tried to sell it. Nobody needed it, right? Although we believed it was the greatest thing on earth. And then we switched our methodology and we were much more analytical. Everything that we're doing is powered by customer feedback. And we do have— we collect customer feedback from All the salespeople that are talking to customers, customers have the possibility to give us feedback via email, via forms, whatnot. I'm doing a lot of ride-alongs with them, with the users, with the decision makers to understand what they need and to collect their feedback. And we're distilling this feedback every time we're creating the next roadmap to know what is the most important feature, what is Or not even feature, maybe something is— maybe it's resilience. Maybe we see, okay, hey, our quality degraded to a level that is almost not our standards anymore. And then we need to see that we're creating that, right? So this is very important to us that we always have the customer feedback in mind and that we're always building on customer feedback because this gives us trust in what we do. I rather think that we did a lot of— or that we did one big bet. And I'm not yet sure whether it was a right or a wrong one, which is the ecosystem that we built. So we created a huge burden for ourselves by creating, having now a mobile app, a desktop app, a web app, as well as we're doing the audio processing completely our own. So we are very deep as well as very broad. And this is always a really bad combination. If we're looking at other players, for instance, in our market, when I look at Granola, for instance, which I really admire for the products that they did. Until the seed stage, they didn't have a mobile app. They were only having a desktop app. There was not even a real web app they had. So no place where you could see your meetings really in a web app view, but everything was just in the desktop app. So it was one ecosystem and they only built it for macOS. So, you know, you can really focus on things. And the biggest mistake that we did, I would say, was, no, we broadened the thing up very early. And this felt wrong, and it was wrong, I would say. We should have done this differently looking back. But this is a huge learning for me that we have to stay focused much longer, especially on the amount of platforms that we are introducing. This needs to be very, very much thought through.

Yeah, that's true. Thinking about the customers, do you think that in a way, a similar approach, like just being very focused on maybe one kind of tool would help for your customers as well, or it wouldn't be the same? Because from what I remember, like, you have customers that are using Microsoft a lot. You have customers that are using some, or I'm not sure at what degree they are using Apple. So at least you have 2 different systems that you have to, in a way, take into account, at least from that point.

I mean, at one point in the future, we have to cover all those platforms. Right. Because we see that the users that we're serving, they're working hybridly. They are on the road where they're using their phones. They're in the company at home using their laptops for online meetings. It's convenient for them to use web applications because they know it. And there are other platforms like CarPlay, maybe the watch, maybe other things, because how do you perfectly integrate into the workflows of those people? So I think eventually we have this target system that we need to achieve and where we need to get to, to significantly different ways how you would go there. And I would say it's always better to nail the major problem for a very, very narrow group of people, for a niche group of people, rather than too quickly responding to requests of other people that don't have access to the tool and tell, hey, we need to do these short-term wins. Right. So sometimes I felt we were prioritizing short-term wins over the long-term speed. And this is rather— in the end, we will be at this desired state. The question is, how quickly could we have gotten to this?

Can you briefly maybe talk a bit about how you move from customer data feedback and so on to a feature idea or an idea or an improvement idea? And I how this whole process works, because I know that you put a lot of effort into that. And even when I was working with you, there was like a lot of changes up to the point where you ended up with the current process that you have.

Exactly. So our process is mainly qualitative. So we're focusing a lot on qualitative feedback. And what we do, as I said before, is we're collecting feedback from our quarterly business review meetings or from existing customers, from new prospects, what do they expect from the tool, and also bug reports and whatnot. We're placing this all into a big table, so to say. So we really need the raw feedback of the people, and then we extract the insights of this feedback. So, for instance, a customer, there was a meeting half an hour, and there were 10 topics where customers like, this is shit and this is shit and whatnot. Of course, it never happens for us, right? And then we're looking at this, and then we say, okay, what is the insight of this? What do we have to what is really the point that we have to improve or what is the desired— the desire underneath the feedback. And we map this to components or to parts of the product that then we know, okay, for instance, transcription, there were a lot of different feedbacks and insights that are mapped to transcription or to the frontend or to whatnot. And so we have a really nice way of prioritizing where do we get a lot of feedback in, what components or what parts of the product should we have a look at, right? And this is the one thing. The one thing is always the stream of incoming customer feedback. It will never change. There will always be feedback, and it mostly will be negative, right? There will also a little bit be of positive feedback, but mostly this is the negative input stream. Then on the other hand, of course, we have a plan, right? We do have a vision where we want to go. We have a red line which we want to follow. And then we need to see how do you bring those worlds together? How do you bring this vision of where do we want to be in a year? What is the status of the product then? Together with this whole customer feedback that is flowing in.

Okay. And after you go to the feedback, kind of what are your next steps to distill the feedback into something that's actionable? Usually startups have, in a way, a couple of pain points. Let's put it that way. They either don't know how to collect or they don't collect feedback, right? The other thing is rushing into development most of the time. And what I'm trying to figure out or what I'm trying to extract from this is like how you make sure that you are using that feedback in the right way to then build the next thing that your customers actually need instead of wasting resources and building stuff that nobody will use?

That's a good question. I think we didn't find a silver bullet yet. Yeah. So what we are using this for is every 3 months or actually every 6 weeks, my co-founder and I, we do our product weekends where we are sitting together and we're checking, okay, where are we? What is maybe contractual obligations? What is the hard hard requirements from the customers that we need? What is user and customer feedback that we get from this input stream? And where do we want to go, right? And then the process is really sitting there 2 days and brainstorm about it and discuss everything, go through these, go through the tables, trying to find the signal in the noise. Exactly. We found that there will be things that never change, So we know that every product has its strengths and weaknesses, and at some point it doesn't make sense to put more effort to mitigate a weakness, but just maybe double down on the strengths that you're having. So this is also— you have to find this for yourself, right? There's one part, one problem. All the note-taking tools have this problem that are not joining a meeting with a bot, which is the speaker identification. So since we were born, Every time feedback is like, I need speaker identification. I want to see who's talking and stuff like this. And in the beginning, we were like, yeah, how can we do this? And we were thinking so much about fixing this. And then at one point we were, but why? Because the product's quality is not degrading by this. We are still having exceptional summaries and exceptional analytics that we're generating on top of it. So why is this so important? Maybe this is something the user notices, but actually it's not really affecting the person. So we usually then, or we say that, hey, this is maybe something that is just a burden that we have. Maybe there's going to be a solution for this in the future. And we are exploring some things right now which are very promising. But you shouldn't force solving a problem that maybe doesn't want to be solved right now.

Okay. Moving a bit towards the closing stage, right? I'm really curious about lessons, blind spots. You are doing this for, I don't know, like 3 years or something like that already. Went through a couple of iterations. So if you are looking a bit back to how things evolved along the way, along the years, was there a product or UX issue that in a way slipped under the radar until later and how that impacted either the product, either the business, either how you were doing things?

Yes, couple, couple. I would say that there were a lot of product decisions which we could have done better. But at the point in time when you're doing this decision, you always have to act with a limited set of information. And this creates, of course, uncertainty. And I would say under the premise that we had a limited knowledge of the industry and the problem and, you know, we still have it, we're always learning more about it, as well as the data points that we had for making a decision, we did a good job. Though then later and retrospectively, you find out that, okay, we should have prioritized completely different. For instance, there were 2 big streams that we saw in the user base. So one stream was high, high velocity sales where there are call after call after call after call and people are like using the product very, very heavily. We had those clients there, they were iterating quickly, it was very promising and we still have them and we still make them happy. And then the other case was this rather slow and just 2 to 3 to 4 meetings maybe a day, but then very long meetings, very technical, very deep meetings. where the requirements were completely different. So a system that is built for the one case is not built for the other case. And then we were often— because this was before we decided for one of the streams, and then it was too often that we decided for one stream, created a feature. Next time we said, oh yeah, but now the others are unhappy. So then we created for the others and then, oh no, now the others are unhappy. And then we were like always between the lines. And then only when we said, okay, we have to really say, hey, This is now— we're building for those guys. We're also selling to the other guys. But having this segregation was very, very important and also relieving for us because all of the decisions and all of the feedback that we're also getting in can now be categorized by importance. And this makes it much, much easier for us to do good decisions for the people that we actually want to build.

Do you feel that the way you make decisions changed, or how much it changed from the early days of building Vero to how you build Vero now? I assume you have more insights and more feedback and data that you work with right now if you compare it to when you started. But kind of what are you looking into or how you make these decisions? Because you still have the uncertainty there, right? Because no decision is 100% sure that it will work out. Where is, in a way, that line that you say, okay, this is good enough, now we can move forward?

I think there are 2 dimensions that we should look at here with decision-making in product. One dimension is actually clarity. If you know where you want to go, you can filter much better. You can really say, hey, this feedback is relevant, this feedback is not relevant. And when you focus enough, it's much easier to see a path forward because all the noise goes away and you have a more limited set of options that you can choose from. And then it's more clear what is to prioritize these options. So really it's about first you have to be certain yourself where do you want to go and what is your path forward, and then you can walk it. That's the one thing. And the other thing is, and this is very crucial for Maurice and me as co-founders when we do decisions on the product, because oftentimes it's not about having a very, very strong opinion on something because it's important to one, but just because maybe one enjoys the discussion or just because, yeah, whatever reason. And then we are asking, hey, how important is this to you? Is this a 5 out of 5 important or is this a 1 out of 5 important? And then often, if we are stuck and then somebody might say, oh, this is actually just a 2, so I don't really care about this, but my opinion is that, right? And then you defend it. And then we're like, okay, you care 4, I care 2, then you own it. Then we just do it how you want because you care more about it, then you own it. So often decisions that we learned are not about being right or wrong, but how much do you care?

So you kind of split decision-making between 2 based on, in a way, how much one of you cares about that specific topic or area of the product or the business?

Kind of, yeah. I think it makes a lot of sense in between co-founders because you're on an equal level and there's nobody you can ask, right? So you have to make a decision.

I mean, yeah, there is not a lot of people you can go to get some advice on these kind of stuff.

Exactly. And you can spend 20 more minutes and then somebody might be upset in the end. Because he lost, just because he lost the discussion. But it's just much easier asking, hey, how much do you care now? Because we are in a stalemate. How much do you care? One cares more than the other. And if both care 5, then it's really worth discussing on it for longer. But 99% of all the conflicts eradicate immediately if you're just asking, how much do you care?

That's a clever plan. Okay, now if you're thinking about how you build the products and the whole process that you have in place, Besides the decisions that you make and how you make decisions, were there any kind of small changes, iterations that it looked small, like at the first it looks quite small, but ended up being quite impactful in a way in the business or the product?

Yes. And this also funnily plays into the question that you were asking before about whether we did not do changes which turned out it would have been very impactful if we did them before. It was a very small thing showing the transcript live while it happens. So we are transcribing live, right? You're talking, and then at the same time, the words or the spoken words are written down into text. And for some reason, we never showed this to people, to the user. We don't know. When I look back, I don't know why. There were always more important things that we prioritized above it. But now in the mobile app, we released the mobile app with this feature at first. And this is a huge game changer in trust because, of course, as a startup, The software is a little bit buggy in the beginning. It's never perfect when you start out. It has to evolve and it has to become more resilient over time, though so important for gaining trust in the product when you just see, hey, it works. How do you demonstrate it works? You show the transcript live, right? And then people read it and they're like, okay, this is the word I talked. I saw it there. Perfect. And also even better, if it's not working, you can see it too. Right, which is then a little bit frustrating for the user. Maybe the tool is currently not working for whatever reason, but you can always then switch to manual note-taking. So you can decide on yourself and do you know switch to to to to a fallback option. So it's this was a super super game changer for us gaining more trust in our system, showing that it's working when it works, and also providing easy fallback for the. for the customer or for the user if it doesn't work.

Cool. That sounds quite interesting. And from what I remember, you have it on mobile. There will be inside of the desktop app, right?

Exactly. Yes. So I was very surprised because the engineer did a little tweak to it and I just got the new version 2 days ago or yesterday. And then I was running it for the first time. I was like, wow, this makes so much sense. This makes so much sense. I'm very amazed by it and looking forward because I really feel that this is something that the users will love. And that gives eternal trust now into, is it working? Is it not working? Of course it's working 99% of the time, right? So that's not the question. But when it doesn't work and you relied on it to work and you don't know it doesn't work, then huge pain. Huge pain. And these are the cases which are not allowed to happen.

Yeah, I think you mentioned quite a lot trust. So it's one of the core things when you think about Lero is trust. Or this is how we would define it.

For sure. I think this is something that Maurice and I and everything we do is building on trust. I think this is one of the major motives that are a red line throughout our life and how we want to build this company. It's also one of our main values at the company is trust, because in the end, we are kind of the second brain of the people, right? So they trust in us that we keep what they say instead of them. They put away their pencil. There's no way to return because they will forget the conversation. After one day, you know 90%. After one week, I think, you know, maybe 30% still of the conversation that happened. Everything is lost and there's no way to get it back. So yes, it's really about trust, what we're building. And this is— it's a great feeling to experience this because I think what motivates me The most is the feeling that you're working on something that is meaningful for people. And the first time when I was screamed at by a customer because something did not work, I was shocked. But at the same time, I noticed, okay, this is an emotional topic and this is something that is important to people.

And this is really what means working to me, to build something that other people enjoy using and that helps Okay, with all those stuff in your mind, trust and the lessons and everything that you learned along this way, if you were talking with Martin from like 3 years, 4 years ago, or like any other founders at the beginning of the road, knowing what they will go through it, what advice would you give to them? What are those nuggets or insights that you think that are like really important or in a way game changers for you and how you develop?

Saying no. Saying no is the most important lesson you need to learn, or I needed to learn at least. I'm speaking now from the product/technical perspective, right? But I think this also can be translated to a business perspective or administrative one. For the product perspective, the worst thing was saying yes to, hey, we now have a desktop app and now we need a web app to display meetings. This was the first Capital mistake. And then too early saying yes to, okay, we don't want to just do it on macOS, we also want to ship on Windows. Way too early. Should have said no there and should have stayed with my no. I said no, but then I did it still.

It was a 2 out of 5?

No, I said no. It was more important. Yeah, kind of. Kind of. And it was like, I don't know, what was it? What customer was it back in the days? But huge thing, right? And then we need Windows now. We need Windows. But they didn't even sign. There was nothing. They were in the process and they were Yeah, we need Windows. They need to test it out for their trial phase POC. And then I was like, I hate this. I think it's a super dumb idea, but I do it now because I don't know it better. And yes, so broadening. So from a product perspective, I would say stay focused, stay at one technology, decide for one user-facing interface, be it a desktop app, be it a mobile app, be it a web app, whatnot, whatever is most sufficient for the case that you're doing. Maybe you don't even need an app, right? Maybe you can just build a WhatsApp bot or something the like. So there's really, really stay focused on what is the problem and what do you want to solve? And don't say yes to introducing new platforms because this is going to be so painful. Yeah. And same focus also by knowing where do you want to go? Put a direction. It will be the wrong one for sure in the beginning. So you will shift plans over the time. But for the time being, go with one direction, try out this case. If it doesn't work, go back, try out another one instead of being too broad and not being sure for whom you're building and what you're doing. And then you're getting forward but not quick enough. And it doesn't feel like riding a wave. It rather feels like, you know, walking through mud step by step. And we did this way too long.

Are there any resources, books, or like anything that you felt it was helpful at that stage? Doesn't have to be like books for like product-related stuff in general.

Yeah, we were a very pragmatic team, I think. So we always had the saying build and sell to keep it very simple. So we're building something and we're selling it. This is how we're doing things. Trying to be pragmatic is, I think, something that helped a lot. There is a book that I can recommend. I got it recommended by CEO that I know and I worked for formerly. And actually, this book helped me a lot creating internal processes when the team grew. How can I create an organization which can iterate fast and move fast and have a process for this, having some advice for this, which makes a lot of sense. And it's High Output Management by Andrew S. Grove, which was the CEO and the founder of Intel. It's a little bit outdated. They're still talking about facts and, you know, it's from the '80s, I think, or something, but you can translate it very well into modern world. And it gave me a couple of very good methods that I'm still using. Yeah.

Great. And can you share like some future plans of like Bleero, how you plan to grow it? What's next for you?

We're trying to nail it, of course, for our users. So We know exactly where we want to go to, and this is a really great feeling. We have an amazing team. We just scaled it up. We moved into a new office here in Munich, so we have a really great spirit right now in the office moving forward. And technology and product-wise, we will now explore the field of agents much more. So we really are doubling down on this agentic workforce. We're seeing it everywhere. It makes so much sense to not stop. at the boundary of our tool, but actually step over this boundary and have agents that are working in other tools for our users, really making their life easy.

Awesome. Thanks, Martin. It was really nice having you here and learning about how you built Bliro and the lessons that you learned along the way.

Thank you so much, Daniel. Pleasure as always.