Is that a cultural issue for the Portuguese?
It's absolutely fundamental to go to a market much larger than Portugal.
What is the feeling of being ahead of your time?
Because focus is fundamental for scale. Distraction kills scale.
What was the feeling when it collapsed?
There was a week where it was decaying at 5% per day.
Those who can't do it will disappear.
80% of scale has to do with the anatomy of the transaction.
And the world was going to end.
It was one of the biggest revolutions I've ever seen in technology.
Was it the pressure of everyone around you leaving that made you think, 'Wait, I also have to be an entrepreneur'?
How many times did you think about giving up?
That's a Milanó...
Look Paulo, OutSystems already makes several billion, has more than 1,500 people working, it's a unicorn, a pretty big company. But I'd like to go back a bit to the beginnings of when it all started, right? Why did you create OutSystems? What motivates you? Can you make that journey back in time and think?
It's difficult, each time... it's difficult, right? But I think it has a lot of value because the people who are listening to us, we don't have many unicorns in Portugal, so if everyone is listening, at least one of them is sitting here, so there are even fewer. I think people would value understanding those early days of OutSystems.
It's important to understand a bit of the context that was being lived in Portugal at that time. So, unlike what fortunately exists now, where I am positively amazed by the number of entrepreneurs and people who already have knowledge about how to start companies. We have dozens and dozens of people who have good ideas about this, understand how it's done, have already made mistakes. When I started in 1997 with my first company, in Portugal, I couldn't, there was no one I could turn to.
There were no mentors, accelerators, incubators, there was none of that.
There was none of that. There could have been, but... there weren't even concepts of startups, right? Yes, all that didn't exist. So, there were obviously companies from a few technical entrepreneurs who did the first things, two or three.
There was, and Altitude was one of them, EasySoft. But these were two or three people, everything was very divided and there was also a bit of that old context that was not very collaborative. We collaborate much more now, which is an extraordinary thing within Portuguese society that has evolved towards that. So there was very little. So it was more the complete internal drive.
Personal drive, you mean?
Personal drive, yes. So, what was that personal drive? You want to build something? Yes, wanting to build. I've always been quite curious. I like to solve problems. Big problems attract me. But I didn't know this at the time. So what happened was I went to the United States in '92 to do a PhD and so on, and I ended up getting tired of studying. And when I finished the master's part of the PhD, I left, decided to abandon the university and went to work. At that time I was at a university in the Valley, in Silicon Valley, and I went to work at a Valley company in '94. So, even, by the way, the first browser, Mosaic, appeared when I was in the master's. So, I was already using email and the web appeared at the end when I left the master's. So it's funny to understand exactly when that occurred. And that was the beginning, the Java programming language appeared around that time, anyway, there was a peak, a very big transition and I was right in the Valley at that time.
And while I was there, I went to work for an American company, which was Oracle. And while I was there, I did a series of projects and so on. But what I found funny was that it started, the vast majority of my colleagues all left, they all went out, they all joined startups, some created startups and so on. And I was the only one who stayed, we were 17 in the group I worked with for a longer time. And in the end, only I remained after about a year and a half.
So they were attracted by the entrepreneurship and startup mentality of Silicon Valley.
Yes. Yes. And due to that absolutely immense moment that existed there.
By the way, that departure from your PhD, so you did the theoretical part, let's say.
Uh-huh. And when it was time to write the thesis, don't forget that, because when I went... I was on the PhD track, but instead of going directly into that, I preferred to do the initial part because I had a big gap between what I had learned here and I was missing things and some things I wanted to learn. I made a bridge and so I ended up doing quite a lot there.
So it was the disinterest in writing something that no one here is going to see?
I think, I think it was... I never worked so hard in my life as at Stanford, so I had an interesting moment there where I basically had, the university was organized in trimesters, each trimester had 10 weeks. In the 11th week were all the exams and the trimester ended. So there was a time I had three exams on the same day, 2 hours each. So the level of pressure, each subject had an assignment per week, so I had 10 assignments, I had three, four subjects. So that gave me about 25 to 30 assignments per trimester. So the pace was such that it was a huge shock even in the first trimester, but after that I got used to it. So I created a huge productive work capacity. So that was a very, very big school, but the fact is I didn't have a single free hour. And I remember I made the decision to leave when I was at 4 in the morning finishing an assignment and it was me and there was a group of Chinese colleagues talking to each other and at that moment I decided, no, I'm not going to do this. And so I decided to leave, absolutely sure that if I got out of this area, I could rest a bit more. So I had no weekends, it was basically 24/7.
But you decided to stay there, right? If you had to stay.
No, I wanted to work, obviously I wanted to work there, also because that enthusiasm was noticeable in the university itself. So the professors, most of the professors who were, for example, at Stanford, had companies, participated in boards or advisory committees, technical committees, of companies at the time. It was at the time when the new RISC architectures and the CISCs were being developed. There was a Cray at Stanford, a supercomputer, anyway, there were many people within the Stanford Computer Science school, which is a good school, working on immense problems and cool things. But I ended up being an assistant, I stayed as an assistant at Stanford, I also did some research, and this also allowed me to meet a large number of people. And it was there that I realized that the whole community worked around entrepreneurship and starting things.
Was it the pressure of everyone around you leaving that made you think, 'Wait, I also have to be an entrepreneur'?
You know what happened? It's when I started to see, it was there that I noticed I had an entrepreneurial spirit from the root, until then it was dormant, right? As I think happens with many people in Portugal who have the entrepreneurial spirit, but it's dormant and the context also doesn't help. But what happened there was that I started, at that time, when I tried to do all those assignments, I came across a brutal lack of productivity in software, because the vast majority of projects I did were software projects. So I developed techniques to compress, to do 30, 40 projects per trimester.
And then when I went to Oracle, I ended up introducing a language that is still used within Oracle today, which I've apologized for a thousand times because it was a tremendous mistake, but I introduced a language that is still in Oracle products, which was a language I thought was highly productive. And so, as I had this computer science background, theory of computer science, theory of languages and so on, I ended up getting interested in that problem, but the problem was a software productivity problem. So that created, basically, the genesis of what years later ended up being OutSystems. So software productivity, you're saying, is, I want to make software, I have to write a lot of lines of code, it takes a long time until I can have a finished product. And productivity is basically increasing the speed with which you can develop software, compressing the time it takes to be done and doing the least amount of work possible to get the result.
But was your main concern speed or flexibility, the ability to change things later?
I'm giving you a somewhat theoretical, structural, and academic thing, right? What happened later at Oracle is that I was part of the product group. There I came across immense inefficiencies. I also learned some things about how not to do software. For example, Oracle had its differentiator, which was the fact that Oracle essentially appeared with a product that was the database. So they, Larry Ellison, who is a very fast and very aggressive guy, realized there was a new way to organize data around what was called, what is called today, the relational model. Relational databases. So IBM had already come out with that. The IBM researchers had defined the SQL language. And Larry Ellison, basically, Oracle moved to create a competing product with the goal of storing, in a way, relational databases allow you to have a company's data and access it very quickly. And at the time it was super difficult to structure data and access it and so on. And this was really a revolution, it was one of the biggest revolutions I've ever seen in technology. So it was relational databases and Oracle caught that. But then they did something, their differentiator was that the database ran on all hardware and at the time there was a variety, there was a migration from mainframes to minicomputers, personal computers, there were lots of architectures, Sun, DEC, Unisys at the time, inclusive, right? Exactly. Unisys, well, on mainframes there was Unisys and outside. It ran everywhere. Oracle ran everywhere.
Man, that has a brutal impact on the code, because the code, the same code that ran on a PC, ran on a mainframe.
But there were, for example, computer architectures where, for example, the C compilers, with which it was written in C, the compilers didn't allow writing a name with more than seven characters. So, all of Oracle could only create a name with seven characters. The code was completely opaque, you couldn't understand anything. When I arrived and tried to open it, I was in a subdivision that used that code, I despaired. It was so far behind in terms of basic principles of legibility, maintenance.
It wasn't spaghetti, it was simply due to that restriction of being portable everywhere, it had the lowest common denominator. In terms of that, technically it's horrible. Nowadays, I arrived there and ended up doing a series of tools to understand the code. So the tools first went through the code, explained to me what it was and then I went there to work on it, but I had to work with tweezers because it was so difficult to understand that it was a nightmare.
It's hard to read and understand what each line meant, because basically the variables and names were almost all numbers, they were the types that were already there and that made it work.
That was spectacular software and it had really good people around it. The guys who designed and programmed it from scratch. Those guys had all those terms memorized in their heads. It's like a London taxi driver. It was all in the knowledge, so they knew the names of the functions everywhere in that gigantic code. For a new person, it was a huge learning curve.
OK. And what happens after Oracle? Or what makes you, as I was asking earlier, decide, right?
No, I started, I started to think that at the time what I started to see was that there was an opportunity to do this type of systems in a faster way and that it would be easier to change them. And it was a general thing. And I started talking to colleagues of mine and it was there that I started to realize that in practice I could do something like this when two or three said they had, look, I have 10,000, I have 50,000, man, I'll join you and put money in and go with you. And when I started to see that, but these guys ended up leaving, obviously, right? It was then I thought, man, my next step is I'm going to create a company. Then, at the time I had to return to Portugal, for personal reasons, but I ended up creating the company in Portugal.
But with those American investors?
No, investors, they weren't investors, they were colleagues who had pocket money.
Colleagues. OK. Ah, right.
They were angels. Family, friends, and fools.
Yes. Family, friends, and fools.
And those were café conversations we had, but when I returned, I was earning very well out there. Then all our friends are saying: 'What are you going to do? Are you crazy?' My mother, poor thing, full of fear because she...
But did you have the ambition to compete with companies like Oracle?
So when you were thinking about creating that software, what was your space in the market? What was the ambition?
That, over time, I then created a company, it made a platform for the internet and I still had some big clients in Portugal. And what happened? That was the final part, basically phase three of my learning or my experience with the problem, because what happened with Intervento, Intervento had 12 clients, we did about 10, I don't remember anymore, 12, 14 projects, maybe I couldn't finish a single project on time and on budget that had been allocated.
So, Intervento was software development, consulting.
Yes. We had technology and we did consulting. At that time.
So you ended up selling the company to where?
I didn't have, I didn't have capital, I had no capital at all. It was running on a shoestring. So.
You ended up selling the company to one of the clients.
Altitude needed knowledge. The internet.
Yes. They were wanting to go public at the time, right?
It was right before the crash, before the bubble burst.
So, you realized that, ok, I'm trying to deliver projects, I know how to do it, I know how to make software, but I never get the timing right and I never get the budget right, so this doesn't make money. So what I really needed was a technology that would help me deliver this quickly.
And that's where OutSystems is born.
But before that, I think it's curious Paulo's journey up to here. Look, he is in the United States at the moment of greatest effervescence and the beginning of the internet.
Uh-huh. So things start to bubble and he, curiously, is at a company that is not an internet company, which is Oracle, right?
So, in other words, he's at a company that is also very innovative, but betting on more traditional things than the internet itself.
Hmm. But look, for example, the great disruption at the software level at that time was the appearance of the Java language. Right? Don't forget that we were, we were migrating from clients, right? At the time more... Jim Gosling was inside Sun, and so in SunLabs, but that was a pure research department, because Sun made more than 98% of its revenue from hardware, right? So that was there, a thing, some games and so on. And what he was doing was, I don't know if it was in '94, if it was in '95, he started doing a road show through the Valley looking for companies that were willing to adopt the Java language with the attributes it had, which the promise was that the software written here would run on any hardware, so open systems. And Oracle, that was core for them. So Oracle decided to adopt that and there was a big partnership with Sun Microsystems. They had developed it in C.
They had developed it in C, right?
Yes. Your database was all in C. It probably still is, because it's a language that was very well made from the start.
Ah, and super efficient. But yes, but the Java language appeared. I had a great experience with the Java project. That was also another. For me, the Java language was one of the worst things that happened to the technology industry. It took us back again, until then we were on a path of almost exponential increasing productivity with the 4GLs, the CASE tools and so on. So, there was a lot of productivity in this kind of thing and suddenly the Java language appears and it took us completely back to a world that was almost feudal and lacking productivity.
Because it drastically reduced productivity. People today have no idea. It reduced productivity. It's that, it went back again. The Java language was a great example of object-oriented systems. But to do anything, before we could do, we already had tools, we could make a screen in an application very quickly, in minutes, and suddenly a Java language appears where to do anything you needed to write dozens and dozens and dozens of lines of code to put a button. Then the language model itself, you needed to have a lot of knowledge of garbage collectors, anyway, technically it was a complex thing.
So, what was the advantage of Java?
The advantage of Java was that it was a modern language, it introduced later C# was copied in a certain way, it brought very interesting constructors, but at the time we were already having in the industry a very big evolution of software development tools, very fast, mainly coming from PCs. I don't know if you remember a thing called dBASE IV, Clipper and anyway, they were tools. That was super fast, you could do, I made an accounting software for a friend of my father, I think in two weeks, the complete software with everything. In those tools. And so, there was a very big wave of evolution in these tools to drastically increase productivity. And suddenly something appears that takes everything back. Ah, in the Enterprise this doesn't work, for companies we need this. And that created a huge recipe for system integrators. At the time that gave... a lot of things were created. Obviously the systems that were built in that language are robust and so on.
That coincides with the fear of 2000, right? Of the year 2000.
Yes, exactly. Then there was the opportunity to redo a large part of the systems.
The fear of the year 2000 was that everything would go to zeros, right? That it was 2000 instead of 99 and it would go to 00 and the computers would get confused.
And the world was going to end. Yes. And the problem wasn't as big as people thought.
But it was a big business. Well, anyway, all these things appear at the same time and have some complexity. But anyway, what happened later... after it collapses, the bubble collapses, right? And you are in Portugal?
I am in Portugal. Hmm. What collapsed?
What was the feeling when it collapsed? I was at Altitude, I was part of the team that was helping in the IPO process of Altitude. What I felt was that we were doing the work of taking the company public and the market, there was a week where it was decaying at 5% per day. And so there was a retraction. We entered a bear market at that time, a retraction of investors. We needed to have multiple large subscriptions, we didn't get those subscriptions. And I also had, when I sold the company, I stayed with the responsibility of staying there for 18 months, but in reality I was with that and it was a corporate environment, it didn't completely suit my way of being. And at that time, after the Intervento experience, everything finally closed. And I started to think I wanted to address this software productivity problem, mainly for enterprise companies, I thought there was an opportunity there. And that time at Altitude gave me a lot of knowledge on how to raise money, how stock exchanges work, how private equity works, how VCs work and so on. That was a very, very big school. And then when I left, basically with the idea and the network I had created, I launched OutSystems. It wasn't just me, but with my colleagues.
When you launched OutSystems, what was the value proposition?
The value proposition came, in practice, from the pain that happened at Intervento with projects. In other words, you wanted to build a software Lego?
No, it wasn't like that. No, that's not how it was thought.
OK. I wanted to build a portal, for example. I wanted to make a portal. By the way, most of the projects we did at Intervento were internet projects, so it was a sales portal for Telesp or an e-commerce portal for SAPO. So, they were projects of this kind. And those projects, we gathered the requirements and when we were building, we showed a first demo, the requirements changed 20%. And when we put it in production, they changed 40%. So we immediately faced a problem that I later realized by being in the industry, that it was a general problem and that everyone accepted it, which is that it was assumed that the way to stabilize the construction of a system is to ensure that the scope of requirements is very well defined. And so the way system integrators, everyone who did software projects worked, was like a bridge. So you made a design, you understood exactly, you made a survey of the margins, the dimensions, how many cars and so on, which was all very well defined. You made an architectural design of the bridge and then you built it, did validations, audits and so on, and then you opened it and it went into production and the bridge doesn't change for 60 years. In software, exactly the same philosophy was used with one big difference. Which is that the capacity is every time you put in an information system that introduces a disruption, until then in that case everything was done with fax and paper and we put in a portal for them to do transactions through a browser. That completely changed the system. So the people tried, gave us requirements, how it worked on paper, but the introduction of the technology itself changed the process. So the first time I saw this, I said this is not how people want it, which was the opposite. So it was the same thing as we are building a bridge and while we are building it we change the margins and the requirements of the river depth and so on. And so we were building software in a German project model, what they call waterfall projects, which are done in phases, when in reality it was impossible to define the great, the great Eureka, the moment of innovation of OutSystems at the time, was we looked at the problem and said: 'The way to solve the completion of finishing a software project is by ensuring that the requirements are correct, assuming that the requirements are never correct, that it's impossible, then the best... is to not have requirements, is to focus on... but it has to be finished, it has to be done, right? There has to be the bridge at least. It can be projects and that's not completely off-base, that comment, but what we looked at was then why don't we lower, make the cost of change very low? Because the big, the other big problem is how software technology worked at the time, programming languages and so on. If we could define a functionality at the beginning of the project that cost a dollar, but after having the whole software built, that is, the bridge was all done, making a correction cost 50 dollars, it cost 50 times more, almost two orders of magnitude, because a change there would impact a lot of other things in the software. It's the same as you building a house and suddenly you forgot the bathroom. And now? Now you have to destroy a room, you put something, it never looks good. So, it was things like this. And what we did in practice, we started to think, what if we lowered the cost from 50 times to five? And it was that that no one had ever thought of in this way, which is instead of trying to get the problem right, what I do is correct it much faster.
That's why your consultants had to understand the client's business very well, right?
To be able to build the system.
Yes. But with this you needed to know less, because you could go there, implement what they were saying and then as you were doing it, as it was very easy to correct, you were adjusting and so you were learning the system with the users, with the IT, with the company's IT department and the consultants at the same time. So, OutSystems is widely used, it has more than 80,000 use cases. We have 27 macro-industries, from banking to agriculture and so on. It's used to do almost everything, basically everything, because it's very easy to absorb the requirements and make them and be very effective in producing a final system.
I know several projects that were initially built in OutSystems, precisely because of that flexibility, right?
Uh-huh. to then know the requirements for application development. More... that at the beginning I had that problem.
No one could believe that it was so easy and so fast, could be robust.
These are people who then don't understand how systems are made. We built the platform, we designed the platform. There was also some genius from the people I had with me, right? I had absolutely fabulous guys. So we designed that as a genuine egg of Columbus. That's why the platform, after 24 years, still has a very, very large percentage of the original design because it was very well designed.
Why do you call it a platform?
Because... it's not almost a programming language.
No, it's not a platform. Platforms are a concept. Hmm. So in technology, there is a lot of this notion of platform versus application. Hmm. So platforms are normally things where you can build applications, have several use cases. Ah, it serves for several things and it serves to do several things. So the platform is always something that serves to do several things on top and so, or, for example, relational databases, just to reference the previous topic, that in reality is a platform. So platforms always have a notion of generalization in relation to the specific problem we are going to do when we are very, but it is...
Look Paulo, and how is it, what is the feeling of being ahead of your time? In other words, when did you realize that what you were doing was effectively way ahead of its time and that you had to cross a great desert whose size you didn't know, right? You didn't know at the time until you arrived.
It's exactly when you're in a desert. You don't know exactly where it starts and where the desert ends and the trees begin. You just keep walking one step at a time.
How many times did you think about giving up?
I never thought about giving up.
You never thought about giving up.
Giving up is not with you. At BOLD we have many episodes for you. More than 250 guests who share the most diverse experiences. Go to our YouTube and take the opportunity to subscribe and be the first to receive.
For me, I just needed a point of motivation. So, in these things, and you know this, right? In these startup things, for every 10 no's there's a yes, right? So we have to take advantage of the small victories. But the fact is that the product really worked. The product worked. We...
One thing is to work. We have an example of a startup that we've been following from the beginning, which was also way ahead of its time from the point of view of digital advertising, right? And it's still ahead of its time, because the technology hasn't appeared yet, it had to stop, so it has patents and so on, but it doesn't...
Yes. We were ahead in this type of products. By the way, we introduced many concepts that in the last 20 years were adopted. For example, the concept of DevOps, I don't know if you've heard of it, or continuous integration, continuous delivery, which joins developers with the operators who operate the software, for example, in the cloud. That union was at OutSystems in 2002, the platform joined that because that was one of the big levers to lower the cost of change. We needed to do that. So we did reverse engineering, basically, we took the problem and came to the conclusion that we wanted to implement six things that later came in one way or another to be adopted in the industry. But you saw it like, and man, you guys are very smart. No, no. We had a process of thinking about it from the point of view of the problem, how do we solve it for the solution? And when you think like that, everyone seems smart. OK.
But the question is, you were then observing some market signals that were in the right direction, right? Is that what you're saying? Yes, because... and you had hope that it would get there.
The problem in practice was that we were ahead of the market in the way we did things. Our big problem was, and I once wrote a paper about six or seven years ago, because the conversation I had with the IT departments to which we tried to sell this, was that it was too good to be true. Where is the problem? That's what they asked me, this is like a miracle. Where is the problem? And I couldn't write it for them. Because we had solved the basic things, we solved the problem in a complete way.
The problem is in the adoption.
Well, it's in the adoption and in marketing and in the timing. If I had been in Silicon Valley, the company probably would have had another path, but would have reached billions in revenue much sooner. As it was starting from Portugal, it was on a shoestring. We didn't understand anything about marketing. This thing of product-market fit. This concept, you catch it through field experimentation, which is if the client doesn't want to buy something, it's wrong. But our product solved a client's problem. It solved a problem. It was enough to do a small proof of concept and it was suddenly miraculous. So they believed in it, but I had to be able to do that. I always worked in initial disbelief. That is the big problem of being ahead, is that you're not navigating a category that is suddenly hot, that everyone buys. If you solve the problem, what is the difference? What is the technology or the way you solve it? Because there is distrust of the future. Because in a transaction, a sale, mainly B2B, the markets, the clients are divided into four big categories. And those who are willing to take a chance on a company that has a completely crazy idea, that no one has ever heard of, that has seven people, some of them don't know how to dress when they come to a meeting, don't know how to explain things, don't have marketing and so on. This percentage is very small, they are what are called technologists or visionaries in that product introduction model. I don't know if you've heard of the Chasm, it's that model of crossing the Chasm by Geoffrey Moore? But the vast majority of clients we sold to, mainly in Portugal, were in the second, what is called the early majority, which are the pragmatics. The pragmatics have certain characteristics in that they buy if someone else has already bought, they work in herds, they work by what is called... and you weren't able to break that... no, you need to find the first ones are very hard to sell. You have to go to the first segment that are not early adopters.
Hmm, they are the early adopters, early adopters, visionaries, technologists, that's more or less the same. That little group.
Who are the ones who take more risks. Who don't mind buying something that is different.
But you can get in with those. The big problem is... No, no, no, those, those are very few.
In Portugal we were very lucky with the guys from Altitude. Tourism in Portugal at the time also... no, tourism came later, Brisa... and with Brisa and then we got ANA, but little by little, basically, I had to find special people from a vision point of view. So your big, the big change was the Pentagon.
In terms of global adoption.
No, no, no, no, it wasn't, actually. It wasn't.
OK. I thought it was when Microsoft in the United States buys... that already gives confidence to everyone, right?
It must be several moments because... because I remember we were two or three years into OutSystems, I don't know if it was the time, I don't know when Cavaco, ah Cavaco was prime minister when was it... it was Cavaco. Cavaco was for a long time still. But he was there during 2000 and 2004 or not?
Hmm. There he was already president, right?
He was already president. I remember Cavaco saying something, maybe he was president when he said this, that Portuguese companies should internationalize by going to Spain. I don't know why, I remember it perfectly. Later I'll tell you what that provoked. I still remember it today as a great example that created a framework I use today, which is the evaluation of mentors and the evaluation of the advice others give you. At that time I remember it, I had great respect for Cavaco Silva and I remember it like this and we were doing that, it was a reinforcement for us to invest. We were in the Netherlands, we invested in Spain and so on. That was one of the things, it was one of the worst pieces of advice I've ever received. It was that piece of advice. In particular, not because the man had... but because he didn't understand anything of what he was saying, so he didn't even know what he didn't know, so he had immense blind spots. And that led me to make the big mistake, for example, of OutSystems, which was the dispersion.
The dispersion.
prematurely by many countries. So when we entered the United States, we already had clients in Asia, clients all over Europe, we were completely spread out. A company that had nowhere to fall dead, we billed less than 40 million and we were in who knows how many countries.
But about that, it's interesting to dig deeper. There are those who defend that, after having the concept proven in Portugal, the best thing is to go abroad right away. And there are other opinions, perhaps in other circumstances, where we still have a lot of opportunity to explore in Portugal, let's be the best before going abroad. Before going abroad, because there's a sales opportunity when there's a sales opportunity, right? What do you think about that?
First of all, it's a bit contextual, but if... or rather, it depends. Of course, that's it. Yes, it depends, but it's not that answer that just stays at 'it depends'. I'll explain. If you're thinking of creating a company that sells to other companies, sells services or product or whatever, it's very important, it's very important that you find a niche, the product-market fit, the fit between the pain and your solution and the sale. The difficulty of the sale decreases drastically if you manage to be solving a very, very specific problem. The sale becomes much easier. A very specific problem forces you, instead of generalizing to a very heterogeneous set of clients, you fix yourself, you start to reduce what is called the target market, OK? You reduce that. When you reduce, typically the first big reduction is choosing a sector. You choose, I'll do it for banking and so on. So much so that the vast majority of companies working in Portugal at the time focused on banking and telcos and government, which were the biggest, or at least those that had more than one or two clients, where it was possible to have several clients.
But what happens is when you're selling a product, from the moment you consume more than 30% within a target market, it's very difficult to catch the others, because the others are already much more conservative, it's too early for them and so on. So, 30% and you're a market leader in an initial introduction product, not even less. Who is focused, who has a good product, a strong product, has 30% as first targets. Then from there, my friend, this is just to tell you why the math here makes it absolutely fundamental for you to go to a market much bigger than Portugal.
So, imagine, I made a product, in Portugal I made a product that initially my business plan at OutSystems was only to attack telcos, but we hit that crisis and we sold to Ótimos, we sold to a small company that was in the value chain in Holland and we sold to Telefónica. So we were doing our plan of being, we expressed ourselves geographically, but we had a sector. And suddenly the crisis appeared and telecommunications companies stopped spending money on anything that was value-added. They had spent a lot of money on 3G at the time, I think. So they were still digesting all those investments and decided to stop that type of investments and our platform was gone.
I was very lucky at the time because the platform was relatively generalist. We were solving a generalist problem and it started to be adopted. That's when I brought in Brisa, Ana, and from there these other companies, because they had... but if I had, and probably if I had been in the United States, I would have died because the entire sector had collapsed. But here, since I already had a more heterogeneous model, I was already doing that, I was thinking like this: if this telco thing doesn't work, I don't have a safety net. And then I remember us making decisions at the product level that were suboptimal for telcos, but that allowed me later to create a safety net to get out of the sector.
But what you're saying is that if you had focused only on telco and if you had been in the United States, you would have had to focus only on telco...
Probably would have collapsed.
You would have collapsed. OK. But the trade, the other side of the coin is that...
