Originally published on the Silicon Roundabout community blog

---

TL;DR Summary

Hi fellow coders, tech entrepreneurs, and startup investors! Francesco from Silicon Roundabout and the Silicon Roundabout Ventures fund here.

In this article, I’m going to use a recent Zoom chat I had with Henrik Grim, Investment Manager at a fellow European VC: Northzone.

For those of you that want the gists of it in 30 secs, here what we will talk about:

• Hackers vs Hustlers: the problem of too many articles on how to make a startup slide deck and not many on what makes an “investable” early stage technology.
• Intro to the speakers’ backgrounds: two former engineers ─one leading a newly launched pre-seed/seed UK fund: Silicon Roundabout Ventures; and one for 4 years at EU + US 25-year old fund Northzone.
• How and when do large VCs like Northzone look at code and technology? Tip: probably later than you expect as an engineer.
• Deep Tech and AI: Henrik’ and Northzone’s opinion on how to gauge if the team can actually build such tech.
• How to “hack an MVP” for the investment committee: make it work on the front end ─as long as you can render the “experience” and address the early customers’ problems, you should cut as many corners to have a working release you can showcase to investors (who may not really care about how pretty or complete your code is! -Edit note: "unfortunately" I personally do in my VC :p)

Hackers vs Hustlers

They say that to build a startup you need a couple of founders. Common wisdom has it that you ideally need at least 2: one hacker and one hustler. Steve Jobs and Steve Wozniack are perhaps the most famous example.

The hacker is the tech person. They’re the programmer that can put things together and can find innovative solutions to meet the near term business goals.

The hustler is all about business development, marketing and sales. They’re excellent at establishing relationships and getting the word out about the product, establishing partnership agreements, and, of course, raising the holy-grail of venture funding.

As the team scale, functions within the company grow. However, in all tech startups-turning-scaleups, the tech function and the BD function always remain the two main pillars of the business. After all, the tech product and the brand that goes with it need to keep ahead of the game for the company to eventually turn into the Amazons, Apples, and Facebooks of the world.

##Who writes for the hackers? Most startup blogs, groups and VC investors tend to focus on writing for the hustlers.

You can find plenty of articles about how founders (aka “hustlers”) can make the perfect pitch deck to present their tech and vision.

You can also find plenty of advice directly from VC investors on how to grow your sales funnel, scale your team, and bootstrap your business venture.

Who writes for the hackers, though?

As a software engineer who got exposed to both startup projects and work for more traditional businesses, I can tell you: it’s WAY different to code for a startup than it is to code for any other old-fashioned enterprise.

Since I recently turned startup investor myself, now running the Silicon Roundabout Ventures fund, let me tell you of at least one key difference. Enterprise tech is mostly about avoiding mistakes and keeping the show running for the existing user base. Startup tech is mostly about getting enough of the job done (kinda) to convince your early adopters and investors to back you at least once more. Then, you’ll figure out what to do next, once you close the next funding round…

The “hidden user” in the story

In essence, therefore, especially for tech startups that need venture backing (virtually all of them), the investor is, therefore, a kind of hidden user in the storyboard of your tech.

The question then is: how do investors look at tech in early stage startups?

How should engineers approach tech development, to help the hustlers in their team sell the perfect story to prospective investors?

Where to focus your efforts when planning the next sprint, or sketching, building and prioritising then next building block?

Enter the tech VC

As a pre-seed and seed tech VC made up of engineers, entrepreneurs and software developers, we thought of doing things differently.

We have been running for a few months now an event series in partnership with one of our community startups: [TechTree])(techtree.dev) [Edit note: a personal investee in my Angel portfolio]. The series focus on CTOs, engineers and tech leads from VC-backed companies, who come to showcase their code, hacks and journeys with other engineers from the tech community. At each edition, we partner up with a different VC. Before or during the event, I interview a tech VC to ask them precisely about this.

How do they assess technology? Especially hi-tech stuff, you know, like these Python algos that most non-techies like to call “AI”. Or like those sensor networks people call Internet-of-Things. Or those signal-processing software bits paired up with Arduinos that finance folks like to call Robotics solutions.

All that stuff.

I mostly encounter investors with a finance or consultancy background, and occasionally other tech people like me.

It’s interesting to see what they see, how they operate when looking at new tech, and I’m here going to report you a redacted version of the latest of these chats I had.

So, before you write your next line of code for your startup team: have a sit back, relax, and read up how our friends at the Northzone VC look at new tech!

Meet Henrik from Northzone

For this chat, I had the pleasure to interview Henrik Grim: an investment manager for Northzone based in Stockholm. He focuses mainly on product-centric founders and companies across consumer and SME markets, in sectors like fintech, marketplaces, commerce and gaming. He is involved in Northzone’s investments in NA-KD, Spacemaker, Tier, Klang and Kitab Sawti.

Francesco

Hi Henrik, this is Francesco, from Silicon Roundabout and the Silicon Roundabout Ventures fund. I’m here asking a few questions for the engineers and startup techies from our community.

As you know, Silicon Roundabout and TechTree are about to host event with quite a few of Northzone companies so, I’d like to really go through a couple of questions about tech and startups.

But before I get into that, do you mind to give us a quick intro about yourself and Northzone?

Henrik

Sure. Northzone is one of the oldest venture funds in Europe and it was founded in 1996. So 25 years ago, this year, and inn Oslo, Norway, of all places. A a lot has happened with Northzone since then. We expanded and are now in three main offices in London, which is our head office, in Stockholm, and in New York, and we invest across Europe and East Coast US.

We try to do what we’ve always done, which is early stage technology, investing, and investing all the way from seed to Series B across industries.

We have a portfolio or roughly 60 live companies today, ranging anywhere from the gaming and consumer media space on one end to enterprise platforms and dev tools on the other side.

So that’s very quickly about Northzone. We’re investment team of 15 people spread out across those regions. And me personally, I’ve been with the fund for roughly four years, and come from an engineering background out of Stockholm. I essentially got the introduction to startups by working for a few of Northzone’s portfolio companies throughout my study. I interned at i-Zettle when they were 30 people and was part of building their first risk monitoring engine and transaction monitor engine. Then joined Spotify in two different rounds and their growth team. I was working both in Stockholm and New York trying to get more people to to move from freemium to premium through different initiatives and marketing and product.

So that’s very quick, quickly on my background. I had a short stint as a McKinsey consultant for two years, then realised I want to go back into tech and joined Northzone. I had a short stint at King and mobile gaming before joining a little bit more than four years ago.

Francesco Perticarari

Great. It sounds sounds amazing!

And we already found something in common because my background is in engineering as well. In fact I was coding professionally until very recently, so great to meet on of the few investors in Europe who come from the tech side of things.

Now, my first question is actually interesting in light of what you just said, that is: Northzone is basically a very old fund. By European standards, at least. And, probably, I would assume that the way Northzone looks at tech must have changed as technology itself developed.

So the first question is, as it stands right now, and especially with someone like you coming from an engineering background: Do you guys, do you personally like to look at code when you review this startups?

How do you get into this sort of “Okay, I like the initial pitch, I want to get to know you more”.

Does he ever get to the stage where you really want to see some tech before before getting really excited about an opportunity?

Henrik

Usually looking at the code itself is sort of post due diligence process.

However, when the tech has a really big part of the value prop, let’s say when there is something using or claiming to use AI. Then we typically make sure that we really sit down with a team, look at the product, look at how they explain the infrastructure and have them really explain how the technology does what they want it to do. Right? And listening, how sensible it sounds and real it sounds.

I think, actually looking at the code, that’s something that we do much more post term sheet. It’s more about saying: “hey, we agree on the value prop, we agree and really believe in what you’ve built as a product and how your technology is supposed to function ─Let’s just have the exercise of running through to see how the technology is actually a built and if it does what you claim to do”.

So that’s more of a checkbox exercise.

That’s where we typically send someone in to do that, because, honestly, you know, nor I and nor anyone else in the team is probably capable enough to quickly run through a code base. That is not the team that we have put together. We focus much more on the commercial and the product, and the infrastructure side than going really deep on the code.

Francesco

Okay.

Before I move on to the second question that I prepared for you, I will just add a little sub question on what you just said about the code. If a company is staking everything on, say, AI, which then would be, I guess, their defensive moat and also the differentiator from the rest of their industry, then: How much are you prepared, since you’re an early stage VC, to trust the founders?

Because building an AI system requires a lot of data, and requires also a lot of optimisation. You don’t just build it by writing some lines of code. So how much are you prepared to trust that the team will develop it over time?

So I guess, in other words: how much are you prepared to accept that there is a little bit of “fake it until you make it” when it comes to pitching the idea? Versus actually having the actual technology there by the time you write your cheque.

Henrik

Right. So, we are in the business of taking risk on execution, right? And on technology execution in particular. So, we don’t at all shy away from taking, taking that type of risk. Such as a founding team, sort of claiming to have an idea on how to build things. That is, you know, that is a core of what we do.

With that said, we’ve obviously worked with very strong teams that have built probably similar applications using AI before. And I think what is very clear is that they, quite early in the in their journeys, were able to identify how they think about building the system. How they think about collecting that data. How they think about refining those data sets over time, such that you’re building a data moat.

There are so many dimensions to how you claim that you will be able to do things. That’s where we typically like to drill really deep to make sure that this is something that they really thought through. So I think there’s a lot of dimensions that we go deeper into, to really get comfortable on the level quality in those assumptions.

That is sort of how we think about things. We love taking risk on entrepreneurs building something that’s not yet done. But we think that it is a lot about hearing the entrepreneurs and then from there try to really understand how deeply they’ve thought about this.

Francesco

In that case, the second question that I wanted to ask you is: Could you tell us a little bit more about the investment process you go through when cooperating with other, earlier stage, investors? Especially Angels and pre-seed / seed Funds like ours. And what is the investment process after that?

Henrik

So you’re saying, what is the process for for finding and sourcing potential investments? And then once we found them, how do we go go about it, you know, determining whether we want to invest or not? Is that the question?

Francesco

Yep.

Henrik

On the first one, how we how we source companies to make potential investments, it’s a combination, right?

It’s a combination of both inbound, where, we through our networks have worked with angel investors, or seed investors, or entrepreneurs, that get to us. Either from recommendations from from people in our network, or people simply just reaching out over email or on Twitter, or whatever it might be.

Inbound is a pretty big chunk of the companies that we speak to. A lot is also outbound. We do a lot of research work in thesis-led thinking and we look for companies within certain topics or segments that we are excited about.

And on the second one, when we do get in touch, how the process works, it is essentially first identifying whether there is a potential fit with with our type of business model.

We really need to believe in in these companies and entrepreneurs wanting to build something really big.

And so that’s usually sort of a first good check, to see if there’s alignment on that.

Then we have a sort of due diligence process that’s very much focused on the commercial side, and the teams.

And then after that, more of what we’ve discussed. We go deeper and understand, how is this team building this product? How are they operating together in the different functions? And then at the end, we go deeper on the technology side to understand, is the product and the technology that they that they built robust and scalable?

So it’s typically a three step process, where we leverage in different steps, our team’s knowledge and experience in different sectors and industries.

We also leverage external networks that can help us evaluate these opportunities.

Francesco

Brilliant. Thank you.

Henrik. In that case: last question would be for me.

Let’s bring it back into the engineering aspect, since people watching the upcoming event will be engineers working for startups or looking to join startups.

What I would like to find out from you is this: Can you give us a couple of examples of good hacks, or really interesting tricks, that companies used when they were scaling their MVP? Anything productivity-wise, or tech-wise that, now that the company has done it, it’s like: “that was a very interesting way of doing it, of trying something fast and getting it done”.

Henrik

Sure. I mean, a lot of it, a lot of these sort of hacks or MVPs to us come down to a focus on really trying to convey a value prop. A full value prop. Even when the technology isn’t fully supporting it.

We focus a lot on what is the the problem that the company is trying to solve. What is the product that they’ve built to solve that problem. And, at times, it’s worthwhile as a developer or a technologist in these companies to try to say, “hey, how can we as quickly as possible, put together something that can illustrate this”.

I think we’ve seen it a lot in terms of companies that start with a pretty light and thin front end.

They really just try to explain the user flows or the user experience or the customer experience with that front end.

But on the back end, actually, there’s still a lot of manual stuff going on. And that can be fine.

That’s something that we are very happy to take risk on.

Because we essentially are playing for an 8 to 10 year horizon. So we think that some of these technology challenges, as long as we’ve identified what they are, we’ll be able to solve them along the way.

So, a lot of the hacks come down to saying:

Let’s just showcase what the user experience could look like, with a great front end. And then on the back end, we’ll just simply either hack it away manually, or cut as many corners as we can.

One example is a company that we’ve had in image recognition, working in the industry of real estate developers. Their pitch was that if you take photographs of a big construction site, you will be able to build a digital twin that, which you can map to the progress reports of a project.

I think in the beginning, in the early days, they did a lot of manual work on the back end there.

They had people sitting there, looking at these images, manually tagging, what was working and what was not.

But what was interesting was that they were also, at the same time, building their own data set. So they were tagging pictures and building their own AI data sets, that they could then use and improve over time.

We were quite eager to see the potential in automating more of that manual process. But in the beginning, it was quite manual.

And it was a smart way of saying, “Hey, we’re showing the full value prop while building out the technology base and the data set over time”.

You know, there’s lots of other interesting examples, I think, a more fun one is probably Spotify.

When pitching to us, but also when pitching to the big labels, they had their products and their interface full of pirated music.

So it wasn’t at all viable to launch. It was probably illegal at the time.

But it really was able to showcase what the full experience would look like.

I think that is the core of the segment, right?

It’s all about being able to showcase what this product will be able to do, and then use whatever technology or and cut any corners that you can, to be able to do that.

Francesco

Brilliant, that’s actually great info for any dev working on a startup idea or in a startup team.

I think that, being an engineer myself and having developed code until fairly recently, sometimes engineers can do the exact opposite. I.e. They want to make it perfect and bug free before showing it to anyone. Whereas when it comes to startups it’s the opposite of big companies.

Much better to go run it and make mistakes and and then go and fix it.

So really, really appreciate that insight. Totally share it. Thank you so much for sharing all of this today.

Henrik

Thanks to you! Let’s definitely keep in touch.