How Freshbooks’ Fear Of Competition Saved The Company | Mike McDerment | BoS USA 2017

Mike McDerment, Founder/CEO, Freshbooks

In 2012, the year after Mike spoke at BoS about the Litany of Product mistakes that had created Freshbooks, the company was growing faster than ever but those mistakes were coming back to haunt him. He knew he needed to rebuild the platform. Two years and $$$$$ later, still nothing had changed. Mike was seriously concerned a competitor would come onto the market that would be 10x nimbler and easier to use. In 2015, that startup Mike feared, launched but in fact it saved the long-term future of Freshbooks. How?

Video, Hangout, Slides, & Transcript below

Video

https://businessofsoftware.wistia.com/medias/u8s2bmyaoi?embedType=async&videoFoam=true&videoWidth=640

Hangout

https://businessofsoftware.wistia.com/medias/629k227fqj?embedType=async&videoFoam=true&videoWidth=640

Slides

Transcript

Mike McDerment: Good afternoon, everyone! That’s all right, thank you, Mark! I appreciate it! Mark did the spoiler alert for my spoiler alert. If you read the talk title it was how Freshbooks’ fear of the competition saved the company but really this is a talk about re-platforming. It’s not something that you hear about every day, it’s not something many people talk about when they’re done. It’s not something many people take it on and we’ll talk about the reasons why.

We’re coming off a re-platform at Freshbooks and I wanted to give something back to the software community and share with you some of the stories along the way. What I want to do is – there’s no big – I don’t know if you’re taking notes here. I will tell you some stories and my hope is that those stories help you better understand some of the thoughts and considerations that go in to making a decision like this, living and managing through it, and then a bit of a look back with certainly one of the bigger mistakes we made along the way I hope you won’t make. The idea is to inspire and challenge you to think about how you build software, how you might approach a re-write which is what we elected to do.

SaaS before SaaS

And so for those who don’t know the story, I like to begin at the beginning. The founding story of Freshbooks is I was running a small design agency, I accidentally saved over an invoice. This was 2003, I was using Word and Excel to run my design shop and that’s what most people still use today. Having saved over that invoice, I said there’s got to be a better way to do this and I hacked together a simple system. And over the years, this is a photo of me in the furnace room at my parent’s house and that’s my mom with a basket of laundry. Our beginnings are humble, I’m the 4th kid, I started the business and wasn’t at home, I ended up moving in with the business, we thought we’d be there for 2 months, we ended up staying for 3 ½ years. After 2 years running the business, we had 10 customers paying us $100 a month. So very crude beginnings.

And what’s more relevant about this and it sets the stage for how you get to writing a re-write is it’s 2003, the tools people take for granted today starting companies didn’t exist when we began. So we were I think the title is SaaS before SaaS – we were SaaS before SaaS! Our business model which has always been a recurring revenue subscription model which is now the thing that is so desirable and people like to do it and it was crazy at the time cause people were buying boxed software. We were building our own frameworks – rails didn’t exist. When you think about that time, it’s a very different time and place to build software than we have today. So that’s we’re starting at. Plus I was a business school student who took computer science elective. My co-founder has a PHD in computer science but was not a professional software engineer – just a really good problem solver. The best kind of co-founder to have as we got done so much so fast but what we wound up with was a codebase that was sort of hard to maintain.

The Downside of Pioneering

And so you get those beginnings, we started before there were the tools and frameworks people used today, we didn’t have any professional engineers on staff but as one of our now board members and advisors likes to say, Mike you figured out the hard part, you built something people wanted to pay for and they loved. So yeah, you suck at technology but you did that. And so ultimately, I’d rather solve that way and figure out the other part. We were able to scale up and build for a while, but ultimately being sort of pioneers in business models and technology and all these things – very early days.

We just wound up with this place when we started the iPhone didn’t exist. Right? Just think about that for a second. That is a huge change in terms of what consumers expect. So we had this codebase that was – we’d actually refactored the backend quite a bit and we had a huge and unfortunate combination of front end and back end logic still persistent. And the notion to refactor it to a place where you could make the changes we felt were necessary was hard to imagine. Again I use the iPhone as an example. The notion you push a button and a car shows up at your home or food. Suffice to say, consumer expectations had changed.

And what I’d failed to say, over this time we started at the basement, we actually – you may have heard of Quickbooks, we were number 2 in America for accounting software. Failed to mention that! Pretty successful business, millions of people use our software each month. What we were able to do because we were coming at the market differently and building for ourselves, we said hey, what we are is we’re ridiculously easy to use accounting software built not for everyone. We don’t build for restaurants, manufacturing or retail, just for folks who get paid for their time and expertise. And that difference of not serving everyone is important. It means we focus a lot on invoice and billing and we’d just segment the market in a different way. By virtue of that, and some of these decisions you don’t understand how important they are once you get going, but we uncovered a segment of the market that wasn’t being served by any product before us. It was building for people who weren’t accountants. If you use accounting software today and it’s easier than 10 years ago, you have us to thank because prior to us everything was built for the accountant because that was the sales channel. And so we went direct to owners and that meant it had to be simple and that’s what we built around. And so very successful, segment leader, whole new thing.

But consumer expectations had changed and primarily around design and user experience to my mind. The technology is in the background but for the customers it’s how you interact with the products and how it feels. And it was just our technical situation was one where, as I like to say, you can’t refactor your way to greatness. As I ask myself the question do I believe – we have the market leading product today so this is since 2014. Do I believe in 3-5 years, if we keep doing what we’re doing, we will have the best product in the market? The answer I came to was no. I had my doubts. We might be a segment leader, but I felt like we’d be under pressure and that forward time state. And so you get to thinking about a re-write.

And I think to give this talk some gravitas, it’s worth spending some time and talking about the number one rule in software development. Don’t re-write your software! There it is! There’s some really good reasons why. And you can read some articles from some very smart people why but I will tell you the reasons if you haven’t spent time thinking about this before. So you have first of all, it will take longer than you think and cost more and it will be harder. So yes, I can verify all those things standing here today. Estimating is hard – we just saw a nice lightning talk on that. Things just won’t be like you think it will be. And then there’s the old guess what? Most IT and technical projects of any scale, they don’t finish. They fail. So that’s a problem.

While you’re working on a rewrite, your competition is catching up and so we had a lead on a bunch of vectors but you’re standing still when you rewrite so people have the opportunity to catch up. You can make mistakes in a re-write and undermine the trust of your customers. You can’t lose data in my business so that’s a problem. And then my personal favourite is what I like to call the sophomore jinx. You ever had a band you really loved and the first album is amazing and you go buy the 2nd album and it makes you want to cry. I can’t believe it! I love this band so much! That was great 1st album but the 2nd one sucked. So when you think about building a whole new software platform, you flip the switch on a rewrite, who’s to say it’s better? That’s when you start finding out. So for all these reasons and a whole bunch more, the number 1 rule in software is you don’t rewrite. Did I mention we’d try 3 times before and failed? Ok. So that’s the downsize of pioneering, there’s a little bit of situation context.

The Blank Page Problem

Then it gets to how do you approach such a thing? And I like to call this the blank page problem. I don’t know about you all, but I’m a better editor than I am dealing with a blank page. And a big part of this rewrite and we will see how much time we spend out here, maybe in Q&A, it’s actually has been my journey. I don’t know how many of you are CEOs or founders, but I never worked anywhere else. I’ve been learning the role on the way and encountering all these challenges that I’ve never seen anyone solve before. So one of them was something I always struggled with. I actually have a pretty clear picture in my head, I’m fairly well-suited to like I can tell you about a vision. But if you ask me to put it on a page and what is it, that gets hard and I didn’t know how to do that.

So if you go back to this problem of we’re going to rewrite, we thought about how to approach that thing and it was primarily a user experience thing, so we decided we would just start with some light designs and that kind of thing but we needed to have a vision. And so if you picture yourself in – just put yourself in a meeting room, it has a white board and there’s 5 people in the room, and my responsibility was to set the vision for this new product. I didn’t know how to approach that problem. How do you do that, how do you capture that? So what I ended up saying is, I basically said here’s what it needs to do, it needs to do three things. 1-2-3. Build something that does that. And I think it’s important to understand so that was hard, deciding these 3 things. I kind of had to walk away. And what’s hard about walking away, with our old platform, we didn’t have consistent design patterns, it’d grown up organically. We will talk about this later as well, but I used to see every commit that was customer facing before it went out and my rationale for doing that was to try and achieve some measure of consistency cause there had been so many different things done so they ran past me before they go out.

And this was the beginning of not working like that anymore cause I don’t want to be in that place either. So team, they’ve got three things. Build me something that does these three things. And our CTO who was really great and the leader behind pulling all this off, said ok Mike, you’re done! He had this really cool office at the time. It’s about 20,000 sq feet with 6,000 of it was like a barn, with a 40 foot ceiling, it was amazing! I walked in there, saw the board and said we’re doing it! It had a loft that was not connected. So this team, we weren’t using that space just yet so they went up there and the CTO was like nobody talk to Mike for 2 weeks, Mike he can’t talk to us and we’re going up in a room. What happened next was remarkable to me and it was really all about the team. They went off and they just poured their guts into this thing. They had three things and they had 2 weeks. And if in two weeks they didn’t – I was the gate, they had to come back with something and if I wasn’t digging it, it ended. So they had an opportunity and they had a potential dead end staring them in the face.

And so they went off and about – they kind of decorated that space and you can imagine they had motivational statements and personas and did all kinds of customers research and this good stuff. And about 36 hours before they would bring me what they had, they were doing research and showing me the initial designs to customers. And the two pieces of feedback that they remember, the first one was this is so juvenile! What we had done, I think where they’re getting at, one of three things is it has to be ridiculously easy to use. Even though we had the easiest product in the market, I wanted it to be even easier. What they learned is they went too far, it was too facile! You’re building for business owners, they might not be the most sophisticated financial people but they’d skewed too far, that was number 1. So thing number 2 was, if this is the future of Freshbooks, I want no part of it. So suffice to say if you’re working on something you want to pack up at that moment – you want to give up. But they didn’t. And 36 hours later they came back to me and they had 3 approaches to solving what the UX could be. 1 based on timeline of how you’re running your business and another one based on entities. It was cool. My responsibility was to say ok, what’s your recommendation and make a decision. They went off and they got another 2 weeks to live. This was the pattern and it was good one because what happens with a project like this, and especially I’ll say this as a founder guy, it’s really hard to create deliver or die urgency in people. They’re getting a pay check. It’s just tough, right? There’s some kind – when I say that, I mean the kind of like up all night scared for your life stuff that people who found companies generally live a good chunk of the time. A deep seeded paranoia that this thing won’t go on. Anyways, I think these sort of milestone approaches were something that were helpful to us in that and the team had the support, but I think it’s why innovation often doesn’t work in big companies. It’s too comfortable. There was a nice transference with the team on this project. So that was the key part.

Convince the Board

But now, I don’t know how many of you know the history of Freshbooks, but I’m the resident poster boy for the anti-venture capitalist movement. Those who’ve known me for a long time would laugh and agree with that – or at least I was. Founded in 2003, took a lot of phone calls, but somewhere along the way things changed and what I had done, just de-risked the product and market and the final thing for me was hiring executives. I was like I thought I had before and I really hadn’t and then you get one and you’re like this is great! I see how we can scale and build. Long story short, July 2014, we raised $30 million and about 8 weeks ago we raised another 43. And back then in July 2014, we did this raise and we honestly weren’t thinking about re-platforming. And we tried it and what have you and it wasn’t really a thing in our minds. It was weighing on me in the back of my mind, can we win with this product? And we started out innocently enough with a little team doing a prototype, you know, what could happen? This wasn’t a decision to re-platform, but can we come up with a user experience that’s different enough and compelling enough to convince us we should? That was the exercise.

If you fast-forward a board meeting or two, folks who had just written a cheque and now you should be talking about re-platforming and it’s an interesting problem. How do you convince the board? Cause they’ve probably seen this movie before, they know it takes longer and costs more and all the rest of it. And so we had the prototype and it was the 2nd or 3rd meeting where we had to have the, hey are we gonna do this? So it started out with us talking about a prototype and we showed some stuff and the third meeting was the decision time. And what was interesting by that point was, I’ll just speak personally and say, was the team inside the building was so excited about this thing, you got your best people working on it, they’re super fired up. It’s like a whole new thing. And then you have a new board that has just written a cheque and is not aware that this might be a thing. I thought I’d just share some of the dynamics. That’s the problem set, that’s not great from a company management standpoint but we’re blindsided by the proposal.

So I learned a thing I wanted to pass on to you all, something I noticed the first board meeting. One of the things we do the night before and then we do the board meeting the next day. And we started off, I was trying to figure out how to run a board meeting. Another whole thing. If you want to talk about that come find me. But we started out by showing demos of our products and everyone was a good mood. Think about board members is they want to help you grow your company, but also be a part of building things and change the world. We create the environment we wanted but the real trick to convincing the board, and just food for thought for those of you trying to raise capital, is the people we chose to have on our board. It just so happens we’re in Boston today, so one of the guys on my board was a guy named Jeff Fagnan formerly of Atlas Accomplice. I will give him a plug because Jeff is a creator. It was unusually for him to write us a cheque because we were more a growth stage organisation and he was more seeding early stage, but it was great to have that diversity of investors because he was all about building something and doing something new. Which is not necessarily what you expect and anyways, bit of a diversion. It speaks to some of the challenges along the way you encounter if you had good governance and running an organisation and are thinking about a rewrite, how do you decide to do that? So we got through that, we got the board on hand and I went from geez best people, how can I convince the board to now the board is in, how do we get people going and sustain that sense of urgency? And giving credit to our CTO, he came up with a really interesting way to approach this problem.

Welcome to SMUX Co.

So the board’s kind of greenlit us to go and we’ll keep you posted with milestones but we’re giving this a try. And you gotta create that urgency, not easy. So what did he say? Forget Freshbooks! We had a small team not everyone was working on it. So it started out as one team and coming out of this boardroom we increased it to 3 and he said forget Freshbooks, you have 100 days to generate $619 of revenue. Go! Welcome to SMUX Co. That stood for simple modern UX. And so what the team had at this stage was a 100 days, and if you think about a free trial which our business model has and reverse engineer all that stuff, they had to figure out how do we go from here to there and generate revenue at the other side? It was a super tight timeline. It was such a concrete destination that it was very motivating. Slight of hand in influencing people and creating urgency, I thought very well executed by him and the team. All right. What else happened? Right. Ok.

So we got things off running this project, trying to sustain urgency, doing pretty well at that. We had another problem emerging. Which was we had these internal designs and technology that’s starting to work, we have a target of launch and making money, but how do you launch such a thing? What do you do with it? And my concern I talked about right off the top, some of the problems with the rewrite are that you don’t know if the thing actually performs better from a business standpoint cause you flip the switch one day, what happens? So I really want to figure out how do we de-risk that problem? Cause to work for 2 years and end up flipping the switch and have it perform worse just seemed like a non-starter to me but that’s almost what you should expect. So how do you de-risk that?

Then there’s this other problem of competition. I didn’t really want – if you’re building this thing and taking risks, you want to get as much time out of it cause it just so happens we live in an industry – I have one competitor that has an internal mantra of copy to compete. That’s discouraging. I remember early 2000s you’re reading the net and hearing America and the western world complaining about China, and copying IP and now you look at FB copying Snapchat features the day they come out. It’s a crazy world. So you want to create as much time as you can if you’re doing something like this and it’s a long lead and slow moving – just so you get a bit more surprise and an edge. So that was part of the problem and consideration. And then we’re thinking about international. Our initial launch plan for what we were gonna do with this is we were gonna launch in Germany. Cause we weren’t really serving that market, with paying customers in 128 countries, but we weren’t really serving Germany at that time. And fun fact about Germany and maybe someone in this room will correct me on this, but it’s my understanding that it’s not a bad place to start because the character phrases are the longest and widest. So if you think about the UX, you want to get that out of the way cause you can always go shorter. So for those two reasons I thought we will launch in Germany as a side-market and then we will get things going and figure it out. Our product is not completely regionalised but somewhat regionalised and taxes and these kind of things. I don’t want to build a product that was right for that market and not for our core market.

And so I was chewing on these problems one weekend and came in Monday, said to the team, what if we created another company that competed with ourselves? Put another product out there. We’d get the benefit of knowing how it’s actually performing. You’d actually know, like the funnel, I’d rather not talk about it anymore, does the performance of that product compare? Are you ready to put your business and all your traffic on top of it? Do people like it? Does it actually work? These are questions you don’t know if you flip a switch one day. So it took 4 hours and it’s a pretty good idea. So that’s what we did.

We created a company, its own name, logo, website, URL, incorporation documents, terms of service, we spent legal fees on that stuff and we just had this completely independent thing. And the team did that, they built it up and it made them feel like it’s our thing. That was pretty cool, that was BillSpring. A pretty novel approach to this that other folks will be copying in the years to come. It helped us solve a bunch of business problems which is why I like it. So that was BillSpring. I think that’s the maybe the most novel part of the story for what it’s worth. And it presents some interesting problems cause we ran them both parallel for 8 months and this happened. We had a customer call up and he said listen I’m sitting here and I just recommended your software to someone and it’s very different. What’s going on? And cause we had been testing it on our site. So we had a job of we were supporting 2 products in the wild for a while. It had its own phone number and some of these other things – just a bunch of hairballs that came out of that.

I think the way I knew we were ready to sort of mainline, we had the 2 independent things and I knew we were ready to switch over to the new platform is when we got a phone call. Everyone at FreshBooks starts in Customer Service. They spend their first month in customer service. Our CFO who previously was a public company CFO for 10 years, he’s taken 3 companies public, he started in customer service, he spent a month there. Go off and do your other thing, big on service. And this scrum master who started with us was spending his first month in service and he knew about the two products. there and someone called in and said I’d like to cancel my account. And I go to this new product called BillSpring instead. How do you like that?

Founder to CEO

All right, so a big part of this journey for me – I don’t know, I think I will just touch on this, I got more stuff on it but I want you all to know it’s there, is how do you operationalise your involvement if you’re the original product leader and visionary? To be sure it’s not seeing every change that it’s customer facing that goes out. I met 100 people doing that and the truth is I didn’t want to be doing it. And it was a hard thing because I got dubbed like control freak, bottleneck which that was true. Control freak was like I was sitting there going hey, I hate to say it to you all, but like these decisions that you’re making they aren’t clearing the bar and aren’t good enough. You’re working a hard scenario because the product doesn’t have consistent design patterns and some of the things you want to have to build a scalable thing. But it was a challenge and I think sometimes if you hear about these founders getting kicked out of companies and certainly I don’t think anyone is thinking about that in our case, but it’s easy to be misunderstood. And the difference for me was building that executive team who could then actually, to some extent, found it easier to interface with them, they could understand and implement and it wasn’t hard for them where with other folks there was a disconnect cause I’m living up here in the 5 years down the road version and someone is replying to a customer email. I got on well with everyone, it wasn’t like that, it was frustrating sometimes. So what this all did was it actually get a set of structures in place where it was easy to kind of work with the team.

My job throughout this stuff was – I kind of skipped a part where we worked on design principles when they were up in the loft. So we had 3 things the vision needed to do and from a UX standpoint, there’s probably more of these design principles but I will tell you what 2 of them are. And one of them was immediately intuitive so anytime you see a screen, I just want you to be able to take it in if you walk past, know what’s going on on that screen. The other one was screwdriver which is the concept that you build something so simple that people like it and they feel powerful with it and use it to do other things. If you think about a screwdriver, you open cans of paint with it, you might use it as a chisel here and there, it’s not just a screwdriver for turning screws. The team then went and built 7 more of those. I had some non-negotiables I sort of enforced and the rest of it was built up by the group. And they told me what those were and I was like, cool. And I started to play the role more of asking dumb questions and really trying to imbue the paranoia living in my mind like are you gonna pull this off? Does the customer really like that? My trick became instead of being directive which is like old Mike which was hey do this. Cause I’m 5 steps down the path and this will be the fastest way as far as I can tell but that doesn’t feel great to someone who has asked a lot of questions. If I ask the question more than once, I am begging you to really take it on and think about this. If I ask you a third time, it’s like please, please think about this. But that was just one of these little parts of it. It was interesting to see how it changed and what happened was we just ended up changing everything about how we built software. It wasn’t just the product that changed it was how I interacted with the teams and how the PMs did their leading. We interviewed over 2,000 customers in the building of the product so that rapidly became part of how we do things. It’s interesting so the rewrite wasn’t just the software but how we ran the company and how we built the software.

Rewired and Ready to Rock

So that’s leading us to the finishing up. I want to be clear, I don’t know if this all sounds like good news to you all, I’m hoping you have some questions. But it wasn’t all perfect. We made some mistakes and I think you had to pick the biggest mistake we made, so this is the ‘hey, if you’re going to rewrite, it’s hard, here’s some tips on how to do it, and this is something to absolutely not do’. And that would be this; with the building of the new platform, rewriting the software, and by the way I didn’t mention this, I don’t regret this, it was a decision we made. We said hey I hate being forced to upgrade, don’t you? Especially a totally new UX, don’t force me to do that. We had high NPS scores and customers loved the thing so why force them to move? They might just turn and leave so that’s bad for our business model. So we actually as part of this project and it was a huge tax on everything but one that I think was worthwhile, we enabled people to choose when they can migrate and gave them the option to roll back. That’s intense if you think about how hard it is to do and you think about the new things you want to do in a product and not the same exact data models and all this sort of stuff. But for us, I mentioned we’re really in the service, so it wasn’t really an option to put a gun to people’s heads and force them to switch. And one thing we learned about rewriting is often in cases it goes horribly wrong. You flip that switch and customers freak out! We certainly had our shares of freak out. Good news is we had an escape hatch and we could roll back but overwhelming positive. But one of the things we learned and about why rewrites generally fail when you flip that switch, certainly in our case, there were so many tiny UX changes we had made over a decade, imperceptible things, that greased the wheels on how a product works and is astute on how I lead you through a task you do in the software every day. Those are the things that – they don’t get caught. You think about building MVP and you think about a direct line and you don’t appreciate the value in the tiny little things that you forgot you did or maybe you did by accident and didn’t even know they were so important. And they don’t show up – we don’t write specs or anything but if we did, they would never show up in them. It’s the stuff that you don’t realise it until you flip that switch. It’s the stuff that really starts to p*ss people off when they think about going between the two platforms cause now it doesn’t work the way I want it to for this thing I do every day. Why the hell did you do this? Why don’t we help you get to the other one and I’ll let you know when it’s working the way you like? That’s what we’ve actually done for folks.

So, that’s a lesson you probably want to spare yourself from learning but maybe it’s a good reason to think about migrating or giving people the option. The thing I want to tell you we did wrong was we didn’t only rewrite our software and give our customers the ability to move at the time of their choosing with the ability to go back at any time, same pricing and everything else, but we changed our customer service systems. That proved quite well. Finally moved to ZenDesk, we were using something terrible. But when I think of our service operation it’s 80+ people and a big deal. The place where we made the mistake was the billing system. We went from home grown to building our own billing system and that’s not something I advise anybody to do. In fact, I’m not even so sure you shouldn’t keep rolling your own billing system. Thinking about that is crazy. Maybe someone in here does that. It’s such a narly problem and we had something like 1,400 individual packages people had built up over the years so really complex and our model is not like we have 100 customers, in fact it’s a lot more actually. On a relatively small credit card sizes. The single first and biggest change we would make if we had a do over is don’t do those two things at the same time, really bad idea. Anyhow I think we’re on the other side of that now, but it’s something I would share with you in hopes you don’t do that. Having said that, I would say that the common analogy for this is like changing the engine of an airplane inflight. My personal analogy is something else. We chose to compete with ourselves and build a better product for the good of the company 3-5 years out and it was necessary to do something invasive and hard. We ended up rewiring the DNA of the company.

I didn’t mention this, but you know that Fortune 500 best places to work thing? We competed in that. We’re in the under 1000 employee category and we were number 1 in 2015. Pretty cool, right? And number 4 in 2016. I really care about customers and the experience we bring to employees. In 2015 we working on this stuff, 2016 too. Through all that it was tough, challenging and hard. And the team felt like they re-thought everything that we did and re-wired us for future growth. I saw them achieve new levels of performance which is exciting. So the big gift was not so much the technology but the effect on the culture and the DNA of the company.

If you want to learn more about the story I would rdirect you to – Forbes wrote about 3000 words on it at one point and that’s pretty cool. There’s a pretty good telling of it with some nuggets that I didn’t get in to today.

With that, thank you very much and let me do some questions!

Q&A

Audience Member: Hi! Thanks so much! The folks on your team that you had for your first company were the same for the 2nd company? You had a lot of those UX related enhancements that you did but maybe you didn’t have all the documentation, how did you reverse engineer? Was the advantage you had all the same people? Second is when you had the second company and the same customer who switched from the first to the second company, how did you make sure they had the same experience? You had a lot of data from the customer. It’s the full experience, the migration part of it. How did you make that flawless

Mike McDerment: Yeah. So I can’t even remember the first question. Same people, I think that’s how hard it is to know the little things. Some people were with us 2-3 years, but they did the month in service. I wasn’t standing over their shoulders, I don’t know if I would’ve caught it all, I think it’s the nature of things. With regards to the data, we started out with – part of the reason to create the new company – I’d actually forgot this side of the story – frankly, our engineering team with the old product and the technical debt we had built up, it was just the technology, the debt was intense. And so we’d have a hack day and someone would have a great idea and they’d be like oh yeah I have this great idea – oh man no, that’s too hard I’m not going to bother. And we tried to rewrite 3 times and we made some progress but we didn’t believe we could do hard things until this project. And that’s one of those great gifts – now there’s a dragon, let’s go and slay it cause that’s what we do and the rewrite brought us there. To answer your question more directly, as I try to remember what part 2 was, the migration of the data. Creating that new company, I wanted people to be able to take extreme risks and not damage our brand. And so they did that there and when we knew what was going on, it was solid engineering to figure out how do you do that? It’s a tax. I mean, we’d be done sooner, better and faster. This was a decision we made because of our customer orientation. A lot of other companies wouldn’t. You could argue that it was a bad one, it was right for us and who we are.

Audience Member: So you decided to do a second company. I wonder if you got any backlash from people saying why are you trying to hide behind a new company. Why not build a new product under the same company and give it a different name? What did you see as the difference?

Mike McDerment: No backlash. We only had the one case I’m aware of where people figured it out and that was at a time where we brought the two companies together and we were splitting traffic when we really ramped up on the new platform. Basically because of stealth and secrecy, we had 250 people who like – this was top secret. We have nine values at Freshbooks and an invisible 10th value which is secrecy which is no forward looking statements, no financials, no strategy – don’t teach your competition how to think. So they all kept that a secret and the day when my wife found out about my new platform was when we launched it. So there’s no reason cause we went to a lot trouble – incorporated company, no trace between the two – there’d be no backlash because people didn’t know. And then the other question I will say I will try and frame it again. I think there would be 2 primary reasons. One is I hate when people say, people just need to be empowered. That tells me you don’t understand what you are talking about, don’t say that to me. What I do believe is you should create the conditions where people can be empowered to do great things and that’s your role as a leader. In this scenario, I wanted people to take great risks and wanted them to have the ability to lose data and I don’t believe that doing that under our brand which is service oriented in nature and I thought it was a conflict of one another so I had to create another brand. Does that make sense? That was the primary reason. That and stealth. You don’t want people watching you.

Audience Member: Maintaining 2 code bases is expensive. I’m curious to how long you kept both?

Mike McDerment: Yes it is. We’ve been doing it for 2-3 years, but it’s not too bad and we do like 10s of millions of dollars of revenue on that old code base so it’s worth to keep it up. Easy business case. Also customers who are happy. Why push them off of it? It does create some hairballs and my hope is that someday we either have so few or no customers on there we get to one codebase but in the meantime we decided to run them both.

Audience Member: You mentioned that when you wrote the codes that frameworks like rails didn’t exist and that presumably that codebase didn’t leverage those frameworks but when you went to re-architect you wanted to take advantage of maybe what was the latest and greatest frameworks and tools were. Can you describe the process that you used, since it was the same team that moved on to do the new re-architecture? Can you talk about the process on how you get them up to speed and they trained?

Mike McDerment: I see. So crazy thing about this whole thing, we built this thing up and frankly as a founder from a design and product standpoint all these new things came out, these better ways to do stuff and I had a decade of ways I thought we could be better. So I was super excited about the prospect of building a better, simpler product. The same is true with all the technical tooling. I will say the team as in specific decisions, we prototype stuff, hey does this work? Some people would play with things and we’d settle on the core pieces of the stack. We use amber js for part what we do and we didn’t know much about that and we had a team of smart engineers who didn’t know so we ended up bringing in some consultants and we had a bootcamp for a week with the professionals teaching us so that we could work on our own after that. So that was the process of how we figured that stuff out.

Audience Member: Thank you! We’re in the middle of the rewrite ourselves – how did communicate this internally to the rest of the team that wasn’t involved in the project? We got a bit of backlash.

Mike McDerment: I think you can quite quickly get to 2 cultures. The people who get to play with the shiny new toy and the people that do the rest of the stuff. We didn’t end up having major difficulties with that fortunately and so in your scenario how do you communicate it. I think in our case, everyone was excited about it. That wasn’t – and to be honest, being part of one of those is really exciting. It’s like going on a journey and you don’t know if you can get to the destination. That uncertainty creates magic. So we didn’t have that problem so I’m not sure I have great advice for you! I mean yeah, you must have a really good reason and for me framing it in 3 to 5 years from now is maybe the answer to your question. Maybe give that a shot.

Audience Member: What is the promise you made to the customers on the old platform? Do you support it or you have to switch to the new one?

Mike McDerment: Your price will stay the same, you won’t be forced to switch. I think – like the word never didn’t come up, but it will be years. Our belief is we have to build so much value on the other side and people see the momentum that they will opt in. It’s a matter of time. We’ve made it easy for them, they click a button and they’re there – c’mon that’s pretty good. We see it as our responsibility to compel people to switch. Because we had already been running for two years with the two to keep going seemed like a fairly well understood risk.

Audience Member: Thanks, Mike! I don’t know how much the timing aligns with the financing you took. You were a bootstrapped for a long time and we’re a big advocate for this. I’m interested in the internal dialogue you had with yourself through this transition period. Not necessarily how you took the decision to take financing, but once you did make the decision, what kind of things were you working on personally to change? What values did you want to stay grounded in or did nothing really change at all?

Mike McDerment: So definitely a longer file. I think getting to the place of why I made the decision is important – I got to a place 30 years from now I was if I look back, I can keep doing this and it’s great, but I just felt like there was more adventure around door number 2. That was the reason to go down that path. But I’d also de-risked, I’d had a board for 5 years at that point. I think that’s that part. And then I guess you’re saying once it’s in there, what’s changed? It’s funny, I’d say very little. I think we chose wisely with our board members and there are folks that wants a capable management team to run a company, they don’t really want to get involved so it took a while to really get that and keep going so that’s a thing. And I’ll say this as soon as we raised the $43 million bucks in July the first thing I did was hey everybody, refresher, yeah you walk past them everyday when you go to lunch but then you taught them when they first join the company, we give out our value cards, these again are our values. Any questions? Straight back to basics and no changes. People aren’t writing cheques because they want you to change, they want you to keep doing what you’re doing. That’s a headshift to get around as well.

Audience Member: It was bold decision to make a separate brand and website. Did you start building website 100 days ahead of releasing second brand? How long it took to gain traffic and what was your differentiator?

Mike McDerment: The answer is no. We did the opposite. We paid to put traffic there because our core goal wasn’t to build up another brand it was to prove a prototype with real world use. So marketing was great partner in that but not the driving factor!

Mark Littlewood: Thank you, Mike! Thank you very much indeed!