In today’s episode, Matt Watson and Jeremy Snyder, Founder and CEO of FireTail, take an inside look into API security. Matt and Jeremy discuss IT, cybersecurity, and the rising API security risks. They also talk about what it is like to sell to developers and IT people and the value of listening to customer feedback. Finally, they urge listers to rethink assumptions during the product development process.
Covered In This Episode
The best path to becoming an entrepreneur is being an expert in your field. That expertise allows you to see problems that need to be solved clearly. People who work outside of an industry will never be able to see and understand the challenges within them.
On today’s episode of the Startup Hustle podcast, I interviewed Jeremy Snyder. He worked for 20+ years in the enterprise security industry, including working for AWS. His experience led him to start FireTail, a company focused on monitoring and securing API applications.
Most modern software is built heavily around APIs. Both consuming them and creating them for modern UI frameworks like React to consume.
His vision was how to secure all those APIs properly.
Listen to today’s episode to learn these things and more from Jeremy:
- How a major pivot dramatically changed his business
- Going from an IT practitioner to selling back to IT
- The struggles of selling to IT departments
- The importance of taking customer feedback
So what are you waiting for? Join the conversation in this Startup Hustle episode now.
Highlights
- IT, cybersecurity (0:56)
- Cybersecurity and vaccine development (2:07)
- What does FireTail do? (4:23)
- API security risks (6:08)
- Jeremy’s an experienced startup founder (7:37)
- FireTail’s initial thesis and pivoting (9:32)
- APIs security and monitoring (13:12)
- Challenges of selling to developers and IT people (15:59)
- From working in IT to selling IT (18:26)
- Building a tech company in Virginia (23:09)
- The value of feedback and listening to customers (28:56)
- Rethinking assumptions in product development (32:09)
- The sales process of selling API security (36:19)
- Remember to learn along the way (39:58)
Key Quotes
APIs are actually particularly attractive to attackers for one kind of interesting reason, well, maybe two or three reasons, but one is that APIs sit in front of both data and business logic and transactional processing. By breaking into an API, you can not only likely steal and exfiltrate data, but you might be able to manipulate the underlying application to do something for you. -- Jeremy Snyder
So, that is something that I've very much preached in the teams that I've built, in particular, in the sales engineers that I've built. And with the account execs, the actual salespeople that I've hired over the years, I've always tried to reinforce to them that your job is not to win a deal. I feel like there's a lot of unintentional but negative adversarial relationships that go into that. Like, if you, the salesperson, feel like you're winning the deal, then what's happening to the customer? Is the customer losing the deal? -- Jeremy Snyder
A lot of times, the feedback you get is just as important as whether they buy or not, right? It's because you need to learn from that feedback. The value of that feedback is just meeting with people and talking to customers. It's easy for people like you. You're like, Hey, I've worked in IT security forever. I know what they need. I'm gonna build it. They'll buy this thing versus actually going and talking to them and figuring out if that's really what they want to buy, like, it's a totally different thing. -- Matt Watson
The things that you think intuitively are right if they don't resonate with the feedback you're getting. You’ve got to rethink them and don't hold to those tenets just because you're convinced you're right. -- Jeremy Snyder
Rough Transcript
Following is an auto-generated text transcript of this episode. Apologies for any errors!
Matt Watson 0:00
And we're back for another episode of the Startup Hustle. This is your host today, Mount Watson. Really excited to be talking about something that's kind of near and dear to my heart. It might be a little boring for some people, but I promise it won't be boring. Today, we're going to talk about IT and API security. And nobody's excited about that, Jeremy. I'm sorry, but we're gonna make it exciting, I promise. So stick around everybody. We've got Jeremy Snyder, who is the founder and CEO of FireTail. For those who know my background, I sold stuffed it before, and I've got battle scars and nightmares to talk to Jeremy about today. So it's gonna be a fun conversation. Before we get started, I do remind everybody if you need to hire software developers, Full Scale is the option for you, and hire software developers sort of 60, 70, 80% less than normal. We have great senior-level talent in the Philippines who are glad to work with you. Check us out at FullScale.io. Jeremy, welcome to the show, man.
Jeremy Snyder 0:52
Very happy to be here, Matt.
Matt Watson 0:56
IT is exciting, right?
Jeremy Snyder 0:57
It is always exciting because there's always something new, and it's always changing. And when you think it's gotten boring, that just means that you're not paying attention or you're not staying ahead of the curve, or your org has stagnated. Because there's always
Matt Watson 1:14
Well, nobody cares about IT until something doesn't work. Like the website's down, the software is down, like, an outage, like, then everybody cares about IT a lot, like, a whole lot, right?
Jeremy Snyder 1:27
Yeah, I get what you're saying. And I will say that is very true. And by the way, doubly true for cybersecurity. No one cares about security, nobody even less than IT, until the moment when something goes wrong. And the crazy thing is, I actually like not to go down too deep of a tangent here. But I thought I was done with cybersecurity about three years ago, the security company that I was with at the time got acquired. And I thought, you know what, that's enough security, it is a high-stress job. That is no thanks. When everything is going well, nobody getting a lot of blame when the, you know, the crap hits the fan, so to speak.
Matt Watson 2:06
And then you get fired.
Jeremy Snyder 2:07
And then you get fired. And actually, what changed it all for me was the pandemic. And what I ended up experiencing at the time was I was working on cloud security. And I was working with customers around the world, my team and I focused on a kind of security strategy and security architecture for some of these companies with large scale cloud footprints. And what ended up happening is that as we were all in lockdown, we were working with a couple of the companies that were working on vaccines. They were under sustained constant attacks. And what we found was that actually being able to protect their cloud environment allowed them to keep running simulations that ultimately led to the mRNA techniques that were the basis of the vaccines that we all hopefully got. And then I realized, like, okay, I understand this stuff, I can actually add some value, I can understand and identify some of the new emerging IT, like, some of the different it paradigms, constructs, technologies, whatever you want to call them and help to mitigate threats and risks around them. So, I decided it was a good use of my time. But otherwise, like, yeah, it's it's, it's not always super exciting. I get that.
Matt Watson 3:25
Well, let me let me ask you this. So we're in the middle of a global pandemic, you know, 2020, or whatever, like you're talking about? Why would these hackers be trying to mess with people who are trying to create vaccines to solve a global pandemic? What do you think is their motivation?
Jeremy Snyder 3:41
Politics, profit, and geopolitics. So you had largely state actors, a nation state actors who were going after intellectual property that their own R&D groups didn't have. And these might be nation states that are kind of cut out of global supply chains and trade organizations. And so this is ultimately for some of them their best path to getting their hands on some of that intellectual property. That would be the basis for a vaccine. And then the other side is, if you are a, you know, the the companies that created the vaccines landed very large contracts with governments around the world. billion. Billions. Exactly. So the profit motive is definitely there as well.
Matt Watson 4:23
Very cool. So tell us more about FireTail. What is FireTail, exactly? And what what led you to create it? What was the inspiration behind that, exactly?
Jeremy Snyder 4:33
So what FireTail is, is we are a software company that helps organizations identify risks on their API's, mitigate those risks, and then put in place continuous discovery, monitoring, alerting, etc. So we'll help you find what API risks you have today, fix them and then put that in place going forward. Little bit of a set it and forget it type of vibe to the software itself. Once you're up and running and you've kind of gone through that initial phase of mitigating your current risks. What led us to create it is that, you know, my co-founder and I, we both came out of cloud security. And what we saw was a lot of the risks on cloud security, were starting to get fixed, both by the cloud providers like AWS, Microsoft, Azure, and Google, creating more secure default configurations. And also just customers and security teams getting better at cloud security. But at the same time that that was happening, there was a large shift in software development kind of architectures. And we really moved into a world where API's were central to a lot of modern software designs, I'm sure if you go ask your your teams, or let's say, the folks at Full Scale that, you know, what are some of the software requirements coming in for projects that they're working on? I bet you that at least half of them, if not more, start with designing back end API's and figuring out, you know,
Matt Watson 5:54
I mean, almost all software development is done this done today and React or Angular view or some kind of front end framework that uses API's to talk to some back end like, like, seems like exactly 99% of it is done that way. It's not 99%. But it sure feels that way.
Jeremy Snyder 6:09
Exactly. And so that was the shift that we saw starting kind of around a similar timeframe to what I already talked about. And so we realized that, yeah, you're going to mitigate a lot of your crowd risks or cloud risks already. But you're going to have a whole new set of risks around your API's. And API's are actually particularly attractive to attackers for for one kind of interesting reason, well, maybe two or three reasons, but one is that API sit in front of both data and business logic, and transactional processing. So by breaking into an API, you can potentially not only like steal and exfiltrate data, but you might be able to manipulate the underlying application to do something for you. Right, that might be as simple as like, order me a free pizza, using somebody else's authentication token. Or it might be as complex as, like, remote unlock a car, remote start the engine, as was reported earlier this year as a vulnerability around API's in connected cars. If I could remote unlock and start your car, using API's, I can steal your car using API's. And so there's, you know, this kind of dual element of why they're so attractive, combined that with what you said about how all software projects pretty much start with API's nowadays. So, there's a lot of there's a lot of reason that people should care about this, maybe more than they do right now. But maybe they just don't know what they don't know at this point, which is kind of where we end up spending a lot of time right now talking to customers about what these emerging API risks are.
Matt Watson 7:37
So you mentioned before we started recording that you, this is actually the third company you founded. Tell us a little about some of the things you've done as well.
Jeremy Snyder 7:46
Yeah. So this is my fifth overall startup, third that I've co-founded. So I co founded a videogame company in 2006. We were a 3D Metaverse, only about 15 years before the next Metaverse hype cycle. And which also, by the way, has fizzled out pretty quickly, I will point out. But, you know, we raised about 20 million at that point in time to build this out. We ran that for four years. We had a really interesting run, we grew to about half a million players around the world. Big chunk of them in Southeast Asia. So, that actually led me to move to Singapore to run operations there. And then we ultimately crashed and burned. A lot of good lessons learned coming out of that one, also co founded a company in the E-commerce space working on kind of sharing economy collaborative consumption stuff. We made a white-label engine that would let anybody build their own kind of Airbnb style website. And a lot of fun, a lot of learnings but ultimately, like there wasn't a large enough demand and so we kind of shut that down by selling off the IP to our existing customer base and then moving on to do other things. I've also spent some time at AWS, I worked in cloud security for a number of years with a company that I joined as an early stage startup. I think I was employee number six or seven there. I don't remember exactly. We grew that business, about 20x in a four year period before that got acquired. And I spent some time with a larger cybersecurity company that acquired us actually working on M&A. And before all of that I spent 13 years as a practitioner doing IT and cybersecurity. So kind of hands on board building networks, building data centers, building teams to build networks and data centers, and then then transitioned into more kind of customer-facing roles.
Matt Watson 9:32
So when you guys had the idea for FireTail, did you have any idea? Like is it the same today as what the original idea was? Or is it has the idea kind of changed from the very beginning?
Jeremy Snyder 9:42
It's changed a lot. It's changed a lot. Our initial, our initial thesis around how we were going to tackle API security was based around creating inline controls to examine API calls in real-time. And we built out a set of open source libraries, they still exist, by the way, and we do have a number of people using them. But, we really thought that this would be like a, hey, let's make this set of open source libraries, let's put them out into the world, let's make them available for developers who are building API's. So, they can just kind of ship a an API that is secure by design has some protections, you know, integrated into the API itself as a package before it goes live. And what we found is in talking to people, and we spent a lot of time talking to developers, a lot of time at, you know, developer events, or talking to developer meetup groups and whatnot, we just didn't get the reception that we thought. We got a lot of that is academically cool. I have other fish to fry. You know, there's there's just a lot of priorities and a lot of kind of conflicting priorities for the developers' time and attention. And I get it actually, and you know, I didn't get it at the beginning. But after going through that process and talking to a lot of people, what we found is like, developers are under immense pressure to ship and anything that kind of slows down their development cycle or that slows down their delivery times, maybe surplus to requirements, or may just kind of get left by the wayside. And so we've ended up having to pivot, what we were building, and how we even frame the problem and talk about the problem quite a lot in the last 9, 12 months.
Matt Watson 11:28
Well, in from my you know, so I had a startup before called Stackify that I sold a couple of years ago. And that did application performance monitoring kind of kind of similar kind of related in some ways. And I always liken it to, we have the same problem of developers, right? If trying to get them to understand like, this is a tool that can help you it can help you do your job, your job better, etc. But like into, like most of them were like firefighters, but yet, they didn't even really have like a real fire, like a real fireman toes, they had like a little garden hose trying to put out put out problems, right? And they didn't even stop and realize like, hey, there are better tools and better ways. And like, we could bring in like the big pumping station and the big fyros To solve these problems. But like, yeah, they wouldn't do it. It was very frustrating for me.
Jeremy Snyder 12:14
Yeah, yeah. But like I said, I get it. I mean, they've got all these competing priorities, and they've got all these, you know, product requirements being fed to them. And, you know, generally speaking, a lot of these technology companies operate in very competitive spaces, where the ability to ship a feature, you know, two weeks earlier than your competitor might make a meaningful difference. And, you know, to that firehose point, like, if you've got your boss breathing down your neck to ship and deliver, and then you've got all this set of extra capabilities that you should build in an ideal world, or you should integrate in an ideal world. I get it.
Matt Watson 12:57
So how, so how did this change then? So you wanted the developers to install some packages that would help implement some of the security? Yeah, what changed? And how does it work differently today, without getting like crazy over technical for our listeners here?
Jeremy Snyder 13:12
Yeah, we'll try not to, but it's very easy to get quickly pulled down that rabbit hole. But what ended up changing was that we realized that the person who is really tasked with solving the problem of, you know, the problem writ large of API security is the security team. And it's kind of challenging to figure out how they're supposed to do that because ultimately, they have responsibility for overall organizational security or InfoSec. But they very often don't control the things that they end up having to monitor and secure. And so what we realized was, the best thing that we could provide for them was kind of continuous self-updating visibility into all the APIs that they have inside their network, and then an assessment of what are the security risks of those APIs. So at a high level, that's what ended up changing. We do one more thing on top of that is we put in place ongoing monitoring of the APIs for their kind of utilization and behaviors and traffic patterns and things like that. But a big part of it is now instead of being a set of open-source code libraries for developers, we still have those, by the way, but instead of that being the primary focus of the company, the primary focus of what we're building out turns to be, let's help security teams identify and mitigate risk on their APIs. So that is kind of the main thing.
Matt Watson 14:32
So is it more of a monitoring tool? Or does it actually prevent, you know, potentially malicious, you know, activity?
Jeremy Snyder 14:40
So the preventative controls are still there, but they are still in the open-source code libraries. So their customer journey ends up being very much like security teams kind of sign on first. They identify all the API's, they assess them, or they get the automated assessment that tells them like, Hey Matt, you have these 100 API's out of Which of these 10 look really bad? Maybe you want to go work with the developers of those 10 to implement the preventative controls. Okay. And so that kind of ends up being the customer journey.
Matt Watson 15:10
So do you end up having a bunch of problems where your software conflicts with other software that they use, like, other monitoring and APM tools and intrusion detection tools or, like, all that kind of stuff that you have to deal with too?
Jeremy Snyder 15:25
So far? No, I won't give it a categorical No, but so far, no, we haven't run out of that. And I mean, maybe that is a result of the environments that we support. We're primarily built for public cloud environments. And so you know, we don't run into a lot of customers who are implementing a lot of that stuff. APM, yes, sure. But that's not conflicting, doesn't do end up generating kind of APM telemetry data for APIs as a byproduct of what we're doing in the kind of log analysis and log monitoring. But, but no, we don't end up conflicting, thankfully.
Matt Watson 16:00
So, tell me in the early days, you thought you were gonna build these these packages and basically sell this to developers, right? Like, how did that? What was it like selling to developers? Because I have nightmares from that?
Jeremy Snyder 16:13
I, you know, I don't promise.
Matt Watson 16:16
So, I always say they because it Stackify this is what we did, like I always say like they you know, they all use ad blockers. They don't like spam. They don't they don't answer the phone. They don't you know, they don't answer emails, I feel like most of them are like wearing aluminum foil hats in the basement somewhere. It's fine to market to the end, they have no budget, and no authority to make a decision to buy something. That's that's how I always kind of summarized it.
Jeremy Snyder 16:43
Those last two points were a particular concern, the more we dug into it, right, like, but by the way, security teams are very, very similar. They all use ad blockers, they, you know, all have email filters on. Yeah, you know, all of that is very challenging for almost anything selling into IT in the modern climate, by the way, yeah, like, you know, it could be APM, it could be cybersecurity, it could be just general, like, I don't know, you could be a Windows patching company, or you could be like an anti-malware or anti-ransomware company, you could have the greatest anti ransomware solution ever invented. And that's, you know, maybe arguably the number one problem in cybersecurity today, you could have that solution, and you're still going to find it difficult to connect with the buyers. So, we kind of knew that going in. Thankfully, from previous experience. We knew that it's really hard to reach those people through a lot of traditional outreach methods. So we, we decided not to do any of that. We decided we're only going to engage developers at the places where developers congregate and where we're allowed to. So we put out a ton of proposals to present at developer meetups, virtual developer meetups, conferences, open-source conferences, etc. And we did a number of those. And that's where we ran into the, hey, this is academically cool, but like it's not a high priority for this audience. So, we didn't thankfully, we didn't get maybe to the level of trauma or traumatization, that you got to only because we didn't pursue some of those tactics. But I do agree that like reaching people within IT generally is very hard nowadays.
Matt Watson 18:26
It's very, very hard. So you, you mentioned before, about you worked in IT for a long time, and now you sell IT instead, how has that changed your perspective of IT?
Jeremy Snyder 18:36
Um, I mean, I continue to think of it like we talked about earlier, it's that kind of thankless thing. And so, I guess the main thing that I would say is, I can relate to a lot of the problems that customers express to you. It does make me take a much more thoughtful approach to things than I often saw. One of the reasons I kind of made that transition was I often hated the vendors that came calling on me. And I'm sure like, if you've spent time in IT, or any of the audience, as you can probably relate to this, especially going back maybe, you know, 10, 15 years, and I've been doing this 25 plus years at this point, not to date myself, but you would very often have that kind of thing where you've got an account exec, who kind of knows nothing, if we're honest about it, right? His job is to wine and dine you, schmooze you, whatever, make you feel special.
Matt Watson 19:35
You figure out if you have budget and the need.
Jeremy Snyder 19:39
Yep. And then you have a like a sales engineer, solution architect, pre-sales technical, whatever it's called, right? That's the person that you ultimately will want to talk to. And the one thing that I used to get really frustrated with those conversations was, I always felt like I was being talked at not communicated with very much, like, it's a Okay, we're gonna ask you all these questions. Do this whole discovery song and dance qualification, conversation, etc. But then I'm ultimately like, no matter what you say, you're gonna get the same spiel from me. And the solution architects, they at least would understand, but they were, their job was generally to just kind of repeat the same stuff, I'm going to run the same demo, I'm going to run the same kind of, you know, process to tell you about how amazing this is, and show you the same screens and reports and automations or whatever. What I will say really has informed my own, you know, my own approach to these conversations, as I've transitioned from being the user to now selling to a lot of, you know, what would have been the old me. I tried to be much more thoughtful about it. And actually, like, try to understand their environment, and their challenges a lot more than I always felt like I was treated. So, that is something that I've very much preached in the teams that I've built in the in particular, in the sales engineers that I've built. And with the you know, the account execs, the actual salespeople that I've hired over the years, I've always tried to reinforce to them that like your job is not to win a deal. Your job is because I feel like there's a lot of unintentional, but negative adversarial relationships that go into that. Like, if you the salesperson feel like you're winning the deal, then what's happening to the customer? Is the customer losing the deal? Like and I feel like there is that kind of, you know, I won despite everything Matt told me about, you know what he needed.
Matt Watson 21:38
It has to be more consultative, selling..
Jeremy Snyder 21:40
Exactly. And so I've always kind of coached the sales, the salespeople that have been at companies where I've, you know, manage them, your job is to facilitate your job is to guide a customer towards the most logical outcome being to work with us. But sometimes that doesn't work out. And so like, in the cases when it doesn't work out, a) Don't be a jerk. B) Don't nag the customer at the end on the way out, which I've seen far too often from salespeople, you know, the whole like, Okay, you go with the competitor, you're going to fail, and you're going to call me back in six months. Like that is just a jerk comment. I've seen that all too often. Yep. But you know, you will find along the way that not all you don't have the right solution for every customer environment, you're not able to meet every customer's needs. Be honest about that. And, you know, as a salesperson, your goal is to kind of like, project manage that whole conversation to its logical conclusion. Ideally, the logical conclusion is that they do end up going with you. But, you know, sometimes it doesn't. And so again, just you know, manage that well.
Matt Watson 22:47
Well, and worst case scenario, hopefully they refer somebody else to you. Yeah, right. If you're looking at it the right way. Yeah.
Jeremy Snyder 22:54
I mean, if look, if you're the best thing that can happen, is that a deal that you didn't get, you know, somebody that didn't sign up as a customer, refer somebody else who is a better fit for you. Yeah, that tells you a lot about your organization.
Matt Watson 23:09
Yeah, absolutely. Well, I do want to stop mind, everybody, if you need to hire software developers, Full Scale is great option for you. We have over 300 employees in the Philippines, I work for dozens of other startups and scale ups. We build dedicated teams that work only for you directly for you. And, Jeremy, you have a interesting development team, I think is really cool. We were talking about this earlier, that is in places people don't necessarily think of. And so you're, I guess, first thing is, you're in Virginia, which like can't I'm in Kansas, nobody thinks of Kansas or Virginia as being high-tech. But I guess first question is what is it like to have a business in Virginia, as are any pros or cons or?
Jeremy Snyder 23:52
I mean, generally speaking, people talk about Virginia as being a business-friendly state, I will say, you know, not to get into politics, but it is a generally a business-friendly environment, very easy to incorporate get up and running, not expensive, not non-existent, but low state taxes. We do have a bit of a tech scene. We do have, you know, Amazon HQ to is here. This was for those who have been around for a while, this was the headquarters of some some very, like kind of shameful names to look back on. But companies that actually established a lot of the modern internet. So, if you're, if you remember a name called UUNET, AOL, MCI, WorldCom, all of these, like early internet service providers, we're all here. We have a legacy of that now. So, if you're using modern cloud platforms, AWS, US East One is here. Microsoft as your US East is here. Google USA is here. We've got about 25% of the world's internet capacity here, literally about 15 minutes that way. So, you know, it's just row after row of data center, because we've got the convergence of two of the largest fiber backbones, the intersection of the north, south, and east-west. And we have no natural disasters, and we have relatively cheap electricity costs. So it's a, yeah, it's a good place to have a data center. But so it brings a whole community around.
Matt Watson 25:17
So, it's a great place to put servers, is it a great place to Is it a great place to find software developers.
Jeremy Snyder 25:25
It's challenging on the software development side. And so there, there's a large software development community, but what you end up competing with here, if you are a startup founder like me, is you end up competing with both the federal government and all of its various branches, who started to pay market competitive salaries. They pay proper market rate. And if the federal government directly doesn't, then all of the contractors and systems integrators that serve those federal customers, they pay well. So, you've got a lot of competition for talent. There was a joke a few years ago, the cloud security company that I was with, we had all of our software development here. And we would sometimes lose candidates to the likes of Booz Allen Hamilton or, you know, Lockheed Martin, or whatever. And you're like, well, what is Lockheed Martin doing on cloud platforms. And it's not that they themselves were, but all their customer contracts, they were building a lot. And the joke was, you know, if you could spell AWS, you could land a 200k a year job with one of those guys pretty easily. So, with FireTail, Well, it certainly helped that my co founder lives in Dublin. And so you know, it was a very easy decision for us to look at building up teams on the same timezone on that side of the world, okay, easier for communication purposes. So, we have our R&D split between Ireland and Finland. I, myself am a Finnish citizen, I've got a number of family connections back there. Okay. I did three years in chemical engineering in Finland in university level before dropping out and moving to the States, separate story. But you know, I had connections from my days back there into the tech community and, and we found a couple people who were exceptional talents, and we decided to build a team there around them as well. And both of those have worked out really great for us. We do bring everybody together, we're, you know, we're remote-first, but we do bring everybody together twice a year for kind of team meetups, and, you know, and kind of just bonding team building, but also to whiteboard together solve difficult problems. You know, sometimes, when you're working remote, it can be hard to remember that, oh, Matt's really good with graph theory. And there's something I'm trying to figure out. So let's get on a whiteboard and work together. That's one thing that I do feel like you lose in that remote-first culture. So we try to bring some of that, you know, you know, brainstorming together into those get-togethers. And those have turned out to be a lot of fun, in addition to being very productive sessions.
Matt Watson 27:53
What does it cost to hire a software developer in Finland or Ireland?
Jeremy Snyder 27:58
Less than half than what I pay here? What you would pay here in the DC area? And that's DC. That's less than New York. That's less than the West Coast? Yeah. So yeah.
Matt Watson 28:07
So probably 50 to $100,000 a year. Roughly, yeah, that's fair. Yeah. Most people don't think about, like, I never would have thought about hiring developers in Ireland or Finland. And there's, but most people don't realize that 90% of software developers are not in the United States. They are all over the place, right. And like at Full Scale, we have 300 employees in the Philippines to do work for people and there's talent everywhere, they're everywhere. And so there is very cool that your team is there. Did you mention you all sorts of people in some other places not just aren't
Jeremy Snyder 28:43
Just Ireland in Finland, we've got a few different places around across the US on some of the sales and marketing team. Okay, so we do a lot of customer-facing stuff here. But we do a lot of the technical stuff over there, pretty much all
Matt Watson 28:56
So when we were talking about selling this earlier, and you were the struggles of trying to sell to software developers. So, you've since made the pivot and you're selling directly direct to CISOs or other which is Chief Information Security Officers, and other like security kind of department, you know, related positions and those departments. How was that? Is it you know is that been a really good transition for you guys how was like growth and kind of the phase of the company now?
Jeremy Snyder 29:30
We're in a strong growth position right now. So we've we've picked up a lot of new signups and in new companies coming on board in the last several months here, but it's a combo so we do both that kind of direct sale to the security teams. Often it's not the CISO themselves who gets involved but it's you know, one to two levels below but somebody within their organization, right. You know, any C-level often is involved in more kind of company management and and strategy than they are in the day to day implementation work, and perhaps rightfully so, right. But we work with a lot of people within those organizations. I would say the transition has been generally like overall positive and the right thing for us to do. And it has led to a lot of success for us. But it also meant that the set of capabilities that we had had to dramatically change, like, we had to really go back to the drawing board to think about, like, Okay, this is a complete new stakeholder, a complete new persona, what are the challenges that they face, and then design for that, and then go out and, you know, validate assumptions, and then test that again, and again. You know, every customer conversation you have, even if it's somebody who shows no interest, in the end, you learn from that as well. Yeah. And so you know, just kind of being very, very good and diligent at like, kind of listening to what people say, you know, running demos, talking about your vision, problems you're trying to solve, and getting the feedback along the way, customers, partners, analysts, all of it is informative, and help you, can help push you in one direction or the other that, you know, ideally leads you towards providing a better solution that solves their problems more effectively.
Matt Watson 31:15
I mean, a lot of times that feedback that you get is just as important if they buy or not, right? Like because you need to learn from that feedback. And that's one of things I post about on LinkedIn quite a bit is the value of that feedback, just meeting with people talking to customers, like, it's easy for, for similar like you, you're like, Hey, I've worked in IT security forever. I know what they need, I'm gonna build it, they'll buy this thing, versus like actually going and talking to them and figuring out if that's really what they want to buy, like, it's a totally different thing. But it's easy to fall in that trap, right? You're like, Yeah, I know what I'm doing. I've done this for 20 years, because I kinda, I kind of fell into that trap myself. On the Stackify side, I'm like, I want to build what I think what I wanted, and everybody else is gonna want it right. Like, yeah, yeah, did you? I'm curious if you had some did you go through? Did you go through any of that and have like, some kind of Stark like learnings of like, wow, there was something drastically different than I ever thought? Like, did you run into some of those scenarios?
Jeremy Snyder 32:10
Yes, a couple of them along the way. I mean, first was the initial pivot, right? Like where we thought we knew better in terms of how do you actually solve this problem with a preventative? Right? Will you do that as with these code libraries, like, you know, that was the number one lesson learned. But even then, as we started to make the pivot, a lot of the things that, you know, would sound super straightforward and logical, were not necessarily things that we thought of. So for instance, you know, one of the things that we thought was going to be super intuitive for people was the idea that APIs belong to an application. That's just a like a natural thing. For anybody who comes from a software development background. It's like, what are you building that, oh, I'm building the user management app, or the user management service within this broader application. And so under User Management, I've got any number of APIs. And so we thought, like, hey, that's the right way to kind of think about organizing APIs. And so like, the v1 of kind of what we started changing the product into, came with that as a required, hierarchical construct in the data management, right. And so and then we started going to security teams, and they're like, could not care less. Like they care to the extent that they want to know who built the API later on. But they just want to know that the API exists, the fact that it belongs to user management, almost irrelevant. And so like, you know, requiring an app construct around it, we had to rethink. And there was a number of lessons like that along the way. A lot of you thought, like, oh, we absolutely know how this stuff is. We've built modern apps, we've built modern cloud apps. We've run modern cloud apps, we've run security for modern cloud apps, we absolutely know. But again, I mean, to your point, like the things that you think intuitively are right, if they don't resonate with what feedback you're getting, like, you got to rethink them and don't like don't hold to those tenets just because you're convinced you're right.
Matt Watson 34:11
Well, and we this really highlights another challenge for startups, right? Like you, you understand the problem you want to solve, like, Hey, we're trying to solve API security. And it's like, no matter who we try and solve it for maybe 60, 80% of it is sort of the same at the core of what we're trying to solve. But that other like 20, 30, 40% can be dramatically different, depending on who you're trying to solve the problem for. Right? And I want to I have like a my own startup company separate from Full Scale that I work on and we do digital marketing, dynamically controlling Google ads and same sort of thing. Like, are we trying to serve as a marketing agency or is our target customer a plumber? Because it's like, just like we're trying to do the same things, but if we're servicing the plumber, they are going to want different things in the working agency. Want, even though like the core like that 60, 70, 80% of the functionality is the same, it's like the other 20% is dramatically different. But that 20% is the difference between success or failure, right? Because that's the 20% that's like special and unique for them of what they need to see. Otherwise you forget the other 60%. It was a waste of time.
Jeremy Snyder 35:18
Yeah. Yeah, absolutely. And I mean that 20% can include some very impactful things, right? Like, I would argue that your core algorithm for how you're actually solving the problem is got to be the most important thing. But then beyond that, that 20% might include things like oh, single sign on, or reporting or
Matt Watson 35:40
integration report, they want to see
Jeremy Snyder 35:43
Exactly, or like integrations into the ticketing systems that they use every day that like, nobody's going to log into your tool every day. But if you can push data into a ticketing system, right, that they do work in every day, like then you actually become super impactful and helpful to them. So like, a lot of that stuff, you've got to, again, you can't make you can maybe start with a base set of assumptions, but then you've got to validate in those conversations is like, is this hitting the mark of what is it you want to see? How do you want to see it? Where do you want to see it? You know, all of that has to be checked. And as part of your customer discovery conversations.
Matt Watson 36:19
One of the things I'm curious about, and I think is great for our listeners to understand is, what is the sales process and sales cycle for selling something like this, right? Isn't it's like a kind of a complex enterprise sale, like, it takes weeks or months to sell, right? Like, like, what is the sales processes something look like for you?
Jeremy Snyder 36:39
I mean, generally, yes, it is kind of a complex enterprise sale for a larger organization. What we've tried to also do at the same time, is making it really easy for small organizations. So to that end, we're actually quite open about what we've built. And we try not to be a super secretive company, we actually put a free trial on our website, you can click and get started without ever talking to anybody at FireTail. So, if you're so inclined, have at it. For larger organizations, what we tend to see is a initial engagement that leads to a conversation that might have a demo in the first conversation might not, we try not to, again, we try not to be jerks about that I do see a lot of companies that are still throwing up like intentional roadblocks and, and hurdles in a customer's buying or evaluation cycle, where it's like, oh, well, we have to have a discovery call before we can schedule a demo. Like why? You know, we don't want to wait a call and do a demo. Yeah, cuz
Matt Watson 37:38
that's like, because we don't want to waste our sales team time to talk to potential customers if they can't afford it. Right?
Jeremy Snyder 37:44
Like, that's such a terrible customer experience or logic, I just think like that, to me, that just paints the company in such a bad light. That I don't want anybody to ever feel like, you have to jump through hoops in order to talk to us and in order to see what we're doing and understand what we're building. You might very quickly determine that it's not for you. No harm, no foul. But I don't want you to have to, you know, go through a huge back and forth qualification process, scheduling email chain, whatever. Yeah, you know, yeah.
Matt Watson 38:16
You pointed out something else. That's that's it's interesting dichotomy is if you try and optimize for those sorts of free trial self-service people, that's also dramatically different than the bigger enterprise deals, right? Like different types of sale, the even probably the features they want, the price they're willing to pay are totally different, as well, right?
Jeremy Snyder 38:37
To some extent, yes. However, I do think you can manage some of that with good documentation and tips inside the product. Because the core product may be roughly the same, let's say like, you might need to give them one of those little things called like guides as you go through the product to navigate. It's like, hey, hey, Matt, you just signed up. The first thing you might want to do is connect your AWS account. So let's come over here. Here's the documented process so you, you know, you can manage that without changing the product dramatically. If you provide the right supporting documentation and the right set of first-time user experience features,
Matt Watson 39:13
Yep. Well, I do want to remind everybody if you need to hire software developers check us out at FullScale.io. We have hundreds of developers in the Philippines working for dozens of startups and scale up, helping them build whatever they need to build different kinds of front end technologies, programming languages, and all the different things mobile apps. Check us out at FullScale.io. Jeremy, your website is FireTail- T,a,i,l.io. I like the IO, we're FullScale.io. I like that. So, on the way out, I always love to ask people if you have any final tips or words of wisdom for other entrepreneurs who are listening.
Jeremy Snyder 39:58
Just try to remember to learn along the way. I think it's really easy to get kind of married to the initial vision that you've set out with and not take that feedback into account as you go, and as you grow, we all make mistakes. That's natural. And it's very easy in a startup, as you know, yourself, Matt, it's very easy to get too high on the highs but then really too low on the lows. You're going to have any number of setbacks along the way. You're going to have any number of, oh crap, we were totally wrong, or, you know, this person was totally wrong for the organization, but we didn't see it until x had happened or so much time had gone by, or whatever, you got to learn to kind of brush things off, take the learnings away from them, keep going, stay resilient, and, you know, learn and adapt. That is the number one thing, I mean, if you can learn and adapt along the way, and you identify a good problem that you're able to solve, you know, that's the that if you can manage all of those things, then the real question is, can become did you choose the right problem to try to solve? You control all the things that are within your control.
Matt Watson 41:09
I love it. And it feels like a weekly challenge as an entrepreneur. It's like never-ending problems that come along
Jeremy Snyder 41:14
Daily, hourly, I mean.
Matt Watson 41:18
Well, thank you so much for being on the show today. Again, this was Jeremy Snyder, founder and CEO of FireTail. Check them out at FireTail.io. Thank you so much, Jeremy.
Jeremy Snyder 41:27
It's been a pleasure, Matt. Thanks for having me.
Sponsor Highlight
Make the right decision and choose Full Scale when hiring software developers. They have highly qualified developers, engineers, testers, and leaders who will only work for you. And they have a platform to help you manage that team effectively and efficiently. Define your project’s technical requirements now!
Lastly, don’t forget to check out our Startup Hustle partners. These organizations support the startup community and varied services for different businesses.
