Working with startups (with Jessica Lin and Jonathan Lehr)

Episode 211 · Tue, 26 Nov 2019 14:00:00 +0100 · 27:59 · SRT · archive.org · all Tanzu Talk

0:00

Welcome to another episode of the Cloud Native in 15 Minutes podcast. The goal of this podcast is simple, to explain some complex but increasingly important and even strategic technologies in about the time it takes for a coffee break or a short commute or whatever it is you do in 15, 20, or in this case, maybe closer to 30 minutes. So because this episode runs a little longer than the 15 minutes in the title, I'm going to be brief. I'm Derek Harris from Pivotal, and the topic today is how to engage with enterprise startups. So if you're a large organization thinking, hey, I would like to buy software from the startup, or I'm thinking about buying software from the startup versus my legacy vendor, or maybe buying this cloud service from a startup, my guests today are going to give you some advice on how to go about doing that. And they are Jonathan Lair and Jessica Lin, the co-founders and general partners of an enterprise startup-based venture capital firm called Workbench. Also, if you are listening to this podcast on Apple and could be so inclined to leave a review, that would be very helpful. We enjoy them. Without further ado, please listen to John and Jessica from Workbench talking about engaging with enterprise startups. Okay, so John and Jessica, can you guys quick give listeners a brief description of what Workbench does and then, you know, like your quick 30-second personal history so people have a sense of where you're coming from? For sure. Happy to kick off, and thanks for having us. So Workbench is an enterprise VC fund. Our team is fully based in New York City, but we do invest across the country. And our mission is to rethink enterprise investment by leveraging our past lives in corporate IT and the 52 of the Force 500 that are fully headquartered here in New York City. So just by way of quick background, this is John speaking. And I used to work in IT at Morgan Stanley in a pretty cool team. It was called the Office of the CIO. And what we were tasked with doing was really helping figure out how to best use our $4 billion IT budget and engage the startup community. And that could be through identifying new revenue opportunities, cost efficiencies, or just net

2:02

new capabilities that working with the startup community could bring us. So on a daily basis, we would meet hundreds of startups a year, all the big name VCs, all with that goal of figuring out who has technology that isn't just with bank tech, but also aligns to a pain point internally. And this is Jessica here. So prior to co-founding Workbench with John, was at Cisco Systems, working on an internal team on agile software transformation. So got to work with some of the high performing teams at Cisco and document those best practices on agile software transformation. And prior to that, worked with student startups at Harvard University and led a design fellowship program for students in Cape Town, South Africa. And so, so much of what we talk about at Workbench is really being at the intersection of what we call suits and hoodies. And that's really core to the DNA of our VC fund. All right, cool. So, yeah, so let's get into it. I think, I think as someone who's spent time working inside startups, the one thing I've noticed is like, does that enterprise customers are kind of the holy grail, you know, the bigger, the, the bigger the customer, the, the more validation, the more, you know, the more marketing you can do around it, all these different things. But if we, if we, if we turn the tables and we say, you know, like, so, so that's, but and there's, I think a lot of advice on how startups think about engaging with enterprises. But what I want to talk about here, and I would love to get your opinions on this, you know, like just from the, at a high level, I mean, if you're, if I'm an enterprise thinking of buying technology from a startup or engaging with the startup, how do I, you know, how do I begin thinking about that, right? What should be on my radar in terms of ways to get that process started? For sure. So when we think about the corporate community that we actually wrote a post a few months ago called Dear Enterprise Startups, Not All Customer Intros Are Equal. And what we try to do is actually break down the sophistication levels between someone like

4:02

a Wall Street bank, who tends to be really at the high end of the spectrum. And then as you go down, there's regional banks and insurance companies go down further. You've got healthcare, pharma, and the media space, which do have pretty sophisticated processes of working with the startup community. And then if we go down even further on the list, things like telco, retail, manufacturing, those tend to have the least sophistication and a very difficult time actually engaging with the startup communities. So let's maybe start with some of the best practices that you have seen from companies that actually do are good at engaging with startups. So if I think back even to my personal experience at Morgan Stanley, as I mentioned, we had a team dedicated to this search and scout function. But in fairness, a lot of the Fortune 500 can't afford such a team and they aren't going to engage as frequently. So as a best practice, just even having a view of like, hey, what are some of our initiatives for the year and what are places where the existing large vendor landscape can actually meet those needs? And what is perhaps one or two key initiatives that we're going to look to do? So that could be something over the past couple of years of like, hey, we want to bring in a chatbot for customer success. Or we want to try, we have treasure troves of data and we want to try to do some sort of machine learning for better personalization. Or even something like, hey, we're getting tons of cyber attacks recently and we need to boost our internal kind of safety posture. And even just getting a sense of like, hey, the whole company is going to align around these goals and as a starting point actually makes a difference. Because where we've seen a lot of issues historically is different pockets of folks chasing after different companies that either inbound to them or they outreach to, but without a process and a desire and really a need to do so, at the best case, it leads to a quick no. But at the worst case, it could lead to a lot of wasted cycles, both for individuals at an

6:02

organization as well as the startup itself. Are there things that these companies should think about too? I think the big fear sometimes is around product maturity or resources around support or commitment. I mean, like what is the expectation do you think that smart enterprises have as they go in and think about buying something from a startup? Yeah. So not to make this a total Morgan Stanley talk, but one of the ways that we viewed things internally was across really a couple of quadrants or four quadrants rather with these axes of number one is the risk of the startup itself. And number two is the risk of the service internally. So at the end of the day, most very early stage companies, series A and B, would be in that high risk category. But the key is, can you map that to a service or a use case internally where the hypothetical question of if they disappear Monday, what happens? You're actually okay. Because you'd be surprised how many times, even in, let's use an example of like the database world. Back in the day when we were looking at columnar databases and in-memory databases when they were kind of a new thing, we had a whole team that was set up cross-functionally with different expertise to meet with some of the leading startups at the time. And this was a big undertaking. So what we figured out was what are use cases, whether it was like a fixed income team or another small pocket of the firm where, look, we're not going to replace out IBM DB2 databases. We're not going to get rid of Oracle databases. They're not going away and no one's going to touch them. But for these net new capabilities, could we actually generate revenue if we brought in a new analytic database that could compress the data, enable cost savings, and frankly, just give us faster calculations? So part of it is really just as a starting point, figuring out where can you actually explore in a safe, so to speak, way? I mean, I think it makes a lot of sense, in fact, because you're right. I remember someone years ago who had a SaaS startup in the analytic space, and I remember the discussion being, hey, we're getting these big customers, but they want a code escrow

8:04

or something, which was a thing. And they were like, well, this is a SaaS product. Like there's no, everything is tied so tightly together. It was a wholly new concept to them, right? And you know, you got to think like... The joke with that also is, because we used to sometimes have people ask that internal at Morgan, and it's like, hey, put it in Iron Mountain. And the joke is no one internally at Morgan could have ever actually supported that code base. And number two, that startup, a lot of times they didn't even go out of business, which was kind of the trigger. A lot of times you would have these zombie companies. So we kind of did away with that whole kind of notion of a code escrow for the most part. I guess the question back to you, John, do you think that's a litmus test, right? If a large enterprise is asking for a code escrow, do you think that's a litmus for how sophisticated they are? And is that a warning sign for some emerging startups like, hey, maybe this large customer is not great to work with? Yeah, that's a key point, I think, which is it has to start from the top, as we said, with these initiatives. But then there needs to be buying across legal, procurement, security, because the worst thing that we've seen is companies that are dying. And let's play off that chatbot example again, that say, hey, we have a use case, we want to share some data that's actually not sensitive, maybe it's support tickets. And then they get stuck where they'll start engaging the startup community, they've gathered their requirements, and they'll meet with these companies and throw a 50-page kind of POC agreement in front of them. Or they'll put crazy, onerous security architecture reviews, or things, as Jess is saying, like this code escrow. So one of the things that companies could do best is actually learn from some of these earlier adopters and more sophisticated buyers around, what does procurement look like? Can we meet internally with our legal teams and come up with a way abridged version of an early test and then ultimately support contract for this particular use case? And if you're buying from IBM, of course, that procurement cycle is made for them, right? But if you're an emerging startup, that's not going to be the best fit.

10:04

And that's where, quite frankly, we spend all of our time at Workbench, is coaching our startups to say, hey, what is actually non-negotiable in a procurement, but what are other things that, quite frankly, you need to give in on, whether it's an MSA or warranty of the product or indemnification, right? There's a lot of education. I think an opportunity for both the suit and the hoodie to meet in the middle in order to be able to accelerate the procurement process. You mentioned this chatbot option, right? And the chatbot seems like a, you know, generally speaking, a low risk sort of place to engage. Are there certain areas or layers where it makes more sense, whether that's applications via infrastructure or tooling, you know, developer tooling versus databases, like in terms of this is probably a good startup place to look at a startup versus, you know, this is a place where we want to, we need to be dealing with a... Yeah, so a lot of times that does start at the application layer, just because if you think about the quadrant concept that we discussed, a lot of times, if you're going to match the high risk of the startup, anything touching infra, not anything, but most things touching infra are going to be hires themselves. So it kind of needs a more mature company. But what's been in, thinking back to the early days of SaaS, that is where Salesforce and even Workday came into play because the joke was, you can throw our own data on the cloud, you could throw an employee data on the cloud, but we never wanted to put our own customer data on the cloud. So that's where something like Workday, even when I was leaving Morgan in 2012, 2013, we were dealing with a huge limitation of that. What I would say is the whole cloud native ecosystem has made it easier in some areas, paired with the rise of an open source in the Forge 500, to do some of this more bottoms up, so to speak, adoption, both from the startup side. And if you think about it as an end user in the Forge 500 company, but I would say that the hype level of Peep developers being able to just spin up whatever they want in the cloud native space is a little bit overhyped from reality when you think about what it actually

12:06

takes and the amount of systems that most tools would have to integrate with, that you're going to get some security person looking over your shoulder or touching you and saying, or tapping you on the shoulder and saying, hey, I see what you're doing and you're not allowed to do this. Is that a matter of, do you think that's a matter of the open source nature of the stuff and that it is theoretically, you know, it's there, it's available, you can, you have the access to do it if you want, if you want to start spinning stuff up? Or is it a nature of, you know, just some of the complexity generally? I mean, if everything in the cloud native space was closed source, it would still be a very complex ecosystem, right? And, and you open up a lot of avenues, I think for, for vulnerabilities. Yeah. Part, a part of it is the number of internal stakeholders that have to touch a given product between security teams, infrastructure teams, even sometimes like touching identity if it has to integrate with Active Directory or create some on-ramp into the cloud and versions of that. So that is where historically it has been tough. I mean, I even think to the early days of MongoDB and a lot of products that people know as open source winners, when we would evaluate them while I was still at the bank, it really did have an enterprise sales counterpart where people were really coming in, pitching that mid-level executive. So it is important to note, it's not about the CIO, he or she making these decisions, but it's about those people a couple rungs below at that ED level or even MD that have that pain point. They're looking to solve them. And to tie it back into your point, which is how do the enterprises themselves navigate this, I think that it all comes down to what is our mission for the year, what is the goal and then how can we arm our teams to, part of it is even just have the bandwidth and the prioritization because it sounds very simple to say, hey, let's look at a new business intelligence vendor or we need a new database. But you have all these people grinding at a big company and they're nine to five. And to be candid, the less sexy industry, the less they're getting paid, the less they may be enjoying their job, the more old school their peer group may be in terms of the tech

14:09

that's adopted and their viewpoint on it. So you're really asking someone to do something differently and usually on top of their day job. And it comes down to what's the motivation. And if someone knows that the CEO and the CIO say that this is our goal and by doing this project, it ties into a bigger vision, they'll be more than willing for the hungry person that wants to get promoted, put in that extra effort. But if not, it's going to be kind of a bad road for everybody. Is there anything to, you know, the one thing we've seen, I think, that's really spun up the past couple of years, this idea of cloud providers versus startups, especially in the open source space, right? And, you know, it's this notion of, you know, well, should I buy from the startup, which might have created this project or has the creators on its team and theoretically is going to open up more opportunities and, you know, give us more, you know, there's more competition in the market, et cetera, et cetera. Or do I buy from like Amazon Web Services, which I know is going to be there in 10 years and, and I already spend, you know, X number of millions of dollars a year on, I mean, have you seen that discussion? How do you think about that notion in terms of just what should the marketplace for enterprise software look like? And do you benefit from buying from a startup in the sense that you're, you're expanding that marketplace theoretically? Yeah, that's a great question. Something we talk about probably every day with Fortune 500s. In fact, our September New York enterprise tech meetup had a whole panel all around cloud adoption. And when it comes down to it, you know, for the most part in the Fortune 500, we are hearing that the cloud is still safer from some of these larger vendors like Microsoft and AWS, because they can put in these large enterprise agreements in place for the service that they need at the, for the most part of the startups are still a little bit too risky for them. Well, how we define startup, I think shifts, right? I mean, I've been, you know, you sometimes are at a, like, like a 15 person company and that's definitely a startup, but sometimes you're at a company that's, you know, maybe five

16:10

years old and, but it has hundreds of people and has raised whatever, a hundred million dollars. It's a huge valuation. Is that still a startup? I'm not sure where that level is. Scale up startup. Well, from the enterprise perspective, I think the question becomes, what is their revenue? What sort of customers in their peer group are using it? Because there's companies that have raised hundreds of millions of dollars. Let's look at Docker, for instance, but not to beat a dead horse, but like the enterprise adoption there was pretty limited at the end of the day. And that's why when they were looking at what's the actual use case internally, what are we going to get benefit from it? The, the large enterprise ultimately, I guess, and the world moved to Kubernetes, it just wasn't aligned there. Docker is a unique, I think it's supremely unique and maybe like, is like the epitome of, of, of, of some of the risks of the current state of enterprise IT. But, but, but even to share then a few other examples, I mean, part of my old job was to help with the financial viability assessments of the companies. And it was actually a lot of fun because what that entailed was getting on the phone with CEOs and CFOs of all of the startups that we do, did business with, which is actually a huge number. And reviewing their P&L, but also beyond just the pure numbers. Because again, most of them were early understanding things like who are your top 10 customers? What is the concentration risk associated with that revenue? Help us understand the background of your management team. Help us understand your net burn and then also your VCs. And does it look like they would fund you in the future? How much cash do you have left in the bank? And of course, a lot of startups are naturally reticent to share this information, but we actually did have a Chinese wall where it wasn't going to the purchase of the house for the users. So they ultimately would share in an effort to try to win that Morgan Stanley contract. But the things that you would see in terms of some of these high flying companies and candidly how small the revenue was, a lot of these companies that you see hyped in the news are pretty early.

18:11

So the trick becomes who actually will get the benefit from that use case that they're pitching so much so that they wouldn't use the AWS offering of it or the Microsoft managed service offering. And when a startup can actually solve a problem that they can bypass some of these big vendors, you know that you can be onto something huge. Have you seen notable success stories within your, let's say within your portfolio, maybe of companies, I guess I should say of enterprise customers who've engaged with, you know, a startup in a particular space and seen like really notable results and that, you know, like it was a really a net win for both sides. Yeah. So there's a ton. We have a company, SoCure, it's in the financial services space for identity verification. And they use online social data and some algorithms they developed to basically help with at new account opening, make sure that someone is actually a real account and it helps increase acceptance rates and decrease fraud. So you're touching money and bottom line from both sides of that equation. And we actually put them in touch with Bank of America back when they were just series A funded. And B of A had a ton of different use cases they were exploring internally, but decided to just start with one several years ago. The beauty is, is that, and we can say this publicly, they spoke at a conference that we co-hosted with B of A back in May, and they're on multiple use cases now where SoCure is offering, it's a simple API integration that fits into their existing workflow, has been helping them dramatically change the acceptance rate and actually reduce fraud. And again, that's been just money that comes to the bank's bottom line. It sounds like the start small is the, is probably one of the key things, right? I mean, obviously like, like, don't think, yeah, I'm looking at the startup and this is going to, like you said, replace our Oracle databases tomorrow. Right. But it's not, it sounds like the answer is what's this one thing we really think is strategically valuable. And we probably, you know, there's probably, there may not be a legacy vendor that that's

20:11

even doing that. Right. Is that, is that kind of the, the ideal starting point? Yeah. So it's funny because we've seen actually both work successfully. One, which is, Hey, there's a legacy vendor. Maybe we've been with them for years. They're up for renewal and they're not meeting our needs. And we're ready to understand what the startup landscape looks like, because maybe there's been a 10 X improvement in, in efficiency and lower cost, et cetera. And sometimes there are those net new use cases that just never existed. Like back when containers first came out and all the orchestration stuff related to it. But you, you, it really is company specific because someone like a Morgan or a Goldman or a B of A could make a big bet because they know how to properly evaluate again, the internal mechanisms for, for control, as well as that, the startup. We have seen that even happen in pharma too. So we have a company algorithmia that focuses on model deployment and with one pharma that we can't share the name publicly, they made a huge bet on empowering basically all their data scientists on this single platform for model deployment. And then they've built up an internal sort of a model marketplace internally for people to collaborate on. That was a pretty new, it was a brand new offering and a pretty big bet, but because they, it was a pain point that they felt they collectively got behind it and built a relationship with the company so that they were willing to, to kind of give it a shot. We commented on this implicitly, but I want to do it expressly. If I may, so, cause this is one thing I've noticed too, like, yes, there are huge companies and they have, they're sophisticated in many ways. And then there are these midsize enterprises that, that might be, you know, many years or several years behind, you know, where we see the cutting edge. Um, well, if I'm that kind of company, what's the, you know, what's the path to, to, to engaging with the startup? If I'm, you know, I have to digitally transform, I have to do all these things, right? Every buzzword. And then what's the, what's the move? Yeah. And so there's a whole spectrum, right? And, uh, we've advised our companies and John blogged about this.

22:11

How do you find the ones that are, uh, much more sophisticated, much more early adopting. And the reality is that there's also, uh, you know, people behind that curve. And the question is with those folks, what tends to happen is they have these internal innovation teams and the challenge is if they're not tied to actual business challenges or be used, it can suck a lot of time out of startups. Um, and they end up, uh, in these cycles with them doing demos, showing them their product. Um, and the end of the day doesn't end to actually anything meaningful, whether it's a POC or pilot. Um, and for startups, you know, every day is burn. And so that can be really, really painful and actually harmful to the startups. And so for, uh, these large companies who are trying to, you know, make their KPIs, whether it's how many new startups they've met with, they don't realize that it can be really, really hurtful to start up. So we actually advise most companies to stay away from quote unquote innovation teams and as soon as possible, get into the line of business. And to just play off that. So one of the things that we do recommend when you're saying, Hey, what should you do? So don't necessarily jump to an innovation team. The thing that we recommend actually is talk to your peer group. And there's some structured ways to do this. And candidly, we offer a corporate round table series for areas like machine learning, cloud native infrastructure, future work in cybersecurity is we bring all our corporate exec friends and it's, we, we joke, it's like group therapy because they can talk in the machine learning one about everything from hiring data science talent in today's environment to again, like deploying models and new, new modes for ETL and whatnot. And in that process, they're in a safe, so to speak, because it's only corporate peers and us as the XIT person in the room, but there's no vendors, there's no consultants. And we think that there's a need for more safe spaces like that because there's in every area of a, of a corporate kind of IT stack, they're going to be a laggard in some, maybe there'll

24:14

be a leader in another one. And for them to be able to actually learn from their peers, keep that conversation ongoing on some cadence. I mean, we do these quarterly, it helps them actually tie in the pain points, not just tech, but also the people, the process related things to make sure that they're bit by bit actually driving change in the organization, hopefully tied to that big picture goal. The last thing I'll just add, we heard about this from a financial institution is that even within large companies, there are pockets where people and business units will be able to engage and others won't, right? And so this one financial institution has shared with us how they had a matrix, right, of people who have the ability to buy from a startup, but won't, and vice versa, right? People who want to help buy from a startup, but don't have the internal power and capital to actually push that through. And so to be able to see that type of a matrix was a real eye opener and just goes to show that even within large enterprises and corporates, they recognize there are people who can actually help startups move things forward or who unfortunately can't. And then finally, I just, you know, I'm curious, are there spaces where you, if you were, where you think it makes next to no sense to actually meaningfully look at a startup company? Like, I mean, if I were being frank today, if I were a large enterprise and I was looking at, you know, getting into like the infrastructure as a service space, right? There was a while where it looked like startups maybe could make a dent and I'm not sure that really happened. But are there other spaces where it's like, or maybe that's the one where it's like, yeah, it's just, it's not worth it. Or, you know, it's very hard to imagine the startup really having a competitive offering in that area. I mean, I think you hit the nail on the head with some of the stuff going on in the cloud infrastructure world. And in order for someone to consider a startup, they'd have to have a very different and nuanced answer for why you should work together. I would say there's a lot of big vendor hype to flip that question a bit. So, and look, this is kind of beating a dead horse at this point, but the whole IBM Watson

26:16

thing four or five years ago, a lot of people were saying, hey, we already have these engagements with, with IBM. Should we look at that to them for our MLAI needs? And people learned that that wasn't the solution. So I do think it's just about being thoughtful and saying, hey, in this category, is there a leader in this space like an AWS or an Audra, is there, are they meeting our need? Do we have existing relationships? And should we just work with them and focus potentially maybe riskier efforts or more time to unpack potential efficiency gains in another sector? Because at the end of the day, it's all resources. The one thing startups forget a lot is that even if their product is free to evaluate and use for a period of time, it takes people and people have limited capacity in a big enterprise to, to explore and do stuff more than their regular day job. Great. Well, that's a great place to end it. Thank you so much, John and Jessica. And there you have it. I hope you learned something. For more information about Workbench, you can visit them online at work-bench.com. Again, that's work-bench.com. They also have a great enterprise newsletter you can subscribe to there. And for more information about Pivotal and our broad suite of products for building and managing and running cloud-native applications, as well as transforming how you build software, check out Pivotal.io. And if you like this podcast and want to keep up with all things digital transformation, including blog posts, guides, and some other stuff, you can visit the home of this podcast, Intersect, at Pivotal.io slash Intersect. And again, leave a review on Apple. We appreciate it. Thank you. Thank you.

Tanzu Talk · 🍕 Get more pizza.