VCs kind of get by on the opacity of the process. Normally, if we make the right decision for the wrong reason, you’ll never know. If we make a bad decision that was obvious in hindsight, you’ll never see precisely what we missed.
But I think I’d like to publish as many of these as possible anyway, when and as permitted by the founders, trying not to filter them or publish only when the company is successful. I mean, GitHub has tk/tcl code I wrote in 2007, so this can’t be more embarrassing than that?
It’s hard to describe what my decision-making process is, and maybe this helps with that. Maybe it’s generalizable to how other seed investors make decisions. I’m not sure. In general, we need more people to have access to VC, to understand the game. Maybe this helps a tiny bit.
Here’s a link to where we’re keeping them all: [https://github.com/rootvc/investment-memos]
And if this experiment doesn’t work out, there’s always git filter-keys…
(From this Twitter thread.)
]]>In the spirit of strong opinions, weakly held… 👇
You can’t “just build” a dev platform on top of your successful SaaS business. It’s a different customer and more importantly a different user.
Developer Experience (DX) and Community/Developer Advocacy on the founding team probably more important than the second/third technical cofounder. Ditto Open Source community experience, for certain products and business models.
Low code is infinitely more interesting than no code. The most popular programming language in the world is Excel. We are massively underestimating the number of people who can low-code in their area of expertise. The barriers to entry for coding are lowering every day.
By the numbers, most developers live outside of Silicon Valley, and they work in all kinds of industries and typically on small teams at non-tech focused companies. SV engineers are great for PMF, but GitHub, MSFT, and CircleCI make their money on the rest.
But Silicon Valley exports developer culture in the way LA does popular culture and NYC does (non-tech) business culture. 10 years ago, I’d never have predicted CI/CD, PaaS, cloud based source control, and agile methodologies would go mainstream.
People underestimate the number of junior developers. The population of engineers by age is shaped like a pyramid, because of demand in the labor market. Implications to average experience/average current skill level, and to exponential growth of new tools. (Rust Java.)
There is a ~3M global developer deficit relative to industry demand. Even during a recession, and even after layoffs, companies will pay for developer tools that amplify productivity. Honestly, they don’t have a choice, because developers will use whatever they want anyway.
Deep learning isn’t very popular for truly valuable business use cases. Much simpler models drive much more value. There’s an interesting bet that it will change, but it’s far, far from certain. That being said, deep learning is the coolest fucking thing I’ve ever seen in CS.
Build v. Buy is pretty much always Buy for the vast majority of developers. This is not true at GAFA, but true at N, and most of the tech unicorns.
Developer tools are not enterprise software. They’re not consumer software either. They’re a third thing that has elements of both. But the biggest developer tools companies have an initial go to market that looks like organic consumer growth more than enterprise sales motion.
Accordingly, the best devtools investors will understand the developer user in the same way the best consumer investors understand consumer trends. I may be slightly biased, but… I think it helps to be a devtools user to understand developer experience.
Open Source is not free labor. Building community is hard, sustained, work. It’s rarely ROI positive from a payroll perspective. But that’s not the point.
Developer evangelists/advocates, technical writers, and Developer Experience (DX) designers may be the most critical early hires, and these are in even shorter supply than developers. These salaries will skyrocket, with good reason. Do not let these people go.
It’s often hard to imagine the $1B business in even a popular developer tool. We should be more willing (myself included) to take a flyer on the consumer-style investment thesis: if the team is great and the tool is ubiquitous, a good revenue model will be discovered.
But I really mean ubiquitous. GitHub is a multi-$B company at $7/mo/seat because literally everyone uses it. If you build a company with 5% of GitHub’s users (huge!,) can you build value worth $140/mo/developer? Some can. Look at Pivotal’s ACV when they filed independently.
A lot of developers hate things like Javascript, Ruby.
In general, tools like Heroku are the most often underestimated. Don’t forget the bottom of that triangle. The huge majority of developers really don’t want to configure kubernetes, and increasingly, they won’t have to.
Silicon Valley, in the case of programmers, is a mindset as well as a place. Silicon Valley is still the best place for density of Silicon Valley culture, but there are plenty of Silicon Valley style developers elsewhere. Bet on remote developers.
“Older” developers are underestimated. Experience is underrated. Many senior developers actually do keep up with trends, and leverage their experience in evaluating and building technology. Invest in “second career” founders. Especially if they are good at mentorship.
The best technical skill is people skills. A developer of any background or experience level without empathy is not going to be a good founder. A highly empathetic founder who is a mediocre developer is far more likely to succeed.
Bet on the trend of increasing diversity across all axes in programming. Access has never been better and awareness has never been higher. Silicon Valley leads the way, and the rest will follow.
Bonus hot take: Rust will be one of the 3 most popular programming languages for new startups by 2025. WASM will cannibalize a lot of Javascript. Rust will be the best WASM targeted language.
Will mostly stay out of the programmer wars, but if you care:
What am I missing? Where am I wrong?
(From a tweetstorm.) Slightly edited here.
]]>Presenting: Meet. Note: I first wrote this post before Google merged their several video conferencing solutions into one and named it Google Meet. Oops!
Pull requests and Issues welcome. I’ve abstracted away all the Root-specific code, so you can now deploy your own instance of Meet to your own Netlify account with one click from the GitHub README and a few short configuration steps.
We’ve now completely switched over to this side-project at Root. If you video chat with us any time in the future, you’ll be using Meet.
All that was reason enough, but since building Meet, as The Dude would say, new shit has come to light. It turns out Zoom is a privacy nightmare.
Daily.co uses a peer-to-peer architecture and end-to-end encryption. They offer a HIPAA-compliant product to protect personal health information (PHI), being used by several telemedicine customers today. You can read their privacy policy yourself.
How it works Code here: [https://github.com/rootvc/meet]
Meet is a React app built on create-react-app. Most of the relevant code for video conferencing is in /src/Room.js, which loads the daily.co iframe and builds the HTML/CSS around the iframe.
The daily.co Javascript API is dead simple:
window.callFrame = window.DailyIframe.createFrame(
document.getElementById("frame"), {
showLeaveButton: true,
iframeStyle: {
...
}
});
let url = `https://${config.DAILY_SUBDOMAIN}.daily.co/${roomName}`
window.callFrame.join({ url: url });Styles are defined in /src/index.css for the generic styles and /src/brand.css defines the Root Ventures specific styles. This should make it easy to brand it yourself if you fork the repo, without messing up the basic layout.
Finally /src/config.js loads a config object that stores values from the environment. The README defines what each of these variables do, but the key one is REACT_APP_DAILY_SUBDOMAIN.
This simple app uses daily.co’s front-end API only. Note that the front-end API can’t do anything that would require your secret key (as that would then be served to the client.) You’ll need the REST API for anything like that (e.g. creating rooms, recordings, deleting rooms, getting meeting analytics.)
So that’s great. The whole app is a handful of static files, so I can host it on Netlify, a popular static site host that serves files from the edge.
Instructions for deploying on Netlify (with CI/CD hooks) are in the README.
Try it yourself either by forking the repo or deploying with the Deploy to Netlify button in the README. Then just follow the 5 steps in the readme to configure Netlify, Daily, and the app itself.
Hopefully this shows you how easy it is to create an app that has video chat built in. Go ahead and make an account on daily.co.
Code here: https://github.com/rootvc/meet
Root Ventures is an investor in [Daily], a company that provides reliable, secure video chat and screensharing via a simple one-line API. Yes, I am totally talking my book. Sorry, not sorry.
]]>For a developer tool to be venture scale, let’s say that it roughly needs to achieve $100M in high-quality (software margin) annual recurring revenue, within 10 years or so. This is a daunting task, and the rare company achieves it. But look at the NASDAQ, among top unicorns, and large acquisitions, and you’ll see several examples. Stripe, Segment, GitHub, Elastic, RedHat, Pivotal, Atlassian, Stack Overflow, Twilio, New Relic, Pager Duty, 10gen, Algolia, CircleCI, Snowflake, and the list goes on…
One framework I like to think about in large developer tools opportunities is what I’m trying to call lowering the floor and raising the ceiling (trying to make fetch happen.)
Look at the history of how we’ve built software, and an obvious trend emerges. What used to be hard, becomes easy, and then eventually free.
When PayPal was being founded, according to one tale, a bank told them that credit cards would never be processed over the internet. It’s funny to think about now, but PayPal had to invent a number of hard technologies for security, encryption, and transaction guarantees. Years later, Braintree built on innovations from PayPal to make it easy to integrate credit card processing with an online service. Then Stripe came along, and made a somewhat cumbersome integration five lines of code, or essentially free in developer time.
More broadly, you can see in the world of programming, that we are constantly building abstractions that improve productivity, and in some sense, lessen the need to understand underlying technology and difficult abstractions in all but the complicated edge cases (where of course, depth of knowledge is invaluable.) Where once, all programmers built and allocated memory for strings of characters by hand using pointers and malloc, manipulating them with handwritten functions, almost all programming languages now include powerful list comprehension methods that are teachable to new programmers quite quickly.
This is one major benefit of products that raise the floor. When we make hard things free, we not only improve productivity of our projects and teams, we open the door for a new type of software developer.
My best heuristic for a true floor lowerer is:
Can I teach this to someone in a three month bootcamp?
Today, we’ve seen a movement of hard to easy in: robust mobile applications, highly interactive web applications, stable and repeatable server deployment, and integrations with all kinds of third-party services from payments with Stripe, to text messaging with Twilio, to real-time streaming video with Daily.
We’ve seen a movement from easy to free in: content management systems with Wordpress, e-commerce with Shopify, static websites with Webflow, and several early attempts at doing the same with mobile applications.
Some people say that easy or free includes AI & deep learning, but I disagree. Certainly this is true for computer vision applications, natural language processing, and other simple models. But I’ve seen junior developers even with computer science degrees struggle to achieve a useful quality of prediction for pose detection, or facial recognition, even using great libraries like TensorFlow, Keras, and PyTorch. In these algorithms, the model architecture, and sometimes even the data, isn’t enough. The efficacy depends on model tuning that requires deep domain expertise in the fundamentals of both mathematics and computer science. Most deep learning problems are therefore somewhere between hard and easy, but will be nowhere near free until better tooling is invented.
I expect this is one area where we will see the floor raised soon. Other areas might include game development, even more movement in devops, AR & VR experiences, embedded software, and outside of pure software: CAD, hardware design, and autonomy. But I doubt we’ll know it until we see it.
On the other end of the spectrum, we have software that pushes the boundary from impossible to possible.
The most salient example of this is machine learning. Under old programming paradigms, it was essentially impossible to imagine software that could read unbounded datasets of human handwriting. In the 1970’s computer scientists proposed algorithms based on linear algebra that could do just that, and by the 2010’s, hardware was good enough to implement these algorithms at large scale.
Today the boundaries of what is possible with software are moving rapidly. We are training robotic grasping manipulators to complete arbitrary tasks, completely in simulation that translates to near perfect behavior in the real world. AlphaGo was able to beat the best Go player in the world, a task experts from the 90’s predicted would take 100 years to achieve. DeepFake, now widely available, can already fool many humans with realistic, completely fabricated video and audio. And it is improving at this task rapidly.
In all of these situations, the paradigms changed to make them possible. In simulation, we can generate training data for machine learning models that teach it faster, and sometimes cheaper, than any real world experience could. Where the computer that beat chess Grandmaster Gary Kasparov was built on complex logic, AlphaGo was built on a handful of novel learning algorithms. The generative adversarial networks behind DeepFake are even newer academic inventions, and even later became feasible on real hardware with large datasets. They all have one thing in common, which is my heuristic for software that raises the ceiling.
Does this software let us do something we didn’t think was possible before?
One place to look for new possibilities in software is advances in hardware. We’ve clearly seen theoretical algorithms become feasible as Moore’s Law has continued over the years, and we’ve seen linear acceleration become the primary driver of GPU-based computation of late. But we also see that low-power processors are enabling inference, and sometimes training, at the edge, unlocking new opportunities like fully autonomous aerial drones. The proliferation and low cost of sensors combined with novel sensor fusion algorithms is bringing powerful capabilities to even more devices.
What will constant connectivity, even more ubiquitous sensors (especially always-on cameras and microphones,) and federated learning bring? We can get crazier and think about low-cost commodity LiDAR, infrared, millimeter wave, and even sonar. Can we imagine new algorithms that can achieve the performance of complex models trained on huge datasets, that work just as well on smaller datasets, and therefore less capable compute? Which algorithms are prohibitively expensive (such as GPT-2,) that will become more affordable with changes in compute?
Software that raises the ceiling is categorically different from software that lowers the floor. But they both have the potential to disrupt. It’s not a necessary criteria for a venture-scale business, nor is it sufficient. But evidence of one of these two things can strongly indicate that there’s at least opportunity. More on this later.
]]>Note: I’m not talking about anything here other than indicators that an idea might be the kind of software we invest in. Very important questions like market size and go to market strategy are not in here!
]]>Much of this applies to anything at all, from physical objects, to software, to music, and art. But I’ll stick to what I know, and keep examples confined to engineering-driven things.
The ability to conceive of the right thing. There are a lot of uses of the word design, but I want to use it in this specific way. Whether you use “Design Thinking,” or ethnography, or subscribe to the ideas of vision or divine inspiration, you’ll need to conceive of the thing you want to build before, and while you build it.
As engineers, we often skip this step, to disastrous consequences. It can be fun to make a thing that works, but unless it’s designed intentionally, it’s not going to solve a real problem and no one is going to want to use it.
Design helps us answer questions like:
The ability to make the thing work. A broader definition might be technical skill, so this could be writing, or playing an instrument, or painting canvas.
In the realm of engineering, the technical skill required to make a thing work can span from engineering design, to software architecture, to design for manufacture. It may involve circuit design, writing code, or solving a static analysis problem.
Engineering helps us answer questions like:
The means to make the thing. Whenever you have an idea for a thing, if you aren’t independently wealthy, you’ll need to figure out how to finance making it. Part of that may include paying a salary yourself and your team, if this is your company. Or making the business case to get a budget, if you’re inside a larger company already.
The most frequently overlooked of the 3 areas, engineering students often view entrepreneurship as boring, or as something they can outsource to a “business person.” In fact, business and entrepreneurship are the enablers of getting your thing into the hands of your users. Design and engineering aren’t enough. Without entrepreneurship, you may have a thing that solves a real problem, that works well, but fails in the real world.
Entrepreneurship helps us answer question like:
The exciting thing about today’s landscape is that so many tools exist to apply leverage to these areas. Less technical founders can learn low code/no code tools like Shopify and Zapier. Design resources have never been so abundant, and the practice of design so front and center in how we think about the process of creation. Powerful advertising and marketing tools like Instagram Ads and Hubspot exist to help distribute products online.
What this means is that no matter what your background is, you’re capable of making things, if you simply invest the time and effort to round out the areas you don’t yet know.
At Teespring, we used to say everyone’s got one good t-shirt idea in them. I’m pretty sure this holds true for all things.
]]>Consumer-first developer tools companies tend to shift to enterprise after product-market fit. Which is to say that once developers love a tool and bring it to work (the consumer bottoms-up adoption approach,) enterprises often need enterprise features — security, permissioning, on-premise, customer support, services-heavy integrations, fixed contracts and site licenses. A developer tools company that focuses on these could be said to be an enterprise company.
And in many ways, the description works. A company at this stage might hire an inside sales team. They probably have a VP of Sales. Their company milestones might be related, ARR or MRR. They may keep a close eye on monthly churn and cohort analysis to understand the health of the business.
That’s not at all surprising — I think the enterprise framing is the conventional way to think about developer tools companies. But one thing worth talking about is how market segmentation for a developer tools company is unique.
In Startups Should Be Deer Hunters, Mark Suster makes the argument that there are three basic segmentations of an enterprise company — startups and other small business (rabbits), SMBs (deer,) and huge companies (elephants.) You often see this segmentation in the board or pitch decks of any mature enterprise company (but with less hunting metaphors — I like the hunting metaphors.) You often find the top of that scale represented as Fortune 500, or Fortune 100, or Fortune 500, or FTSE 1000, usually whichever makes the company look more favorable. The bottom end might be personified (and oversimplified) as either YC startups or mom-and-pop.
But this landscape looks a bit different to a developer tools company with an enterprise strategy.
To grossly stereotype the Fortune 50/100/500/1000, these are large, “legacy,” cash rich businesses who in many cases have serious tech FOMO. Many of these have a core competency outside of software, or tech in general, and have done well by excelling in that area. Many Silicon Valley startups falsely assume these companies don’t innovate, and don’t care about trends in software development. That’s a tempting position to take, but it’s wrong. More on that later. The important takeaway for this segment is that the biggest hurdle is convincing these companies that they even have the problem you’re solving, at a scale that matters at all to a multi-$B annual revenue company. This makes Fortune X likely not the right target for a seed-stage developer tools company.
But there’s a glaring categorical error in using Fortune X as a blanket customer segment for devtools.
Whichever silly acronym you want to use, some combinatorial set of Facebook, Amazon, Apple, Google, Netflix are now topping the Fortune 500, but they operate very differently in relation to their peers. In most of these cases, developer tools that bring a big impact have already been built internally. Rather than the pitch to FAANG being about exposing an opportunity or problem, it has to be about buy vs. build for a solution they’ve already built. This possibly makes them the worst customer for many developer tools, and in fact, many of these internal tooling teams will spin out and start new companies that bring what they’ve learned building tooling to a startup of their own.
But there are other companies that don’t top the NASDAQ with a similar profile, and they don’t have a common name to refer to them.
Public companies like the ever-present Uber, Lyft, Slack, Dropbox, Square and very soon Airbnb similarly have internal tools teams, but have demonstrated a much higher propensity to buy over build than the tech companies of the decade or two prior. Tack onto this list a set of public tech and tech-forward companies that make the news a lot less often, e.g. Zoom, Stitchfix, Domo, New Relic, Twilio, Etsy — and the profile doesn’t change much. A similar set of companies exist who are big enough to have been public in a bygone era of more frequent IPOs — companies in a state which Matt Levine has often described as “public companies which happen to be traded privately.) At the time, he was referring to pre-IPO Uber, Lyft, etc. But today I might include Stripe, Flexport, Affirm, Brex, SpaceX, Wish, Zenefits, OpenDoor, Checkr, Chime, Juul, or really any multi-unicorn.
This set of companies belong in the same bucket, and if I were a venture analyst, I’d try harder to attach a name to these and quantify them on some long thinkpiece with 100 logos (and maybe I will,) but it doesn’t matter exactly who is on this list — and it changes often. The important takeaway is that these are the elephants of the devtools sales strategy, not the Fortune 500, or even FAANG.
I think there’s a lot to say about the implications of that, which I’ll save for another post.
The rabbits of Suster’s analogy are the thousands of Silicon Valley and SV-like startups. It may be appealing to try to build a channel to them through something like YCombinator. I think that’s a fine thing to do, but view it more as a great early adopter set to build features against. Sooner or later (and likely sooner than the A,) the enterprise sales milestone needs to be revenue and/or logos. Seed stage startups will provide neither.
This makes them bad targets for an enterprise focused strategy, (but totally fine early customers of your consumer-focused, bottom-up strategy.)
What most of the world means when they say SMB is the kind of business owned by a person who will ask Elizabeth Warren a question at a town hall. Targeting folks like this seems kind of absurd, but for the right kind of product, this could make a surprising amount of sense.
Fun fact: Only about 100,000 of the 4.4M software engineers in North America live in Silicon Valley. Build a useful tool for the rest, and you’ve got a big business on your hands. Of course, it seems to be the case that Silicon Valley is a tastemaker in software engineering practices. In some sense, we export programming culture in the way LA exports popular culture. More on that later?
This says nothing of the many tens of millions more who script Excel, write simple SQL queries, maintain a static webpage, or use markup in their CMS. I don’t even know if I’m excited about no-code. I just know that more people can write some code than almost everyone seems to think. There are certainly opportunities for many more tools built for that customer.
It seems obvious when you look at some companies whether it looks more like a consumer company or an enterprise company. But the reality is that most devtools companies are a hybrid. How do you know which one is right for the product you’re building? Or is it both, and if so, how much effort should you put into each strategy? How do you know when to shift tactics? More material for a future rant.
]]>Rather, I intend to call attention to an implicit assumption some firms are making — that developer tools are enterprise software. There is certainly an extent to which this is true. But it’s not my mental model at the seed stage, at least for most devtools companies.
The economics and growth of enterprise startups is well-understood, especially as the company moves into later stages. Mark Suster is one of the best bloggers on this topic. To be a bit reductive, the business depends initially on the founders building business-to-business (B2B) relationships with customers of the segment they intend to focus on. Then the company grows by bringing in an inside sales team, and their success is measured by a number of well-defined metrics such as lifetime value to cost of acquisition ratio (LTV/CAC,) churn rate, or retention cohorts. Their milestones are measured in annually recurring revenue (ARR.)
Consumer startups on the other hand are a bit more like magic! Even the most successful early stage consumer investors will say that they need evidence of mind-blowing, rapid, hockeystick-shaped, exponential growth to invest. The thinking goes (and again, this is reductive) that early on, a consumer startup’s growth is viral, word-of-mouth, organic. A more mature and growing consumer startup starts spending on advertising, content marketing, influencer marketing, TV ads, etc. to acquire customers. Often, there is no revenue at the beginning. And that sounds insane, but it is the story behind nearly every consumer success story from Twitter to Peloton. In order to predict the occurrence of raving fans, early stage consumer investors often describe themselves as keen observers of social trends and consumer taste, and may even style themselves as tastemakers or product experts. And among the very best consumer investors, it’s hard to argue with that.
Which of these sounds like the majority of developer tools and services startups to you?
When I look at a software product intended for software developers, I read the docs. I do the hello world. Sometimes I make a toy project. I’m looking for developer ergonomics, developer user experience, or as DHH might call it — programmer happiness. It’s often hard to describe to an outsider the difference between say GitHub and Sourceforge, or VMware and Docker. I’ve even failed to explain these to non-technical people today! You might even say the differences are intangible.
And software tools go through the same ups and downs of taste and trends, as you know if you’re a programmer with a few years of experience (or a Javascript developer since the last sea change looks at watch 5 or 6 minutes ago.) Beyond specific tooling, it’s even true that trends in developer taste and style change. Classic examples include the sinusoidal popularity of: functional programming, type checking, object-orientation, interpreted vs. compiled vs. JVM languages. Recall the popular Paul Graham blog post about LISP, which has been I think at least directionally, but not literally, correct.
Software tools also grow and scale like modern consumer businesses! Influencers in the world of programming exist, bringing their audiences from platform to platform, leading communities, giving talks, and sharing YouTube videos. Content marketing is super effective in the spread of developer tools. Look no further than Joel on Software, which propels growth for his companies even years after the new posts stopped coming.
But developer tools can also be enterprise software, and that’s the subject of tomorrow’s post.
]]>Specifically, seed-stage software seems quite overpriced, and late-stage everything seems overpriced. A low-confidence guess is that A and B rounds in 2020 will look like the best risk-adjusted return bets in hindsight. And "hard tech" will be good.
— Sam Altman (@sama) January 3, 2020
Well, I clearly agree! Our firm, Root Ventures, has always had the thesis of hard tech — and what we mean by that is technology that is difficult, where the founders include the necessary technical talent, the tech is often (but not always) unique and defensible, where we underwrite and take on technical risk, and the 12–24 month goals might be tech development.
What we don’t mean is deep tech, where science risk is primary. There will be major successes in deep tech, but we’re engineers, not scientists, so we’ll leave that to the experts. And there will obviously be tons of successes in consumer and enterprise software. But we think hard tech has the antidote to a lot of the recent problems in venture investing. Software still has the high margins that made the previous generation of multi-billion dollar startups successful. Often it’s defensible, and it leverages the talents that Silicon Valley is uniquely positioned to utilize.
So that raises the question — what’s the hard tech in software? Next blog post.
]]>