Jack Newton, Founder of Clio | How to Run a Beta Program

Jack 0:00 What was really clear to Ryan and I, that cloud computing was going to transform every industry in a pretty profound way. What we went to work on was identifying an industry that we thought was ripe for transformation and especially amenable to the kind of transformation that the internet would bring. Pablo 0:21 Welcome to the product Market Fit Show, brought to you by Mistrial, a seed-stage firm based in Canada. I'm Pablo, I'm a founder turned VC. My goal is to help early stage founders like you find product market fit. Welcome to the product Market Fit Show. Today we have Jack, the founder and CEO of Clio. Cloo is a startup in the legal tech space. They basically did vertical SaaS before it was cool , before it was a thing. They sell a product that helps lawyers run their firms. They're based in Vancouver. They have over 800 employees and are worth well over a billion dollars. Jack, it's a pleasure to have you here on the show. Jack 1:01 Hey, thanks for having me, Pablo. Pablo 1:03 The topic of today's episode is how to run a beta program. I think beta programs are pretty well-known. I think most B2B SaaS companies that I speak with do them, but they're not all made equal is how I would summarize it. I think there's much better ways to do it, much worse ways to do it. Oftentimes it's something that people are just going through the motion. They know that you got to run a beta program, so you do it and then you just -- all you really want to do is launch the product. You seem to have done it really kind of thoughtful way that led to a really successful launch and obviously over time to a unicorn and a big company and one of the biggest successes to come out of Canada, so really looking to forward to diving into that with you. I think maybe to start, it'd be great to go a little bit backwards and kind of get started on early 2008 and how you came up with the idea in the first place. Then we can dive into the beta program and all those details. Jack 1:59 Sure, yeah, sounds great. Cloud Computing in 2007 Jack 2:01 So my co-founder, Ryan Govoro and I, back in 2007 -- I sometimes describe us as two hammers looking for a nail because what we saw back in 2007 was this enormous technology transformation wave that was cloud computing. What was really clear to us, even though this is 15 years ago now , is pretty early innings for cloud computing. Salesforce was just starting to get some traction. This was before the first iPhone was released, so very different technological era in many industries. On-prem software was still, the dominant computing platform. What was really clear to Ryan and I is that cloud computing was going to transform every industry in a pretty profound way. What we went to work on was identifying an industry that we thought was ripe for transformation and especially amenable to the kind of transformation that the internet would bring. It didn't take us long in surveying these industries to hone in on legal as an area that that really had not changed how it operated in hundreds or maybe even thousands of years, the way lawyers -- Pablo 3:19 For context, you were doing what at the time? Were you working? Were you a student? Were you -- what kind of phase were you in? Jack 3:26 Yeah, so I Transforming Legal Technology Jack 3:28 was at the time working as a product manager at a company called Knenomics, which was a life sciences company. Ryan, my co-founder, he and I have been life- long best friends. We'd always been noodling on different business ideas and going back and forth on what we might be able to do together. Ryan was both pursuing his MBA and working as the IT manager at Gallings, which is one of Canada's largest law firms, about a thousand lawyers. He had a first row seat to how technology was being used in law firms or maybe better put was not being used in law firms, hallways full of paper -- filing cabinets full of paper and very manual processes. The other relationship that Ryan had that really helped us validate this instinct that we had that there was an opportunity in legal was with The Law Society of BC. They're, for US listeners, very analogous to US Bar Association. They're regulator of lawyers and if a lawyer does something wrong, it's the Bar Association or the Law Society that ends up having to discipline them. We had a relationship with the Director of Practice Standards at the LSBC that really helped validate this idea that lawyers , number one, struggle with using technology overall. At large law firms, they often compensate for that lack of technology use with sheer manpower. They've got a lot of paralegals and support staff and other folks to make sure that the engine is running and humming along and that they're not dropping balls like missing key limitation dates or mishandling trust accounts, for example. Solos and small firms didn't have this human infrastructure to help support them. Therefore that's what the Law Society of BC and many other law societies across Canada and bar associations across the US -- what they see is that this solo small firm segment of their membership is the one that struggles the most to stay on top of their practice and is therefore the group that they end up needing to discipline the most when they drop the ball on some key client deadline or maybe in mishandling trust accounts and so on. This is really the light bulb moment for Ryan and I was realizing that there's, number one, a huge opportunity to transform legal technology from on-premises software to cloud-based software and a gigantic opportunity in this solo and small firm segment, which we eventually realized was -- it sounds like a niche, but it's actually 80% of the legal market is lawyers practicing in firms of one to ten lawyers. Fully half of all lawyers practice in small firm -- in a solo environment with maybe one or two support staff. So even though we think about lawyers practicing in these big office towers in a nice AAA downtown office space of -- with a thousand lawyers and five floors of people, that's not the reality. The reality is it's a very entrepreneurial, very SMB market. Back in 2007 -- to kind of set the stage for the discussion around the beta, 2007 was where Ryan and I built the conviction that this was a big market opportunity. We pulled shoot, we quit our jobs, and we started building Clio. Pablo 7:01 Maybe on that, I mean, did you quit your jobs? A lot of this sounds like top-down market research, understanding cloud computing at a high level, understanding the makeup of the legal industry, dissecting that until you come up on a problem that you feel is worth solving versus, let's say, scratch your own itch or even customer discovery-driven effort. Was that the reality? With that, you decided let's jump off this cliff and quit our jobs, or was there a lot more customer discovery that kind of led to that moment? The Customer Development Process Jack 7:33 Yeah, one of the really influential books for me at this time of Clio's journey is a book called Four Steps to the Epiphany by Stephen Gary Blank . Much of the ideas that he puts forth in this book are kind of later built on and elaborated on with some of the concepts in the Lean s tartup, for example. What S tephen talks about in this book that I think is so important is this idea that you can have an idea for a product, which is great, but a t rap many founders fall into is a build it and they will come mentality. They're so excited about their product. They think it's obvious there's customers out there for that product and don't go through a really important step o f the process thathe talks about in this book that's called customer development. So go find the customers that you think will buy this product. Put your product in front of them and validate that they'll actually buy it. As obvious as that sounds , it's a step many startups skip only to find that they launched the product to an uninterested and un-buying audience. Where Ryan and I spent a lot of time -- and this was moonlighting, by the way, in the early days. We were working evenings and weekends, and I was spending late nights working on this idea and doing this customer development work alongside Ryan. We really built the conviction that this was an idea that was worth pulling shoot on on two great jobs to go and make a reality. What we were able to do in this early customer development process is just put prototypes in front of solo and small firm lawyers and say, hey, based on this wireframe and based on the capabilities that this product would deliver to you, would you give me your credit card number, not just is this interesting to you, is this something that makes you excited but is this something you would pay cold hard cash for and what would you pay if you were to pay for this product? That's a really important part of the product validation process and one that gave us a lot of conviction by the time it came to quiting our jobs and going full time on this thing that this had traction before we wrote a line of code. Pablo 9:53 Perfect So that makes a lot of sense. So now you've got indications that firms really have this problem and are willing to pay for it. When do you start thinking about -- are you following this book, Four Steps of the Epiphany, which is a great book by the way, and I highly recommend it . Are you following step-by-step and therefore your next step is clearly okay, let's run a beta and extract dollars from these clients? Is that how you were thinking about the next step? How to Run a Successful Beta Launch Jack 10:17 So our approach was building out this beta-level product and where we were really deliberate was in framing the beta as something that we believe did not have full product market fit. I think there's -- you talked a little bit about how do you run an unsuccessful beta? How do you run a successful beta? I think many companies -- many, many early stage startups launch a beta with a presumption and maybe even the dependency that all that's being tweaked in the beta is bug fixes. You really don't want to learn anything new about your customer in the beta. You launch the beta and you're launching the full product two weeks later or a month later. It's more of a hardening step to make sure there's no catastrophic bugs. We took the approach with the beta and the way we engaged with our customers as we think we're 80% of the way there with the product and the product market fit, but we're going to really be open-minded about learning new things about what our customers need and building incremental functionality over the course of the beta. With that view, we launched the beta in March of 2008 and launched the final product, the paid version of the product, six months later in October of 2008. We really created this time box for ourselves to say, hey, we're going to bridge this last 20% over the course of this six months. We're going to work really, really hard over the six months probably, and we're going to need a lot of highly engaged customers to help us get over this last mile. With a view to rethinking how the beta program runs and really, again, leaning into this customer development framework that Stephen Blank talks about, we approached the beta as something that we would rather have a small handful or two of very highly engaged customers that are representative of our overall customer base than thousands of lightly engaged customers. The reality with a lot of beta programs is you get the tire kickers that just come along, sign in once, check out the user interface, and play around with it for five minutes and they never come back. You're obviously never -- you're not getting high information content. You're not getting good signal to noise feedback from those customers. The question Ryan and I asked ourselves is how can we really create a bit of a hurdle to getting into the beta so that the customers that are in there really care and are really going to give us valuable feedback. We came up with this pretty straightforward idea, which was you sign up for access to the beta, you request access to the beta, which is a concept lots of companies do, but the friction point we introduced was you sign up for the beta and to get into the beta, you need to attend a 30-minute live webinar with one of me or Ryan. We would walk you through the product, teach you how to use it, give you a bit of a tour, and give these beta customers a chance to give us real time feedback. Two things ended up happening. One, as you would expect, there was a huge drop-off in that the tire kickers were not willing to spend this half-hour. The customers that did spend this half hour with us ended up engaging with a product deeply, and we ended up having about a hundred very engaged, high information content, high value beta customers, giving us a ton of valuable feedback over those six months, not only that, but this 30-minute webinar ended up being something that turned into oftentimes a one hour , two hour , three hour information-gathering session with the customers where they actually gave us a huge amount of feedback in real time over the course of this tour of, oh, well, I can't use this product because you don't do X, Y or Z, or I find this flow a little bit confusing, or where do I go to do X? We were able to really quickly hone in on what are the key things they're trying to accomplish; what are the friction points of the product; And importantly, what are the gaps that don't exist in the product that we need to build in time for this full-blown October launch? It sounds obvious, maybe, in terms of like, hey, this is a good way to structure a beta program, but it ended up being transformative to us in terms of how high quality our October release ended up being and how willing a really substantial percentage of those hundred beta customers were willing to convert to paying customers on October 1st when we flipped the switch and said, okay, your free beta access period is over and here's the full product and you're now going to be one of our first hundred paying customers. Pablo 15:11 It makes a lot of sense. I think that's what often gets missed. If you think about product market fit, there's really two sides to it. I mean, you have the product and you have the market, and oftentimes the focus is entirely on just changing the product, changing the product until things work. Half the battle at least is figuring out which market you should put this product into. There's a lot of talk about making things as frictionless as possible, which probably makes sense as your product matures, but in the early days, you really want to make sure you're driving tons of value for those early customers. That partially means having a really good product. It also partially means having the right customers for that product. I think that's what you're doing when up the bar like that. Few quick questions. I mean, the first thing, just to set the stage, was it just the two of you at that point that are doing all the work, the sales, the marketing, and building the actual product? Benefits to Working With a Smaller Team Jack 15:58 Yeah. Over that first six months to launching a product in October, it was the two of us wearing every hat, coding, marketing, selling, doing these webinars. They obviously ended up being very time-consuming, but they were absolutely worth it because we could wrap up one of those customer calls and literally swivel our chair and start coding the feature or the bug fix or whatever the case might be that we needed to do to help make the product a better fit for that customer. Pablo 16:32 These days, and I think things have changed a little bit, and I don't know if you had fundraised at that point, but these days it's pretty common that at that stage, you may have raised one, if not two, not $3 million and have a team of five, ten people doing that. What do you think about that? Would you have rather have a team of five or ten at that point and therefore have devs doing this and salespeople doing that? Or was there value to it just being the two you in those really early stages? Jack 16:56 Yeah, it's a great question. I think one of the things that's incredible about a two-person team that is able to hold everything in their head around what customers want, the customer conversations just had. Ryan and I, like I said, we've been best friends since we were eight years old, so extremely high bandwidth conversations. We were just able to hold everything about what Clio needed to do and what our customers were giving us feedback on in our heads. The communication overhead that comes with even a five-person team ends up being enormous compared to the kind of velocity that a really small team can move when you've got the clarity of vision of what you need to build. If I had to do it again, I'd probably do it the same way because I think we were just able to iterate and pivot and hold so much context in our heads that we were able to move at the right velocity with the right information. I think with five people, we might have actually had more bandwidth than we needed going into communicating and not enough torque going into actually building the product and writing and shipping code. Pablo 18:14 Yeah, that definitely foots -- and I totally think there is that part of communication overhead that's totally diminished velocity. The other side to it too I find is there's power in constraints. When there's two of you, you can really only focus on so much because you're maxed out. You're probably working 12, 14 hour days or whatever it is. When there's 10 people, you want everybody to be doing something and the challenge is you might do more than you need to and go down wrong tangents that take up so much time and have so much higher trade-offs than you might see at a time. I think that makes a lot of sense. The other question I want to understand as well, because I think this is really important, is you talk about having access to a beta and then having a funnel to find the right ones. Moving up that funnel, top of the funnel, there's just two of you. What are you doing to get law firms in the first place? Are you smiling and dialing in your city? Are you doing online ads? What was the strategy? The Power of Constraints Jack 19:10 Yeah, so we had -- you talked about the power of constraints. We had the power of two constraints. One, there was only the two of us, and the second was we had almost no money. We'd raised a hundred thousand dollars from friends and family that really went mostly into legal and startup costs and our IT infrastructure and some of the very early kind of cloud infrastructure in those days. To answer one of the questions you asked , we hadn't done a fundraise at this point, so we're really working off of this hundred thousand dollars, which created a ton of constraints. Again, in retrospect, I think there were constraints that actually had a very positive outcome on the company. The other backdrop for this 2008/2009 period we were launching the product in was obviously we were in the depths of the financial crisis and in the worst fundraising environment that existed over the last 15 years. We're maybe in the midst of really the only other downturn right now that we've had in the last 15 years. So that made even fundraising that friends and family round challenging in the sense that people were really worried about where the financial system was headed. It feels like it was an alternate universe, but people were worried about the financial system as we knew it collapsing entirely. There was a lot of fear out there. We had a lot of constraints and the approach we took was let's tap into this audience of lawyers that, if you think about the technology diffusion curve and crossing the chasm, tap into this group of potential customers that are in the early adopters segment, the technophiles, the people that really are excited about new technologies and tap into that base as our first early segment of customers to go after. Then we got really deliberate about a PR campaign and a marketing campaign that -- where we got coverage on some of the top legal technology blogs like Bob Ambrosia's law sites is one example. Where we announced our initial beta and where we ended up getting the vast majority of our beta customers from in fact was just a blog post from a legal technology writer that everyone that cares about legal technology pays attention to. We also invested in trying to create a marketing or PR angle around the fact that Clio was really the first cloud-based practice management system to launch in beta form and in full form later in October in the world. We were really the first company to bring cloud computing to legal. What's very interesting about that is lawyers have very specific fiduciary responsibilities around how they manage and handle client data. They have an obligation to protect the confidentiality of client data. They have an obligation to have a reasonable expectation of privacy in where they store that client data. So there's a very open question in 2008 around whether cloud computing is an acceptable thing for lawyers to use. There was a pretty loud contingent of naysayers out there creating a bunch of fear, uncertainty and doubt around cloud computing for lawyers that we felt we had to counter. We realized we're either going to get dragged along by this narrative that cloud computing is somehow dangerous and unacceptable for lawyers to use, or we're going to be able to lead the narrative and chart the course for how lawyers should responsibly embrace cloud computing and leverage cloud computing to their advantage. We obviously chose the latter and created a story around cloud computing in general and what that means for lawyers. Then Clio ends up getting mentioned as an aside when I'm getting quoted or I'm giving a talk or whatever the case might be. That drove a lot of awareness and inbound interest in Clio as well. So our marketing budget for the first year of our launch over 2008 was basically a few hundred dollars per month that we were spending on some very experimental Google ads and otherwise free just with this PR effort Pablo 23:36 That's really interesting and really unique because I would think in the early days, especially for something like B2B SaaS, your go-to thing would be, we'll just start calling. I mean, you got a list of law firms, right? They're pretty public, so just pick up the phone and start going because PR, I mean, there's a bit of a hit-and-miss element and it also, generally speaking, takes time to develop a strategy to get it going and so on. Do Being a Part of the Narrative Pablo 24:00 you think this is underutilized, this idea of tying onto a narrative, especially for people going after the long tail, maybe something that founders should be doing more of? Jack 24:08 I do think it's underutilized and I think too many founders -- and I certainly fit in this category in the early days -- expect that your company is exciting enough that reporters should be wanting to write about Clio. Of course, it's amazing. It's like your baby, right? Why isn't everyone writing stories just about Clio? What I came to realize was reporters aren't looking to write about specific companies with very rare exceptions. They're, of course, writing about Google and Uber and Airbnb. In general, they want to be talking about trends and they want to be talking about informing their audience around important trends that are happening in their industry. You want to be part of that story and part of that narrative. That's actually a much easier thing to do than to get a story written about you specifically. No reporter wants to be just helping publicize your company, at least most reporters don't. There's certainly some that will write about a specific company and there's blogs like Tech Crunch that do that almost exclusively. You want to figure out -- you really -- getting in Tech Crunch is about getting in front of your co-founder friends and feeling good that you've got your company covered in Tech Crunch. Where you really want to be getting covered is in the kind of publications that your prospective customers are reading and staying on top of what's going on in their industry. Again, I think that's where you can have very powerful customer acquisition economics. It's one of the places I think that vertical SaaS has a huge advantage relative to horizontal SaaS where you need to take a much more expensive horizontal and brand-based and advertising in the New York Times or other mainstream kind of media. You don't need to do that as a vertical SaaS player. You can get very targeted your approach, get in front of customers through these niche publications that reach maybe only a million or 2 million readers, but every single one of those million or 2 million readers is your target segment. Again, the headline can be cloud computing is coming to legal. You're catching the reader's attention, and then they're going to hear about Clio and they're going to read a soundbite from me in that article. Reporters are usually hungry for content. They're looking for a story. They're looking for a lead that they can sink their teeth into. I think more startup founders could be putting more energy into figuring out what's an exciting narrative that my company is part of as opposed to rying to get somebody to write an article specifically about your company. Pablo 26:47 You use PR at the top of the funnel. You get that long tail, especially the ones that seem to be more interested in the funnel, and then you raise the bar through webinars to pick the right ones . You get a few hundred of them into the beta. What Active Customer Feedback Pablo 27:01 really happens in those six months? First of all, are you charging these customers or what's kind of the give and take and how do you set things up to get the appropriate amount of feedback throughout and really make the right changes over the six-month period? Jack 27:15 Yeah, that's a great question because there's the initial customer interview and again, something we paid really close attention to in that initial customer interview was trying to get a sense for whether this customer was representative of the wider customer base. This is really important when you're putting on your product manager hat as a founder, is you're going to get requests from customers, and some of those requests are going to be really esoteric, really specific requests that are not generalizable. They're looking for you to make basically custom software for their law firm and other requests are going to be much more generalizable and representative of the market in general. Again, I think the key approach that we took here that the -- again, this customer development framework espouses is if you can do a good job of finding ten representative customers in a large enough niche, you're going to be able to find -- if you build that product market fit for those ten customers and you do a good job of customer development, really understanding what those ten customers need and that they'll buy your product, you will be able to find a hundred and 1,000, and 10,000 and eventually a hundred thousand customers if you take that -- those early steps in the right way. So we were very, very selective and very careful in who we let into the beta in those first 10 and 50 and eventually hundred customers. The bargain that we negotiated with these customers was basically, look, we're -- let me give you the product for free for the beta period. It was open-ended as to how long it would be at that point. We hoped it would be about six months, but we knew it might take longer. Maybe it would be shorter, but likely around six months or longer. In exchange we'd love active feedback from you. We made it really low friction for them to just click a give us feedback button in the bottom right corner of the app and just send us a note around something that they liked or disliked about the app. We also asked that they engage with us regularly, and it was around once a month or so to have some level of follow-up call or webinar and just get feedback on how the product's working for them. Again, we got great initial feedback in that initial onboarding call. Again, a wealth of more deeply rooted feedback after a month or two months on the beta where they could really identify here's the friction points, here's the gaps, here's some of the places I'm struggling in the product, and similarly, here's some of the things I'm loving. Pablo 29:58 There any major -- I'm curious. Those feedback points, was it mainly UI and small tweaks and here's how you could remove a step or were there any -- and I know it was a long time ago, so you might not remember, but do you remember any kind of major breakthrough type requests that really made you rethink some feature or add a feature or take away a feature, something that really changed the course of things? Jack 30:20 Oh, yeah, it was both. Lots of just hey, found this to be a little bit high friction. Can you help this workflow work a little bit better? So lots of that type of feedback, but we had actually yawning chasms of functionality missing from the product in that initial beta and some hypotheses that we had just gotten wrong around what the product needed to do. I'll give you one example. One was we didn't have an integrated document management system when we launched the beta and we figured, hey, there's Dropbox. There's some other relatively early cloud-based document storage options out there. We don't need to get in the document management business with Clio as a first launch vehicle or MVP. Our customers came back loud and clear over the course of that early beta. In fact, by the time we were a few days into boarding customers onto the beta and getting feedback on this half-hour walkthrough, Ryan and I were like, oh man, we missed the feature that customers are saying is mandatory in the product. They want document management integrated. When they're looking at their matter-based view, they want to see those documents that are linked and related to their case. They want to be able to attach billable time to those documents. We got to work on building a document management system and had it rolled out about a month into the beta. Again, we're able to get lots of live feedback on that. So that was an example of where we went in and said, rather than doing a really waterfall kind of process and fully specing out what the product's going to be out of the gate, we're going to build this kernel that we know is absolutely essential and take the approach of rapid iteration on that MVP to add this functionality. So there were I would say at least two or three major features that we developed over the course of the beta that we went in believing we didn't need to have as an integrated part of the product. Pablo 32:26 Perfect. We fast-forward through these six months. You're getting feedback, some which is small, some of which is really big. Prepare for Launch Pablo 32:33 When do you feel like you're really ready for launch and what does that look like? How do you set that up? Jack 32:41 Yeah, so one was when we felt like we were -- we'd move from that 80% to 90%, we actually circled a date for a major conference in legal on October 1, 2008 when we were --we had to commit to that conference and commit to the PR around launch about three months before the conference. So we were about halfway through our beta and we felt like we feel like we're tracking to a place where maybe we'll be ready by this conference and then circled the date, wrote the checks, committed to it, and got -- hired an actual PR firm, got on a retainer that felt extremely expensive to us at the time, which was $4,000 a month committing to a quarter of intense PR over Q4 of 2008, burned the boats and said we're launching on October 1st. Fast-forward to September and we're freaking out because we're not ready. We've got a lot left to build. We realized like a week before we were supposed to launch that we hadn't actually built any way to charge customers on their credit cards, all these things that when you really go through the pre-flight checklist, we realized we weren't quite ready. We just worked like crazy and even at the conference, I remember being set up in the conference area of the hotel in one of the business centers with Ryan and we were coding and shipping code on October the 1st, the day we were launching. To me it was a great example of that maxim that if you feel ready to launch, you're too late; you've waited too long. I think it was very much the case for us where we needed that forcing factor. You're never going to feel ready, but circling that date, burning the boats and committing to launching out on October 1st, it was a bumpy ride. Some of our customers got an error page when they tried to sign up. Again, we built the billing system over the course of October and I think without that forcing factor, we would've easily been shipping January, February, March of the following year and not had this amazing launch event. The forcing factor of getting out early and then really starting to learn and iterate. Officially launching also let us shift gears into, okay, let's start thinking about fundraising and getting that team of five people you were talking about on board because now we've got a lot to do and real clarity on what needs to get built next. Pablo 35:15 What did that look like? I know it wasn't the best timing, late 2008, early '09, but you did have quite a bit going for you having gone through this beta and learned everything you learned. Serendipity in Fundraising Pablo 35:26 What was that fundraising like? I mean, how did you raise that first round? Jack 35:30 Yeah, the fundraising was brutal. As you pointed out, people were -- we actually got great feedback and it was kind of frustrating actually to have these two messages delivered together. We got feedback that the pitch we had when we were talking to angel investors or VCs was one of the best pitches they'd ever seen. They loved the idea. They loved the product. They loved the traction we were showing, but they're just not writing checks right now, just heads down in the sand, worried about what the impact of the financial crisis is going to be. People really, for a year there, stopped writing checks almost entirely. So we were actually pretty -- by the time 2009 was rolling around, we were feeling pretty downtrodden about our prospects to fundraise and then ended up getting this cold email inbound from a guy named Christoff Jans who is now one of the managing partners at Point Nine Capital. At this point, he had just sold his own internet company. He has started investing as an angel investor and he sent us an email saying exactly that. I've just become an email -- an angel investor. I just invested my first company called Zendesk, which at that point was four guys in Copenhagen, so his first investment was a good one. What's hilarious is Christoff had, number one, emailed us from this domain that was web.de . He was talking about investment opportunities in Clio in the body of the email. His email went straight to the spam box . Then what's hilarious is we inadvertently cold play or slow play Christoff over the course of a couple of weeks because his email's sitting in our spam box. He sends a follow-up saying just wanted to check back in. I'm really interested in Clio. Is there an opportunity maybe to invest? A few days after he sent that follow-up, describe this as an act of God, but Ryan is bored enough one day to check his spam filter and see what's in there, which I don't think he'd ever done before and probably hasn't done since. Checks his spam filter and sees these two emails from Christoff, forwards it to me and says that this actually looks legit. Can we follow up with Christoff ? I drop him an email and we have a great kickoff call, and he ends up -- cut to a few months later. He ends up leading our angel round and we raised our first million dollars and the rest is almost history. We've got that initial million dollars. We're able to hire the first few employees, a couple developers and our first customer support have raised the better part of 400 million since then. It was that first bet from Christoff and he ended up being just a phenomenal support to the company, especially over those first five years or so as we were going through the initial growth phase. I don't know what the takeaway lesson is for your listeners, Pablo, Pablo 38:42 Randomness is a crazy thing. I mean, the reality is the more we do these, the more we realize just how much serendipity plays a role. That's not to say you wouldn't have raised your round some other way, but when you actually put the pieces together of how a certain round got raised, it really does feel like the analogy of if I take a deck of cards and I lay it out, it's going to come out a certain way, but the odds of it coming out that way are pretty damned low, right? That's right . It's kind of that -- yeah so -- Jack 39:09 [Unclear] huge role and I think that old saying about luck being -- preparation, meeting opportunity. You need to be sure you've done that groundwork. I think what Christoff saw that made it easy for him to write that check when he did engage with us is that we were customer-obsessed. We had great retention metrics. We had good NPS metrics. We had good initial product market fit. We had good initial data points on how we could scale customer acquisition through paid channels like Google AdWord. So I really think that you do need to wait for that serendipity, that luck to come along, but do everything you can to prepare in terms of having a good story to tell and good customer metrics to tell. You'll eventually find that investor that wants to write a check against that traction. I think sometimes founders get that inverted almost and think that they need the investor and they need the investment to go get the customer traction and build the product, build the story. That's possible sometimes, but the investor's obviously taking a much bigger leap of faith writing that check as opposed to trying to be a very small team, try to bootstrap as much as possible and build out that initial traction. Pablo 40:28 That's totally right. True Product Market Fit Pablo 40:30 We'll end it there. I will ask the final question, which is where we like to end all these episodes, which is when did you feel like you had true product market fit? Jack 40:41 I think we felt like we had true product market fit when we had our first beta customer using the product to run her law firm and was really using Clio to make money for herself and depending on Clio in a production environment. What was a little bit scary is she did this almost without our permission. One of the disclaimers we had around the product in the beta phase, by the way, was, hey, look, this is really a beta and you could lose your data. We could go down for six days. We could dramatically change how the product works, so please don't depend on this product. We want you to use it and we want you to give us feedback, but we don't want you using this in a production law firm environment. This very first customer, it was a woman named Catherine Marino Reman that we actually name our annual customer awards after these days. She was this first customer and she was our first paying customer and she was the first beta customer that Ryan and I started getting stack traces of her creating errors in the app at all times of the day and night. She was obviously using the program intensively, and we reached out to her and said, hey, we saw you ran into an error here. Are you really, depending on this particular bit of functionality working? She said, yeah, I'm using this for my law firm and I'm trying to bill my clients and everything else. It was kind of an oh- shit moment for me and Ryan when we realized like, oh, wow, the stakes all of a sudden are a lot higher. Pablo 42:19 That's a good function, that's for sure. Jack 42:21 It was another great forcing function where we were just like, hey, look, it was a moment of conviction where this isn't somebody that's just intellectually curious about our product and giving us feedback. This is somebody depending on it. It was a real crucible for us where we said we need to make Clio work for Catherine and we need to make sure that she can run through the product on a daily, weekly, monthly basis and do everything she needs to do with no errors, no hiccups. It took probably a month of really intensive work for us over that beta period to make sure that it was working well for Catherine . We got to that point. One of the bits of advice I give startup founders sometimes is you find your Catherine, find that -- we often think about building for ten or a hundred or a thousand customers, but often if you laser focus on the right single customer and just make sure your product is really singing for them, again, you can find ten you can find a hundred, you can find a thousand. Finding Catherine and really focusing our efforts on Catherine was enormously clarifying. At the end of that, to answer your question, is when I felt like, hey, we've got product market fit. We can scale and iterate from here, but we've got that kernal of functionality we can build a huge company around. Recap Pablo 43:42 Perfect. Well , thanks a lot, Jack . I really appreciate it . Maybe just to recap, we went through how you came up with the idea in the first place and how you pretty methodically set up a beta program. You use PR to really drive people through the funnel. You raise the bar with a webinar to only let in the right type of customers, and then you really focus, as you said, even on one single Catherine- like customer and made sure that that type of customer could depend on your product. That's what led to a successful launch and ultimately the first fundraise and many, many more since . So thanks a lot for sharing your story with us. I think founders will really appreciate it. There are a lot of great nuggets there that they'll be able to steal hopefully to make their s tartups more successful. Jack 44:33 Well, that's, that's the hope. Well, thanks for having me, Pablo. Really appreciate it and it was exciting to be a part of this podcast. Pablo 44:40 Thanks so much for listening. If you want to see more content, check out pmf.show .