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.

Claude has a memory problem

 (^me working on my clickbait titles)

Claude (and ChatGPT) has gotten pretty amazing at conducting long-form tasks. But it still lacks a long-term, shared-across-the-entire-team memory, or what we used to call a "database." For example, I am doing research on X industry, asking Claude 10 questions in succession. Some of the links I click through and read (and don't like -- too low quality); some of content I disagree with and mentally ignore; some of it is repetitive or off-topic. 

Currently, there is no way to share the distillation of your thoughts. (Also - distilling your thoughts to just the essence is hard!) Claude (and other LLMs) don't make this easy. You can share a whole chat, but that is a huge pain to read through. You can Claude to give you a summary, but it sometimes doesn't capture things correctly. The only way -- at least, in my opinion -- is to transcribe the highlights by hand, and/or summarize it in your own words (i.e. old-fashioned reading and writing). I still subscribe to the belief that "writing is thinking," so the time taken to write is time well spent. 

In investment-land, institutional memory takes the form of memos (or investment decks). However, few places take the time to write up all the info on deals they did *not* participate in -- the effort is too high. The big opportunity, then, is lowering the activation energy it takes to turn research (i.e. reading an article, cruising through Google, skimming LinkedIn, interrogating Claude) into saved, institutional, and trustworthy memory. I think the workflow model that will work best long-term is human-as-curator (and AI as secretary and first-pass analyst). The big challenge is designing a workflow and data structure that fits, and the institutional buy-in to think this way.

Source / Pick / Win

 A little bit of introspection on being good at source / pick / win ... 

1. Sourcing is both "becoming commoditized" ... but also isn't. It *is* easier than ever to build AI tools to help list out all the companies in the known universe. It is *significantly* harder to get founders to respond to cold emails, without some sort of brand name or reputation (or in the worst case, a desperate need for cash). 

Nothing will beat having boots on the ground, spending quality time face-to-face with a founder, building rapport and telling your story. I've found a few start-ups that (a) I would've otherwise never found and (b) who otherwise wouldn't have responded to my emails. 

Sourcing is a learned skill, an extremely process-oriented step, and a very human process. It's one that I've been slow to uptake, but getting better at.

2. Picking is the due diligence. AI will be able to help accelerate diligence, but I believe good investment taste will be hard to find. The apprenticeship part of the business, one I continue to cut my teeth on (writing memos by hand, assisted with AI searches).

3. Winning is the very human part of it that will forever be human. Who do you want to be invested in you long-term? Who brings value outside of capital? Who do you trust? Who do you like? It seems crazy that you would take money from person A than person B just because you like being around person A and find person B annoying ... but that is a very real part of the process. 

This is the piece that spending 8+ years at Epic learning to build trust come in handy. 

VC Notes: Part ?

 Recently got looped into a conversation about a start-up in a little bit of trouble. Another fund (the lead) was spending a lot of time with it. Question came up: has the fund had any big exits yet? (Do they need this one to do well?)

Never thought much about this -- that a fund really really would like a few big early exits (because that helps raise the following funds, and a variety of other reasons). Incentives can get misaligned with start-up founders (or the success of the company). Weird behavioral quirk you don't think of if you're not at the table.

AI: a race to turn probabilistic into determinstic

A newer way that I've thought about the phase of AI and LLMs that we're in: it's a race to turn probabilistic/stochastic ("random") processes into deterministic ("not random") ones. 

• Easy example: adding two numbers together should use a calculator, not an LLM. Bad use case of AI.
• The company tracking suite I'm building out is built using the help of AI, but ultimately it's to build a strong database in the format I want, so that I can store companies, market maps, data, thoughts, etc. for the long-term. In my opinion, a good use of AI: turning a noisy, messy process (AI-driven coding) into something reliable (a deterministic database)
• LLM/agentic loops are all trying to build processes to reduce the error rate to close-enough-to-zero (e.g. double-checking/validation agents) or putting humans in the loop to bring it to "zero." The challenge is that you can reduce the probability of error close to zero, but can never quite hit it. I see this in the "document processing" realm -- we hope that the frontier models can read the PDF with 100% accuracy ... but for high stakes scenarios, would we trust it?

The art of investing == the art of cooking?

 If you only used recipes for cooking, do you really know how to cook? I say this as someone who seldom follows a recipe closely (which is why I don't bake), but does following recipes make you a good cook? I'd argue no -- it's all the smaller things: getting the pan to the right temperature, knowing when to turn the heat back down, sensing when to put keep things cooking for a few extra minutes, knowing what to do if things get a tiny bit burnt, adjust to different pans and stoves, etc. Yes, you can cook food by only following a recipe, but good cooks are able to both (a) fill in the gaps where the recipe is not 100% prescriptive and (b) adapt if things don't go 100% according to plan. 

I keep thinking about this through the lens of investment frameworks. On one hand, investors (and more generally, most people?) do a bad job of formalizing their thinking into easy-to-digest checklists. Investment frameworks push people to standardize tribal knowledge. (And, if you're a GP looking to raise from institutional money, you need to have some well-defined process, and a framework -- even if light -- accomplishes this.) On the other hand, a purely framework-driven investor would likely miss things. 

Whether frameworks alone can drive investment decisions is a core question in AI-driven investment diligence. As an investor, I believe most investors would say "no, there's some human element to it." It's hard to say exactly what they'd miss -- just in the same way you can't teach all the norms of cooking all at once. Sure, you could try to list everything out, but (a) doing that is very hard, (b) it creates an unruly-sized checklist that nobody would follow, and (c) new things always come up. Frustrating to me as a newer investor, but very understandable as someone who cooks a lot. Exceling at the earlier stages require a mix of framework, good coaches, and reps.

How I'm thinking about VC now

I think a lot about where a VC firm like CT Innovations plays in the larger venture ecosystem, as well as what types of deals are in our "sweet spot." The way I think about it now (which is sure to evolve over time) is that we are an agglomeration of many VC strategies all lumped under one umbrella. I'd like to think that most venture firms have one or two "founder archetypes" in its sweet spot -- but given our mandate of investing in nearly anything that comes out of the state, we have no singular archetype. The way I've come to think about it is a sort of mental accounting: many deals fit our portfolio, but some because with an economic/catalytic tilt and others because they are ones larger players (a16z, etc.) would be interested in. 

From what I've seen thus far, some of the archetypes I've seen and diligenced:

• Industry specialist, great founder, great business, "small" TAM -- Right now, I think this is our sweet spot -- a great founder (often repeat founder) building great businesses in a $1-5B market, too small for other venture investors to get excited (i.e. no "homerun," unicorn upside) but a potential for a great return. 
• High-growth potential unicorns -- Connecticut simply gets fewer of these high-growth, "hype" companies where valuations step up 2-5x between rounds. These are the a16z/Sequoia/Thrive archetypes -- super high growth potential, high valuations compared to revenue, "true" venture deals that can go 30x or 0x. 
• Catalytic capital -- These deals have an "impact" angle to them. By no means are these deals meant to be concessionary, though. CT has a host of amazing talent -- Yale/UConn professors across science and tech, as well as pharma and insurance expertise -- that have the potential to become great companies. We can be one of the first checks in on these deals. 
• Economic development -- Less often, we make deals in part for local economic development. 

At a higher level, the way I'm thinking about it now on the tech side is we invest in (a) good, solid venture-able businesses, (b) a few moonshots, and (c) a few true pre-seed companies. A really fun mix of companies -- albeit a bit disjointed for a "typical" VC firm -- whose strategy is driven by the natural restrictions of CT Innovation's mandate.

The curse (and benefit) of the Epic culture

 Working at a place for 8 years -- through your 20s -- really shapes how you view the world, how you interact with people. I think about this more and more the further I get away from my time at Epic (I left in Jan 2023). There's some quirks I've noticed about myself as I venture into the outside world, double-edged swords. A few of the things I've been thinking about are below.

Speaking with certainty / humbleness

We're trained to speak with our hospital customers with certainty and knowledge; better for someone to trust that everything you're saying is accurate, even if it means half your answers are "I'll get back to you." In healthcare, this works amazingly well -- it's a cornerstone of building long-lasting trust. Works less well in the real world / the investing world, where you can't possibly know everything and are rewarded for having an opinion.

It leads to a natural culture of humbleness (especially on the TS team) -- you're generally aware of your limits, and you constantly have to reach out to other people for help and expertise. 

Low/no sales

Our long-term technical support (TS) team has almost no sales that we need to do -- no upsells, no selling new products. If we ever do get to that conversation (say, of adding on a new module), we kick the demo and contracting to our implementation team. I believe it's an excellent model of support: we could just focus on fixing problems as best we could, and never had to worry about billing or budgets or upsells. 

I realize now it's a weakness I have now -- that sales muscle isn't there (for better and for worse!). For example: in the investment memos I've presented, I've focused on the facts of the investment, treating it like a puzzle to solve for us to decide on. Others do much better at "selling" their companies -- again for better and for worse. 

Replaceability

Part of the Epic culture -- for better or for worse -- is that everyone is replaceable. My cynical take: the genesis culture of this is that turnover is/was high, so you need to ensure that if someone leaves, you can replace them. This works well when you have to travel to a customer site or go on vacation -- you can have real back-ups to replace you. A lot of energy thus goes into ensuring that other people can easily know what you're working on, into educating others on niche areas of the software, on building redundancy. In some investment firms (and in some governance structures), this replaceability -- a focus on process, on sharing -- is not a focus. 

Deference

At Epic, we supported the hospital IT's team who supported end users (doctors, pharmacists, etc.) Thus, as Epic staff, my goal was always to make the end users trust the hospital IT team -- and ideally, never know that I existed (unless I came onsite). I would go out of my way to ensure that the hospital IT team looked like the heroes instead of me -- good for them, good for me. Same with newer team members: the quicker customers trusted the newbie, the quicker I could roll off; feeding the newbie answers was a win-win strategy. However good this may be for the org, the "leading from behind" strategy is not visible enough, especially when switching careers. It's a hard skill to unlearn.

"Build it yourself" mentality

Epic famously does not acquire; any tool you wanted, you had to build yourself. I feel the same way now -- I'd rather build a tool that works just how I want it than try to find a pre-existing software that does 80% and locks me in. A blessing and a curse.

High product-building capability

I've spent over 200 days onsite, which taught me how to think about designing a product to address real customer needs -- noticing small pain points, asking questions to understand larger workflows, figuring out which issues were root causes and which were a symptom of another larger problem. This is unanimously a good thing -- I like to think of it as the original Forward Deployment Engineer popularized by Palantir -- but it is devilishly difficult to put on a resume. Talking with another ex-Palantir engineer, it's a rare, subtle skill, but one that is very hard to boast about or verify (save being an ex-Palantir FDE).

VC Notes (Part 3)

"In investing, you're rewarded for having a point of view." 

Heard this recently, and it's a mindset that's been hard for me (and other STEM majors?) to adopt. In my prior roles, I was rewarded for being knowledgeable, not saying wrong things, and couching my uncertainty. In investing, the best speak with knowledge and conviction, but it seems the next best thing is to speak with conviction but not necessarily knowledge. To sound impressive -- or to have a view, even if ill-informed -- can take you further. Investors don't like to hear "I haven't done my research on that topic"; it seems they'd sometimes rather force you to glom onto a position. Obviously, there's a lot more nuance than that, but I'm slowly learning how to thread the needle of speaking like an investor. 

Gut investing

I wrote about this a little previously, but it also feels like there's some flavor of machismo in some corners of venture where people "trust their gut" and increasingly "learn to trust it more." I've heard it at least a few times, and I think it's something that uniquely exists in venture as something that people are proud of? You never hear a fundamental equities investor talk about their gut as the sole driver of decisions. Anyways, I hear it a lot, I agree with "gut" as a data point, but I think it behooves everyone to tease apart what "gut" means (founder charisma? founder anti-charisma? etc.)

What it takes to build a novel software (e.g. computer science research) is drastically different than what it takes to distribute a novel software

Perhaps it's embarrassing it's taken this long to fully comprehend, but the cool stuff that computer scientists are doing seldom translates to a successful software company, especially in age of AI. Cool algorithms or cool technology usually don't sell; "dumb" software with great distribution are what matter. Most of the MAG7 today are fundamentally "dumb" software with great distribution (save Google perhaps). I've become increasingly cynical about the software technology itself being any sort of differentiator; it's the people and sales channels that make a tech product pop.

Same goes deep tech, say in climate. Great lab work (i.e. science research) needs to be coupled with even better engineering to have any chance of survival. Sometimes it's not the best core science, but the one that can scale up better that wins. 

Syndicate vs. the more modern sole lead

Historically, VC investors looked for syndicates of other investors to share risk. The largest VC firms now don't need -- or want! -- syndicates; there's too much money that needs to be deployed. Instead, it feels like it's sometimes better to elbow others out of rounds. Almost has a PE flavor to it. 

Authentic differentiation

This is probably more through the lens of an allocator, looking at VC funds. (We recently had a day where we saw a few of our portfolio VC managers.) The VC funds that resonate the most are the ones where the point of differentiation feels authentic -- ties back to the person's past career, past predilections, or a difference in the way the GP thinks that manifests itself as strategy. Hard to describe without naming names, but something I think about more and more as I build my "brand."

Progress on CRM

I wrote a few weeks ago that I had started to build a CRM tool. I've made pretty good progress, but I've realized that it's less about the CRM itself and more about building the tools that I want to see, with AI/document processing at its core. I've come to remember that I'm opinionated on making the tools as easy to use as possible, but also insistent on clean audit trails and ease of troubleshooting, as well as clean data structures and modular code. 

What's done so far:

• Core data models -- I've built out the core data models and data tables into Supabase. Users can manually build companies, investment firms, and people into the system. 
• Document uploads -- Users can upload documents -- which can then create new companies, etc. in the system and link them automatically. I think this is the holy grail -- just upload documents and have it update your internal notes! 
• Audit trail -- I have a good audit trail mechanism built out, telling you how a company was created (manually vs. automatically), as well if individual fields were updated. May seem like overkill now, but I think a must longer-term (and something we can build on). Good foundations!
• Authentication -- started but not quite working. Google OAuth login enabled through Supabase. Something not 100% working
• Designed to be plug-and-play -- I've designed this to be plug-and-play for any investment firm. All you'd need to do is plug in a few of the company's own things (e.g. Supabase information, OpenRouter API key, and a few more things), and you'd be off and running! (This could also be deployed in a Docker and shipped to multiple customers!)
• Data pipelines -- Much of the data gets piped in from somewhere, on some sort of cadence. Examples: (1) some VCs look at a16z's website weekly to add to their sourcing queue, (2) CT Innovations could pull companies from the CT business registry weekly, (3) newsletters delivered to my email might contain start-ups I should check out. I have a simple data structure to schedule these pipelines, which will need to be built on with more use cases.

What's next:

• Vision of email-driven + automated workflows -- From what I've seen, investment workflows and communications are driven largely by email. Therefore, a good CRM should integrate into existing workflows, while having the capacity to augment them. What this looks like: the system tracks email flow, downloads documents (and automatically uploads them to CRM), and the CRM interprets where we are along in the process. A concrete example: if we're doing diligence on a fund, the CRM tool should (1) automatically download the pitch deck and supporting docs, (2) interpret them, (3) interpret and import important dates (e.g. expected closing date or other funds circled), and (4) ensure we follow up (either with a rejection or a request for updates, if it's been a few months since last communication). The system should drive the investor to do this, without having to configure anything additional in the system. 
• More granular company/investor data -- Next up from the data model side will be adding in things like revenue (for a single company), funds (for investment firms), and other data (portco allocation, percent ownership, cash flows, etc.) The challenge is finding a good, flexible data structure that can account for all the pieces of info you might want to store discretely. 
• Showing provenance of data -- Data can come from multiple sources e.g. public/published articles, hearsay from other investors, and source documents from the company itself. The system should be smart enough to track the data provenance -- revenue numbers from the company themselves are much better than a guesstimate from a published article, which are much better than a rough estimate. This distinction is crucial for contextualizing the system data (and thus for downstream AI processing)
• Handling Excel and better text extraction -- Right now, the text extraction (i.e. PDF -> text) is pretty good but not bulletproof, which'll be important for trusting the numbers. Likewise, we don't handle Excel yet. (Excel documents are universally tricky for LLMs to handle.) Both are fixable but more technical problems; better to get a rough version 1 of the entire system before honing in on these challenging minutiae. 
• Integration with other vendors -- So far, I have integration with Google OAuth for login. Perhaps some integrations with other parts of the investment stack (e.g. CRMs, knowledge management tools, financial tools) to allow this tool to orchestrate everything together.

What I've learned/observed about AI and sustained human superiority:

• Humans still need to make decisions -- I can use AI to help me build the data models and SQL tables, but I (as the human) still need to make decisions on how simple or complex the data models are. LLMs often over-engineer, so it's still up to me to set a good foundation by building a simple but strong core data model. (These data structure tradeoffs are nearly impossible for AI to handle -- it doesn't know exactly what I want to build next, so it doesn't know what foundation to lay!)
• A silly example: if we had robots that could build a house, we would still need expert humans to help guide us through the trade-offs (e.g. how many bathrooms, what materials to use, cost vs. quality of material, which type of siding, etc. etc.). No difference in engineering code.
• AI lacks taste -- For some decisions, like on UI layout, the AI adds a bunch of crud which makes the app look/feel distasteful. I'm no designer, but I think on many decisions, I have taste that AI will never quite be able to capture. 
• Humans know when to quit (and where to be creative) -- My AI coding agent was dogged in trying to fix a particular issue -- it tried to brute force its way through the problem, without success. After about 20 minutes (and a few failed updates), I pushed it to try a different solution.  (Technical detail: I asked it to make a synchronous call asynchronous, and update/centralize code to make this work.) The new solution worked well. It's a case where a human (me) knew when to say: "This is taking longer than it should, and I have other good ideas on how to fix this that match my longer-term vision better." This is also a case where knowing how the underlying system works is crucial -- if this were vibe-coded, there'd be no way to know the root cause of the problem, or approaches to fixing it. 
• AI coding agents are great at execution -- AI coding tools are very good at writing code. The more prescriptive you can be, the better the execution.

Claude Co-Work vs. In-House Tools

Just a month or two ago, the tech world boasted about how many tokens it burned (i.e. how large its operating expense was). That party didn't last long. The consensus now is that for many jobs, hiring a person is easier/cheaper than hiring an AI agent. 

This has been my fear with agents all along: (1) what kind of agent truly needs to run automatically 24/7 and (2) how many tokens would this eat up needlessly. Side note: I got burned with cloud hosting on both Snowflake and Databricks for a personal project -- billed for cloud/GPU capacity that I wasn't using at all -- so I'm more sensitive than most to trusting tech companies with my credit card.

I've also consistently heard great things about Claude Co-Work. I've been tinkering with building my own tools for a while, and I had a moment of panic: is there any use in what I'm building, or am I reproducing things that Claude (and thousands of other smart developers) are already building?

ChatGPT helped drum up where the tradeoffs are. I put them below, as a reminder to myself that in-house tools -- ones that you know how they work, that link to the data you want, etc. -- have lasting value. Maybe not as a venture-backable company, but real time-saving workflow value. 

Anyways, here are the top dimensions where building your own software really shine over what Claude (or similar) offers. 

Dimension	Claude / Chat UI	Custom Pipeline
Time-to-value	Extremely fast	Slower
Repeatability	Weak/moderate	Strong
Flexibility	Limited	Full control
Structured data extraction	Okay	Excellent
Audit trails	Weak	Strong
Multi-stage workflows	Awkward	Natural
Integration with database	Limited	Native
Cost at scale	Can become expensive	Often cheaper at volume
Vendor lock-in	High	Low
Human-in-loop review	Limited	Fully customizable

Intuition vs Process

In the investing world, there's a tension between intuition and process. 

Some of the "greats" that I've met seem to eschew frameworks or process. The thinking goes: process makes your lazy -- you think better if you start from "first principles" every time. On the face of it, it feels like it should be correct; great investors are great because they've had to teach it to themselves from the ground up. What makes an investor great is their ability to think and diligence. 

It feels like some investment firms (especially smaller ones) are designed with the solo investor in mind. There is no firm standardized process, no standardized sourcing pipeline, no general training. To do so would constrain the investor, who needs to use their gut to make their decisions (so the thinking goes). A framework would stand in the way of intuition.

However ... when you assess funds as an LP, a lot of focus is on process: can we trust this manager to produce alpha, and do they have a replicable process? To assess this at larger investment consultants is the other end of the extreme. The investment framework is truly a process, a 200-plus-line Excel spreadsheet of investment criteria which is then synthesized into a memo. The intuition purists would say: yes, you've checked every box, but you've missed some je ne sais quoi about the investment, something not in your checklist that makes it stand out (or makes it fall apart). There are parallels to Atul Gawande's The Checklist Manifesto, where checklists improve surgery (and air flight safety) despite being initially despised by surgeons (and pilots, etc.)

All this to say: the investment firms that will be most successful with AI will be those that translate process into software-codified systems -- i.e. investment in AI will be all about process. One example: right now, as a firm, sourcing at some places feels spontaneous -- every investor has their own set of connections, resources, rules, etc. Some of this could/should be codified in agentic workflows; I've started to collect a list of "high quality" sources (e.g. a16z speedrun, etc.). Another example: we have a light investment memo template, but many questions are asked beyond what the template contains. These questions should ultimately be subsections of the template, which can then a yardstick by which to measure investment diligence. This means updating a core investment framework template, to ensure that that questions is answered every time. 

On one hand, I hate it -- filling out a 200-question survey (and adding questions to it) seems to take the joy out of reading, learning, and investing. On the other hand, it's a bit embarrassing to miss certain pieces of diligence over and over again. And as a newer investor, it's a bit bewildering to be given tens of documents to read, without a rough mental framework in mind. 

Ultimately, I'm coming to believe that "investment experience" might just mean "I've built a really solid investment framework in my head." It means you know where to look first when doing diligence, or what the top questions are to ask -- those sections of the framework are raising red flags. So why not hand out this framework to earlier-career investors? I think it's ultimately what we'll be training investment LLMs on, a long-time reckoning that investment process is essential.

Beginning a larger project: creating a CRM

 I've been putting off creating a CRM tool, but I think it's about time. Maybe CRM is the wrong word: I need a tool to store info about all companies, investors, people, etc. to be able to build on down the road. The tipping point: I want to create a sustainable sourcing framework that scrapes data from X source weekly. (Again, I am too "lazy" to do this weekly myself -- I'd rather list all the sources I want to pull from, and have it run automatically.) 

Part of this project is to see how long it takes to build something like this. I know a lot of folks are building these kinds of tools in Notion, but who wants to build a "Notion database" when you can build a more robust SQL one? I also think this sort of tooling is going to be critical scaffolding to build other AI tools on top of (e.g. document processing). 

My full vision makes this a little clearer:

1. Create core data models. Create data models for "organizations" (companies and investors), funds, people, programs (e.g. a16z speedrun, DARPA) and cohorts, as well as all the relationships between them (company-to-person, investor-to-company, program-to-company, etc.). Allow users to create/update these. All built in Supabase (backend), frontend in Streamlit (for now).

2. Create data pipelines. Populate companies from websites. For example, a16z speedrun cohort 6 was recent; the pipeline should be able to pull from their website and pull companies and relationships.

3. Audit trail. See who updated the companies (pipeline? user?) 

4. Add authentication, other usability tools. Let users log in via Google, email users when things are updated in the pipeline, make the scheduler work.

5. Add in investment details and company details. Right now we have the basics (basic company demographics, binary on whether an investment was made). Expand out to support a more full investment structure (e.g. X invested $Y in Z in Series A) as well as more robust company reporting ($X in revenue in 2025, etc.)

6. Add database partition? Find best way to make the database specific to a single investor, so that you can layer on multiple companies who can't see each others' data? (And try to stay in Streamlit for simplicity?)

6. Add in document processing. This is where it gets investor-specific. Process documents to extract revenue, investment #s, etc.

7. Add in other fun workflows? Allow users to connect their emails so you can see if you've emailed X company? Layer in automated meeting notes?

Hoping to be able to get through #1-3 this weekend; would be great proof-of-concept. The hard parts: database design (need well-designed database to withstand all future additions I'm planning!), knowing how to layer in the additions, knowing which order to tackle these in, knowing what the benefits/weaknesses of the tools (like Streamlit, SQL, scraping tools, etc.) are, hoping Google Antigravity is able to suss out what I want it to build with my instructions. 

The various modes of investment work

I've worked on a few deals in the past month, and I now finally have a lull to think a little more about how to use AI to automate/replicate some of the work I've been doing. I've been thinking a lot about the types of work that I do. Investment memo work falls into a few buckets:

• Information distillation - given a data room of information, distill it down into the main points
• Information search and aggregation - given a topic, try to find as many pieces of info on it and aggregate them together
• Information verification - given a piece of information, verify whether it's correct 
• Financial analysis - digging into the historical financials as well as checking the assumptions in the financial projections
• Anomaly detection - given a document or set of data, see if any piece of it is off/wrong
• Interviews with founders, experts, customers, etc. - requires a lot more EQ and conversational skills, but also preparation to tee up the highest impact questions for the investment (and the best fitting questions for the interviewee)

This all feels a little abstract and unnecessary, but teasing out these modes of investment work is the way a developer would look to approach a broader fix to the problem. And, more importantly: AI is going to be used in a different way for each of these modes of work. I think that LLMs are sufficiently strong where a lot of problems can be resolved through clever infrastructure (i.e. not just throwing everything into the chatbot and hoping it does everything we want). 

Some examples of the investment memo process that are particularly time-consuming:

• Industry background - a lot of "information search and aggregation" -- Googling, ChatGPT'ing for trusted sources, listening to podcasts, reading consultant market maps, etc. Requires a lot of exploration and breadth; feels a little like climbing a mountain, and the surrounding landscape becomes clearer bit by bit. 
• Competitors - "information search and aggregation" -- Google/ChatGPT for competitors, then look up info on each of them (market niche, traction, last fundraise, etc.)
• Public comps and recent M&A - "information search and aggregation" - Google/ChatGPT for this info, then look each up (e.g. in Bloomberg/Yahoo Finance for public comps, internet verification for recent M&A)
• Company (e.g. team, product, GTM, moats) - "information distillation" -- taking the whole data room and compressing it into a few pages of info. There's additional critical thinking (e.g. does their GTM actually make sense? are the moats really moats?), but otherwise a lot of depth here.
• Term sheet review - most terms are typically standard (or within reason), so this is both "information distillation" (taking a 30-page legal document and boiling it down to a few key points) and "anomaly detection" (seeing if there are any particularly egregious or atypical terms). 
• Traction/Financials - "Financial analysis", but then a lot of critical thinking and gut-checking on top of that.
• Investment benefits and risks - this feels like it should be a lot about "gut" ... but I think an LLM could surface many good benefits/risks (and a human could then review and prioritize them)

I've been working on a verifiable, AI-driven "information distillation" process. Given a data room of information (or a pile of industry reports from McKinsey plus a few internet articles I dug up), can I get the AI to synthesize the info rooted in the files I give it? 

Part of me feels a little foolish for doing this: the Googles and Anthropics of the world are already doing this, and they have teams that are much smarter than me! However, I think the tech giants are solving a fundamentally different problem. Their chatbots are generally interested in: "can I answer any question given to me well?" and "if the user uploads documents, can I answer any question he asks about it?" The challenges are at least twofold: (1) the chatbot has to retrieve info about any topic I might throw at it, and (2) it has to be able to answer any question I ask. 

My little tool is much simpler: given documents, read the info and file it away neatly into folders that I ask it to. The process looks something like this:

• Go through each document and extract information relevant to different buckets I give it (e.g. "company background," "team," "moats," etc.)
• After processing all the documents, take one final pass to synthesize the extracted data together

Advantages: 

1. You can apply this process to any document in the data room (just need to dial in the "folders" you file info into)
2. The extracted info and process are verifiable (unlike typical LLMs which are black boxes)
3. You can apply this process to many use cases -- just swap out the extraction schema and synthesis prompt

I'll have another post with more details, once I tidy up the development.

1. 
   

AI pulse check

 Tech is changing week to week, so seems like it would be good to journal the in-the-moment sentiment. Tech news — especially those that get clicks — tend to be sensational, absolutist, … and conveniently, good marketing for tech products. 

Token consumption: one thing I remember hearing a few months ago was “don’t think about token count at all when you build, LLMs will get continue to get cheaper and go to zero.” I was a little skeptical — I’ve gotten burned on cloud hosting costs, and am skittish about letting pay-as-you-go LLMs go unchecked. There’s been some pullback on this sentiment: (a) agents run amok, churning through tokens without real value, (b) announcements of companies trying to maximize their token usage, a clearly misguided goal, (c) realization that smaller models (and gasp Chinese models) may be good for some use cases, and (d) the realization that cheap tokens are subsidized by VC money, and over time prices might increase just as Uber prices have. 

Pure vibe coding enthusiasm also has been tempered. The market believed (believes?) that vibe coding would end SaaS, but hitting the realization that software is ~20% code (the rest is infrastructure, marketing, support, installs, etc). I buy that vibe coding is lowering the barrier for designers to build MVPs, but I don’t think it’ll be able to build full apps well within next few years. Too many software architecture decisions etc. that will be hard for it to do.

The hot topics on my mind today: 

- Claude Cowork — I need to explore this more; it’s gaining early adoption. I’m little nervous about it having access to all local documents, but I can see the appeal of having one provider access to all your docs.

- Skills — excellent marketing term for a “template of instructions for the LLM.” Lowers the barrier for LLM entry, adds abstraction in a way non-programmers can understand. Need to play with this more to see if there’s more to it than that. 

- Process and clear instructions — interestingly with “skills,” the hard part is the boring stuff: process, governance, clear instructions. I heard one good analogy: treat AI like a new employee — you have to onboard it with culture, rules, norms, all the boring stuff. I think this will continue to be a trend; humans will be more and more important, just doing (what is to me more) boring work. But AI as with great companies: governance, structure, feedback win.

- Death of SaaS — world still seems split on whether SaaS is dead. Maybe it’s moving from a seat-based model to an outcomes-based model? I think one way SaaS dies if if (a) you can build your own software or (b) there comes along a superapp that can do everything for you. I’ve tried (a), and that approach may work for a small subset of technical people (who probably were building their own tools pre-AI). I could imagine a world where all computer commands are routed through an Anthropic or OpenAI who has access to your whole digital world. Hard to tell now if this will be mass-adopted or just confined to the most technical. 

Example of AI coding speed + implementation

My start-up, Transpose Health, has a core data conversion engine, but data work also has a lot of random stuff that needs to be done. AI coding has been transformative for this. What might've taken a few hours to code (and test) now takes a couple minutes to prompt ChatGPT for, then a minute for it to code. 

My prompt:

write me a python script that: 

 - opens up <excel file> (an excel file) 

 - loops through all CSVs in <folder> that are CSVs and do not contain the word "Copy" (table 2) 

 - inner joins table 1 to table 2 on "Legacy Rx" and "PrescriptionNumber" (to only get the rows from table 2 that are in table 1) 

 - prints out all of the messages from the "hl7_str" column in table 2 into a txt file (separate the "hl7_str" rows with a return character)

Of course, ChatGPT was not perfect the first time around. I had to (a) prompt ChatGPT it to be less verbose (I needed a quick-and-dirty script I could review quickly, not an industrial-grade one), (b) run the script, (c) debug it (it had a small bug, so I had to do a deeper code review), (d) then test the outputs and iterate. Overall, the end-to-end process took ~30 minutes, but I saved significant time and brain energy on the coding part. 

(Interesting that my value-add shifts from understanding/writing the code to understanding how to prompt the LLM and QA the outputs. In other words: AI is taking all the technical implementation work from me, for better and for worse!)

AI: the boring things will be the most valuable

 I've been writing quite a few memos in the past few weeks, poring through data rooms with tens or hundreds of documents. I think I'm in a unique spot because (a) I love poring through data rooms (perhaps spending too much time on it), (b) it feels like many parts of the process are slower than they should be, and (c) I know that some of the pieces could be done by LLMs. 

Some concrete examples from VC: company background, IP, founder background, cap table, and past funding rounds are all pretty time-consuming, as well as a little tedious/rote to write, low on the time-to-value scale. (I'm more often than not annoyed that I have to dig through legal docs to get the investors, amounts, terms, etc. from prior rounds -- can't AI do that yet!?)

= = 

I've spent more time than the average person thinking, "If I were to write a program to do my job, how would I have it do my work?" (This pursuit of abstraction -- from real world to code -- is what software development is all about.) It turns out, when I'm writing an investment memo, I have a generally set rubric of questions I'm trying to answer. The largest, most institutional players (like NEPC, $1.7T AUA) have frameworks and checklists to make sure that you're hitting all the boxes. For me, these frameworks feel a bit boring, but it's hard to touch on exactly why; perhaps in my imagination, investment research is a creative endeavor that can't be done by checklist alone. Or perhaps, it's that nobody is excited about process -- which in this case can mean a 200-line checklist. 

But ... this framework approach approximates how humans think. I have a list of sections that I need to fill in, and each successive slide deck or Excel or article that I read adds some piece of evidence to one or many of these sections. To make it less abstract: let's say I'm researching low earth orbit satellites, and my goal is to write an industry report. My sub-sections might include: market segmentation, market size, growth drivers, demand drivers, regulatory/policy, and market risks. I might read a few McKinsey market reports that fill in some sections, then a policy report, talk with an expert, then review a few pitch decks for LEO start-ups. With each new document, I gather information for each bucket, then after I've reviewed everything, I synthesize it together, weighing the most trusted resources more highly. The process never happens this clearly, but I believe it's replicable steps that most people follow.

This same general framework -- read documents, extract relevant data, organize data into framework, resolve data conflicts, and synthesize a final analysis -- are what most knowledge work seem to follow. Breaking it down this way gives us a chance of replicating the steps with AI.

Why are LLMs not good at this out of the box? I'd argue that LLMs are general-purpose tools, built so that you can ask any question you want. Tools like Google's NotebookLM are excellent at this -- feed it documents, and ask it anything. Investment research -- and most knowledge work -- fundamentally has an end goal or question, and the framework/process that you use to get to the answer is "tribal knowledge," typically not well-documented and slightly different firm-to-firm. This "tribal knowledge" is what the LLM lacks out-of-the-box, and what I think can be codified for success.

= = 

The knowledge extraction process then becomes:

1. Read documents,

2. Extract relevant data points,

3. Organize data into framework,

4. Resolve data conflicts, and

5. Synthesize a final analysis.

Each step has its own technical challenges. For example, finding relevant documents can be difficult, as is reading them (reading slide decks, especially graphs and charts, is not easy for LLMs today). I believe the most valuable piece, though, is creating a knowledge framework, documenting that "tribal knowledge." The more we use AI, the more we'll realize that for most companies, value will still come from the boring things like process, documentation, and frameworks.