There is no low-hanging fruit
***** A quick plug: I recently began piloting a workshop to help early stage biotech startups select data tools and infrastructure, and define consistent work practices that will get them to the next inflection point. While I’m rolling it out, I’m offering a 40% discount to anyone who applies before November 22nd. Check it out here. *****
Those of you who have been following this newsletter for the last few months will recall that I’ve been exploring the different use cases that software for biotech needs to support, working backwards from writing an IND. Well, I think we’ve now gotten through more or less the whole thing. There might be another step or two I’m forgetting about, probably a handful I missed along the way, but there are a bunch of other topics I’ve been itching to post about. So I’m going to call it here. This week, I want to summarize and reflect on what I’ve learned from all this.
I started the series after a number of conversations with folks who had recently founded, or were in the process of founding, software startups serving biotech. These conversations all felt very similar, and all focused on the question of how to find the right problems to solve with software. These founders mostly fell into one of two buckets:
The first kind had spent the last few years building software internally at a biotech startup, realized that they were building the same internal tools as lots of other biotechs, and wanted to build the one version that everyone can use.
The trick for these kinds of founders is to understand what aspects of their experience and the tools they built were general to a large range of potential users. How do you balance building something that will closely fit a few customers’ needs against building something that will support a lot of different customers?
The second kind had been working outside biotech, had heard that biotech software is bad and wanted to help make it better.
These founders are starting from scratch, usually having as many conversations as they can to identify the low hanging fruit. The implicit assumption is that our software is bad because we don’t have enough engineers, so they just need to pick a problem off the backlog and solve it with engineering. There’s nothing wrong with starting from this assumption - that was me four or five years ago. But the ones who stick around realize that our software is bad for other reasons. Plus, if there was a readily available backlog of low hanging fruit, a lot of people (including, probably, me) would have already founded their own software startups to pick it off.
Which is not to say that founders aren’t building software anyway - there are a ton of really interesting new software-for-biotech startups. It’s just that none of them are picking off low hanging fruit.
There are some categories like ELNs designed for modern data teams, or biotech-focused analysis platforms that feel like low hanging fruit because they’re easy to define. But they turn out to be extremely difficult to get right - not only from a technical perspective but in terms of how it fits into their users’ broader workflows. This isn’t just “build it and they will come.”
Then there are startups like Kaleidoscope and Briefly that are creating their own new categories. They’re seeing a need before their users see it, which can be a very successful strategy in the long run, but very difficult in the intermediary.
The point of all this, for any readers contemplating founding a software startup, or maybe if you already have: I don’t believe it’s enough to find some low hanging fruit that a group of users already recognizes as something they need. It isn’t enough to give them a tool that simply fits in with how they work today. For biotech startups to leverage data effectively, they need to fundamentally change how they work, beyond just the tools themselves. Good software will enable and even drive these changes. This means you need to identify the problems and pain points your users aren’t even aware of and build something that will allow them to work a better way.
This won’t be easy. But if it was, someone else would’ve done it by now.