A few months ago, I completed a year of investing full time as a venture capitalist after several years as an operator. I had written 10+ angel tickets before, so thought I knew 'the game' but its actually quite different. Writing down a few notes to myself here:
Over the weekend, Tobi, the founder and CEO of Shopify, discussed the major reason investors passed on Shopify in the early days : market size.
I remember that financing round, & I remember having the same concern, & making the same mistake. Living in the valley & driving on 101, the billboards & logo-adorned headquarters of successful companies provide a daily infusion of all the mistakes in I’ve made in guessing how a company or a market might evolve.
Years later, I listened as Bill Gurley shared his thoughts about market size. He asked himself a question : whether the startup was increasing, decreasing, or maintaining the market size? (I can’t seem to find the link - but I have it in my notes!)
I added that question to my diligence list when meeting startups.
Now much later, having seen many companies create categories or reinvigorate aging ones, the question I ask myself has evolved.
It’s not as the market size large enough? Instead, it the question is : do we believe this company can create the market?
Market size is the output of all the players marketing, selling, building. Their efforts alter, distort, & juice the supply/demand curves of macroeconomics. It’s not a given - not an output or a steady-state CAGR.
Often it’s the startups that engender the demand, change the market dynamics, & make markets massive by taking risks with products.
When done right, these founders create category-defining businesses like Shopify (now worth $90b)!
# scheduling workloads to run on humans
Some computational workloads in human organizations are best "run on a CPU": take one single, highly competent person and assign them a task to complete in a single-threaded fashion, without synchronization. Usually the best fit when starting something new. Comparable to "building the skeleton" of a thing.
Other workloads are best run on a GPU: take a larger number of (possibly more junior) people and assign tasks in parallel: massively multi-threaded, requiring synchronization overhead. Usually a good fit for later stages of a project, or parts that naturally afford parallelism, comparable to "fleshing out" a thing when the skeleton is there.
There's some middle ground here - sometimes you can imagine a multi-threaded CPU execution of a small team collaborating.
A good manager will understand the computational geometry of the project at hand and know when to delegate parts of it on the CPU or on the GPU. One notable place where the analogy breaks down a bit is that the worst thing that can happen when you misallocate computer resources is that your program will run slower. But in human organizations it can be much worse - not just slower, but the result can be of lower quality overall, more brittle, more disorganized, less consistent, uglier.
The most common stumbling point here is trying to parallelize something that was supposed to run on the CPU. In the common tongue, this comes from the misunderstanding that something can go faster if you put more people on it, usually leading to outcomes where something is "designed by a committee" - not only is the thing actually slower, but the philosophy is inconsistent, the entropy is high, and the long-term outcomes much worse.
The opposite problem is more rare and usually looks like someone doing something repetitive, uninteresting or tedious, where they could really benefit from more help.
I think this is one accidental advantage of startups - they lack resources of large companies and run compute on powerful CPUs, winning in cases where that is the right thing to do. Larger companies, especially in cases where something is deemed of high strategic importance, will almost always reach for too much parallelism.
TLDR: Think about your project, its computational geometry, its inherent parallelism, and which parts are a best fit for a CPU or a GPU.