KPIs for state-backed venture in tech

If you are a place-based venture firm, how do you measure success? I think this is actually one of the trickiest conundrums out there. As the saying goes (and I may be butchering it), you are what you measure. 

The challenge in tech is that (a) tech workers are well-paid but generally used to living wherever they want, (b) tech companies generally are more human capital light than other industries, and (c) many tech companies fail. So: if you measure by "how many jobs did we create/retain in the state": there is an incentive not to back the high-risk, high-reward moonshots (because if they fail, you lose jobs!), but instead to back good businesses with capped upsides. (There is also some incentive to fund start-ups that maybe shouldn't be funded!) If you measure by "how many start-ups did we create," you run into similar issues -- you can have many start-ups, but most/all fizzle out. Perhaps you measure by leverage -- how many external VC dollars went into our companies -- but then that incentivizes competing in the latest stage companies. 

Ultimately, the question is "what does a tech start-up ecosystem look like, and how do you know it's doing well." This factors in a lot more than just VC money alone can provide -- e.g. the city itself has to be a place people want to move to -- and so the KPIs are challenging. 

The human as the tastemaker

 In my view of AI: (a) the AI is able to collect a near infinite amount of data on almost any topic imaginable, but (b) the human is still the filter that determines what is relevant. Yes, AI can and will get better and better at this, but "taste" will always be a human characteristic. 

My current excitement is around making the market map building process better. Some of this is rote (e.g. finding all the M&A transactions, finding all the companies in the market), but some of it requires a little finesse (e.g. which companies actually get included in the set? how is the market segmented? who are the incumbents?) A lot of this can be automated by LLMs ... but I do think there's still a surprising amount of judgement involved. 

One example: M&A analysts get paid big bucks to determine what companies should go into a comp set. Another example from the software world: a lot of coding is getting automated, but things like database architecture require a deeper level of thinking that AI can't do alone. This is because building a database (and many other human tasks) have no perfect solution and requires weighing trade-offs -- so they inherently cannot be completely AI'ed away. It's a little like saying that AI can, with 100% certainty, pick what you should have for dinner tonight or pick what your child's name should be. (That being said, some decisions that might've felt consequential a few years ago might now just be automated/abstracted away e.g. by using an all-in-one provider like Supabase.) 

Overall, though, it's becoming clearer that all the AI efforts now will eventually lead to a larger emphasis on humans as the tastemakers. They are the ones who will make sense of all the inputs, who will give a lens on how to interpret it all, and who people will ultimately trust. 

"Assistive AI": or, lowering the barrier to being better organized

There are many, many great use cases for AI (and many mediocre ones), but I'm coming to realize that one of the BIG use cases of AI is a technology that lowers the barrier to doing what you should've been doing already. 

In my case, it's getting all the stuff I read or see into nicely organized notes. For example, today when I was cruising on LinkedIn, I came across this post which included the image below:

In a dream world, I would have a file on my computer that was organized, and I would transcribe this info into it. The benefits would be immense: (a) I could recall specific pieces of knowledge across time, and (b) I could easily share this info with someone else without giving them a deluge of links to read. But, of course, few people are this anal in their treatment of data. The challenge is that you can read this one piece of info, but you may never actually need it, or you might just need the gestalt of it in your day-to-day work. Or if you need the same info, you can likely just ask Google or ChatGPT. 

Here is the test of what I've built this far: can it handle it? Can I just give it a prompt and have it find the companies, create them, and load the transactions?

It struggled to find a company's website, so it prompted me for it (great job, agent!), and successfully uploaded it:

Hot damn, it worked -- it uploaded all of these transactions to the "Quantum" market map that I created:

(Note: I've spent a lot of time building all these capabilities and building up the agent to get to this point -- and have hit a lot of bugs -- so exciting to see this work first time.)

This feels so small but so significant at the same time. If I can upload this info via chat, it'll be (relatively) easy to set it up via a WhatsApp chat, or routed to an email. Imagine -- I can just forward this LinkedIn link to an email, and let agents handle the rest of the information organization. Very small, but information -- and organized information -- compounds. 

If you give a mouse a cookie ... (CRM progress)

I read a recent post about how Draper's investment team used to run on 8 spreadsheets but now runs on a patchwork of tools stitched together. (For example: one Airtable page per company.) I'm sure this solution functionally works well, but it's made me realize that I think like an "enterprise engineer" -- almost the complete opposite of a start-up engineer. At Epic, I've spent nearly a decade thinking about "if we add this single line of code in the wrong way..." or "if we make this data structure look like XYZ," then it's not optimal long-term. In other words, the enterprise engineer's belief is that there are many nearsighted, wrong ways to solve a problem, but only a handful of good long-term solutions. This is in stark contrast to the "move fast and break things" ethos of Silicon Valley of yore, and to the "just vibe code it" ethos of today. 

I say this in part to justify my slow movement on building my CRM tool. The tool blossomed into much more -- I'm adding in market maps along with companies (public and private), investors, etc. One thing I am spending the most time with is the data structure, or how all the different entities link to one another. To make this more concrete: yes, you can have one Airtable page per company. But then how do you link an investor to it, especially when you consider that an investor can invest multiple times in the same start-up, out of different funds? Getting this data structure right is a pain in the ass, especially if you consider that the data is sparse (if you have a cap table, you have all the info, but most of the time you just have snippets of info -- and the data structure should work for either!)

Along the way, I also realized that a good tool should allow you to centralize and share preliminary information easily, something that investment offices I don't believe do well today. For example, if I review a data room or do market research, who knows what I've searched for? (Even I forget what I found, unless I take the time to write it out!) The only way to know is to ask me, and hope that I remember or have the time (and that I remember correctly). I think this is a hidden crux of a great tool -- make organizing my knowledge easy, and thus make sharing it easy.

So this has been the "if you give a mouse a cookie" scenario for my CRM tool. It's slowly blossoming into a more all-encompassing "system of record" tool that has all the info. The other thing I've always been interested in -- and have shaped up the "marketing" of it in my head: the tool should allow you to layer public info (e.g. public articles) with private info (e.g. private phone calls, confidential pitch decks, etc.) to create a tool that can TRULY manage a mosaic of information. This requires tighter auditing and control of what data came from where -- but if successful, can be a really cool tool that mirrors how people actually think. But! the hard part is the data structure -- and knowing that the hard part is the data structure! -- something enterprise-thinking me is stuck thinking about. So, hence the continued slow roll.