Sean Falconer - Skyflow

In this episode, Sean Falconer, the head of marketing at Skyflow shares his non-traditional career trajectory, from studying computer science to becoming the head of marketing at Skyflow. He discusses the challenges of marketing a new category of product and the importance of educating the market on data privacy and protection. Sean also emphasizes the need to understand and engage with a technical audience by speaking their language and providing authentic content. He highlights the significance of aligning sales and marketing efforts and targeting the right personas through channels like events, digital ads, and account-based marketing. Sean concludes by sharing two career lessons: knowing when to move on and being open to mentorship and feedback.

Transcript

INTRO:

The Demand Generation Club Podcast is back and we're turning up the heat with season three. Get ready for insightful conversation with experts from Splash, TrustCloud, WorkRamp, UserGems, and more as we dive deep into B2B marketing approaches that are making an impact in 2024.

This podcast is brought to you by SaaSMQL, the SaaS growth agency that helps B2B software companies land seven figure deals with highly targeted multi-channel campaigns. Since 2018, SaaSMQL has helped over 100 SaaS companies generate millions of dollars in sales pipeline and recurring revenue. To learn more, go to saasmql.com.

Franco Corporale:

Welcome, everyone. I'm here with Sean Falconer, who is head of marketing at Skyflow. Hi, Sean. Welcome to the Demand Generation Club.

Sean Falconer:

Hey, there. Thanks for having me.

Franco Corporale:

Can you tell us more about your background? How did you end up becoming the head of marketing there at Skyflow? What was your career trajectory?

Sean Falconer:

Sure. I probably have somewhat of a, I guess, non-traditional path to the role that I have in marketing today. So, I actually studied computer science for over a decade. I have three degrees in computer science, undergrad, master's, and PhD, and even did a postdoc in bioinformatics at one point on the path of trying to become a professor or professional researcher. While I was doing my postdoc, I actually started working on a company on the side and I was originally the CTO and co-founder of that company. And I left essentially my postdoc after a year, after we'd raised money to do that company full time.

And we went through a lot of ups and downs with the company. But one of the things from running that company for seven years that it really pushed me to do was learn a lot of other parts of running a business that are outside of essentially just the technical parts of that business. Because when you're a small under-resourced company and as the founder, you just have to wear a lot of hats and you got to figure out a lot of things like go-to-market. And that's where I learned sales and marketing and sort of the business side of the business, mostly because I was forced to do it because if I didn't do it, we were going to run out of business. And it was like you don't have anybody to depend on besides yourself, so you got to figure it out.

So, it took a lot of trial and error and learning and mentorship from people that we could learn from as best we could. But it really came down to the buck stopping with us. And then after that company, I was wrestling with what I was going to do next. I was looking at software job, software engineering, going back to my roots, also product roles. And I also considered marketing because I had spent really the last few years at my company doing primarily marketing. And then I decided to put that on pause and go back into engineering.

I joined Google where I led developer relations, developer experience teams for several years for multiple API products there. And then leaving Google, joined the company I'm with today, Skyflow, and I originally joined as head of developer relations to build out that function within Skyflow. I'm sure we'll get into this, but a big part of what we need to do at Skyflow is essentially build out go-to-market to technical audiences and that was my original role. And then from there I ended up also leading product marketing part way through the year. And then about a year ago, I took over all of marketing. So, that's kind of what has led me to where I am now.

Franco Corporale:

That's super interesting. And obviously today, we're going to focus on this particular part of your background, which is incredibly valuable and is how to market and sell to a technical audience, which is something that a lot of companies are trying to crack. I like that you have this developer relation background as well. Is that something that was instrumental for you to understand also how to build community, build engagement around the specific product with engineers or developers?

Sean Falconer:

Yeah, I mean, I think that was a big part of it. The developer relations really, sometimes people forget about the second part of it, which is it's all about relationship building and I think a lot of marketing and modern marketing is building relationships at scale. So, there's a lot of similarities between them and that's why sometimes DevRel functions fall under marketing, but they can exist in other areas as well.

At Google working in DevRel, it's very much an engineering function. Other places, it's part of product. At Skyflow, it was originally part of marketing, which is what kind of led me on the path to becoming head of marketing. But we serve such a heavily technical audience and really sell into [inaudible 00:04:29] and technical practitioners. So, it makes a lot of sense to have that alignment at the organization that I'm at now. But there is an aspect of community building, thought leadership, authenticity that really comes from the DevRel world that is at the heart of some of this work that we do at Skyflow now.

Franco Corporale:

Going back now to Skyflow, because obviously you guys have such an innovative solution and you mentioned you're basically building a new category there from scratch. Can you tell us how you approach that, because it's probably one of the hardest thing to do in marketing?

Sean Falconer:

Yeah, maybe I can start with a little bit of just an explanation of what Skyflow is and then we can kind of get into our challenge there and some of the things that we've done. So, Skyflow is a data privacy vault as a service, and essentially that concept originated from companies like Google, Netflix, Apple, they were some of the pioneers of this concept and technology. And the idea is that historically, we've essentially treated sort of all data the same when we built systems, it's all zeros and ones. We'll take someone's name, there's social security number, the address, as well as application and transactional data, and we'll just shove it in the database.

So, what some companies like Google, Netflix, Apple, and so forth, recognize was not all data is the same. We should take essentially the sensitive data and not co-locate it with all of essentially all our data, and put in a special location and treat as something special and develop technology for handling that. This is where this concept of a data privacy vault came from. And the problem was that they're hard to build. They take a lot of resources. So, Shopify built something similar at their company for solving issues around analytics. It took them like three years and close to a hundred engineers to do that. It doesn't make sense for most companies to dedicate a hundred engineers to something that's not core to their business.

So, essentially we built this concept of the data privacy vault for everybody else and made it available through a simple API. So, that's kind of the little bit of background on it. But the big challenge that we have as a company is that this is a new category of product. Most people don't know what a data privacy vault is. That's starting to change, but it's taken a lot of effort to get there. The challenge from a marketing perspective is that because in any new category, you can't just copy someone's playbook. There aren't competitors you can go and look at and say, "Oh, they're doing this thing, let's try that as well. And maybe we'll do it better and we can out-compete them." You just don't have that, essentially when you're creating a new category.

The advantage you have is this green field, but there's just not a lot of references for it. People aren't necessarily searching for what you're selling, so you have to be a little bit more creative about how do you essentially bring this thing to market and capture the right audience. It's a little bit like MongoDB had this problem back in 2011 because no one knew what a NoSQL store was or a document store, and, "Who cares? I've been using SQL Server for the last 20 years? I don't care about this thing."

And what they did was rather than trying to position themselves as this NoSQL thing or document store, they talked about the flexibility of their approach, which was really appealing for the startup market at the time because if you're a startup, you don't know what your schema for your business is going to be in three months, let alone in three years. So, it was very nice to have this level of flexibility that Mongo was able to deliver, plus the scalability that it could. So, it could grow with your business and then essentially they were able to go from startup into essentially larger enterprise businesses. But it took a long time and a lot of their early marketing material was around essentially teaching people about how do I use this Mongo thing with technologies they understand.

So, it was Mongo plus PHP, Mongo plus Ruby on Rails or whatever the technology was at that time. So, you could hook into these existing communities and deliver them something that actually worked better for them. For us, we have to do over invest in some ways around awareness of thought leadership in order to make people understand what the problems are in the world of data protection, data privacy. It's an area where a lot of engineers just don't have that much training.

I spent a decade and three degrees studying computer science. I have one course, this is technically a security course that I had to take in undergrad, that was only about encryption. And that's generally the kind of level of education that most engineers have. They're building systems, not necessarily thinking about, "Oh, what impact could this have as someone comes and needs to delete the information I'm storing about them?" They're just not thinking about that sort of stuff. So sure, of course they're going to copy the data everywhere. Why not?

So, you have to educate the market a little bit on the potential landmines they're going to step on if they essentially mismanage this thing. We've made a lot of investments around events, content, podcasts, videos, educating the markets or shouting from the highest mountaintop. And that's also where a lot of our sort of developer relations, developer evangelism work comes into play as well. But the other thing that's important is to understand what people do care about. So, there are people trying to solve some of the problems that essentially we can help them solve.

If you look at places like Stack Overflow where lots of engineers go and ask questions, there are people asking questions about, "How do I safely store a social security number? Or how do I keep customer data out of my log files?" Or these types of problems, people do care about and they are trying to solve them. They might not be looking for data privacy vault, but they're looking for solutions to those problems. So, you can create content around that that helps serve that need and teach them this about the wider approach.

Similarly, if you look at places like HubSpot, there's all kinds of people in their customer support forums saying, "I have a bunch of healthcare data I'm putting in HubSpot. How do I protect it?" And HubSpot's like, "Whoa, whoa, whoa. Don't put healthcare data. It's against our terms of service." But they need a solution to that because HubSpot's not HIPAA-compliant and they're storing essentially data that touches on HIPAA and they need a solution to that. So, how can they serve that need?

So, you can kind of tap into these challenges if you understand the market and the audience correctly and develop content and sort campaigns and demand generation plays around those problems and challenges. I think of our job as marketers is really to both understand what the market cares about and relate it to what we are doing. So, people might not be searching for data privacy vault, but they're searching for and posting about these problems that we can help them solve.

And I'll give one last sort of example of some of the things that we've done. One of the first things that I did when I joined Skyflow was I wrote an article, a guest article, a podcast and website called Software Engineering Daily, which I'm now actually a host of, and the article was titled Why Every Engineer Should Have a Data Privacy Vault. And essentially I was tapping into this existing community of technical practitioners, engineers that are reading and consuming this information. Just I didn't talk about Skyflow, I was just talking about the concept of a data privacy vault. You can go off and build this thing yourself, but the starting point is to understand why is this important? Why should I care about it?

So, I wrote that article and then about six months later, an article came out in IEEE and IEEE, for those who don't know, this is a marquee publication for anybody in computer science. I'd always, when I was an academic, had hoped that I would someday publish something in IEEE, which I never accomplished. But anyway, so these two folks from, at the time, they were from Infosys and they wrote this article about the future of privacy engineering. And in that article, they state that essentially now is the time for us to move beyond privacy by design, which is this framework that came out about sort of guiding companies on how to deal with privacy challenges. And the approach that they champion in that article, as the future of privacy engineering is data privacy vault.

And the article they reference when they introduced the concept of data privacy vault was the article I wrote for Software Engineering Daily. And now you're getting this sort of really marquee influential publication to talk about the core concept that we brought to market and from people who are not associated with our company that are well respected in the industry. And that is I think was one watershed moment that has helped catapult our company to more of an awareness of play for companies that are looking for solutions in this market and trying to understand what they should be building or what they should be buying in order to help them solve all the various privacy challenges that we're having.

Franco Corporale:

That's pretty amazing. And obviously privacy is growing and growing in terms of awareness with the GDPR and everything and all these losses that are popping left and right. So, it's definitely, the problem is becoming clear, the solution much less. So, you guys have definitely a lot of work to continue building this new category.

I also want to touch upon something that is a little more common problem versus building a new category, which is selling to head of engineering, selling to CTO, selling to head of cybersecurity, selling to a technical audience. Because it's definitely different than other sectors like when you're trying to market to a sales executive or other departments. So, what is your secret to engage with a technical audience in a way that build demand gen opportunities, et cetera?

Sean Falconer:

I think that the approach is not that different if you're selling to a sales or marketing organization or anything like that. A lot of it comes down to understanding who the audience is and meeting them at their level and speaking their language. So, there's this sentiment I think in the world of engineering, sometimes you've heard it. You hear it in developer marketing, developer relations as well as where people will say, "Engineers hate marketing," but I don't really think that's true.

They hate bad marketing, but everybody hates bad marketing, so don't do bad marketing and you'll be fine. When it comes to engineering, the bullshit meter is a little bit higher or there's a little bit more sensitivity to it, but it really comes down to speaking their language and it has to feel authentic and feel like it's from them. Someone goes and reads a blog post and it feels like a bunch of marketing fluff, but it's supposed to be a technical blog post. That's not going to engage them, and it's not going to help you from a thought leadership standpoint. And that is kind of the missteps that you can make.

And understanding who they are means that you don't insult them by sort of underestimating their intelligence. When you're telling to CTOs or architects or engineers, you don't need to dumb down things in a way that someone who's not technical in a sales or marketing role can understand it. It's not about making something that's appealing to your sales team. It's about making something that's appealing to a CTO who's going to buy your product. So, you can show an architectural diagram in marketing material and they're not going to see that and be like, "Oh, my God, this looks so complicated." They're going to be like, "Oh, this is my language, this is what I understand." So, that is the key. The key is authenticity and kind of meeting them at their level.

In terms of Skyflow know, we kind of segment our technical personas or audience into three buckets. So, our executive sponsor, the person who's ultimately going to be signing a check is a CTO or a very senior engineering leader within their organization. And then there's going to be an architect likely involved in the conversation and sales cycle at some point to evaluate the product as well as figure out, where does this fit into the existing infrastructure and are we going to run into any sort of scalability issues or is there any concerns from an architectural standpoint?

And then when it comes to actually integrating, there's most likely going to be an application or data engineering, depending on what your problem you're solving, involved with the integration cycle. So, you need to meet each of these people at the right level and essentially serve their need, but they're involved typically at different parts of the customer journey. So, any point it could fall off. The data engineer, application engineer and the architect are influencers, they're not necessarily signing the deal, but if the engineer comes back and says, "The documentation's terrible. The SDK is horrific. I can't do this, or it's going to take too long," then that's going to be a problem.

So, all of those things play a factor from a marketing standpoint, even though it might be an engineer within Skyflow that's ultimately building the asset. There is a marketing side to it that needs to be aligned as well to make sure that people feel like, "Oh, these people are experts. They're thought leaders. They have something to teach me and they're speaking my language and I understand what they're trying to say." So, it comes down to sort of building campaigns based on what problems people care about, aligning sales and marketing around those and supporting the full customer buyer journey from awareness all the way down to decision making.

And we've made mistakes I think along the way. We've invested a lot in events. I think originally when we first started doing that, we went to some incorrect events where our buyer persona wasn't there, and we've gotten better over time and haven't made those mistakes. I think places like AWS re:Invents, Snowflake Summit, Databricks's AI and Data Conference, those are the types of events where our personas are there and they care, but they're trying to solve this problem and they understand the data needs of it and they get what we're doing.

Franco Corporale:

I have another question on this because obviously that's on the marketing side, but there are many instances in which the salesperson might not be a technical person, right? And I think even that might create some friction, especially at the initial part of the sales where the sales engineer is not involved yet. What is your philosophy, that you think salesperson should have a technical background to approach these opportunities?

Sean Falconer:

Every call that we do on the sales side has a sales engineer on it, even the first call. So, there's always a technical person on it. We do have several people within the sales organization that are fairly technical. They've come from one, they used to be a sales engineer and then moved into a pure sales role. There's other people who worked as data analysts in the parts, so they understand and can speak the language of data engineering, data analytics and particular use cases. So, there is some aspect of where we've been able to bring in people on the sales side that have some technical training.

But I think that there's, what we've seen successful is even on the sales side, even if you're not someone who's necessarily going to go and engineer this thing, they need to have some understanding of the data landscape and sort of how different parts of infrastructure play together, at a certain level. You need at least some base level technical understanding in order to connect with the audience and sell it, even if you have an SE there to help back you up with the more nitty-gritty details, when someone starts asking about what is the TPS of this API endpoint or something like that.

We wouldn't expect a salesperson to be able to necessarily answer that, but they need to be able to at least talk through the core use cases, why companies use us. And then eventually develop a sense for when they look at a company, what are the problems that they likely have that map to the things that we can help them solve.

Franco Corporale:

And one more question on this is you mentioned events, which is one of the channels that you used to find the right persona, the right context, obviously the right events. What other channels you see successful engaging these senior technical people and what channels did not work so well for you guys?

Sean Falconer:

So, we do see success from traditional digital ads, advertising channels like Google Ads and LinkedIn. Now, I think there, we typically capture maybe more of a mid-market company than necessarily an enterprise company, although there are ways of, as you build up more awareness, you can start to capture more of the enterprise. I think you need slightly different plays though to get to a lot of bigger companies.

And then also recently, investing in things like account-based marketing allows us to go up market to larger businesses. And that really comes down to really aligning sales and marketing and having a coordinated effort targeting specific types of businesses and core use cases, and then having tight messaging around how we can help them solve it and addressing the right persona and all that sort of stuff. So, those things have helped. I think that areas that have been less successful, one has been mistakes around maybe targeting sort of a pure healthcare company or healthcare audience where they're probably dealing with a lot of regulations, but they're not necessarily on the sort of technical side.

Whereas a digital health or health tech company that's like a mid-market or even a public security company that's more on the technical side where they're going to have a large investment in engineering, that's more core to us than something that's maybe traditional healthcare is one area. And then I think some of the experiments we've done around certain types of channels, like maybe directly advertising on Reddit or something like that, haven't really necessarily paid off because there, the audience that we're often reaching is more the application engineer where they might care about this to some degree, but it hasn't really... It's a less direct path to the right person than essentially some of the other channels that we're investing in. I think there's some value potentially in that, but it's also a good way to burn a lot of money that doesn't necessarily lead to pipeline or revenue.

Franco Corporale:

No, this is very interesting. And also understanding what you tried, and didn't work. Reddit is always something that comes up here and there, and I don't think a lot of people in B2B figured out how to use Reddit, in a profitable way, at least.

Sean Falconer:

I think the challenge is just refinement, right? I'm sure there's value if you can really figure out how do I get the right... What is the right subreddit where my buyer persona is predominantly hanging out and stuff like that. I just think it can be difficult to find that for certain types of businesses.

Franco Corporale:

Absolutely agree. I have one more question for you, Sean, more on the career side. What is that one thing you wish you knew at the beginning of your career, both in marketing but also in general in your entire career? What is the one thing you wish you knew?

Sean Falconer:

It's a good question. I'll give you two quick ones that kind of go together. But I think one is that I think knowing when to move on, when to call it on something has sometimes been a challenge for me. This was, I think about this particularly with my startup. I think that I tried to make it work a little bit longer than probably should have. I think I should have walked away a little bit earlier. And there's just been times when I've held onto a current situation too long because I convinced myself that I really needed to. But you only have so much time to invest and work in your life that you somewhat need to be a little bit brutal or honest with yourself about, "Okay, this isn't working. I could spend my time on something that maybe is higher value or is ready to move on."

And then the other thing which kind of goes, I think my problem with that is, it's hard for me sometimes to quit on things because I guess I can see it as some sort of personal weakness. And I think related to that is, this was certainly true in my early part of my career, was just being more open to mentorship and feedback. Think I was a little bit resistant. I wanted to kind of just do everything on my own and not necessarily need to ask for help. And I think over time I've realized that it isn't a sign of weakness or some sort of flaw in my abilities to seek help when you need it. And there's a tremendous amount of value in sourcing mentorship, and people have been there, done that, or have value to bring you and is a way to get better and continue to grow and educate yourself.

Franco Corporale:

Sean, it's been great chatting with you. I learned a lot today. So, thanks again for joining the Demand Generation Club.

Sean Falconer:

Yeah, thanks so much for having me.

CLOSING:

That's a wrap for today's episode of the Demand Generation Club Podcast. If you're curious about how we're landing enterprise deals and unlocking millions in recurring revenue using account-based marketing and integrated direct mail campaigns, check out our website, saasmql.com. That's S-A-A-S-M-Q-L.com. We share tons of content every week on tried and true strategic ABM initiatives that actually generate pipeline from enterprise accounts. Thanks for tuning in.