Categories are about the what, but the how matters too.

Next week, I’m going to do a big reveal about why I’ve been writing this series on how biotech teams find (or fail to find) the software tools they need. But that’s next week. This week, I want to take one more pass at this question I’ve been exploring about how categories of software emerge, and what to do until then. My current theory, which I’ve come to in the course of writing all of this, is that categories are mostly defined by the goal the software is trying to accomplish (the hole in the wall), but we get tripped up because we tend to think about them in terms of the functionality that allows them to accomplish that goal (the drill).

Take, for example, the category of Electronic Lab Notebooks (ELNs). If you were to write down the kinds of functionality that’s included in an ELN, the list would include the log of what happened in the lab (the lab notebook itself), the inventory system, the sample registry, the registry of assays/lab protocols, maybe tools for designing plate maps, and so on. Yes, each of these is built around an outcome. But in the grand scheme of things, they’re all intermediate components of functionality that enable a larger goal the user is trying to accomplish, namely supporting the operations of a lab doing early discovery/exploratory work.

In other words, what puts a piece of software into the category of ELNs is not which of those components of functionality it includes. It’s whether or not it supports that larger goal of supporting the operations of the lab. The different components of functionality help determine how will it accomplishes the goal. But if there was software that supported the operations of such a lab through completely different set of functionality, the team making the buying decision would still evaluate it based on how well it would support the lab’s operations. And they would compare it to other “traditional” ELNs based on those outcomes. So for all intents and purposes this software would still be an ELN.

Incidentally, by this logic I would define a Lab Information Management System (LIMS) as software whose goal is to manage the operations of a lab doing repeatable/production/high-throughput screening work. That’s a different goal (if only slightly) so it’s a different category. Of course, accomplishing this goal involves a lot of the same functionality as an ELN, plus there are a lot of labs that are either doing both exploratory and production work, or doing something in between. This is why the two categories tend to bleed into each other.

But even though we have these two distinct ways of thinking about these categories (goals vs functionality), it still mostly works because as a community we’ve agreed on the standard set of functionality that maps to the goal.

New categories arise when new goals emerge, such as supporting ML and comp bio teams. Or they can shift when there are new ways of mapping functionality to goals, such as new ways of collecting and evaluating data across multiple assays (functionality) to make strategic scientific decisions (goals).

But as these new goals emerge and as we settle on the canonical functionality to achieve each goal, we need to make sure we distinguish the two. Because while the functionality is important, the category is defined by the goal.

So, I know this is getting kind of abstract. But I promise I’m going somewhere with this. And if you stay tuned for the big reveal next week, you’ll see exactly where.

---

Thanks for reading this week’s Scaling Biotech! I really appreciate your continued support, and I read every comment and reply.

As a reminder, I offer several services to help connect biotech teams with tools, practices and expertise to make their organizations more data driven.

• For Biotech Startups: Sign up for a free consultation call to clarify a problem you're facing and identify the best options to evaluate.

• For Software Startups: Add your application to the upcoming launch of the Biotech Reference Stack so your target users can find you.

• For IT/Informatics Consultants: Learn how Merelogic can help you write white papers and case studies to define and demonstrate your specialized expertise.