… five years ago, really smart people with PhDs in machine learning or AI could get funded. The next stage was you needed to be those people, but you also need to have access to proprietary data to do your training. And now you need to have those two things. But you also need to have customer insight or access to real customer traction.
An interview with Paul McNabb, a Managing Partner at Episode 1 Ventures, a $81M seed stage fund that invests in software companies.
Investments: Zoopla (IPO at ca.$1B valuation), betfair (IPO at ca.$1.5B valuation), Shazam (acquired by Apple for $400M), and other companies.
Peter Zhegin:
Welcome, everyone, my name is Peter Zhegin, and today I'm talking with Paul McNabb, a managing partner at Episode 1 Ventures, a seed stage fund that invests in software companies, and is headquartered in London.
Paul McNabb:
It's a pleasure to be here. Thank you.
Peter Zhegin:
Awesome. As a kick off, can you please introduce yourself and maybe tell us more about Episode 1?
Paul McNabb:
My name is Paul McNabb, I've got a background that includes several stints as a VC, as an entrepreneur, and also working for large corporates. I started my career in London, working for Accenture, moved to the US, worked for a couple of smaller companies, and then started a couple of my own businesses with a mixed bag of success. Some did quite well, some, not so much. On the back of that I worked for the first time in venture capital in California, moved back to Europe, worked for Cisco for a long time in lots of different roles on a global basis. And then when I left Cisco, I joined Episode 1, which is a seed stage investor here in London, investing in UK-based software startups.
Peter Zhegin:
Can you give us a couple of examples from your portfolio of data science related startups?
Paul McNabb:
Yeah, I mean, I think data science sounds is really super interesting. Because it's one of those things, where it kind of went from being the kind of the really kind of incredibly sexy technology everyone's excited about that was almost enough in it of itself to create the startup, all the way through now, where it's something that actually everybody needs to think about and needs to be part of the mission of almost any business, because everybody's generating these huge data trails.

I think almost all of our businesses now are thinking about data science, about AI. But a few that we have focused on that are really kind of sort of super deep and super construct and that in space. Including one Peter that you and I worked on most recently together. It is a company called QuestDB, which is building a next generation time series database. Time series data, you know, whether it be from sort of internet or mobile events, whether it be from IoT, financial trades, there's all sorts of things that are creating these huge trails of data that are sort of time sequence and time dependent. And there have been a number of players that offer databases to support that kind of data, which has a particular set of structures and sort of things that people want to do with that data ,manipulations and applications for that data that are quite repetitive.

The company that we did the investment for has got some combination of incredibly fast technology, very close to the sort of physical infrastructure on the machine, but also with a very easy to understand and accessible interface. So that's, that's one example.

Another example is a company called Auquan, the company that bridges data science into financial markets problems. The founder was a quant for a big hedge fund. And what they're doing is they're sort of turning market issues such as what's the correlation between commodity prices, weather and stock markets in different countries, those combinatorial kinds of problems that people look at and then turn them into math problems that data scientists respond to through a big community that they built.

Another example is a company that we've invested in fairly recently called Sano that is looking at bioinformatics data. They're pooling the results of genetic disease information across all sorts of providers like 23 and me, and create kind of macro data sets and then some analysing those for patterns and then sort of commercialising that that kind of data, making it available to much bigger trials. It has definitely been a theme. It's things that we have invested in at the infrastructure level, the data science as a service level. But I also think it's increasingly something as I said, that we see sort of being folded into the border portfolio.
Where do investors see opportunities for data science startup? What are investors' expectations?
Peter Zhegin:
I'm curious... if we understand that there are a lot of opportunities, what could be your opinion, a framework, or a hint for a founder to understand that a pet project that he or she leads might become a startup? What could be the flags for someone to understand that my pet project actually might become something bigger?
Paul McNabb:
Yeah, so it's a really good question. And a very complicated question, I think. Certainly at the infrastructure level, there is always need for new tools and new platforms to help make data science more accessible, to provide tools towards practitioners to make services and software like QuestDB, that we were talking about the time series database, available. And as we think about the demand side of this, digital economy, I mean, the number of applications, the size of the data streams adjust exponentially. And so the volume of transactions that needs to get performed is just increasing at an exponential rate. So the infrastructure that needs to be there to support that is just going to need to continue to grow and transform and provide productivity.

We live in a world that from an IT point of view has been dominated in recent times by the success of the public cloud. And that has been a fantastic boon to data science and AI practitioners around the world. But we increasingly know that sort of centralised and one computing architecture paradigms aren't gonna work for every kind of problem.

There are all sorts of problems that need to be done on the edge, for which latency is a big issue, for which sort of standardised x86 compute architecture isn't really going to scale isn't really going to work. There's just a tonne and tonne of work that still needs to be done in that space. And there's a lot of investor interest at the moment in those areas.

I think as you start to go further up the stack, and you start to think more about the application side of it, the nature of the problem changes. The ways I think about this, as you think about any kind of industry, it's generating these huge data streams. And it's fair to say these days, that data about things is actually more interesting than things themselves. There's all sorts of secondary and derivative things that you can do with data that is generated about an industrial process or about any kind of a business that can actually give you insight and accelerate decision making. The data about activity, the data about things becomes more valuable in some ways than the things themselves.

If you are working as a data scientist or AI practitioner, you've identified new ways to collapse a data stream or to analyse something in real time, that can be very exciting. I Whereas a few years ago, if you just had that sort of expertise, and you have that technical breakthrough, that would have been enough to get investor interest.

I think now investors actually now want to see a little bit more of a full service, they want to see that you understand the customer, they want to see that you have perhaps some access to some proprietary datasets, or whatever it is that you can use to train or to practice on. So it's not just a theoretical problem, you can prove that there is some practical application that you can bring to the startup and that there's some knowledge of the end customer problem that can be solved.

I always used to think that five years ago, you know, really, really smart people with PhDs in machine learning or AI could get funded. The next stage was you needed to be those people, but you also need to have access to proprietary data to do your training. And now you need to have those two things. But you also need to have customer insight or access to real customer traction. Because a lot of people invested in science projects and haven't had the outcomes that they want.

In between those two things, so we've talked about infrastructure, and then we've talked about the application layer, but in between those two things, is a universe of opportunities that have some of the characteristics of both. We have this whole progress of the auto ml space... We know that the good news for all of you that that are listening to this is that you have a skill set that is in massive demand. And we know that the world needs many, many more of you [data scientists], then there are a of you, and so that's probably going to stay that way for a while.

So there's been a tremendous amount of interest in how to scale the productivity of that cohort of people, because not every company can afford to go out and hire an ex-Google Data Science person or ML person for a quarter of a million a year, or whatever it costs. So there's all sorts of stuff in the middle of think about making the jobs of either, ordinary researchers or accountants or folks like that more scalable through the application of data science, creating auto-ML or auto-data science tools, and libraries and paradigms. There's a world of stuff in between, I think that offers industry and application focused libraries and toolsets that can be can be super productive.
Signals that an investor looks for: 'we don't expect you to have the answers, we don't expect you to have any revenue… But we do expect you to have some insight into the business
Peter Zhegin:
You mentioned the evolution of the lens, the way how investors look at data science startups. From purely research-driven startups, to access to data, and the right now it also includes some customer validation. What kind of milestones, what kind of indicators, do you expect to see when you work with a startup at the seed stage?
Paul McNabb:
I'll just clarify perhaps our position, our criteria, as a first instance. We're typically the first institution to invest, we normally would write a check if something like a million pounds. In a total funding round, that could be, a million, a million and a half, perhaps up to two million, something like that. And before that, there's perhaps been £300K, £500K [invested], maybe some grant funding, depending on the nature of the business, you often see that in very technical businesses, that there have been a couple of grants. Perhaps some University funding and things of that nature. Maybe a year, a couple of years into the evolution of this concept before someone like us invest.

At the stage at which we invest, the business is still very much in the future. So what we will look at is the signals. We will look a lot on the founding team, the quality of the team, the mix of team. Will look a lot in the case of the business like this at the technical foundation, who is the real technical visionary? How differentiated is that person, if we will do references around that and try and really ascertain, do the folks that have worked with them, in some cases of academic supervisors, or sometimes co-workers occasionally, it will be enterprises, or folks that they know, from elsewhere. What they think about them, or they like to work with how do they scale as an engineering lead, and all those kinds of good things. But it's a lot about understanding who the team is.

A part of what you want to see from the team is that they have a very clear idea about what the problem is that they're solving. I mean, the only thing we know about a company at this stage is that everything's going to change. People are going to come with spreadsheets and PowerPoints and tell you, 'do this, we'll a change the world, we're going to be 5 million pound company in a year', and all these other kinds of good things. And of course, none of that stuff is ever going to play out at this stage because there are just too many unknowns.

What is important, is that the team that you're going to back has got a great mix of skills to address the problem. They're going to deal with the hurdles and the challenges as they come along. They're going to run through a brick wall, if that's what needs to be done to solve a problem.

And the first instance of that, in the case of something like a data science or machine learning kind of startup is that they've got a sensible grasp about what the problem is that they're solving. Ie. who is the customer, what is the pain point that the customer has, and that they're not in the business of pushing some sort of core technology that they think ought to be really super useful into the world, and that customer adoption will just happen.

There's a famous anecdote that that's been attributed to Marc Andreessen, which says that if you're backing consumer businesses, breakout consumer businesses, you invest in your two folks who are doing something completely bonkers that you don't understand at all.

And if you're, if you're investing in a B2B space, you want to invest in a team that knows the business, has done it before. And it's preferably done it together. Because enterprise is very different from from consumer. Consumers either adopt something or they don't. With enterprises, you've got to figure out the rhythm of adoption that will fit into a purchasing pattern that enterprises have. People in enterprises are a part of a very complex mechanism. And they typically can't make one off decisions, and they won't make decisions just in the back of something being cool, they'll make a decision based upon how it fits into their workflow, or how it addresses a milestone, or a KPI that they are responsible for.

So one of the things that we're really looking for is... we don't expect you to have the answers, we don't expect you to have any revenue, typically. But we do expect you to have some insight into the business, what the customer pain point is. Usually [we expect] at least one person that we can reference that you've been working with, at some level. Again, doesn't have to be a paying customer. Maybe someone who is co-developing the technology with you or, can put their hand up and say 'we absolutely buy what these guys are doing. This is a fantastic idea, would be transformational if it happened'.

You know, you want to see that whole pipeline: we've got a good mix of skills, I've got some really capable technical people that have got something a little bit differentiated, and have a very clever insight. And then I've got someone that can take that, who understands the tech, understands the product direction, but it's also got real kind of customer insight, and has identified a problem worth solving.
Team composition for a data science startup – 'it's not unusual for all the founders to be technical'
Peter Zhegin:
Cool, it is a very clear definition and description of milestones. I'd probably ask you about the team a bit more. How does a relevant team of a data science startup typically look like?
Paul McNabb:
Well, you know, different kinds of startups have different profiles. For SaaS businesses, you're expecting to have someone with a strong sort of sales background, deep sort of industry experience in there. But for something like what you're talking about, it's not unusual, I think, for the entire founding team to be technical.

We are certainly a very strong believer in founder sales. The way that the venture works is that each fund will play its position. So in other words, we come in, we're a seed investor, we lead the journey from seed to series A with the company, and then the series A investor will then have a different set. They're much more concerned about scale, typically. And they'll then take that early on, on the next leg.

So for that first stage, which in our view is very typically about product market fit, about customer discovery. Like 'we've got this great insight into, you know, the way that utilities work, the way that automotive works, the way that industrial manufacturing works. We've been having some conversations with these guys, they seem to think that we're right'. Taking something from that point and turning into something where we actually know what really is the problem. What is the use case that we're sort of addressing? What is that worth? How many customers are out there that have that kind of pain? What's the best way of optimising the revenue take out from those people? That's kind of the journey that we're going.

So it's not unusual, I think for all the founders to be technical. But for one of the founders to have some natural sales or business development skills. it's very, very hard, I think for a 100% technical team that just wants to be an engineering, that wants to sit and code, doesn't want to have anything to do with the commercial side - it's very, very hard to back a group like that. Because it's at least as hard to figure this problem out [th commercial problem], as to figure to figure out the technical problem. And if you don't have someone that wants to own that problem in the founding team...

Well, a lot of people think, well, I can outsource that, right? I'll go and hire someone, and it's really hard. You really can't, for all sorts of reasons that I'm happy to go in, but it just doesn't work. So it has to be a founder. You can all be technical, you can all be planning long term to continue to be technical, maybe someone evolves into being something like head of product. But it's important that you have somebody that wants to work with customers, and figure out what really is the the journey that we're on, what really is the problem that we're solving.
Qualifying potential customers - 'One of the ways that can help to qualify people is by the quality of commitment that they have given back to you'
Peter Zhegin:
Imagine a founder who has a long list of potential customers, let's say, 50 or maybe 60 potential leads. What's your intuition on how they can prioritise that list? Maybe to approach corporations first, or an then to go to smaller potential customers?
Paul McNabb:
It's a very hard thing to generalise about. Because it depends a lot on the solution that you're bringing to market and the nature of that. If there's, for example, an open source or tools element to that, then you would look at which developers are adopting it and using it, and use that as a way of navigating customer opportunity and so on.

But some things, for example, a lot of machine learning applications in an area, like finance, tend to be something that needs to be done at an enterprise level. Because you kind of need to be part of the credit function, or the risk function, or whatever that thing is. So you've got to go in there and convince that audience of people to adopt or to trial your solution.

There are lots of ways to... I just talk generally about that, and then pick me up and see if there's anything you want to sort of double click on... there are lots of ways that you can short circuit that.

Lots of big enterprises have sort of innovation groups these days, they are without question a two edged sword. What they're looking for is flutter, they're looking for small young companies that they can put on their own little internal demo days and make them look good in front of bosses. You're never going to get a lot of revenue out of an Innovation group, because they don't control the budgets inside of the corporation.

When you start to look for [you] first big contract, you're not gonna get it from an innovation group, by and large. But you'll get some exposure to the corporate world, you might get some good introductions, you'll get a better understanding about how the company works. And maybe you'll get some pilot projects, or something like that.

Lots of accelerators. You have sort of famous sort of really deeply technical ones like EF [Entrepreneur First], and of course, there are lots now that Seraphim on the space side, of CyLon on the [cyber] security... Lots of enterprises have their own accelerators, as well. Lots of consulting firms have accelerators.

And those things can be useful, because what you're basically doing is trusting someone to be a broker of relationships for you, to help you make sensible introductions and to engage with the right kind of people who can be decision making. So there are ways that you can shortcut those kinds of processes.

But one of the things I always think for an enterprise sales as a way of qualification is, you know, unless somebody is prepared to commit something to you, it isn't that important. So, either that a lot of time access to production data. You're probably at the stage that we're talking about your most important metric, believe it or not, is probably not revenue. Your most important metric is customer discovery and sort of future indicators of where that revenue could be coming from.

No one is going to fund you at a series A stage because you've got, you know, whatever million pounds worth of revenue versus 600,000 pounds worth of revenue, despite what people tell you, that's just not the case. People want to see what the future... people are always looking at the futures. People are always thinking - 'Okay, I'm investing at this point. What's this business going to look like five years from now? And then two years from here? What do you look five years from now?'. So that's what they're looking at. and revenue is a lagging indicator.

You know, businesses need to commit something to you. Maybe it's pilot revenue, maybe it's something like that, that is actually financial. But it could also be that they're giving you access to production data. It can also be that they're letting you into their data centre, so that you can trail something out. It can also be that they're spending a lot of quality time helping you improve and feedback the product.

One of the ways that can help to qualify people is by the quality of commitment that they have given back to you. And I think that the customer journey is one whereby, at the beginning, as long as you've got, you know, the first two or three qualifying lenses on the prospect, so you know, I'm in whatever it is, let's say it's financial services, and I'm talking to someone that's in the middle office, and I'm talking to someone that actually procure software - so I've got my first sort of three high level lenses on it.

Almost every one of those meetings at the beginning is going to be interesting, because you'll find something out, you'll get an anecdote, it'll help you clarify what not to do. Because the question is a founder that you're always asking is - 'can my product do that? Should my product do that? If we were to change the product to do that, what would we lose, and what would we gain?'.

So you're going constantly making this trade off. And that, by the way, is why you always have to be doing ourselves. You can't outsource sales, because a sales person is always thinking - 'How do I sell something here? How do I sell something here?'. They don't care about this kind of pipeline of product discovery. They'll do whatever they need to do to get a sale, and they'll end up sending [a message] something that isn't coherent with what you're trying to build as a company.

I think that a founder [should be] having those meetings, and gradually, you'll get more and more clarity around what a good customer looks like, and what the buying signals are, and what the pain points are that will that will take you into business.

Another question that you asked is about the size of enterprise. And that's something that we care about a lot. Big enterprises are big beasts. And there's a famous blog that I think I forget who wrote it... But it's basically... elephants, deers, and rabbits. It basically goes through and basically says - for a startup to go after elephants to go big elephants, if you can do it, it's fantastic. Because they're huge, and you can live off an elephant for years. The problem with rabbits, is they often too small to be very interesting. You don't get through along, you need to find many more. And the cost of getting rabbits can be quite high.

So what you end up on as a startup is often something in the middle, something that's substantial enough - deer - to live on for a while. But it's also something that maybe doesn't have 19 levels of decision making. It won't take two years, you don't get to this point, and then discover you've got to go through procurement, all those kinds of things.

I think that enterprises, when you're in that customer discovery part of the journey, it's okay to talk to enterprises, because you will find out an awful lot. But what you may find is that as you have to narrow your use case and your proposition to something that is very clear, and that you can deliver convincingly and differentiated, that you narrow your prospect list and will probably end up looking at [something that] much more like a deer, than a giant enterprise.
Filtering customers feedback, customisation, a role of consulting for a product startup
Peter Zhegin:
Do you think that through talking to enterprises, a founder may learn more about competition?
Paul McNabb:
I think one of the issues, if you look at a big enterprise now, everyone loves the startup economy. I think that it is true and sort of well understood that innovation takes place outside of the firewall. It's very hard for large corporates to do breakthrough innovation. Some of them may have huge R&D budgets. But when I was at Cisco, we have massive R&D budget. But most of that went on product line extensions, frankly. So Cisco is one of most acquisitive companies on the planet.

Innovation people [in a corporation] are always trying to find startups to work with, to engage with. But if you look at that, across the company, like a big bank, or Cisco, or a big consumer goods company, you may be talking about hundreds, if not thousands, of small companies that somebody somewhere has engaged.

Only a very tiny percentage of those are going to go on to become core vendors to the corporation. And the ones that do that will be because they're solving a real problem, they had a real pain point, they found something that the company really, really values.

I think the point there is, it's very easy to have a lot of time and energy sucked up in these processes, and to get not a huge amount at the back end. And you have to be super cautious about that with big enterprises. Great, great for knowledge, grate for you customer discovery, great for data sets and things to play with. It's tough to convert those people into big customers, unless you've got a lot of experience and a lot of time, and a lot of resources to throw out the problem.
Peter Zhegin:
How typical in you experience is a situation when an enterprise, a potential customer, asks to do some customization, to introduce some features, do some custom development? How a founder may avoid becoming a consultancy?
Paul McNabb:
I think another question we could probably talk about for the whole time, I think it's a, it's tough. There's clearly some value to that, because what you're trying to do with customer discovery is discover what one of the customer pain points, what they care about. And almost certainly you will find that your original thesis needs to be changed, needs to evolve. The opportunity to be working with someone with a real problem, with a real dataset, with a real customer their own, and to adapt what you're doing to solve that problem much better, is fantastic. That is something that's well worth doing. If you're good, you can certainly harvest product development and have a customer at a minimum be your product manager and helping you with features, and possibly even be paying for some of that through a pilot or other area.

The second kind of bucket of things that come along is that there's probably always going to be some things that you don't want to do, that somebody's going to want you to do. Some integrations, maybe an extra feature, maybe, linking into some analytics layer, or whatever the thing may be. And you're going to have to do some of that to get customers, and over time that will get less, and over time your ability to say 'no' will get greater because your brand will grow and you will have a much stronger proposition in the marketplace.

What you should always try and do is to charge for that. You should always say, 'you know, that's great, we want to work with you. It's fantastic that you've trusted us. But you know, that's not on our roadmap and we need to differ our engineers that are busy coding the next set of features and, you know, you need to pay us whatever, 800 quid a day or 1000 pounds a day'. You should charge rates and go into a negotiation to do that.

[You need] to be very wary of people that want a product for free, a customization for free. and you've been having this conversation. For a long time, you know: 'I'm always telling you, it's going to be next week, and we're going to do this great and my boss is going to come in, it's gonna be fantastic'. Just be super wary of that situation. I've seen so many of those, and they take months and months and months, and it's always going to be coming, and it never does.

Then there's a third bucket of things. So I think that middle bucket, try charging for customization, expect that you're gonna have to do some customization that you don't want to do. And then there's a third bucket that says that people who either want you to change the product into something that isn't what you want it to be. [Like] put it all in house when you want to run it in the cloud, and you don't really want to have to deal with some sort of legacy implementation. And almost no matter how exciting some of that stuff is, or even if they want to pay for it, you're going to have to say 'no', because it's not your core business.

You made you mentioned something that I think is important, which is this notion of consulting in startups. And investors do not like services-based businesses, by and large, because they don't scale. You have to keep adding more people and complexity grows. But I don't think at this sort of stage that you should be too worried if you have a chunk of services in your in your mix. And I don't think it's a bad thing. If it's helping you. The goal is to get to product market fit, the goal is to go on the customer journey, where you know, who the customer is, what the problem is, you know, what the business model looks like. That's the goal. And if there's a bit of services in that mix, particularly if your customers or larger companies, I think that's alright, you can get rid of that later.
Peter Zhegin:
Yeah. And what could be the red flags, that may help a founder to understand that it's too much of a services, it's too much of a consulting?
Paul McNabb:
At the end of the day, you're in the business of selling the product. So if there's no product in that mix, if it's all customised, or all one offs, then that's the first set of instances. I think, if what you're being asked to write, or what you're being asked to produce is not coherent to the overall vision, or perhaps at most one step removed. Then you have to really ask about why we're doing this If it's coherent to the overall product vision, then that's great, right? Because somebody is hopefully paying for us to build our product. And we can harvest that we can reuse it.

If it's plus one, well, you know, we'll probably see another Zendesk implementation or another, you know, zero interface, somebody somewhere will also have that pain. So we'll, we'll do that. And we're going to get this customer as a reference, and it's going to be great. So we'll do that, and hopefully, we'll be able to reuse it again, at some point in the future. And we're going to get paid for that, hopefully. Or at least we'll make it absolutely clear to the customer that they're getting something amazing for free, because we really want their core business.

But if it gets to be plus two, and you're kind of like, well, we're having to write a whole module, it's going to take three months, I don't think we'll ever use it again, we don't really want to be in whatever it is... risk analytics business, we don't really want to be providing all these interfaces to these huge GRP systems, it's not our core business. You just have to be really cautious and say 'no'. Or to take a very bold decision that you're willing to take that risk. But I think the further you get away from the core of what you're trying to do, the tougher it should be.

If we think of it in the context of data science, machine learning in particular, well interpretation is a consulting business, right? So we run these models, we've analysed this data set, we've come up with these patterns, with these trends, with whatever those things may be. And it'll often be that your first customer won't necessarily know how to interpret that, won't know how to draw the conclusions and lessons, wont maybe be able to present that in a convincing or meaningful way to their management. So you're probably going to have to spend quite a lot of time in your first few engagements doing that work. And that mix [consulting/product] could be as high as 50/50 for the first few. But then increasingly, as that goes on, you'll automate some of that, you'll be getting better at what your target customers should be, you'll make your results, your analytics kind of layer much clearer, much easier to understand. So you learn lessons that consulting and services piece becomes very additive into what you want to build back into your tool and into your platform.
Enterprise buying decisions and their tech stack – how to fit in
Peter Zhegin:
We've talked about kind of the micro level, let's say how a founder may interact with a corporation move these pilots, etc. There's a macro level as well that you mentioned – these buying cycles, replacement cycles. How to understand them better?
Paul McNabb:
Well, I mean, there are lots of data services out there right now that will tell you what stacks people are running, and all these other kinds of things. You can find a lot of that data around. But yeah, it's a tough question.

We work with startups that go into this with a mentality of 'we have discovered the secret of how to make gold, and we're going to put you all out of business'. And so it's a kind of, you know, burn everything down, scorched earth, start over kind of a strategy, we're smarter than you are. And that's fine, it's pretty hard to pull off. And what you end up doing, if you take that kind of approach is you're going to have to build the whole stack yourself. So you're gonna have to be a new manufacturing company, you're going have to be a new financial services, you're gonna have to be a drug discovery company, whatever the thing is, right? So you're gonna have to build the whole stack and do it all yourself, and you need a lot of money, you're gonna need, credible technical vision, so on and so forth.

If you take a different approach, which says 'we're going to have to go in and work with the business and augment an existing business process', then that's a much more feasible strategy. But it also means that you've got to understand the rhythms of the machine that you're going to engage with.

We've seen lots of lots of businesses recently looking at the data analytic stack inside the corporation. And you've got to understand that whether they're good or whether they're bad, there are things like, Tableau, and QlikView, and Microsoft, whatever, that are incredibly well established in the enterprise. And they have enterprise relationships, and they have support relationships, and they have people trained in them. To go in and displace that kind of stack, in a large or even a medium sized company is really, really, really hard. You're gonna have to have an extraordinary value proposition, you're going to have to sell at a very high level. And you have to be really, really confident that you can take on all the work that's taking place right now inside those pieces of software and do it successfully. Really going to be almost impossible to do.

So what you are going to have to do is you're playing into that stack is find something that sits or works with that side, but does something better, like breakthrough in productivity, breakthrough in presentation, breakthrough in speed, whatever the thing is. You can use that as a strategic entry point, and then work backwards and take more and more of this stack away. But to go in and displace an existing process, an existing software stack is really, really hard work. And not only are you finding all the users, all the other users of that product. You may have a sponsor that thinks your product is better than anybody else. But you're fighting all the other users of all those products, you're fighting IT, you're fighting procurement. It's a really, really uphill battle. It's going to be really, really tough to do that. So, if you're selling into smaller businesses, startups, they are buying tools for the first time, that can be a better way of getting something like that. But when you go into somewhere that has an existing business process, an existing workflow, going in there and trying to replace it all in day one is a really tough sell.
Negotiating with corporations
Peter Zhegin:
Before we close, maybe just two or three last questions. Is there any theme or question that we did not cover?
Paul McNabb:
So I just want to pick up a couple of points that just made that. So one is procurement. So if you deal with any larger enterprise, you end up dealing with procurement. Your ability to get through procurement is usually dependent on the strength of your sponsor.

One of the things that you have to be able to figure out if you're trying to sell into a bigger or even a medium sized business is, is my sponsor a decision maker? If I'm talking to the head of sales, in any corporation, heads of sales, get what they want. Because that's just how stuff works. People own businesses, run businesses, get what they want, because they're revenue makers, they're moneymakers, they will always get what they wants. Having someone in that kind of line of command is always really helpful, and can help push things through procurement.

Going into procurement, you need a strong sponsor, you need the right sponsor, and you need to stand your God. Discount in year one - fine. Discounting products – fine, but don't give up your value forever. Don't do a one off license, don't do something that you can't come back and rectify. After year one, when you've done your trial, you've done things cheaply, you can always come back and raise the price as long as you've left yourself a strategic opportunity to do that.

The thing is, I don't mind giving up something now, because right now what I need is this logo, I need this proof point, I need to go in there and show that my tech works at a high volume in a big space. I don't mind giving up something now, because it is valuable to me. But don't sign up forever. Don't give the rest of your future away with the procurement. You have to really be careful with procurement.

Most corporates have innovation groups, as we talked about, most of them have now, venture groups either investing off a balance sheet, sometimes with separate funds depends on how sophisticated they are. There's usually a difference between somebody taking a minority stake and somebody that wants to do an acquisition in terms of the kinds of thresholds and milestones that people need to have proof for internally in the signoffs. It can seem very attractive, if you're in an industry to get a big brand name invested in you. The danger with that always is that the assumption of all their competitors will be - 'well they [corporate investor] has got the inside track, they'll know what's going on. They know what the product pipeline is. If we do business with this small company, then our competitors will know everything that's going on about us blah, blah, blah'.

So if you're going to take [corporate] investment, you have to be really cautious about it, either in terms of the threshold at which you take that investments, a very small percentage, perhaps having multiple investors from the same industry. And just really being cautious about how close you get to them in terms of things like information rights, observer seats, and all that all that kind of good stuff. But what we do see, and, Peter, I'd be interested in your thoughts on this, is that corporate venture capital is becoming a big source of investment for startups, it's becoming bigger and bigger. Sort of innovate, innovate or die is definitely something that the world's corporations have taken to heart.
Peter Zhegin:
I don't remember the exact numbers. But we've done some research on post-COVID time like April, May, these month. Things that I remember is that corporate venture capital investments didn't fail as sharply as independent VC investments. I'd agree that the volume at least, and participation of corporations in the number of deals is either flat, or even maybe increasing. Even more in Europe, because I'd say it's less developed here than in the US.
Paul McNabb:
And I think there's a difference between a VC like me who is financially motivated, and a VC like a big corporation, they strategically motivated. We don't get, you know, ahead of this technology that could kill us five years down the road. So it's a very different motivation.
Closing remarks – you need to know who you are before launching a startup
Peter Zhegin:
Yeah, absolutely. And that definitely deserves a separate talk. And the last one, maybe before the close - the single advice to a data scientist who plays with neural nets on his or her notebook somewhere in the garage, and thinks about the startup? The most important advice in your opinion?
Paul McNabb:
So I always used to think... I lived in California... I'm a Brit, but I lived in California for a long time. I always used to think that when I grew up in Britain, everybody wanted to be in a band. And when I went to live in California, everybody wanted to be in a startup.

So I think you kind of have to know who you are. Are you the person that wants to do that, and wants to take that risk, is prepared to put everything off? And, you know, take all the risks, all the financial risks, because you want to pursue that vision? Or are you not that person?

I'm not sure, on average, the expected return in terms of an overall career between being an amazing top data scientist at a great company, like Google, or going out and being an engineer or a founder in a successful data science business - I'm not sure that the expected return is necessarily that different. I think there's more standard deviations on the startup side, you're quite likely, most likely to have get nothing out of it. You know, there are a small percentage of people, of course, that go on to be super, super successful. But, you know, I think, you just have to look at yourself and say, is that, am I really ready to do this? Do I really want to do this? Because it's gonna be tough, the highs are higher, the lows are lower, which, you know, in of itself was enough for me to want to do it. But you know it's always a different way of getting to a career. Other way around your question.

One of the questions I saw on your on your sheet was, well, when should I quit my job? Right? If you have to ask that question, you should not quit your job.
Peter Zhegin:
Wonderful answer.
Paul McNabb:
Because if you really want to do a start up, you don't even need to ask that question.
Peter Zhegin:
I've heard something like that about artists and painters, someone told that he couldn't not paint. It's what we have to do. Thank you, once again. It's a wonderful talk and super useful. And I'm sure we will hear a lot of good news from Episode 1, and from your wonderful data science portfolio.
Paul McNabb:
My pleasure. I hope it was useful.