Monetizing SaaS Episode 22 with Jen Ayers, ex-Crowdstrike & DNS Filter

Jen Ayers, former COO at CrowdStrike, reads market signals from Reddit and product usage, not financial reports. She warns that SaaS pricing mistakes like haphazard experiments and ignoring margins are common, and that engineering often becomes the bottleneck when companies try to support multiple billing models at once.
Chapters
Jen, it is so good to be here with you. I've gotten to know you over the last few years and oh man, we've talked about so many things, but you've had this really interesting and textured career. You've led teams in information security and ops across huge companies like GE, FireEye, CrowdStrike, startups like DNSFilter. You're now a COO of a private firm. You serve on various boards. Can you tell us about your career journey, how you got to now?
I always like think about this question when I'm asked and I always find it like, you know, funny. You know, how are you supposed to answer this question? Life is not linear, right? It's never linear. Like, you know, I didn't wake up one day and was like, I want to be CEO of a private firm. You know, kind of took a winding journey, I think, you know, starting out my early days in GE. And I, you know, was thinking about that this morning in relation to this to this webinar, it was like, you know, back in the day when I was at GE, it was a lot more linear. It was, you know, this sort of defined career path that you were pushed to pursue. And I'm not saying that in a negative way. I think it taught me a lot. I mean, coming out of the military, going into GE, into an environment that was almost equally as structured as the military, and you just move through the thing. But it wasn't until I got out of GE that I learned that there was like this whole other world, right? You know, in GE, working internally in internal information security, you know, your world was GE. It was the, you know, as I always like say, nation of GE. And, you know, each individual business unit was its own country with its own rules and its own requirements. And then moving to Mandiant after that, you know, became this huge world of, Not necessarily a bunch of GEs in the concept of conglomerate, but a bunch of companies, you know, a bunch of financial companies, a bunch of healthcare companies, a bunch of media companies, a bunch of, you know, and so found that to be just really, really fascinating, you know, working in the vendor space. And I think that is kind of what set my career going forward was I loved working for, you know, working in the vendor space. I loved working in multiple, working with multiple companies. How I ended up here in terms of being a CEO of a private firm and doing, you know, doing board advisory work is probably, it's really just the same path, right? I mean, I love working with, you know, these smaller startup companies. I love being a part of the early phases in the early days of, you know, just helping, you know, helping to listen and helping to apply, you know, my knowledge and my experience where applicable. And learning, I think, on the flip side of that about, you know, early-stage startups and how hard it is. It's fundamentally very, very hard to build a company, but I really enjoy working with the companies that I do, like, you know, Dubzero, like GigaSheet, for example, you know, just, and also Schematic, we're, you know, just watching all of you grow in terms of, you know, creating these fantastic products that fit into fit into a market and solve particular problems.
So good. You know, one thing that I'm— you've seen so much, like across such a broad surface area in terms of the companies that you've advised, operated within. When you zoom out and when you think about building a software company today, and when you think about the founders that you advise and their executive teams, Are there big market inflections or big market forces that you yourself are particularly interested in? Like, you, you think about them a lot?
You know, I'm not sort of the type of investor that, you know, goes and reads 700, you know, different financial reports when I wake up in the morning. Um, because what I've learned, especially over the last couple of years, is that The market, I think, and market analysis is a good data point for the past. Um, but it is an impossible data point to predict the future. Um, what I'm finding more interesting that drives, you know, we'll call it market in the broad term, not necessarily just the financial, but in what I'm finding more fascinating is market behavior in the terms of purchasing, um, how companies are purchasing, watching how different companies are succeeding or different companies are failing, trying to ascertain how, you know, environment is impacting, you know, impacting success of a company in a specific, in a specific market, for example. And I know that sounds really broad and very, very fluffy, very, very fluffy, but I don't really know how to articulate, not being a total expert in the market field, for lack of a better term. I'm taking these different data points and just kind of like, okay, if you are a development, you know, a company who's specializing in development operations, what is it looking like with other companies in that particular startup? Space, you know, what am I hearing, you know, what am I hearing on social in terms of the buying game? What am I reading in Reddit of all places? Actually, Reddit is a very good place for good information. What am I reading in Reddit, you know, in terms of how people are feeling about stuff? And I think that's kind of been pretty good in being able to kind of predict a little bit, a little tiny bit about how I'm helping companies think about what their next future state is, needs to be, or maybe some product, you know, how they need to be thinking about their product and how they need to be thinking about marketing. Marketing their product. Again, not a marketing expert. My superpower is in operations and getting stuff done. But, you know, how does that apply? Are we going to shift the dynamic a little bit and put more into SEO instead of, you know, instead of, you know, hiring, you know, additional 3 engineering contracts to, you know, contractors to finish a particular product as an example. I wish I had like, you know, some experienced broad answer of, yeah, I go on a Bloomberg terminal and read these 25 things every day and that sets my day. But I'm certainly not Warren Buffett. I still have a job and I still I have to work for the next X many years until I can retire. So for me, it's just really about, it's a lot about ascertaining, reading data and kind of feeling where things are.
There is so much change though, in the way that SaaS companies monetize. I mean, that's, there's just massive flux there. So I want to come back to that. I think that's really important to talk about. One thing that you and I have talked a lot about in the past is how teams build trust, especially how engineering and product build trust. Often, you know, their companies are founded with an engineering founder, and then eventually you bring in product and product is abstracted out of engineering. What techniques have you seen be really successful, or have you found to be personally useful in establishing trust between product and engineering as companies start to, start to find product market fit and start to grow quickly?
Deliver on what you say you're going to do. Period. Hands down. That simple. Yeah, don't game it, don't push it. You know, if there's a problem, bring up the problem before it becomes, you know, a bigger issue. Don't bury it, don't lie about it, you know, don't try and brush it off, but just deliver on what you say you're going to do. If you say you're going to deliver this in Q1, deliver it in Q1, you know. Don't, don't, you know, and I get it, there's variables, there's things that come into play, you know. There might be a market change, there might be a prospect who, you know, causes you to push a little bit on your roadmap, there might be a requirement, FedRAMP requirement or something like that that comes up and inevitably changes, you know, the dynamic of your delivery times. But as a whole, you know, especially for early stage companies, if you say you're going to do it, do it.
I love it. When you start, let's go back to monetization. And, you know, I think that this is true of companies that I've been in over the last few years, I would assume is true for companies that you've been in. But but tell me where it might be not true. It seems like modern B2B SaaS companies are having to support a lot of complexity in the way they monetize. And I think that complexity is coming from 3 sort of big things. One is the need to support different go-to-market motions, like product-led, like sales-led, like channel-led, the need to support different billing models. It's not just seat-based anymore. There could be usage-based, there could be hybrid. And if you're successful, the need to support the evolution of your product, multiple products, add-ons, modules. Does that seem like, is that the right framing in your experience to think about the complexity that B2B SaaS companies are having to support from a monetization perspective? Or would you think about it differently?
No, I do think that's right. And I think that, you know, in the context of, you know, D, all of the above, I think every B2B SaaS company is going to experience one or more of those situations that you just outlined in different ways and at different stages. I think the one that you're slightly missing as well is customer customization. So if you kind of— but it's, I guess, more like maybe a little bit of a subset of, you know, the product piece of it and the product add-on piece of it, which is, you know, Customer A, who's in the financial industry, wants these three particular things that are not included in the bundle, you know, but they're also not separated out as an add-on. And Customer B in the healthcare industry wants these 5 different things. Like, you know, how flexible can you be in the context of an à la carte model, which also does take some business analysis. Is an à la carte model the right structure for your, your particular business? You know, does it limit your ability to upsell? Does it limit your ability to expand? So there's always lots of variables and dynamics that go into that. But flexibility, I think, is one thing that in many cases is lacking. The ability to be that flexible, the ability to do those kinds of experiments, the ability to really kind of, again, I'm saying customization with a light hand here in the sense of being able to close that deal, right?
What makes it so hard for companies to achieve that type of flexibility in your experience?
I think it's a combination of the three that you just outlined in a way. Sales, product, and engineering, to be honest with you. And I'm not talking about necessarily the relationship between those three organizations. I'm talking about the capabilities of being able to actually execute. On a consolidated product vision, not in the terms of delivering the product, but being able to execute on, you know, we'll call it Bundle A or Bundle B or Bundle C. It's very challenging, you know, especially, you know, the bigger a company gets because more variables you introduce, whether, you know, especially if you're selling across multiple segments. So you've like your SMB and then your small enterprise, your large enterprise, your whale enterprise, and You know, all of that, you know, all those are little worlds within their own. So how do you, you know, how do you keep that moving? You know, do you just dictate this is what our product is, this is all our products that we're going to be, and this is what we're going to sell it at and we're not moving regardless of who that person is? No, no company is ever successful doing that. It'd be easier. But you know, how do you, you know, how when you're, you know, SMB, you know, a large subset of SMBs, how do they customize You know, for, for clients that don't want the 50,000 bells and whistles and they want to pay a reasonable price, you know, how do you turn that off in the product? How does engineering put in the gates to be able to do that? I mean, you and I both know that where you end up at the end of the day in most scenarios is engineering needing to build a system that ultimately does those pivots. And even that system isn't flexible. You want to do a pricing change? 9 months of engineering work. Right? You wanna do a bundle adjustment, 9 months of engineering work. And I'm, I'm being very, you know, sarcastic when I say that. Some companies have the advantage of being able to do that much faster, but it always ends up going back to an engineering team who has to just jump through these insane hurdles just to be able to do things. Just build a module, attach it to a thing, and then you can change that middleware, for lack of a better term, and it doesn't impact you know, in terms of, you know, who, who gets what, right? Engineering can build module A, module B, module C, module D, and you let the middleware be able to handle, you know, A, B, and C being part of bundle 1 or A, B, and C being part of 2 or feature flags, I guess, is probably as we've always called it. It's always ended up in engineering's domain to both build and manage. And I think it's just, you know, in some cases unnecessary overhead that detracts from them being able to focus on developing great product. It detracts the product team from being able to focus on the needs of their customers, and it detracts the sales team of being able to close deals faster.
Yeah. It's like, there's this just like really ridiculous trade-off. I have to consider if I'm an engineer supporting some monetization initiative that is in the best interest of the business and the customer or shipping new value. Which do I pick? That's a trade-off that should exist.
Exactly. Exactly. It's not an easy problem to solve, and it's not as simple as buy this thing and it'll magically happen. Because each and every business will have a different structure in the sense of how their product currently works today, how they've enabled those bundles currently today, what their sales motion currently is, what their deal desk is able to approve, and what their customers are ultimately looking for. But being able to do that, you know, put something in like Schematic early enough allows you to be able to iterate and build much faster, right? You've, you've already got something that's connected to your billing system. Again, it's always about mapping. It's always about thinking about the impact of things from, you know, from a ripple effect, you know, if I make this tweak here, how does it impact that? You know, nobody's ever getting away from that, but taking the burden off of an engineering team to have to manage all of that on behalf of the business, you know, to me is, is a no-brainer.
Yeah. Yeah. So you've seen pricing and packaging done, I imagine, really well and really poorly, uh, throughout your career. And I imagine it's been both on like the strategy side of pricing and packaging, as well as the ops and implementation and systems side. Can you just describe what are the 3 or 4 most kind of consistent mistakes that you've seen companies make as it relates to pricing and packaging?
You know, I think that's a very tough question because I hadn't been so connected to that until recently with my time with DNSFilter and later on, you know, later in my career at CrowdStrike. So I wasn't necessarily involved in the ultimate decision-making of the pricing and packaging. But I think from my perspective, from an operations side, so if I leave out the nuances that go into pricing and packaging and instead focus on what it's going to cost to produce said product or produce said service and ultimately what your margin needs to be, I think some of the bigger mistakes I've seen is the throw spaghetti at the wall. Well, you know, try, try it for $6 a thing, see what happens. And if that doesn't work, let's go back to the $3 a thing. You know, I think experimentation needs to be thought out very, very carefully before a decision is made. I think once you make a decision, you have to remember that it's like, you know, it's like social media. You post something, it's there forever. And people aren't going to forget that you offered it at $3, you know, a year ago. And now you're, you're asking for $6. Like, I think it's just really a lot of thought process has to go, a lot more thought process has to go into that. And when you do make that decision, you got to remember you can't take it back. That's probably one of the biggest mistakes I've seen. But outside of that, like I said, I haven't really been as heavily involved in that particular space in my previous roles.
Using DNSFilter and maybe other companies like CrowdStrike as examples, um, what do you think companies can do, especially early stage companies, founders and their early executive teams? What do you think that they can do in the pursuit of getting better at pricing, packaging, monetization? What can they bring into their organizations to continuously get a little bit better every quarter?
I don't know. It's really hard to answer at an early stage company because you're missing all of the key data, right? So if you don't have any customers today, it's an impossible question to answer. That's kind of where you get back into that sort of experimentation phase. One of the better companies I've actually seen or had an opportunity to participate in is GigaSheet in terms of how quickly they're able to analyze and review the data that comes back to them in order to make decisions on pricing and packaging. Really good about identifying what customers are using and what customers aren't using. And not necessarily putting the engineering effort into things that people aren't using, but instead expanding on things that people are. And I've found found that just really fascinating, their use of data and analytics to drive decision-making going forward like that. You know, DNSFilter was a little bit very different, you know, type of business model. You know, when we were there, we switched from usage-based to user-based, you know, still ended up with, you still ended up with that split, some usage-based and some user-based, because there's, you know, customers that you're just not going, that it just doesn't make sense for users for. Let's like an example, you know, I don't know anymore what DNSFilter setup is, one that comes to the top of my head for usage versus users, education, right? You're just never going to get a good count of how many students are particularly going to use it, and they ebb and they flow, right, depending on registration count or summertime or seasonality, you know, spring break or whatever. So I think, you know, it's always been, it's just for me been very interesting to watch and see, you know, what seems to work and what doesn't work. And what I've learned is, is there's no one size fits all.
Really good. Um, this has been so much fun. I have a couple closing questions for you. My first is, what's been the experience that's been most influential or formative for you professionally?
Wow, deep thought question as a closing question.
Deep thoughts with Jen Ayres, right?
Hmm, like, you know, just Just in general, like what, what makes me go?
Well, is there an experience that just had a really big impact on your career or the way you think about work and business?
Oh, there's so many though. I'm kind of old now. Yeah. Trying to think about like one particular one. I think probably one of the bigger ones was like, as I said earlier, um, when I left GE and went to Mandiant and discovered this whole world. This whole world that wasn't specifically just GE. I mean, that was hugely influential. I can attribute some of that not just to the team that I worked with, but Kevin Mandia as well, who helped me, not directly, but indirectly, helped me understand that you don't necessarily have to fit into a box to be successful, that you can go about and do things the way, you know, the way you want to do them, the way that makes you happy to do them, not necessarily because somebody else told you you needed to do it in order to get to the next level. So this is probably one of the more big ones. And then the second one would be, you know, the, the, the person I worked for at CrowdStrike, um, you know, developing a very unique partnership, um, you know, that involved— we'll call it just, you know, just pure, pure, pure absolute trust. You know, having an opportunity to work for somebody who trusted me so much, and then I trusted him, you know, equally as much to be able to be successful. You know, he's a very much a big visionary. I'm very good at getting stuff done, and it just made it, you know, made it a very equitable partnership in terms of, you know, both of us being very successful.
It's really great. Where can people learn more about the companies that you're helping? DevZero, Gigasheet?
Um, you know, I think they're all on my LinkedIn profile actually, so you can certainly take a look there. If they're not, then I've been remiss in updating my LinkedIn. Not a big social person.
Awesome. Um, thank you so much for doing this. It's been a blast.
Thank you, Fynn Glover.
More from Fynn

Schematic at Operators Guild Demo Day 2026: How to bill for AI credits without a surprise bill

Should you move to usage-based pricing because AI is compressing your margins?

Why raising prices every year backfires (a pricing leader on the Mastercard quota model)







