← The SaaS Podcast - AI, Growth & Product-Market Fit for SaaS Founders
The SaaS Podcast - AI, Growth & Product-Market Fit for SaaS Founders
439: Metabase: How Ignoring Expert Advice Led to Real Growth - with Sameer Al-Sakran
00:56:19
Loading summary
Transcript68 lines
- [00:00]
Samir Al Sakran
Foreign.
- [00:10]
Omar Khan
Welcome to another episode of the SaaS podcast. I'm your host Omar Khan and this is a show where I interview proven founders and industry experts who share their stories, strategies and insights to help you build, launch and grow your SaaS business. In this episode I talked to Samir Al Sakran, the founder and CEO of Metabase, an open source BI tool that helps teams quickly turn raw data into charts and dashboards. In 2014, Sameer started building Metabase as a side project, just a simpler way to answer basic questions from a database without needing a complex data stack. It wasn't supposed to be a company, but once he realized others shared his frustration with bloated over engineered tools, he spun it out and raised the seed round. Then he did something most SaaS founders wouldn't dare he he waited four years before charging a single dollar. Even when customers tried to pay, Sameer said no. And there were good reasons for that. One wanted to embed Metabase in their product, but the deal came with heavy demands and another required a 50 page legal contract. So he turned both down, instead choosing to focus on building the right product before chasing revenue. When they did finally monetize, it wasn't through a polished sales motion. It was a buried CTA deep in the admin panel. No salespeople, no support, just a credit card form. And surprisingly, strangers started paying $300 a month to remove the Metabase logo from their charts. That scrappy self serve flow eventually pulled in close to six figures in ARR without a single sales call. It wasn't fancy, but it worked. But instead of doubling down, he followed advice to do SaaS the proper way. He and his team built an enterprise edition, ran sales calls, hired AES, and as a result, nearly lost all their momentum. Eventually they returned to what had been working all along. Self serve. Low friction growth. And that's when the business really took off. But the detour cost them years that they'll never get back. Today, Metabase is used by over 70,000 companies, generates eight figures in ARR, and has a team of over 100 people around the world. In this episode, you'll learn why Samir ignored paying customers for four years and what finally pushed him to monetize. How a simple CTA buried in the product helped Metabase generate real revenue with zero sales or support. Why following expert advice nearly derailed their growth. And what happened when Samir trusted his instincts again. We talk about how Metabase botched their pricing early on and what changed when they finally let customers pay the way they wanted and what scaling pains surfaced as the team grew and why? The hardest things to scale were the ones that they were best at. So I hope you enjoy it. Are you building or scaling a SaaS product? Then you've likely faced authentication and user management challenges. It's crucial, but let's face it, it's not the core focus or the most exciting part of your business. And think about it. How much time does your team spend on Auth instead of building your core product and features? And as you grow, it only gets more complicated. Enterprise sso, custom security, user analytics. Soon you're drowning in feature requests that have nothing to do with your actual product. This is where Propel Auth comes in. They handle all the authentication heavy lifting from quick integration for devs to built in user management for your customer facing teams. It's everything you need to scale without the headache. Here's an exclusive offer for our listeners. Sign up for a free Propelauth account at propelauth.com no credit card required. And if you decide to Upgrade, use code SAAS24 for 50% off their growth plan for six months. That's Propelauth.com I talk to a lot of founders who have this same challenge. They've got an amazing product idea but need a technical team to build or scale it. If you're looking to develop a B2B SaaS product but don't want to hire and manage an in house team, listen up. Gearhart is a product development studio that handles the entire technical side of building your software. They've built over 70 successful products, including SmartSuite, who's found a trusted gearheart after his $200 million exit to help build his next big venture. Some of Gearhart's customers have gone through YC and their portfolio companies have won over 10 startup competitions. Until the end of May, they're offering our listeners free strategy sessions with their leadership team. Just visit Gearhart I.O. to book your session. That's Gearheart I.O. samir, welcome to the show.
- [04:36]
Samir Al Sakran
Thank you. It's great to be here.
- [04:37]
Omar Khan
Do you have a favorite quote? Something that inspires or motivates you you can share with us?
- [04:42]
Samir Al Sakran
Yeah, I was thinking a lot about that and in all honesty, I think I'm just going to quote myself just to like start off on a great megalomaniacal slant. But the thing that kind of kept bubbling through my mind as I was thinking about this conversation was the idea of playing your own chessboard and to stick to your own board.
- [05:02]
Omar Khan
It's going to make a lot more sense once we start kind of sharing the story. So tell us about Metabase. What does the product do, who is it for, and what's the main problem you're helping to solve?
- [05:14]
Samir Al Sakran
Yeah, so Metabase is fundamentally a way for you to get the data that is inside a database you have lying around your company and expose it in either a graphical form, visualize the data inside of it, run reports, generate numbers, produce metrics, what have you, and expose it to everyone in your company. So we are intended to be a daily driver for the average person with a real job. Now, we're open source, so our installer is typically very technical, but analytics is a multiplayer game and they're usually not playing on behalf of themselves. And so we are a tool that is used by anyone in the company. It's installed because we're open source by a developer, but eventually it is meant to be used by everyone.
- [05:53]
Omar Khan
And I think there's about, I think what, 70,000 odd companies that are using Metabase in some shape or form. And, and then you've got the, obviously you've got the open source side and then you're selling to enterprises as well. Give us a sense of the size of the business. Where are you in terms of revenue, size of team, that stuff.
- [06:15]
Samir Al Sakran
We're just under a hundred people. I think we're going to cross a hundred between the taping and when this airs, and we are well into eight figures at this point of ARR.
- [06:26]
Omar Khan
Now, the business was founded in, in the, I guess at the end of 2014 and probably a couple of months after I started this podcast actually, so we can celebrate birthdays together. So what were you doing at the time? And like, where did the idea for this, this product come from?
- [06:49]
Samir Al Sakran
Yeah, so at the time I was working at expa, which was a startup incubator and adventure studio. We were starting companies. We were bringing founders from various companies in the valley, having them kick off projects that eventually became funded. It became real companies. We were largely playing at kind of the seed to a range. And a lot of what I was doing there was building up shared infrastructure for the portfolio. And so Metabase came out of a side project that I had where I was just like, didn't really like any of the commercial options for a host of reasons, but mainly due to just how heavy everything felt. And I wanted to create a lighter, slicker, easier version of a BI prompt. And so, you know, it quickly became a viable real thing, as opposed to nights and weekends project. We staffed the team at expo and then eventually spun it out in 2014. And so a lot of it came from me scratching my own itch of wanting something that I could just slap on top of a database that a company had lying around where there was no data analytics team, there was no data pipelines, there was no data stack, it was just whatever application you had and its database. And it was essentially all about the agility of metrics or measurements or dashboarding.
- [08:11]
Omar Khan
So I think when the whole idea of scratching your own itch, I think many of us are in this situation where you see a bunch of products out there and you're like, there isn't something that does exactly what I want, or this thing does this and that thing does this, but not the way I want to do it. And if you're a developer, obviously life is a lot easier because you can go and build something and live happily ever after. But it's very different saying, I'm going to build something for myself versus saying I'm going to go and build something and turn it into a business. And as you and I were talking earlier, when it comes to like these types of BI tools, you were telling me there were like hundreds of them around at the time. So what was it that kind of pushed you to see this not just as something for yourself, but also a viable business opportunity?
- [09:10]
Samir Al Sakran
I don't think I'm that unique or that special is maybe at the heart of it. And I think the things that I find irritating are the things that a large segment of the user or buying population finds irritating. And so I think a lot of it was just me seeing that most vendors had sacrificed usability at the altar of sellability. And there were just a lot of things that were kind of being enforced by arbitrary, like, industry walls where, like, I just wanted something that slept on top of database, I didn't want a metric store, I didn't want a data cube, I didn't want, you know, to set up any of these tools. I just want something like quick and dirty that would work. And structurally the industry wasn't really making that. And so the fundamental idea around commercializing it was just that my problems were common. Like, nothing I was doing was exotic, was part of like the tension I had where I felt like I had the most basic, simple version of this and there was nothing out there that solved the simple version of five person company or five person team at a larger company. We have like an app with the database. Like, can I just see what's in there? Like, I don't want to again define metrics. I don't want to create a semantic layer. I don't want to deal with all like, I just want to see what's in there. And the level of difficulty of something to do something that simple felt out of whack. And so a lot of the notions of open sourcing it or commercializing it really stemmed from my perception of there being a fundamental missing piece in the ecosystem. And the other thing is that one of the joys of Metabase has been that we are targeting existing use cases. We haven't had to explain why someone needs a dashboard in 10 years. So it was very clear that we were doing something that was intrinsically commercializable and that we just had to do it in some differentiated or some better way and that there would be a, you know, a light at the end of the tunnel with a business in it. So it wasn't like, you know, sorry, I'll jump back, but we were never manufacturing on demand. We weren't like trendsetting, we weren't building something funnily novel. It was just a fairly basic desire that I had that I, I'm sure a hundred million people have had over the last year.
- [11:32]
Omar Khan
How long did you work on it at Expo before you spun this out?
- [11:36]
Samir Al Sakran
I don't remember, to be perfectly honest, but something on the order of six months. So like the, the, the desire was born very early. Uh, but I, I, I, I would want to say that the actual code was not written until six or nine months in.
- [11:51]
Omar Khan
And, and how much money did you initially raise? What was the seed round like?
- [11:57]
Samir Al Sakran
It was just 2 million, so fairly standard for the value of the time.
- [12:02]
Omar Khan
Now the idea with Metabase at the time was a simple, lightweight tool. People can easily download it, they can deploy it in five minutes or whatever. And so you're seeing this as a business opportunity. You start kind of going down the open source route as a way to get it out there and start to just reach more people. But you didn't monetize for like you were telling me for four years. Right. So why, and what was going on in that time?
- [12:39]
Samir Al Sakran
Yeah, so this is one of those things, I'll freely say. I don't know if that was the best of ideas at the time. However, it was very intentional, which was, we want to build a product that wins. We're competing with a bunch of companies that know what they're doing. The options in the market are, I don't like them, but you'd have to be delusional to look at them and say that there's anything wrong with them, it's just like, I don't like the choices they made, but Tableau was a great product and remains a great product. And so for us to build a viable business, the idea was we have to first build a viable product. And that took time, it took effort, it took a lot of iterations. And so there was our own desire to get adopted and then commercialized as opposed to concurrently adopted and commercialized. And at least in theory, that's the open source playbook where you build the open source product, you put it out there, lots of people discover, lots of people use it, you build a community, and then at some point you wave a magic wand and you build a business around that. And so for us, there was always this creeping finish line of we've done enough to commercialize. And it is very natural to just keep wanting to do more. There's always one more feature request. We wanted, before we felt comfortable, we wanted to build one last thing. And there was never a clear, once we checked this box, we're going to commercialize. But there was this subconscious insecurity and wanting to, to do more. And in retrospect, we probably should have shipped something we were confident selling earlier.
- [14:18]
Omar Khan
Did you raise any other money in those four years?
- [14:21]
Samir Al Sakran
Yeah, we raised the second seed round two years in, so another two and a half, give or take.
- [14:26]
Omar Khan
Got it. So that gets you through to the first four years. So tell me about the. How you went about the monetizing the product. What had to happen for you to feel like you were finally ready to do that and then how easy or hard was it to get that first customer?
- [14:51]
Samir Al Sakran
Yeah, I think we, it's kind of funny because we, for the first couple years, people kept trying to pay us and we just didn't take any money. So it's kind of. There was at least two deals that were. People were just basically hammering away, but we didn't really have something that we were comfortable supporting because one of them was an embedded deal where they wanted to embed us in their product. And it was going to have a lot of distorting demands on what, on what our fundamental part was. And we were always trying to build a mass market product. Mass product, sorry, mass, Mass. Mass market tool as opposed to an enterprise tool where for us, success was always measured in tens of thousands of customers, as opposed to 100. And so we intentionally said no to a few people early on, but I think the first serious user that wanted to pay us, we eventually just couldn't do it because we needed to sign a 50 page MSA. We had a jurisdiction in some, you know, someplace in Europe. And we just couldn't do that. Like our lawyers just looked at, they were like, you really shouldn't do this. And so it was a case where we probably would have like accepted their check. But the contracting was very, very onerous. I think that this has been a long running challenge we've had where just the licensing of the license story we've had has been probably unnecessarily difficult. And I'm sure there's lots of unforced errors we've made there. But back to the story. I think the big unlock was really just offering a way for people to embed charts in their product. And we knew that we wanted to commercialize this from really day zero, like from the very, very first versions. We knew that we wanted to charge money for this. And then I think three or four years in, we finally let you go to a Heroku application, give us a credit card, get a code that would remove the power, my metabase and our little logo at the bottom of a chart. And that ended up just kind of taking off. Like quite a few people gave a bunch of strangers $300 a month on their credit card. And at this point in time there were no salespeople, like literally no one to talk to if you had a question. No one asked a question of we didn't offer support. There was literally no support email anywhere to be found. And there was absolutely zero proselyzation or advertising or anything. It was just a CTA deep in the admin panel where you would turn on, embedding on and off and if you wanted to remove the logo, it would ask you to go to this website and bring back code. And so we ended up getting nearly six figures in ARR from that. And then we probably proceeded to do something else.
- [17:42]
Omar Khan
You start out like the first few years, if I just closed right, you're focused on this is open source. We're just going to focus on building a great product and we are going to monetize, but we're going to do it when the time is right. And then when you did eventually do that, it wasn't like a lot of fanfare or going out and trying to knock on a whole bunch of doors to make these big sales deals. It was like, let's enable it in the product. And interestingly enough, just people were able. There were enough people there who saw enough value to start paying you for it. So I think he was saying like 70, 80k in ARR or maybe close to 100k.
- [18:30]
Samir Al Sakran
I don't think it quite hit 100k, but it was, it was more than you would expect. And I think part of it was that we did have a pretty crisp idea of how we want to monetize. So I think we were always very clear about licensing, we were always very clear about where our paid versus free line was. And this was one of those cases where we called our shot years ahead of time and it ended up being the thing that we could monetize, but we kind of did it out of order and a little too late. But the one thing that I think we got very, very correct, which was the one thing that absolved of some many other bad decisions, was just saying if you want to embed this in your application, you will have to pay us at some point. And so holding our ground on that and picking the right license and having the packaging of the product itself respect that and just not flinching because as people were asking for things as, as they wanted this feature, that feature, we held our ground on that line pretty, pretty strongly. And I think that ended up being again, the one good decision. They made up for a lot of mistakes.
- [19:41]
Omar Khan
You basically have this self serve model. You don't have a sales team, you don't offer support, and yet you get people paying and getting you on the way to the first six figures in ARR. And so most people would then look at that and say, great, we've found something that's working, let's double down on that. And I think you look back at that intuitively, you knew even at the time that that was the right thing to keep doing. But then you got advice that that wasn't the correct way to grow the business. So just talk about like what happened? Why did you change course and take a different approach?
- [20:25]
Samir Al Sakran
Yeah, so I think there's. What's been most interesting about our story has been the number of times where a very smart person would have looked at our, at our structure, at our setup, at our market, at our customers, and then advised us to do something where it ended not being the right call. And you know, at the time, and to be fair, this did work. It just, it's a question of ordering. But the commonly held wisdom at the time was you commercialize an open source project by giving away the core and selling the manageability and the different auth options, permissioning, et cetera. And so we ended up building a quote unquote enterprise edition metabase. It ended up being a good idea to build, but I think the the lesson that we didn't learn from the just again, like the little CTA in the admin panel to remove one line and one link from our events. What we should have learned is lots of people are using it, they'll find CTAs and we should stick to our guns there and just be like, hey, here's a way to get this thing that you want in the moment when you're looking at it in the admin panel. And instead the generally held wisdom was you should talk to customers. This is, you know, we're going to ask for a lot of money. You should go and like, you know, establish trust. You should, you know, guide them through the poc. You should learn about their use cases, you should be able to articulate value back to them, et cetera, et cetera. And so I ended up essentially just doing lots and lots of sales calls and eventually selling the first million in ARR or like rather the next 900 in change by just respectively do. Having an inside sales operation would just mean doing it. And at that point we, we hired some AES and eventually grew the directly sold business a little more. But if I could do all over again, it would have just been, hey, self service was working really shockingly well, like far better than had any right to. And we should have leaned into that and like stacked more behind it as opposed to saying no, that's not what serious companies do do. Serious companies that have succeeded in the space or similar to space to ours are following this playbook. Let's follow that playbook. And to be fair, like lots of companies had succeeded and we were watching, you know, Mongo and Hashi and GitLab just do really, really well. And you know, that's what smart people did.
- [22:55]
Omar Khan
So I mean many founders would, would look at that and say, okay, regardless of which growth channel we focused on, we've got traction. We're, we're feeling like we've got some level of product market fit. We've got to the first seven figures in ARR. Why do you feel like was it a problem? Because then you ended up shifting back to self serve again, right?
- [23:23]
Samir Al Sakran
Yeah. To finish off a story is we got to give or take, I want to say somewhere between 2 and 4 million in ARR. We ended up adding a cloud self service option. I'll have to like actually go through my like historical records figure exactly where. But at some point we built a cloud version and the cloud version started off with self service and that blew up and that just was on a tear from that Point on and dwarfed the directly sold portion of business. And so there were a lot of things that were all kind of nibbling away at, at me and at us. And it's, it's kind of easy in the retrospect to be like no, that was the path. But in the moment there was a, the need to raise money. So you know, one of the biggest things was we were not cash flow neutral. We did have to raise a series A. And every single investor that I ever met asked me the question that I still think is a dumb question for what it's worth, which is like, what is your go to market strategy? And at the time I had a combination of a very sophisticated and a very naive answer and that was we're going to get a bunch of installs, we're going to put CTAs in them, people are going to click on them, they're going to give us money. And this has the unfortunate set pair of characteristics which is it ended up being exactly right. And for our customers with our, you know, our, at that moment, our DNA on the team, our skills, our abilities, the people we had access to, so the people that were actually engaged with us and the clear next ring of adoption, it was actually how things end up happening. Now unfortunately this also sounds very naive and very non realistic. And so this is one of those cases where a sensible investor that has seen a lot of these stories go by would say every tech founder ever dreams of that and no one makes it work. It's really unlikely that you're going to make this work. Therefore I want to see something that is a little closer to the patterns that have ended up working for other people. And so there's a bit of, there was pattern matching and from very smart people, they're very successful and they could very easily point to like look, I saw this company, this company, this company, this company all do this. And this included investors and ex operators and advisors. And there was just this general common wisdom that self service is very, very difficult and most companies ended up trying to glue on a PLG motion after the fact, but it was actually fairly difficult to do this. And it's funny because in a way our team was very unbalanced in that that's the kind of thing that we could do very well. Whereas like in person selling was the kind of thing we're really bad at and we're really bad at building that, really bad at like organizationally setting that up. And so it was a place where any reasonable person would say sight unseen, There is a 6 person or 6 to 10 person tech startup with no salespeople, no commercials people. It's a bunch of designers, engineers, they want to commercialize an open source product by self service. And again, a reasonable person looking at be like, let's get them some help, right? And the thing is in the rearview mirror that is absolutely the right thing to say. It just given our specific moment with specific set of tools we had the specific amount of attention we had and the buyer that we understood. So we didn't understand the entire universe of possible buyers. But for the people that had come to us, that had shown up, that had clicked on the website, that had downloaded software, we had an affinity for how they thought and for that slice of the world, we understood how they wanted to buy.
- [27:20]
Omar Khan
I think the irony here is that if you hadn't been given that advice, you would have probably continued down the self service path, maybe ended up in the same place. But I think it was also a matter of how much effort it was taking to get sales and grow the business. And this kind of analogy of whether you were pushing a rock uphill or whether it felt like you were pushing it downhill, that's also I think a factor here. And so do you feel like when you look back that did it make sense that advice or were you deep down, did you feel like this doesn't feel right to me or was that more of a hindsight thing? Hey, have you heard of SmartSuite? They were just named 2024 SaaS Startup of the Year by Startup Grind. Well, I recently discovered that Gearhart was the development team behind their success. Gearhart is a product development studio that specializes in scaling B2B SaaS. Companies built by serial entrepreneurs, they understand the unique challenges of startups and can plug into your team to accelerate growth. With offices in San Francisco and London, plus a distributed team of 43 experts, they've helped build over 70 successful products. To learn more about how Gearhart can help scale your development, check them out at Gearheart IO. That's Gearheart IO.
- [28:49]
Samir Al Sakran
I think I always saw the other path, but there is concurrently the awareness that I am a founder. In my position, I am almost by obligation delusional. Like I need to see things that aren't there for this to make any sense and that there are other people who are very smart and very accomplished who I had a lot of respect for. They're looking from the outside and like, I don't think it's there. And so there's that combination of like, I see this path With a lot of smart people being like, I don't know about that. And there's also. It's my personal realization that there was a lot that I needed to learn. And so at the time, it was like, okay, I should learn how to do the sales thing. Like, I should just do a bunch of calls. I should go through the process. I should learn how to hire AES, I should learn how to, you know, hire VP of Sales. There are all these things that I need to learn, and there's a lot of smart people that are willing to teach me. So let me. Let me go do. Let me go do the work and let me go learn and let me take in the playbooks of people that have made it work in other places. And so I still think that a knowledgeable observer should have said what they said to me in that moment. Just by virtue of being inside the container rather than outside. There was information and things that I saw that they didn't.
- [30:16]
Omar Khan
Let's talk about competitors and just kind of positioning metabase. We talked about the fact that it was. I mean, it's a very crowded market today. It was a crowded market when you were building the business in the early years. And how did you figure out how to differentiate yourself? I mean, I know you focus on saying, building a great product, but what did that mean? And when we were talking earlier, you also said, I wrote down somewhere like, you didn't spend much time looking at competitors, but you still regretted every second that you did spend time looking at competitors. So why was that? And how did you figure out your place in the market and how to differentiate yourselves?
- [31:07]
Samir Al Sakran
Yeah, I think early on we had a very, very hilariously naive and simple growth strategy, and that was just win the taste test. So if us and two or three other options were being tested, we wanted to be the first system standing, and we wanted to be the thing that you wanted to use. And that was the entire extent of our strategy. There was no content strategy, there was no social strategy, there's no pet acquisition. We weren't like, trying to get it onto anyone's radar in the analyst community. We weren't worried about growing the awareness. All we did was say, if us and Tableau and Superset and Looker are being used back to back, if there's a stopwatch, who gets the system standing first and which one do you want to use and you want to keep using. And sometimes the answers to those questions were very flattering to us. Like, you know, lots of things we had to work on, lots of things we had to build lots of things we had to fix. But we very intentionally over indexed on that moment of decision where one person at 2 in the morning is trying a bunch of things out. And we want to make sure that their ability to give us a whirlwind was effortless and that they had a good time. So one of the things that we really chased in the early days was the statement that I can't use this, but I really want to. And in general when we heard that, that was always a cool, we did a great job. So there was no world where we could out tableau. Tableau. We weren't going to be more enterprise ready than at the time MicroStrategy or Oracle BI or a Cobnos or whatever. Like we're not gonna be more enterprises than them. So we're going for is we want to be the daily driver that you reach for first. And that was it that we focused on that we just looped over and over and over again. You know, we, we played with it, didn't like it, fixed it, watched someone else play with it, they didn't like it, we fixed it and that was the extent of it. And we built a webpage. I think we didn't change the webpage for years on end. It mostly just had a CTA which was try it, like it. And a lot of people tried it, not everyone liked it, but enough people liked it to give us information to keep the wheel going.
- [33:39]
Omar Khan
How are you getting feedback? I mean in order to do that. And if you're trying to ignore the competition, you're going to focus a lot more time on how people are using the product, what they like, what they don't like. Talking to customers, I guess. How much time were you spending on that and what were you looking for? Because you're going to get a lot of feedback. Some of it might be valid, some might just take you down dead end. So how did you navigate that?
- [34:16]
Samir Al Sakran
The answer is it was very complicated to navigate. So I wish there was some distillation but in general we did a lot of user interviews, we would shop mocks to users all the time. So hey, we're thinking about this feature. Do you like version A or version B? We would build prototypes and play around with them. We would rebuild an interface, try it, not like it, delete it. So there was just a lot of high conviction attempts to fix certain key parts of the flow. I think the thing that is counterintuitive, that I very much believe is we were first and foremost building something we Liked using. So I think a lot of people over index on the danger of building something for yourself and the fear that just because you like it doesn't mean other people will. But I'd say that inverse of it is almost never true, which is, I don't believe you can build something you don't like that somehow magically strangers will like. So for us, we, like, really, really fought for that first, like, stage or that first milestone. Like, we like this until we like this. Like, we're not. It's not ready. It's not like no one else will either. And so we really emphasize that. And we try to keep in our minds the various classes of users, their motivations, what their data sets look like. We had a bunch of sample data sets and synthetic data sets. We had real data from various places. We tried to see how it worked with various shapes and sizes of data. We looked at lots of different use cases, and a lot of it was just us having to think through, all right, what's the consequence of this choice on all these class of users? And so it ended up being a very mushy puzzle. It's not like there was three metrics that we're optimizing, but we were trying to build a set of Legos that, when used well together, could represent a lot. It could be used to build lots of things. I think we really abused the LEGO set metaphor in the early days and still do, where we're not trying to build a bridge, we're trying to build a LEGO kit that lets you build a bridge or a dragon or a spaceship. And so the way that you build that kind of product is very different than the way you build, I don't know, like a calendaring application or a CRM or something else. So, yeah, to kind of reiterate is we really indexed on creating something we liked first and then valid and doing a lot of validation on it with outside people.
- [36:45]
Omar Khan
There's always a danger if you do that, that you're going to end up building a whole bunch of stuff or just finding reasons to keep adding features or improving features and not necessarily just putting it in front of customers. And so was that something you struggle with or did you kind of have that awareness?
- [37:11]
Samir Al Sakran
I think there was always a pathological need to ship. So I think that from the very, very early days, we wanted to ship. The question of what we ship always was a matter. There was always the, is this ready? But fundamentally, you know, we wanted people to see this. We wanted people to play with it. And so once the Open source version was released, it was just game on and there was a ton of feedback, a ton of complaints, a ton of, you know, user stories, a ton of interactions. And so the pre shipping was kind of torturous because again, there's always the like, is it ready? How about this? How about that? But I think once it's in the wild, it just really shifts gears and you start having a need to improve what's already out there. So the bar is not, is it ready? The bar is, did we fix this thing that's really annoying me or that person? Or did we add this thing that is really necessary instead of like, is the whole thing magically perfect now? And so that transition from, you know, getting something good enough to be a little embarrassing, but to be kind of useful, and then once it's out there, just saying as long as, you know, version 14 is a little better than version 13, we're shipping it. And so long as 15 is a little better than 14 and that kind of fed on itself and so that, that never really became that big of a problem.
- [38:36]
Omar Khan
Yeah, no, no, that's a good distinction because I think that that's that situation that I was describing. It is that pre shipping, right? You're, you haven't got the product out there and you're endlessly looking for reasons not to ship it because it's not ready. But with you guys, the product was already there in the hands of customers and you are more in the mindset of we're going to keep shipping, we're going to keep iterating until we like this product. And that's kind of a different situation. I want to also talk about pricing because that was a really interesting thing that you guys went through. Customers wanted to pay you in a certain way, which you weren't willing to accept, I think where you told me. And so you ended up like trying a whole bunch of things, right? So what was going on there?
- [39:26]
Samir Al Sakran
So early on we had this dream. The dream was everyone in your company should use metabase and we want to do everything we can to get everyone in your company use metabase. And that was considered a victory. We want to be used for everything by everyone and that we want to have our pricing model be in alignment with that goal. And one of the beliefs that we held onto a little too long was that if we had per user pricing, there would be a back pressure or negative feedback on adoption within a company. And that if something is just flat rate or is priced some other way, then obviously give everyone accounts, why not Whereas if it's going to cost you a lot of money per seat, you'll want to hoard seats and you'll maybe want to have people reuse accounts or something like that. So early on we were on installation pricing as a primary metric where any number of users on one set of servers we did per server pricing at one point. We did like per dashboard or per database I think at one point in time. And throughout all of this, I don't remember the exact customer conversations, but it's often some version like can I just pay you per user or per creator or per reader? And we were like, no, we want blank and we don't do creator pricing because everyone's a creator. And in many, many ways we were just a little too principled for our own good. And when we just started saying, look, what does everyone else charge? Okay, we're going to charge that, or some version of that, everything became easier. And even just copying the structure of what our users wanted to pay us simplified our lives a lot. And so I'd characterize there just being a downhill and we were insistent on not rolling downhill.
- [41:21]
Omar Khan
So how long did that go on and what happened for you to finally.
- [41:26]
Samir Al Sakran
Accept.
- [41:29]
Omar Khan
Per user was the way to go?
- [41:31]
Samir Al Sakran
This was a good two years. So I'd say for a good two years we were just pricing in these weird ways. And so they weren't weird, but it was generally not optimal for us or the customer. And I want to say that the main thing that happened was you start doing self service and it was self service. Having there be a transparent fair like price you could point to on webpage was a big deal. And that forced us to just come up with something that would be applicable to everyone and wouldn't require one off negotiation because there was no one right price or one right structure for all of our kind of one to one negotiations. And so we ended up doing lots of things that made sense to that customer. And I think when we had to say, all right, we're going to have like hundreds of thousands of customers on this thing, they're all going to have like an automated way to do billing. We need to just like pick a formula. And at that point it's like, all right, well I guess the formula is X +Y per user. And that ended up working really well. Everyone was very comfortable with it. There were no further like there's very little haggling from that point on. And we eventually kind of took that into our normal negotiations as well, where just it was how people wanted to pay Us and once we accepted that, everything became easy.
- [42:45]
Omar Khan
Okay, great. So you started off in the self serve route, you got distracted a little bit with the direct sales. And then when you went back to self service or I guess your roots, that's when things really took off. And that was basically the main growth vehicle that got you from seven figures to, to eight figures. And then also the pricing stuff we just talked about and some of the challenges you face there. When you look back at sort of that journey from like seven figures to eight figures, what was some of the, I mean scaling a business is never easy, but what was the biggest challenge for you to be able to scale effectively?
- [43:37]
Samir Al Sakran
I think the biggest, the biggest headache was going from there being, let's call it 15 people to 30, but essentially going from a world where there was a handful of senior folks with people that report to them, to there being three layers. So I think that was maybe the, the transition that caused us the most. Harper. And ironically this was exacerbated in the areas that we consider our strengths. So our ability, I think I mentioned our ability to delegate the things that we were just honestly bad at was very easy because lots and lots and lots of people have a better way of doing things than you do. And it's very easy. Just hand it over and be like, all right, you've got this, let me know how it's going to be. I think the places where we had done a really good job of organizing ourselves and having a system and having there be a bespoke, unique, interesting way of doing things were the hardest to really scale up. So early on we had a very like, very tightly threaded kind of combination of folks with product sense, engineering skills, data backgrounds and design sensibilities. And it was very, very hard to untangle those. And now say you're the pm, you're the designer, you're the tech lead. And that originally there was just so much overlap and everyone wore so many hats that we didn't fully understand how to do it in a way where those are different people with different responsibilities. And we had to figure out what the communication scenarios were, how the process would work. And so looking back on it, it's really funny just the degree to which the things that we didn't know how to do were easy to scale and the things that we didn't know how to do ended up being the trickiest, the hardest to hire for and ultimately in many ways the most heartburn inducing.
- [45:40]
Omar Khan
I mean, that's really interesting because I've often when it comes to sort of whether it's outsourcing or whatever, it always feels like if you outsource something you're not good at, there may be people out there. I mean, I'm sure there are people out there who can do it better. But there's also a risk that you're outsourcing something that you don't fully understand how to do well. And will somebody else, Will you be able to manage that resource or whatever. But intuitively I would have thought that the stuff that you do well would be easier to scale. Right.
- [46:21]
Samir Al Sakran
And I think part of it was that we weren't outsourcing, we were bringing in. So, you know, we would hire, we'd be very selective. We'd hire the best people we could find. And in general, it was very, very easy, relatively speaking, to find people that are way better at us than a number of these roles. And so, you know, bring someone in, you trust them, you know, they're. They're on the team, they're in the family, they're going to be around for a while and they will build something that you look on and be like, oh, that's actually pretty cool. Like, I could not have done that. And I think that was often the sense when people would show up and do again, these functional areas where we just didn't have a lot of expertise or a lot of, like, interest or a lot of innate talent. And the places where we're like, no. I had, like, really strong opinions about how the product to design, to engineering loop should look. And finding people that were ready into that system was very challenging. And finding people that would, that were at, at a sufficient caliber where they want autonomy, they want to kind of do their own thing. And there's always that tension of like, but, like, we figured this out, like, let's just, let's not lose this.
- [47:25]
Omar Khan
I mean, it's certainly been a interesting journey over those, I guess, 10, 10, 11 years of building this. When you started out and when you were like, I'm not happy with what's out there, I want to scratch my own itch. I want to build this thing which is simpler and just does the job in kind of the easiest way. Did you ever envision it turning into what it is today?
- [48:02]
Samir Al Sakran
Actually, yes. And more. We literally drew out, like, projection lines on the number of likes, number of stars, number of whatever. And what's hilarious about looking back on, say, the seed fundraising decks is that in many ways we called our shots. It was like, this is how it's going to go. It actually did go down that way. And what's funny though is how much we messed up along the way. So looking back on it, I think that we were largely directionally okay. Like I don't think we made any big decisions. I look back on and you know, face palm. But I'd say there's just lots of things where like, I wish I could have done that a little faster. I wish I could have like not taken that misstep. And so in terms of scale, we were always playing for the scale. Like I think literally, I think there was a conversation before launch where like if this thing doesn't get, you know, 10,000 GitHub stars, it was all in vain. And it probably wasn't that lofty, it probably used like a lot more colorful language. But it was some version of, you know, if this thing doesn't get 10,000 stars, it's completely pointless. And so there was always this sense of we wanted scale and that a lot of us came from consumer web or consumer mobile companies that had, we just saw this huge adoption and we very much were program to see that as something both natural and something you fought for and something you could get.
- [49:29]
Omar Khan
What I love about your story is that, and hopefully the chess piece, the chessboard analogy makes sense that you kind of had a very straightforward, simple plan and you talked about, hey, we're going to have this open source product, we're going to get a lot of people using it, we're going to have this CTA people are going to pay us for this and that's how we're going to monetize it and build this business and it's going to be self service. And I guess that was your chessboard, right? That was the game plan and what you were going to play out. And people kept telling you you needed to do different things and, and you know that they were well intentioned and probably as you said, you know, the right things that you should have been hearing at that time. But ultimately it was kind of like you had a pretty simple strategy and plan and, and somehow it just, there was this, people just wanted. It just seems too simple.
- [50:29]
Samir Al Sakran
I think part of it is that in that era also I would say that the standard naive, delusional dream of a technical founder was that you'd build a self service business. Like that was almost the stereotypical trap to avoid which is, you know, there was a number of, you know, press articles about this, a number of people going on record saying like this doesn't happen, this is not the way the world works. And there's also the honest. The honest maybe uncertainty of if we had fully played in the other playbooks would have been further along because I'd say there's lots of ways we could have shortened the path. I think there's a lot of years we probably could have speedrun or skipped. And it's more than possible that if we had been better wired for the more standard playbook, the success would have been larger or faster or different. So it's hard to kind of rerun history. But I do think that when I look back on the path we took and I think about where could I like cut years off and have turned a 10 year journey into a 4 year journey or 5 year journey, it's just interesting where it's like, oh, I wish I could have snipped this year out and just throwing it away. Which I could have snipped this year out and just throwing it away. Because like in that year, like, you know, we worked, we tried, we experimented, we did things, but it was like we were just like on the wrong path. Like we should have just done the other thing. And you really just like snip that out and then put it towards the end. Because I do think that, for example, right now we are finding success with direct sales and that is something that was going to be part of our next chapter. It's just a question of ordering and understanding what your unfair advantage is and applying your unfair advantage over and over again and not trying to pick fights that you're not going to win.
- [52:22]
Omar Khan
That's great. And I think on that note, let's wrap up. Let's go into the lightning round. I've got seven quick fire questions for you. What's one of the best pieces of business advice you've received?
- [52:30]
Samir Al Sakran
Just charge money.
- [52:32]
Omar Khan
What book would you recommend to our audience and why?
- [52:34]
Samir Al Sakran
I'm drawing a blank on that one. So for the decline and fall of the Roman Empire for reasons that just are tedious.
- [52:43]
Omar Khan
There you go. What's one attribute or characteristic in your mind of a successful founder?
- [52:48]
Samir Al Sakran
Irrational perseverance.
- [52:50]
Omar Khan
What's your favorite personal productivity tool or habit?
- [52:53]
Samir Al Sakran
An empty notepad that you just fill in every morning.
- [52:57]
Omar Khan
You know, you're like, I think you're this. I was talking to somebody yesterday about this as well. Just obsessive about taking notes. It's like it's inspired me to get, get my notebooks out. What's a new or crazy business idea you'd love to pursue if you had the time?
- [53:12]
Samir Al Sakran
There's a zillion people doing this but personalized language tutoring using LLMs.
- [53:20]
Omar Khan
Nice. What's an interesting or fun fact about you that most people don't know?
- [53:24]
Samir Al Sakran
I really enjoy being corrected.
- [53:27]
Omar Khan
You enjoy being corrected. And finally, what's one of your most important passions outside of your work?
- [53:35]
Samir Al Sakran
Some form of movement practice. So it's changed over the years, but some way just be in motion and stay in motion.
- [53:42]
Omar Khan
Nice. Thank you for joining me. It's been a pleasure unpacking the last 10, 11 years of the story. Lots of really interesting insights about building a business like this and I appreciate you sharing those lessons with our audience. If people want to check out Metabase, they can go to metabase.com and if folks want to get in touch with you, what's the best way for them to do that?
- [54:13]
Samir Al Sakran
Just send me an email Samir at Metabase and yeah, it's been great being on here. Thank you for having me.
- [54:20]
Omar Khan
My pleasure. Thanks man. And I wish you and the team the best of success. Remember those AUTH and user management headaches we talked about earlier? If you're tired of your dev team getting bogged down with authentication issues, instead of building your core product, it's time to check out Propel auth. They take care of all the complex AUTH stuff from enterprise SSO to user analytics so you can focus on what really matters your product. Propel Auth integrates quickly for devs and provides built in tools for your customer facing teams. It's the full package and don't forget our special offer. Sign up for a free account@propelauth.com you don't need a credit card and when you're ready to scale, use code SAAS24 for 50% off their growth plan for six months. That's propelauth.com it's time to stop struggling with auth and start growing your business. If this episode got you thinking about building or scaling your own SaaS product, let me tell you about a resource that can help. Whether you need a complete technical team or want to scale your existing one, Gearhart might be exactly what you're looking for. They're a product development studio that specializes in building B2B SaaS platforms. What's interesting is that they can act as your fractional CTO and technical team, but with a unique twist. They've built strong connections in Silicon Valley and can even help connect you with VCs when you're ready. Plus, as a proud Ukrainian born company, they deliver Silicon Valley expertise with an offshore pricing model. They're offering our listeners free strategy sessions with their leadership team until the end of May. Visit Gearheart IO to book your session. That's Gearheart IO.