How Salesflare built a CRM to compete against the big brands – with Jeroen Corthout from Salesflare

Product Stories

How Salesflare built a CRM to compete against the big brands - with Jeroen Corthout from Salesflare

Play Episode Pause Episode

Mute/Unmute Episode Rewind 10 Seconds 1x Fast Forward 30 seconds

00:00 / 00:37:47

Apple Podcasts Google Podcasts Spotify Stitcher

RSS Feed

Share

Link

Embed

Summary

Learn how Salesflare is taking on big competitors with a limited development budget, smart prioritization, and a strong core product team.

Also, learn more about the Google vetting process they had to undertake to have access to people’s emails. Let’s get into it!

Episode

Victor:  Welcome to Product Stories where we explore how founders build successful software products. This is a podcast about product management, software development, remote work, and everything else that technical, as well as non-technical founders need to know to launch and scale successful software products. Today’s guest is Jeroen Corthout, co-founder of Salesflare, and we want to find out how he’s built a CRM that competes with the big brands. Jeroen, welcome to the show. Great to have you. 

Jeroen: Yeah, thank you. Happy to be here. 

Victor: You’re a non-technical founder and I’m getting this question all the time. How did you find your technical co-founder, your current counterpart here in this venture?  

Jeroen: Yeah, I’m half non-technical.

Victor: So what’s your part? Where do you see yourself and what were you looking at in a co-founder?  

Jeroen: Yeah, so I indeed studied engineering myself, so it’s not like I don’t understand what happens in all that, which is an advantage when working with the technical team. But I’m not a coder so indeed I always need someone to take up the lead on the development side. With my co-founder we just met each other in the founder Institute. I was in there with a startup idea I had, and he was in there and we were in the same group. We had to help each other a lot. We enjoyed that, and had a lot of good conversations. I was on the way to work in my car and we would be calling and then go to our day jobs and then afterwards calling in to figure out what we’re going to do.  

We lost touch for a while. And one day he calls me and he says: “I’m going to Vegas with my company (he had a startup company) and we need a sales guy. Do you want to join?”. And we did that. We had all the fun together. I started collaborating with him on his company and it’s from there out of frustrations we had with managing our sales pipeline that we decided to start Salesflare. So I didn’t go out and look for a technical co-founder, it just happened. 

Actually at some point when I had another startup company, I was looking for a technical co-founder. It can be very difficult because you basically need to find someone who you want to work with, first of all. But secondly, also you need to convince that person that you’re onto something. And when you came up with it alone, that’s much harder than when you come up with something together.  

Victor: That makes perfect sense, actually. When it comes to Salesflare, you already mentioned you were looking to manage your sales pipeline and you find a tool that does exactly what you want. Can you tell us a bit about what Salesflare is and who it caters to? 

Jeroen:  Yeah. So Salesflare is a CRM (customer relationship management software). It’s more of a sales CRM, so focused much more on the essence of the customer relationship in many cases. In essence, a company  builds a product or provides a service, and then it’s sold. Especially in B2B sales. So we focus on that sales relationship. And what it does – if you think about it very practically, it helps companies to follow up their leads. From the moment they meet the lead, or they have a lead, towards closing that deal. And then also often afterwards, like following up that customer relationship after the sale. We focus on small and medium sized companies, not on the big ones that need something enterprisey like Salesforce or SAP or so, because these companies need a completely different tool.  

They need something that adapts to their company. An army of consultants come to set up a system fully custom made. It’s when you buy building blocks and then the guy starts building. We built something that comes out of the box, that is really easy to set up. We’re actually the number one most implementable CRM on g2.com. So it’s really easy, you just connect your mailbox, start working and all that. 

Where we distinguish ourselves from other CRMs like HubSpot and PipeDrive is that we built our software from the ground up for automated data inputs. We saw that there’s a lot of very nice software tools out there, but they create this false expectation.  

Somehow they are built on the premise that sales people are going to be this insanely disciplined group of people. Everything they do, they put into a system while they do it. They email someone and then they put that in the system and then calls someone and then somehow they meet someone and they have this trigger in their head that says: “I need to put this person in CRM”. That person passes their phone number. They think like “Oh my God. Now I need to put that phone number in the CRM.” And they’re so focused on the CRM, that in the end, this CRM, is this perfect database on which they can fall back, to do their sales follow up, manage customer relationships, and never forget anyone. It becomes a second brain almost, but they’re so focused on that CRM that it works.  

The problem is if they’re not that focused on the CRM, it doesn’t work at some point. It falls apart because somehow you forget to put some stuff in there. And when all that data isn’t there, it’s not qualitative. The system just starts falling apart. At some point we were working on sales follow ups for the company I went to help Lieven with.We had a lot of leads from a conference and we had to follow those up at scale. We were looking for a system for ourselves, trying different CRMs but we always noticed that we just couldn’t keep it up to date properly. After that we started tinkering and we figured that actually most of the things we were inputting were already available somewhere else digitally.  

And we figured why don’t we just pull these things together? We just connect with the mailbox. We pull out of there emails, the email signatures, the contacts themselves, how often you’re in touch with them, what are the relationship strengths? So many things you can pull out of a mailbox. Then we’ll add a calendar, call history which is in your phone, social media and all kinds of databases out there that we could integrate into this. Also web tracking and email tracking. We saw this whole system, which will basically track all customer information, but also all touch points you have with customers automatically based on the information that’s already there. I think that we are still the only CRM system that is built with that in mind first. Many other CRM systems started syncing information to automate some stuff, but they’re not built with automated data inputs as the first thing in mind. So if you use the software, you’ll see that the flows are very much manual data input with some syncing in, but we use the opposite approach.  

Victor: CRM in general is already not a simple micro SaaS to build. And especially with that in mind, that sounds like quite a big project. How did you go about really deciding the minimum feature set and building something to test out that must’ve been tough? 

Jeroen: That was tough. I must say we built sort of MVP but it was very far like a minimum viable product, which was very, very far from a minimum sellable product and even much further from a minimum lovable product. Our MVP was basically a plugin you had in Gmail and outlook, which would show you all the emails you were exchanging with a specific company next to your emails. And people wouldn’t really understand what the value wasn’t such a thing. And they were like “I have emails on the left, why do I need emails on the right as well?”. But they didn’t see our complete vision which was that everything was going to end up there and the thing was going to automatically keep itself up to date and make sure that you always knew what was going on. So people didn’t get our very first version. It took us three months to create that minimum viable product. It probably took us another three months to even convince one other person than myself to use it actively. And it took us another seven-eight months from there to sell it the first time.

Victor: How did you go about distributing it to people, about getting feedback? Enough feedback to really understand how, what should we do with it from there.

Jeroen:  It was all about, and it still is very much about having very close customer relationships. We did not do any significant marketing, back in the day. What we would do is try to get attention in the press here and there, with which we would get bursts of attention, bursts of leads to add to our pipeline. I would do a lot of customer interviews, to really understand what software people were using, what was wrong with it? What were they trying to do in sales? What couldn’t they do? Then when we had leads, I would take them all the way. I would show them what we built, I would install it for them, because you have to connect your emails and it was very hard at first.  You have to connect your G-mail inbox to IMF, for instance, and open up some security settings here and there. Nowadays it’s just one click and it all works. Then I would set it up together with them, make sure it all worked properly, show them around, did the support. At every step, like every single thing I would do with them, I would be like: “Oh my God, this is not working properly yet.” Then people would ask a question in some direction and every single time that I was in touch with customers, I had a list of stuff in my notepad, to go back to the development team, put it in GitHub,and start tracking stuff, start prioritizing, and start fixing.  

Victor: Do you think that was actually a good thing that you were so in touch or that your customers had to get so much in touch with you to even set it up? Or would that have been way easier if you just integrated with the Gmail API, so to speak directly right from the start?  

Jeroen: Uh, no. I mean, connecting to the Gmail API would maybe have been a better idea. That’s another thing, but staying close to customers, I still believe that’s something we need to do very actively. It’s when you sort of lose touch with customers, that it becomes much harder to build something valuable, knowing what little things are wrong with your product. Very often customers, especially the ones, who pay a lot of money are not going to tell you what’s wrong with your product. They just think up work arounds and all that. It’s only when you’re really in touch with them that they might tell you. So we find that really, really important. And especially in the early stages, I can only recommend going that way, because if you immediately make your SaaS software available freely to the public and everybody just signs up and then immediately turns from the trial and you don’t know why, the only thing you can rely on is Hotjar videos and, and a survey here and there.  

It’s going to take an enormous amount of time to figure out how to best build the product. While if you’re actually in touch with people, you can talk to them, they send you pages of feedback after you’re together, you see things happening because you’re there with them. That’s when you can create the quickest improvement product-wise and I think it’s also one of the only ways in which we can really, really compete with these giant companies out there. It’s being closer to customers because what happens inevitably in these larger companies is that they start building barriers between them and the customer. And these barriers can be simple. That could be a newly hired customer service agent who has no idea what the product is about, which is a very effective barrier. With this terrible customer support you don’t learn anything about the customer because the dialogue is just impossible. There is no proper link between customer and product. That’s what we’re trying to avoid very much. We give a lot of importance to being close to customers. Because of that we can improve our product more, have a better product, and also know where we want to go with the product.  

Victor:  And you also mentioned that you launched on AppSumo, one day. Did that improve customer feedback even more? Did that give you more exposure? Was that valuable for you?  

Jeroen: That was an enormous help when it comes to customer feedback. When you talk to people who have launched on AppSumo or wanted to but didn’t, you’ll very often hear that people on AppSumo don’t pay anything and expect the world. It’s sort of true, but the flip side of the coin is that you finally have people who want to give you feedback, or they bought into your product and basically they decided that whatever it is they need, the product that they bought will adapt to their needs and they will give you all the feedback. So you just have to let them say it, write it down, track it well, and you have a huge volume of feedback.  

Now the only pitfall there is that you start confusing the needs of the AppSumo audience with the needs of your larger customers or the customers within the direction you want to take the company audience. So that’s something you need to watch out and track it well. But apart from that, every little thing that could go wrong with your product, you will have heard it if you have an AppSumo audience on your product, because they’re just so much more engaged than the people who actually pay you.  

Victor: Jeroen, we’ve been talking so much about your early days. How long has that been since you launched initially ?

Jeroen: Our very initial MVP, almost six years ago.  

Victor: Wow. That’s, that’s been a while. So fast forward to today, what’s your team set up and team size right now?

Jeroen: That we are a team of seven, we’ve kept it stable over the past two years, because we want to grow our revenue a bit quicker. Surpassing the team size and growing a team also comes with its own issues. Like the one with the customer service agents that I just mentioned. If you grow too quickly then you have people on your team who don’t really know everything deeply and that makes the quality go down. So that’s also a reason for us to take it a little bit slower. But we have over 2000 companies now actively using the software. And we serve those with this team. The team is made up of my co-founder, who is mostly working on development things, not developing himself, mostly, development related things to get to with three developers. And then there is me mostly working on marketing, there’s Curie, mostly working on partnerships and Taylor, mostly taking care of customers.  

Victor: Awesome. And so you have three developers, your co-founder, who’s like a product manager or CTO development manager. Do you have a designer in-house as well?  

Jeroen: No. We had someone, who externally made the designs for both the website and the app. And for the past few years we’ve been building from that blueprints further and further, we also use Google material design. We very often follow the rules of Google material design to figure out our designs, and we work further on things we already have to make sure everything stays consistent. So we haven’t really been in need of a designer over the past few years. At some point we might do a redesign though, and then we’ll get someone again, but we definitely don’t have the need to employ someone internally.  

Victor: And what’s your structure? Are you remotely, or are you in an office? What’s your philosophy here?  

Jeroen: We are usually in an office. But for the past nine months, we have been working fully remotely. We have seen each other, I think, once in a bar and another time in a bar. But we have not seen each other in a work setting, just due to COVID. It wasn’t a huge jump for us to go remote because we were already remote with our customers. They’re all over the world. So there was no switch, we already had everything digitally. Our communication was running anyway through Slack. It was just mainly the meetings that we had to take online and sort of systematize the communication we have between that. We were somehow relying a bit on being in the same room and you have the sort of natural/accidental communication going on when you’re in the same office. We have to make things way more systematic. Despite all being in our own homes, we all know exactly what everyone is working on, what the latest things are decided and all those kinds of things. Actually, I wrote a blog post about that if you’re interested.  

Victor:  Absolutely. We’ll definitely link that up. And how did you manage to do more creative tasks? People are always saying that brainstorming, deciding on strategies and our directions to take that’s the hardest to do remotely. How did you find a way to replace that more or less, or was that the bar meeting?  

Jeroen:  No, the bar meeting was just meeting each other and not about work. The way we usually attack that is, we very well define first together what the goal is, what we are going to brainstorm and why, what do we want to achieve? Then everybody does some brainstorming over the period of a week or maybe two weeks, you can get some ideas, you write them down, you make a list for yourself. We come together. We explained to each other what the ideas were that we came up with, we grouped them together in one list. And then from there, when everybody has explained very well what it is ( not just showing the list together without explanation) we go into a process where we give them scores. Everybody can, for instance, choose the top three, depending on what we are doing. And then they get a score three, two, and one, for instance (we don’t have a standardized process for it). And now we see what comes up with the highest scores, more as a piece of information, rather than really having that fully defined the decision. It’s always just the model, but the model can be the decision maker. You can still have a discussion about it afterwards.

Victor: Moving into more of your development. How do you decide on new features or how to document them? What do you use to track your software development within your three, four people, product team? What works best for you in this setting?  

Jeroen: Yeah. Our product team is actually broader than just the developers. Actually, our product team is made up of myself, sort of the product owner, Lieven, my co-founder is sort of scrum master, CTO. Then we have one of the developers, the one who’s been with us the longest and knows product’s in and out, he’s also in the meetings to sort of represent the technical side of things. Then we have our Taylor in the meetings who takes care of customers and Gary who used to take care of customers. So I have a product team of five and what we do, we have different meetings, which we run through different aspects of the product development. Let me first explain to you where we track stuff.  

So we work in Intercom for our customer conversations, like all the support related stuff runs through there. A lot of the sales related stuff as well. And every time somebody says something that constitutes feedback in any form, then we log that in GitHub with the name of the person, name of the company, what they specifically said and a link to the Intercom conversation as a comment to an issue. And that issue is something that is wrong or can be better in a product. We generally have three types:

• features – whole new functionality. 
• improvements –  functionality that needs some sort of improvements. 
• actual bugs – things that are broken. Like we built something and somehow it doesn’t do a certain thing, which you envisioned it would do.

This second group, by the way, we brought to life, because at some point we just had bugs and features, and there was this space in between like product improvements.  

It just all fell down into a nondescript bucket. And it was very hard to improve on the product. Once we did that, we saw our product improving very fast and both for the bugs and your improvements we have a priority system which currently is urgent, high, medium, low, and also instances when something needs to be fixed instantly. For the features we do a much more elaborate scoring exercise because there are much bigger things we need to decide on. What we currently have in that scoring system is how well does it align with our product vision of where we want to go with the product. And then to a whole set of scores that define the impact in all parts of our funnel. These would be: what is the impact going to be on the amount of trials we get?  What is the impact going to be on how many trials turn into paid customers? What is the impact on how many people stay with us? What is the impact on our support levels? How much support do we need to deliver? We give all those scores and then we have this formula that calculates what the business impact is going to be together with the vision alignment. That’s somehow built in there as well.  We do this with all the features that reach a certain threshold of popularity. So we can focus on the right ones that are often asked. We also have a series of processes to keep prioritization and planning alive. I’m not going to go into all the details, but it’s really a running machine. As soon as things go live, we close the issue. What happens is that the Intercom conversation with everyone who asked for its open up again, and we can personally tell people that the thing went live, whether it’s a bug or an improvement or a feature, it doesn’t matter. We also ask for feedback, like “Hey, what do you think about what we did now?”. So that we can keep closing that loop. Finally we’ve just started using Acute which is also very interesting because it sort of makes the mapping for us now between Intercom and GitHub. It enables us, for instance, in Intercom to see what things people have asked in the past and also to add feedback very easily from Intercom.  

But we’re still sort of figuring out how that would work best in terms of tools for feature planning. We use Trello, but we’re currently actually looking to see whether it is something that could provide us with a better overview. We work with this kind of feature stories as small as possible, which would turn into Trello cards and then people work on them through the development pipeline. But it’s sometimes hard to know when things are going to land and what we’re exactly working on, how long it took. So we’re looking whether there’s anything better there, if you have any suggestions, very welcome.  

Victor: We’re actually going to be interviewing Joanna Bastow from ProdPad on the show. And that could be an interesting tool. I’m just going to tease her it right now for prioritizing features depending on customer feedback. But I think we’re going to do a more in-depth rundown of that on a separate show. But that was a super interesting insight, especially on how you use the GitHub issues and how you connect that with Intercom, which is probably very useful and efficient to manage that customer feedback. Do your prioritization in a spreadsheet or where do you do that ?

Jeroen:  We give things labels. At least for all of the bugs and improvements. Features are in a spreadsheet because that’s a more elaborate model, but it’s a small set of features really like big things that we’re working on and that we prioritize there.  

Victor: Interesting. Just to quickly mention it for completeness, what is your technology stack?  

Jeroen: It’s a full JavaScript. In the backend we use nodes and in the front end we use angular and it’s built on Google clouds. Mostly MySQL and all kinds of compute engines, autoscaling.  

Victor: There’s one, one last thing that I want to touch on, because I know that you’ve gone through that. And I know that probably a lot of founders out there have been facing this issue recently, which is the Google security review. So that’s something that Google imposed on people using or having access to, sensitive data on Google using their API. Is that correct? Did I understand that right? 

Jeroen: Yeah. That’s when you access sensitive scopes on the Google API, really sensitive Google user data that you’re extracting such as yes reading emails, you have to go through a security review. First, you need to answer some basic stuff to Google, and then you basically get three security companies to choose from. Two of them based in the US, one has a European seat as well. You fill out a very long questionnaire for them, first to make a quote, and then they quote you and it’s extremely expensive. When you’ve chosen one, then you go through a whole security questionnaire thing again, to check off a lot of different things. And then they start doing all kinds of testing as well.  

I don’t know all those things, but things like penetration, testing and all of that. We went through that last year with Bishop Fox. We didn’t have a lot of issues thanks God, because we just did it before the deadline. This year we need to go through it again, and we’re going to do the NCC. It’s going to be thankfully much cheaper than last year but still it’s a pain. Every year it costs you tens of thousands to go through this. Honestly, I don’t think it’s a huge value add if you have your security down. The security companies are not going to like hearing this, but we got much more value from the “security researchers”. We were also asked by Google to have a vulnerability disclosure program, where when people disclose vulnerabilities to us, they get a bounty. They have so much more than the security companies. We’ve been able to fix all these things, which is amazing. The security companies had low informational issues for us. And then still afterwards some guys all over the world, they just start testing and they find so many more things. 

Victor: That must be very interesting to go through. You’re suddenly on the plate for so many people to be tested. So congratulations on living with that. That actually is something you can put on your site as you’re actually thoroughly tested, not just we’re thoroughly tested. That’s a great thing. Well, thank you so much for your time and the super interesting interview on how you’re building a CRM that really goes against the big brands. Where can people find you, find out more about Salesflare and learn more about you?  

Jeroen: Yeah. If you want to find out more about Salesflare, or you can add to salesflare.com, you can read out all about the software. You can also try it. We give a trial, which is anywhere between seven and 30 days, or even more if you add a lot of people. We give you extra days on the trial, as you set it up further, because we see that people who actually properly set it up during the trial are way more successful. And so definitely try that and you’ll know whether it’s for you or not. If you want to get in touch with me, you can do that on LinkedIn. But please do include a personal message, that says that you’ve heard this chat on the Product Stories podcast, because otherwise you will end up in the sea of spam I get every day.

Victor: Wonderful. All right, thank you so much for being on the show and have a good one. Thank you. It was fun.