Podcast

The Critical Role the Developer Plays in Winning Enterprise Deals

In this episode, WorkOS CEO Michael Grinich and Flatfile CEO and David Boskovic discuss how to foster the developer champion, the critical role they play in winning enterprise deals and how building “hero features” changes the enterprise buying cycle.


Transcript

Michael Grinich (00:02):

Welcome to Crossing the Enterprise Chasm, a podcast about software startups and their journey moving upmarket to serving enterprise customers. I'm your host, Michael Grinich. I'm the founder of WorkOS, which is a platform that helps developers quickly shift common enterprise features like single sign-on. On this podcast, you'll hear directly from founders, product leaders, and early stage operators who have navigated building great products for enterprise customers. In every episode, you'll find strategies, tactics, and real world advice for ways to make your app enterprise ready and take your business to the next level.

Today I'm joined by David Boskovic, the founder and CEO of Flatfile. For those of you unfamiliar, Flatfile is a tool that makes it super easy for users to upload data to your app. They take care of all those messy bits around CSV importing and cleaning data, and this results in super fast onboarding for new customers. To date, Flatfile has processed over 25 billion records for both small companies and also some big ones, like Square and Spotify. I'm thrilled to have David here to chat about Flatfile and how they crossed the enterprise chasm. David, welcome to the podcast.

David Boskovic (01:10):

Thanks man.

Michael Grinich (01:12):

So let's get started. Take us back to when you started Flatfile. Describe the problem you came across and sort of how you got started solving this.

David Boskovic (01:19):

I've been building SaaS companies almost my entire adult life, and this was a problem that I experienced at every single one of them. I think engineers listening to this can empathize with the number of times you've had to build a CSV importer for one reason or another, whether that be internal tools, trying to move data around on your team or trying to get data from customers into the system. I remember before Flatfile I was at a company called Envoy. We had just signed one of our largest customers in the history of the business. The company had hundreds of offices around the world and Envoy is like a visitor management company. So people arrive at the front desk and they get to sign in at an iPad. Well, this company was sending in their front desk staff early every day around the world to manually type in visitors that were arriving that day, because we didn't have a good CSV import solution.

It's sort of like the enterprise problem, right? Enterprise customers are oftentimes coming from legacy systems. They aren't using another modern SaaS product with an API. They're coming from some system that was built 30 years ago and they're finally adopting this aspect of innovation, you’re the innovation, but they're coming from something that you can't easily get data from. This is where Flatfile comes in. This is a problem I've seen across every SaaS company I've worked at and built, and the problem Flatfile solves is getting enterprise data into your product. It's usually in the form of a flat file, hence the eponymous name of the company, a spreadsheet, a CSV file, some sort of database dump and getting that into the product quickly.

Michael Grinich (02:48):

What was Flatfile's first big customer? When did you guys kind of feel like we've made it and we're now starting to get pulled into early enterprise?

David Boskovic (02:57):

Interesting. It started as a side project. I wasn't sure if it was going to be a company. So we actually got our first enterprise customer before we even raised money or incorporated the business. Company was Blackbaud, a 3,000 employee nonprofit, Salesforce for nonprofits basically. And they had this problem. They needed to import donors and they had found the React Component and started installing it, and before we knew it we had gotten an enterprise customer. So obviously that was a great piece of evidence when we went to race our pre-seed round, but it was also indicative that this wast just a problem that small startups that hadn't yet built integrations needed. They're a large company, their biggest problem has always been, and you'll see this in a lot of large companies, getting data to the business. And Flatfile was able to solve that problem for them. So very early on, we realized this was going to be an enterprise type solution.

Michael Grinich (03:47):

Did you have an enterprise roadmap then from day one? I mean, thinking about that type of customer compared to smaller companies, a lot of smaller companies now adopted Flatfile since then. What was that roadmap and when did you decide to start focusing on it or not?

David Boskovic (04:00):

What's amazing with the problem that we're solving is that the problem is actually pretty universally similar between small companies and large companies. So a lot of our roadmap, actually is, very little about our roadmap that's uniquely enterprise. Now obviously, there are the things that are uniquely enterprise. Things like authentication, logging, monitoring, et cetera, and those are important, but early on, the problems were actually big enough for enterprise customers that they were willing to forgo almost all of that. And the urgency was very high, and so they would install, even in its sort of original form, install it in their product. That gave us time to start developing out that enterprise roadmap. We were solving something that was urgently important, that the customers were giving us a pass on some of that stuff. And as we've gone, our enterprise roadmap has actually evolved differently than I think most enterprise roadmaps do.

Instead of hammering away at the long tail of authentication, et cetera, we've used partner products that allow us to solve that, and we've even said focused on going deeper into data problems. We find that with enterprise customers where it really comes down to a buy decision, it's around the edge cases. Do you support an access database dump? Do you support this particular type of business workflow? We focused our sort of roadmap on what we call data experience, innovating around the data problems, all these unique and interesting problems that people have, and that's where we really sort of end up closing these enterprise deals.

It almost always comes down to one of these quirky things and we're like, "Yep, we have a platform, we have an API. You can actually solve that." One of the learnings that I consider sort of earned wisdom at this point with the team is the fact that enterprise deals for us are truly built almost always around one specific problem. Once you say, "Yes, we've got that." Everything else becomes like, hey, check the box to get the deal done. But that might be ‘Do you import a 20 million record file’? ‘Do you import a fixed width in this world?’ But once you solve that one thing, your advocates are going to take it the rest of the way.

Michael Grinich (05:55):

You mentioned that you guys have an API and I'm sure developers use the product and integrate it. Tell me more about who your main buyer is, and if it's not the developer, what's the difference between selling to those developers and non-developers?

David Boskovic (06:09):

We think very much of developers being the advocate in the process. We want developers to be able to use Flatfile in small-use cases for free. We don't want to monetize the developer. When we get to monetization, we want to solve a big enterprise problem, so we make it incredibly easy for developers to sign up, get started, and use us in small volume scenarios. As they get to a larger volume environment or a bigger problem, that's oftentimes with the developers actually advocating internally sharing it with their VP of Engineering or their VP of Product and trying to put this on the roadmap. For some of our largest deals from companies like Sage to companies like CBRE, this all started with an individual engineer that got it, was like, "Hey, I think this can be a really good solution for our business problem." So we really focused on go-to-market motion on bottoms up, marketing to the developer. We don't really actually have a monetization motion on developers, enterprise monetization motion and a developer sort of bottoms up go-to-market engine.

Michael Grinich (07:07):

Say more about that sales process, that kind of customer journey. I guess the advocates start using the product, kicking the tires, how does that evolve and turn into a deal? What does that look like through every step of the way? What's the team that's doing that?

David Boskovic (07:19):

Well, as we know, every enterprise deal is exactly the same, right?

Michael Grinich (07:25):

We wish. We wish.

David Boskovic (07:27):

There's a couple common traits there. One is that if you don't have a strong developer advocate, things are just going to take forever. At least for us. At some point the buyer is going to want sign off from the technical stakeholders. We like to start the deal with that already in place. Your technical stakeholders are advocating for Flatfile. They've done some sort of internal POC. They've played around with it and they said, "Hey, let's go buy this." So by the time we get to the business decision, there's already a lot of support internally. Then we get on to negotiating around usage, rollout, initial use cases, the various things that the enterprise is going to need around compliance, et cetera. And that's just a world of creative negotiation every single time. But we find that we really struggle to get the sort of momentum that we want when a developer hasn't already been part of that process pretty early on.

Michael Grinich (08:21):

How does the deal size change with those larger organizations? Does it scale up linearly? Is there a different method that you use to price for enterprise customers where I'm assuming you're driving in more value in those bigger environments?

David Boskovic (08:33):

We try to build our price and monetization around sort of value-added, which almost always comes down to a few key metrics that we are able to monitor. Either the amount of data that's being processed, the number of files that are being processed, or the number of people collaborating in sort of enterprise complex workflows. And that allows us to, pretty early on, align our estimates and pricing with the value to the customer. For enterprise companies, so what's interesting is we saw this early on when we had different pricing where you can end up in sort of an almost adversarial relationship in the negotiation where your pricing on the website is meaningfully lower and then you're going to the enterprise and you're being like, "Hey actually, we're going to ... You need to pay us $100,000 or more." There's not clear differentiation there in why, right?

It all comes down to the fact that supporting enterprise customer is incredibly expensive, but making that clear in your pricing model can be difficult early on. What we found is that we want to enter an enterprise conversation where our public pricing has already oriented the value. We generally are providing volume discounts at that point. You're coming in saying, "Hey, we're going to import a million files, but we don't want to pay a million dollars a month." And we will then provide an appropriate volume discount to that enterprise. And that's a much better place for our sales team to be in, where we're sort of making sure that the volume and the value we're providing is accurately presented in pricing. That has been a challenge for us in the iteration, is making sure that our public pricing is both palatable to the low end as well as properly orients our enterprise customers to the value. And there isn't sort of this having to shift from your left mind to your right mind when thinking about the pricing and the value for each customer.

Michael Grinich (10:10):

How should founders balance product-led growth with the pressure to monetize, or perhaps sell to enterprises sooner? Flatfile and many other companies have this bottom up motion and the focus there could just be kind of “win the hearts and minds across the industry, become the de facto solution”, versus starting to build a sales team actually focused on enterprise and focus on enterprise customers. Do you find yourself struggling to weigh these two sides against each other? Or if you were in the shoes of another founder, how would you approach it?

David Boskovic (10:39):

We made a bunch of mistakes here and some of our mistakes actually invented entire companies around that. So early on, we had a relatively accessible low end price point and then we sort of optimized around the mid-market, partially because we could grow really quickly there and we did. We saw enormous, just, amount of revenue growth across that segment. But by moving to that mid-market price point, we actually really sort of disenfranchised the low end and made it a lot harder for developers to get started for a period of time. And a number of companies popped up just to serve that low end of the market and we gave them reasonable oxygen to do that. That was quite an interesting learning, is that your pricing model can invent competitors if you do it wrong, then we've made a couple mistakes there. A highly aligned consumption price point is also highly aligned with enterprise.

It's actually the mid-market that is actually an interesting struggle there where the usage volume is not enough to warrant a high ACV customer, but you still need to monetize them reasonably well. So what we've actually done over time is we've focused more and more of our monetization on higher volume-use cases and we've really just allowed for the lower end of usage to be more or less a loss-leader. Now, historically, as a mid-market customer you might have to pay us $30,000-$40,000, now you're likely to pay us a meaningfully amount less than that because we've really focused our monetization much higher in the market. So letting go of developers is a dangerous thing to do. We saw that and we've adapted to that learning and we think that a developer promotion is incredibly compatible with enterprise and those two can come together really well to serve both the growth and the enterprise play.

The thing that I rushed into was trying to generate revenue and that forced that sort of mid-market play. Because it was what was accessible to us. We couldn't really run the enterprise motion yet. These are the deals that were on hand, the customers were willing to pay, but if I were to do this again, I would leave the developer motion, I would not try to monetize it heavily, and I would focus on more slowly building the enterprise motion, building maturity there, building growth there. I think both of those things would've come together faster for us. So I think that for us at least, the mid-market was a little bit of a detour.

Michael Grinich (12:47):

What do you focus on with that developer segment? What are you trying to achieve there? If it's not monetization, what is it that that team would focus on?

David Boskovic (12:55):

Usage. So we have three core metrics we track. Ideally you only have one that's really the value indicator, but as a data exchange platform, there's just so many different ways people use us. You may have a customer that synchronizes a billion-record file twice a month, and that's incredibly valuable to them. You also might have a customer that imports 10,000 100-record files, and that's really important to them. So to really sort of think about this in terms of what's the actual sort of value that each sort of segment of value delivers, has allowed us to align these core metrics around the types of ways people use the product.

So if you're in a high volume scenario, we have a metric that is aligned with you. If you're in a high data complexity scenario, we have a metric that aligns with you, and if you're in a high collaboration scenario, we have a metric that aligns with that use case. That means that it's actually beautiful because a lot of our customers are only impacted by one of these metrics. Just use the platform however you choose, the way that you choose, there'll be a metric that's aligning our value with that. And that's been an effort over some time to get to a good amount of alignment with our consumption metrics. And so our chart of success is like, Are these metrics moving up with these developers? Did they implement it in a way where there's now files being processed, data being processed, or collaboration being done?

Michael Grinich (14:09):

It sounds like those metrics would align with what you're selling on value later, for the enterprise customers. Is that what the sales team is looking at? I guess what I want to ask is that about that handoff between that self-serve developer or the bottom end of the market and when those things start to graduate, and when do you engage, what do you look at? How does that handoff for sales, maybe starting to interact with that leader, that customer?

David Boskovic (14:33):

Alluding to what I said earlier in this conversation, developers in enterprise deals are oftentimes the advocates, they've been tasked with evaluating or figuring out whether a solution is right or maybe they're the first one to find this and go, "Oh my god, this could save us a bunch of time." And there's an opportunity for them to present well to their team and show that they're innovating. So they might do like a POC by themselves or they might raise it to their managers who are thinking about this or the decision makers in the business. We find that in a lot of inbound, that's where the sales field starts. We start talking three months after an engineer has already begun the conversation effectively. By the time someone asks for a demo, gets into a sales process, we can track back usage that's been going on for quite a while. And with a little bit more analytics, we've seen, actually, people who've been busy in the platform for six months, a year, just playing around with it and eventually get into a sales deal.

A lot of our sales deals still come to us. Like we have of course our outbound motion is relatively nascent, so by the time an enterprise prospect enters the pipeline, oftentimes they've already reached that sort of decision making process, which is why I think the developers are relatively critical people. They are hard to sell to. If your developer experience, your documentation, and your onboarding process isn't something that they can get through, you've likely lost them sort of before you even had a conversation with them. And we have tried to have conversations with developers. I think everybody who has a developer product does, but developers are very unlikely to hop on a call and talk through their problems with you. They want the docs, they want to read through it, they want to build a POC, and once they've done that, then they're going to be advocates and excited. So I think those two things have to work together really well.

Michael Grinich (16:12):

Couple more questions for you before we wrap up. I wanted to go back in time. What do you wish you would've known before starting this journey? What surprised you or what advice would you maybe give to your past self?

David Boskovic (16:23):

The biggest learning is that nothing stands in for a good company. There were things we did relatively early on to accelerate growth that were incredibly good for the top line of the business, good for fundraising, et cetera. But at the end of the day, everything has to come back to: Is the customer getting value? Are they using it as expected? Do they understand it? And it's actually quite easy to generate a lot of revenue without those things being rock solid if you have a good sales team, which we did. But there were times I think where we missed a lot of good signal because we were growing so fast. And that's something that we've actually adjusted on over time where we've allowed for slower growth in order to learn more from our customers. Where when we don't see usage from a customer, even if they're paying us a lot of money, the type of usage that we want from a customer, even if they're paying us a lot of money, we really go and dig in with them now and try to understand why, what happened here?

And oftentimes we learn something, they're like, "Well, we switched to a different use case 'cause this initial use case didn't actually function like we thought." And that starts becoming incredibly instructive to the business because, hey, if you actually shoehorned us into a different use case, maybe we missed something about the product alignment here. And being able to be attentive to that, I think has been incredibly good for us over the last year, has shifted from necessarily wild growth to really understanding things. That's led to much higher value deals with customers over time by just slowing down a little bit, listening, watching for these key indicators and really paying attention and moving a little deeper than the top line growth that I think was rewarded for quite a while in SaaS.

Michael Grinich (18:06):

Last question for you. There's a lot of listeners of this podcast who are founders or maybe product leaders at early stage companies. What advice would you give them about building SaaS and their journey into the enterprise as they get started selling up market and they're looking at the opportunity in enterprise. Based on your journey, what advice would you share with them?

David Boskovic (18:26):

For us at least, really identifying that key absolute die-for pain point early on is what makes the difference in a win versus a loss. And we have, at times, not been able to meet that pain point. We've tried to redirect these deals to the many other pain points that the business has that we can serve right now, and that is a painful journey generally. We've found that focusing on that initial pain point, making sure that we qualify the deal in off of that and/or prioritize that feature so we can POC it to them, if that key thing that they're looking for is something that's solved for, everything else is a lot easier.

If you end up in a process where you're hammering at 15 different pain points trying to prove this one because the other one isn't as strong, you're trying to redirect different use cases, et cetera, everything just grinds to a halt. And we've had deals run a year long on stuff like that. But if you can get that sort of key thing, get people excited, get the leaders excited around it, we've found that a lot of the traditional things like legal negotiation. Everything else starts becoming a lot more negotiable if the business is like, "This key thing is going to be solved for by Flatfile." I didn't realize how critical it was in changing the behavior of enterprise buyers. Obviously, you want to align with value. Getting that hero feature changes the buying process a lot. So we focused a lot more on that and we found it meaningfully changes the enterprise buying cycle.

Michael Grinich (19:49):

Sounds simple, but in practice, I think it's really complicated to do too.

David Boskovic (19:52):

Yeah.

Michael Grinich (19:54):

Unfortunately, this is all the time we have. Thanks so much for joining us on the podcast.

David Boskovic (19:58):

Amazing. Thanks for having me.

Michael Grinich (20:05):

You just listened to Crossing the Enterprise Chasm, a podcast about software startups and their journey moving upmarket to serving enterprise customers. Want to learn more about becoming enterprise ready? The WorkOS blog is full of tons of articles and guides outlining best practices for adding features like single sign-on, SCIM provisioning, and more to your app. Also, make sure to subscribe to this podcast so you're first to hear about new episodes with more founders and product leads of fast-growing startups. I'm Michael Grinich, founder of WorkOS. Thanks so much for listening and see you next time.

This site uses cookies to improve your experience. Please accept the use of cookies on this site. You can review our cookie policy here and our privacy policy here. If you choose to refuse, functionality of this site will be limited.