Interview with Lasse Hamre, co-founder/CTO at AloeCare Health
Before teaming up with AloeCare, Lasse was the founder of a startup called ThumbPlay, a ringtone company that at one point had 1 million subscribers and was later acquired by one of the biggest US media companies, iHeartMedia, which today owns more than 850 radio stations.
In the interview for the HTEC’s affiliated podcast station “Protok” you can hear about Lasse’s experience with business transformation and scaling during his time with iHeartMedia, his new venture with AloeCare Health and the collaboration with HTEC.
How did you get into ThumbPlay, what was the initial idea and how did it all begin?
ThumbPlay was founded back in 2005, 2006 and I was the technical co-founder. There was a big market in Europe and Scandinavia for ringtones, but in the US that market was really young and immature. So, we saw this as an opportunity and decided to move into that big market and see if we can build something big. We started the company with only a couple of people, and we grew to almost 100 people in 2 years, and we grew to over 1 million subscribers and over 100 million dollars in revenue. It was a very fun time — a bit of a crazy experience to grow so fast. And it was also back in the day when there was not a lot of frameworks to build software and engineering to scale. So there were a lot of challenges around. How do you build a backend to support that kind of a user base? It was definitely a fun time.
You can have companies overseas, you can get people to help you, but if they don’t know how to build products, if they are not invested, if they cannot be a real partner, that’s really difficult.
Somewhere in that period, you got a call from iHeartMedia? How did they contact you, how was that cooperation realized?
Everybody was familiar with iPhone coming out in 2007, and when that happened, the market for ringtones switched very quickly. So, we realized that we had a lot of growth and revenue, but that was not going to be continuing. The market was going to go away, and we had all the relationships with labels, we had a music catalog that was very big, so we decided to switch the focus of the company to become an on-demand music platform. We spent about a year, year and a half, to really repurpose the whole platform to be an on-demand music platform. Around 2010 Spotify was moving into the US, and it was more competitiveness in the market, and we realized we had to have a lot more investments to compete with those guys. At the same time, Clear Channel, which is now iHeartMedia, was looking for a way to digitize their radio stations, so it was a match between our two companies, and we got acquired in the March of 2011.
How did your business model change once you started the collaboration with iHeartMedia?
They acquired the whole company, the whole team, and the platform. We were given, essentially, six months to relaunch iHeartRadio on our platform. One of the challenges around that was scaling. The platform that we had was good, but it would not scale to a company such as iHeartRadio that reaches 240 million people through their stations. It’s a huge market. Scaling was the one thing we had to consider, and also we had to consider this new product — live radio, which we were not familiar with. We knew music, we were into that space for a long time, but we didn’t know how to incorporate it into our platform and make it a very good user experience.
What were the major challenges you had to face during that short period?
My directive was to support millions of users on day one, and we knew that was not going to happen with the system we had. We had a relational database for the majority of the backend, which works fine, but doesn’t work when you have one million concurrent users — it just doesn’t scale. So, we were looking at how to optimize the whole system to handle that and one of the thing we did, which was pretty early, was to move into the NoSQL backend for user data. We kept the user authentication database in PostgreSQL, but we moved to have a NoSQL solution for scaling the user data, so we didn’t have to worry about that. This was really early for NoSQL.
Yes, that’s exactly what I wanted to ask you. It was very experimental for that time. How did you make the decision to go into something that was basically an unknown territory at that time — a big risk for a short deadline?
We tested out a lot of frameworks. We actually ran our own load testing, and we actually decided to go with MongoDB. MongoDB is founded in New York, and we set down with their CTO and CEO, and we kind of walked through all the use cases. We got a lot of help from them in terms of how we should model the data. So we decided to essentially have a denormalized database for the users. We had a lot of redundant data, but we knew that that would scale. So, it was a lot of decisions on how to model the database. And yes, it was a little bit of a risk, but it was the least amount of the risk that we could have.
When you are going from a startup to an offer from a huge company, how do you make the decision to get acquired vs. going on with your own story? I am asking this because it’s one of the biggest decisions for a startup to make.
A lot of times startups are controlled by the investors, so the investors had a lot to say. It was a natural move. Because to compete with Spotify would require a lot of investment and also we saw a good fit combining our platform with iHeartRadio and scaling it to a lot of users very quickly. To grow to the amount of user we did with iHeartRadio would take tremendous time and money. If you look at Spotify, they have spent hundreds of millions of dollars to expand to the user base that they had. We at iHeartRadio grew from 2011 to 2017 to over 100 million users. We actually grew faster than Facebook from 0 to 50 million users. From a technical perspective, it was easy because we realized we could build something very big and exciting pretty quickly.
We mentioned the technical challenges you had. Was that at the beginning, when you first acquired, until that first big deadline?
When we built the platform, initially, we had to make some hard decisions. The platform was actually internationalized. Then, when we got acquired and had to launch this new product, it would have been too much work to make the whole platform international, so we made a decision to stick with the US. We also made some decisions on the backend. We didn’t make micro-services, we had one big monolithic system. Those were just decisions to hit that deadline. We had some technical debt and after the launch, and in the next couple of years we were addressing those things as we grew.
So, you were still sticking with the old problems, even after the deadline, and you moved to the next phase of the technical development. Did you, when you had a bit more time, switch to some new technical aspects or were you still fixing those trade-offs you had to make during that risky deadline?
The thing is, when you launch something, you always get feedback, and you have to build new features and improvements. And you still have to figure out how to address the old issues. So, we continued to build new features, but we also continued to address the backend system, to make it more scalable. And we also moved data centers — from having a hosted solution to an Amazon server. That was a challenging period for us because it’s hard to explain to the management that you’re going to spend six months or so on it, and you going to have to reduce the capacity because you have to move to a data center. They don’t get to see the features or the benefits, but for us, it was important because it was hard to support the platform at the data center we had.
With HTEC, I really found a company which I feel very comfortable with, and which can be a development partner for launching a product, but above all, they have the experience with building hardware, which is pretty uncommon.
How did you cover the multi-platform aspect of your application?
Obviously, the Initial launch was on traditional platforms — iPhone, Android, and Web. But, to reach all the users, and these are the radio users who primarily used our service, we had to be everywhere. So, we spent a lot of time building platforms for gaming consoles, for TVs, etc., and we had a whole team to essentially build integration with cars. We worked with all the big car manufacturers, and that was pretty difficult because they were not super experienced in writing software, API or SDK, so, we had to spend a lot of time making our app work in every car. We spent a lot of time getting a really big distribution so we could reach the biggest amount of users anywhere they were.
You mentioned the growth. How did it change over the years? Was it growing steadily or exponentially?
We had hypergrowth, obviously — the kind that went from 0 people to 150+ million. What happened was that once we passed these 100 million registered users, we didn’t see that growth anymore. There are only a finite number of people in the US, so it happened naturally in a way. In the beginning, we really built products based on our experience, or we built really big features without knowing how the users really used the product. We did some UX/UI testing, but we actually built actual features, which we would spend months on, and then tested it live. What happened when we started seeing a kind of stagnation of our growth was that we realized we had to be smarter — how do we quickly make small changes, and how do we measure it? So, we had to build our own A/B test framework so we could launch small improvements and see if we could get a couple of percent increase and then continue down that path. You can’t just build these major features, because there’s only that many you can build in a product. We became a lot smarter in how we could run multiple experiments, and how we could test the things and we quickly pivoted based on what worked. This is a great way because the users really tell you what to do. In the beginning, you can build features that maybe you have experience with or maybe you have the know-how for, but, ultimately, if you can test it with the users and they give you feedback, that’s how you succeed. That’s how Facebook and all other companies are doing it.
How do you choose to build those smaller features that would steadily give you growth?
We started building these internal squads of people, they were working towards KPIs. So, we could increase retention by 5%. They would come up with ideas of what to do, they would test it, and they would see if that idea had legs. If it did, they would either just launch that, or they would build that feature. A lot of times we just mocked or hacked something together just to see if users used it and if we saw an increase in usage we would build the whole feature. Sometimes it would be easy, and sometimes it would be a feature that would take months to build.
What tools did you use to track the user feedback and see how the users are responding. How did you measure the success of those new small features?
There are a lot of tools in the industry around, like A/B testing, but that didn’t really fit our use cases. We wanted to track both from the client and the back end, and we also wanted to run from our data science, recommendation engines — we wanted to run multiple different models. So, we ended up building our own framework for doing the A/B tests, and then we fed that data into our analytics platform. So. we could have dashboards, and people could run them.
You made the transition from iHeartRadio to IoT and Healthcare business. That was a huge transition to something that’s really a buzzword for a few past years. Can you tell us something more about AloeCare?
Essentially, iHeartRadio it was an amazing experience, and we had an amazing platform. In a way, we grew to a point where, for me, personally, there was not a lot to do, and I was hungry to go back to that startup scene. The time when we built ThumbPlay was one of the most exciting times I have ever had. For AloeCare, I was an early investor. I was helping the founder to transition the idea from what was originally a baby camera for disabled children to elderly care because we saw that one-third of the people used it for this purpose. Once I was ready to move from iHeart, it was very natural for me to move to AloeCare. I am very excited about it, from the technical perspective as well — the IoT, hardware, big data, and all those things. It kind of checked off everything for me in terms of that. And also from a personal perspective, I think this is the business that makes sense. I’ve been in the media and advising on ad tech, but this is actually saving lives. It’s cool to move into something that can potentially be helping humanity and not just making money.
When you were going with ThumbPlay you started off with something that was basically your idea, but was Aloe Care something that started from a need or your personal desire to help people?
It actually started off as a need, for Ray, the original founder. He was using it at first as a baby camera for children with disabilities, but then he started using it for his own parents at home. So, the product actually came from a need and then we changed it to fit this market called PERS — Personal Emergency Response System. It’s something you can have in your home which enables elders to live at home safely, and longer as well. If something happens to them, we can detect that, and they can reach out and get help.
What can you tell us about your cooperation with HTEC and why you have chosen HTEC as a development partner?
As I mentioned, I didn’t know hardware, and we had a lot of challenges trying to find someone who knows hardware — and hardware is hard. Even in the US, it’s something that not a lot of people know. It can be very expensive to go into that market in Silicon Valley. I actually got introduced to HTEC through Digital Knights, a company that I’ve been working with a lot in the past, which finds really good tech teams and companies to match your requirements. When I met with HTEC, it was really cool because they had a very similar culture to what I was used to in iHeart and had a lot of experience with hardware. They also had a lot of experience in building products. For me, it was very important. You can have companies overseas, you can get people to help you, but if they don’t know how to build products, if they are not invested, if they cannot be a real partner, that’s really difficult. With HTEC, I really found a company which I feel very comfortable with, and which can be a development partner for launching a product, but above all, they have the experience with building hardware, which is pretty uncommon.