Shaping Product for Enterprise

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 ship 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 Paul St. John, the former VP of Worldwide Sales at GitHub. It's probably safe to assume that our listeners have heard of GitHub, but for anyone unfamiliar, GitHub is the largest social coding platform in the world with nearly 100 million registered users at this point, and 4 million organizations across the globe. Over 90% of the Fortune 100 uses GitHub. And in 2022, they surpassed a billion dollars in annual revenue. I'm thrilled to have Paul here to chat about the early days of GitHub and how they crossed the enterprise chasm. Paul, welcome to the podcast.

‍

Paul St. John (01:10):

Thanks for having me. Great to be here.

‍

Michael Grinich (01:12):

So I thought a good place to start this conversation would be going back in time. Take us back to when you joined GitHub. Where was the company at that point in terms of the product and sales and the customers?

‍

Paul St. John (01:24):

Yeah. Yeah. Great. So when I joined GitHub, we had a really great name in the open source world. Every developer knew about us. We had loads of developers using us for open source projects. But not a lot of people knew that we had an enterprise product. We kind of didn't have an enterprise product. We had a teams product, which teams at enterprises could use. And in a funny way, we would let people sign up with any email address and any name. So later, when I had been at GitHub for a year or two, I started to realize there were lots of people at big enterprises using GitHub in an unauthorized way with a teams account. But their email was ‘mickeysplayhouse.com’ and so it was really hard to find out who was using it. So we didn't have an enterprise product, but we had a name out there, a virgin control tool that people learned to really love. And we were associated, of course, with open source code.

‍

Michael Grinich (02:17):

Yeah, I remember those days. GitHub was sort of the hottest name in town. At least in the Bay Area. You'd see stickers on people's laptops and people wearing shirts around. It was almost like a cult-like following at that point.

‍

Paul St. John (02:27):

Stickers were a big deal. We'd bring thousands to events and they were gone within hours. That was a big thing that we did was we had a lot of lure around who we were and Octocat and ... Mona was her name. And so there was a lot to be said for the community itself and how that was built up. And it was a very vibrant and strong community, which certainly helped us from a name and brand recognition.

‍

Michael Grinich (02:49):

How did that go to market team or the team that started thinking about commercial focus identify those people that were using it? Because it clearly ... The GitHub product kind of found its way into different teams and different companies. I'm sure it's at some of the biggest organizations in the world. It's the best way to write code. How did you go after those? How did you identify them?

‍

Paul St. John (03:06):

Well, we couldn't. So our terms of service wouldn't allow us to. First off, most people signed up, if they signed up with a real email address, we couldn't use it. And if they had real names, we couldn't use it. If there was ... If it was signed up with any old Yahoo address, and it was paul1234@yahoo.com, that's unusable. And of course, we still couldn't use it. We couldn't contact any of these people.

We could run analysis on what the code looked like. We could figure out that this was code from XYZ company and we could call that company and tell them, "Your code is on unsecured open source servers that have no enterprise security around it." And they would say, "That's impossible." And then we'd share with them and they'd go, "How did you get this?" And I'd tell them, "That's how we got it." And they'd say, "Do you know who the people are?" And I'd say, "I don't." But we would work with them and we'd let the people know that worked at this company that we were going to get an enterprise product for them in place. That was a very long process to figure this out.

So we had no real product led growth per se, in the sense of a freemium product that people would use that they loved, that they would then bring to work as a pro user. You know these folks, they bring something to work, helps them with their workflow, and the person sitting next to them says, "What is that?" And then they tell them and they download it and they start to play with it and use it at work. And before you know it, you have a bunch of pro users and you want to sell an enterprise contract. We didn't have that motion. I wish we had that motion.

But we had something like it, because we could get a meeting at pretty much any company would want to speak with us because they were really interested in what open source code had to offer the company. And they were using it and they knew we had it and they wanted to get closer with us. So we could get the meeting. We'd get there and we'd say, "Great, well would you be interested in the enterprise product?" And they were like, "You have one? We had no idea." And when I first joined, we didn't have a real enterprise product. We had something that we built that was on prem; it could handle 1,000, maybe 2,000 users maximum. And it had no enterprise features, no audit, no single sign on, no multi-user management. Nothing that would help a bank, for instance, to comply with regulation. Anybody could push code to master. And so we had to build all this in.

And our in was always R&D. And the way we went to market was we would figure out who was the most likely to invite us in, want to talk about GitHub, want to learn about enterprise and the features that we would like ... That we have now, we'd like to build. And then we would work real close with product and engineering to start to build that product. We could always make a sale because R&D would want to use it for certain projects. And then we would work with that customer and put in a contract in place where they could add users for, let's say, one quarter. And we wouldn't back bill them, we'd just forward bill them.

And because our product was developing, we would always offer a really good discount in the beginning, which when I first joined GitHub, they didn't like that at all. They're like, "No, this is an amazing product. We could never discount this." But it really wasn't. We had to build it. And it took a couple years to build a solid wonderful product. Of course, we lowered a discount on the renewals. But for us, we had this quasi PLG, everybody knew us and we had to go in and do land and expand. And I really think land and expand was the best thing that happened at GitHub because it was so easy to land and so easy to expand.

‍

Michael Grinich (06:25):

Say more about that, the land and expand. Kind of break that apart for GitHub. Because I think what you said about GitHub not being the typical PLG motion like Airtable or Asana or something like that is super interesting and I think pretty common in the world of developer tools. How did GitHub navigate that land and expand? What did it look like in the first motion and then fast forward and maybe trying to get a wall to wall in an organization?

‍

Paul St. John (06:47):

Yeah, for sure. So first off, getting a large contract in place, a huge contract in place, was very difficult for two reasons. One, we were new and people had their projects ongoing in other version control systems. If there was a team that was ready to go, let's say 100 developers working on something, then we could get the deal done in a relatively short period of time. But we couldn't say to a company, "Please sign an enterprise deal with us." Because they're like, "Are you kidding me? We have ongoing projects on different tools, so we're just never going to do it that way." So it lent itself to a land and expand anyway.

Now, the best thing I could tell you that I learned during this whole process, and it's a learning I've had for the last 25 years, is if you spend time with a customer and you learn how they're using their tool today and the things that goes into their flow and how they want to expedite that and how they want to actually get better at building product and shipping product, you can learn a lot about horizontal ways. You could say social coding helps every company. That's a horizontal thing. But then you could say for retail specifically, if you learn about the company and you learn about the market and how they work, then you develop a playbook around a specific vertical and a specific customer. So when you walk in, you're really well prepared to be a consultant in a sense. To say, "Hey listen, Target or Home Depot or whomever, we know that living at Target, you live in a bubble. You live in the bubble of Target." And that's fine. That's where most people live when they work in a big organization. And they don't see a lot of other ways of coding or other ways of working. So a sales team can come in and say ... They don't share secrets of course, but they could say, "Hey listen, the best retail shops in the world act like ‘this’."

And a perfect example was when we were working with a big retailer, probably one of the biggest retailers in the world. And they were in the middle of the country. And when we went to them and said, "We can share with you some of the best ways of working." And they said, "No, thank you. We don't want to work like that. We've been developing code this way for 20 years. We have our Friday meetings. We have our Monday meetings. We all sit down, we have donuts before, so we're never going to work async. We're never going to work online like you do at GitHub. It's just never going to happen."

And so that company decided to set up a lab group in the Bay Area, and that lab group started to win business from the business. So in other words, the business said, "Hey listen, we're going to launch a new website. We need this ready in a month." Well, the middle of the country said, "We can get that ready in six months. We'll never get it ready by Christmas." But the labs group that was using GitHub said, "We think we can get that ready in maybe three weeks, four weeks." So they started to actually win business from headquarters. And lo and behold, the labs group started hiring people. And the middle of the country started saying, "Well, we don't need as many people anymore because you're not able to satisfy the business."

And so we learned a lot about working with that big company about what would go into retail. And then that meant, what should we put in the product? And that also meant, how should the sales team start to pitch GitHub to a retail company? So our lands became faster and the expands also became faster. And I think if you focus on the expansion, you learn a lot. Because you could probably get a company to buy the first bit, especially if it's a reasonable price, let's say under $10K. Okay, our average selling price was $16,000, but we expanded 800% within two to three years. So if you focus on the expand, you learn why a company would spend more money with you. You learn the value of it.

We had this one occasion where there was an automobile manufacturer in Germany, very strict, very hierarchical. They didn't want to do social coding. We said, "Open the repositories. Share code. It'll help you. Developers can just reuse code, they'll help each other with bugs." All the things that social coding gives you. They didn't want to do it. So we convinced them for one quarter to try it with two divisions. And they did.

We came back and we said, "So did you like it?" And they said, "We sure did." And we said, "See? Social coding." And they said, "Well, yeah. But you know what? We've been trying to hire ML and AI developers for years. Nobody wants to come to a car company. And we can't pay as much as Facebook or Google, so we were terrified. Soon as we open the repositories, these young kids, they came in at night; 19, 20, 21, 22. Hierarchical, they start in the bottom. They start in some group that's not really making software that's really important right now. Of course it's important, but it's not like we need these developers. Then we realized we had talent in-house. And so we just moved them. We said, 'You know what? You're not doing speedometers anymore. You're coming over right now.' And we found out we had talent and these people were really skilled." So all of a sudden, guess what GitHub had? Guess what my sales team had? We had a new thing to talk to customers about that we weren't even thinking about.

So this idea of landing at a company, working with them and understanding how to get value from it, and then reusing those stories and sharing that with other companies. The good thing about having a sales team is they talk to everybody. So they can talk to everybody inside your company, like product and engineering and finance and the CEO's office, and they can say, "Here's what really is happening in the market. So let's try to build a product like that. Let's try to make people understand that this is how you use it the best way." And then you can go to companies that don't have this external influence and come and share these things with them and they're like, "Gosh, this is great. This is a new way to work. We really appreciate it." So that's the way I think you best land and expand. You get the people first in that can make that process, make those playbooks, and then you hire people that can execute those playbooks. So there are the unicorn salespeople, and then you hire the people that are just real new and they just can execute like heck.

‍

Michael Grinich (12:23):

As you're talking about this land and expand, the thing you were mentioning earlier about the open source movement, it's kind of how GitHub got into these organizations and early days of really propelling open source and allowing people to collaborate, allowing people to use open source code in their own work. But what you're describing here around sort of the discovery of those use cases almost feels like a transformation of how these companies are operating. Like the retailer you mentioned, the automotive company, they're just building code and working in totally different ways. And you're describing kind of like a discovery process of teasing that out, kind of pulling that thread out of those companies. Is that how you see maybe the role of sales in early companies? Who should be responsible for doing that? Because the GitHub product didn't fundamentally change, but it was kind of framing it for organizations to change how they operate.

‍

Paul St. John (13:11):

100%. So the GitHub product for the enterprise market only changed in the sense that we added lots of features to let enterprises collaborate as opposed to open source projects collaborate. What does that mean? Well, you got to validate who you are. Like let's say you got to sign in with your extra level of security around single sign-on or in a very sensitive environment, you actually have to prove that you are that developer that's going to push code to a US military installation. It's sort of like gates you got to put on that make it an enterprise product.

But you asked the question about who's really involved at the early stages of a startup to help tease out those use cases at a customer. And I think three main groups. And this is what happened at GitHub. And I believe this is true. When I consult companies, I think this is true. I think it's the sales team who gets to see all these customers and the partners of these customers. It's the engineering team that's going to be receptive to what the sales team comes back with. So the sales team's got to be really good at coming back with clear, understandable and non-biased information for the developers.

What do I mean by that? Salesperson comes back and says, "I think we should build this." Developer says, "You just want to close a deal." That's what's going to happen. But if a salesperson can come back and say, "Listen, we're seeing this trend happen in this vertical, or across many verticals. And I think this trend is a big one. And here's what I'm finding. And here's my data. And here's my research. And here's my customer testimonials." Then all of a sudden the developers are like, "Ah, this actually makes a lot of sense." So if you do your homework, you do your grit, you work hard, you can bring this to the company.

And I think ... So it's engineering, it's product management, and it's sales. And it's the CEO's job to really make this a fundamental priority every week. Because the idea of product-market fit never ends. It just never ends. And I think you got to keep refining that and you have to keep thinking about what is happening in the market and how people are changing the way that they work. And I do believe it's ... The best companies in the world are ... It's about workflow. You have this flow. And so we had to tease out for companies, like, "If you work like this, it's not the best way to work."

And we implemented this thing called challenger sales. You can look it up, it's ... Google "challenger sale" and you'll find it. It's challenging the customer, but in a good way. Meaning, "Hey, here's what we have found are seven of the best ways to code." And, "Are you doing this?" And a lot of times ... If you do it in the right way, a lot of times they're like, "That's really interesting. Well, we do a couple but we don't do all." And then you sort of work with them. "Okay, well let's walk through what it would look like if you did all these things. What if you stopped the meetings on Friday? What if you let people just code? What if they could code whenever they wanted? What if they could share code? What would that look like?" So they would start to think about changing the way they fundamentally worked. And then they would realize that this could be a benefit.

And of course, not just hearing from us. But one of the best things we ever did in regards to teasing out how customers could change or helping them to discover new ways of working is we would hold these brown bag sessions. Let's take an example. In New York, we'd get somebody from, let's say, Capital One. They always kind of pushed the envelope on new tech. And they were always forward thinking. And we had amazing relationships with them. And we would invite them to come and just talk about what they're doing. And we'd invite three or four other folks from banks to come. And it wasn't just GitHub talking about GitHub, it was so-and-so talking about what they were doing. And they were proud of their work. And that was really impactful, because then they're like, "Oh my gosh, we should think about working like this. It sounds great." And of course, we'd sponsor this, but we'd give that information or we'd foster the environment for that information to be exchanged. And then of course, we're there to help the customers go forward. But that was a really great way to help people understand new ways of working.

‍

Michael Grinich (17:03):

It sounds like when selling these enterprise or just large customers, it really had nothing to do with things like SSO. That's just kind of checkbox features. It's entirely about this transformation about how they're working. It's not about pull requests, it's not about encryption, it's about how their organization behaves. You're almost selling like a behavioral change.

‍

Paul St. John (17:21):

Yeah. So here's what I think. I think you're right, SSOs checked the box. You know what else has checked the box? And a lot of people think, "I have this great ROI, therefore I can sell my thing. It's no problem." ROIs are almost like checking the box. If you don't have a good ROI, then they're not going to spend money with you. If you come and you say, "I can make you money." That's like okay. That's cool. That's great. "I can save you money." Okay. What changes things is changing the status quo.

So the company that I told you about, the retail shop, they were suffering, they were under threat. You can read about it, it's all public. They were not digitally savvy, so to speak. They are now, but back then, in the times that I was working at GitHub in the early days, they were kind of threatened by online retail because they had also brick and mortar shops, right? So they were an example of a customer that said, "I'm willing to change the status quo because I need to change the status quo of how I work because I'm losing money." And this is sort of ... The life and death are the easy ones to change status quo.

So you could go to a customer. I did, I lost a huge deal when I went to the customer. It was a bank and the main person that was in charge of all IT granted me five minutes and basically said, "I don't really want to do this. I'm doing this as a favor. And I will not change my mind. I'm going to stay with what I have." And I said, "I'm not trying to talk you out of it." Because his basic premise was, "Why would I change 85,000 developers when I believe I get 50% benefit? Why would I do that?" And so changing the status quo is the thing. It's like, why would somebody change? Why would they go and argue or get legal involved, get finance involved, make these big documents they need to make to get a deal done? They don't want to do any of that.

So what this person told me was, "GitHub is like a tool. And I could replace a tool every three, four years. Tools don't really matter to me. But platforms matter to me." And I said, "What do you want GitHub to be? Like if you could say this." This is probably 2015, 2016. He goes, "More of a platform. More of like how do you get code in, how do you get different tools to work with the code and the developers." That's kind of the genesis of when we started thinking about GitHub Actions, and we started thinking about how that would work. So there's a reason we did all this. And the person told me, "If you made this a platform, I'd move like that." So it's all about finding what would change the status quo.

And sometimes you'd run into people that are ... They're just not ready. A really good sales manager will help the reps figure out, "Don't work that deal anymore. You're never going to close that person. Just walk away and go to the next one." And so we were about market share. So we wanted to quickly get in, start the extension. And if someone wasn't willing to move, we'd have to move quickly onto the next customer. So we had our own criteria for when we would walk. And the funny part is after I left, I had the French team call me, and they mentioned this one customer that we were selling to for five years, and they go, "You won't believe it, but they finally bought." And I'm like, "I knew they would. I mean, eventually they're going to come around." If you become the status quo, then all of a sudden you're the default. But then you got to start worrying about making new products and everything like that.

‍

Michael Grinich (20:31):

Yeah. The stuff around GitHub Actions, just making GitHub programmable I think is a pretty big sea change in that mindset around it becoming a platform. I had one last question I wanted to ask you before we wrap up. A lot of people listening to this are probably founders focused more on the technical side or the product side. They focus on building the best product possible and having that pull them into the enterprise eventually. What advice or insight might you give them about how to think about building a sales team or the sales motion early on? Maybe especially for those founders that are a little bit sales averse or they feel like it could damage the culture. If you were to give them advice in that early days, what would you say?

‍

Paul St. John (21:09):

Sure. Can I just rephrase this question like this, like why would I have a sales team?

‍

Michael Grinich (21:13):

Yeah.

‍

Paul St. John (21:13):

Because I've run into so many founders that go, "I really don't want to have a sales team. Why should I?" So I think it's ... First, I think the sales team brings information that you wouldn't readily get back into your organization in a way that ... As we spoke about before, that talks about what's happening in the market. What are the trends happening at these customers? What are they looking for? And how can your product best meet those market demands, product-market fit? I don't think you get enough information if you don't have a sales team on how to make product-market fit. So that's number one, making your product better than you think it can be. You might think it's the most amazing thing in the world, but a lot of the market is like, "I can't use it. I simply can't use it." And that'd be a shame.

The second thing is, if you're doing product led growth only ... And I've run into many, many companies that feel like, "I'm just going to let this go." And it works great. It's amazing. I've run into one company that had 30 million users and 50 million in revenue. And that's great. They had no sales team whatsoever, really. But I talked to the founder for a while and we started to explore the idea of who's actually selling your product in these organizations. Because it's going to happen in drips and drops, but no one's actually spending time with a customer to find out all these new ways of how people are actually using the product to make their company better. And no one's sharing that with other customers.

And if that could be done and you had a team of people dedicated to actually making contracts ... Because if you were to sell to a bunch of developers, they'll tell their friends, but they're not going to spend all day long trying to sell to the business. They're just not. And they're not going to share these stories. They're not going to know what Target does and Walmart does and Home Depot does. They're not going to know. So there's no way for them to actually try to expand it inside their own organization. Nor do they have time to, they have their own jobs. So having a dedicated team that actually goes around and does this, it's quite impactful if you want to increase revenue in a dramatic way. And GitHub, we grew tremendously over a five-year period of time, but the most revenue came in the last three years when we knew what the product should look like and we had down the whole discussion around why it's useful and how you could best code and be a development shop. So I think that's the second reason.

And I think the third reason is a sales team… It goes back to the whole idea, they talk to everybody. A really good sales team, supported by a CEO and an engineering team and a product team, they can really help the company internally also be proud about what's happening. I mean, we used to invite developers to sit with the customers. We'd invite product to sit with the customers. We'd invite customers back to the organization to talk about how wonderful it is to have this. And it provided real context for them to have this sort of emotional attachment to what's happening out in the field. And in the beginning, it was hard at GitHub. They were very shy about sales. But at the end they were like, "Can we get five more customers to come and speak on Friday? Because the last time we did that, I mean, everybody was just super happy on Monday." So I think those are some of the reasons to have a sales team. They talk to everybody and they're dedicated to making sure that customers get the most out of the product, and it increases revenue. Of course, it's about increasing revenue.

‍

Michael Grinich (24:30):

It feels like when you get those three things working in harmony, product and engineering and sales, it's kind of like three legs of the stool. Then you really have the foundation to grow on top of.

‍

Paul St. John (24:39):

Totally. And I won't forget marketing for the product led growth, because the beautiful thing is you can get PLG, market the heck out of that, get the communities building, and that sales can follow up and really discuss with these companies how to make it grow.

‍

Michael Grinich (24:51):

This has been a really fantastic conversation. Thanks again so much for joining us today.

‍

Paul St. John (24:55):

Thanks, Michael. It was great.

‍

Michael Grinich (25:02):

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.

‍