Software categories come from nails, not hammers
Ok, I’ve been dancing around this week’s topic for the past month or two, but I think I’m finally ready for it. I’ve been exploring why it seems to be so hard for biotech data teams to find and adopt commercial software, and while I’ve alluded to (maybe even mentioned once or twice) this particular reason, I’ve been putting off addressing it head on. Well today’s the day: It’s time to talk about categories of biotech data software.
When I work with a biotech software startup on their go-to-market strategy, the first step is always to understand what categories they live in, in order to figure out how potential users will think about them and what they’ll compare them to. What makes this difficult (and for me what makes it interesting) is that most of the startups I work with don’t fit into any obvious, cleanly defined categories.
When it comes to software for the lab, there are commonly used, if not precisely defined categories: ELNs, LIMS, inventory systems, compound registries, etc. But when it comes to software supporting the data side of the house - computational biology, data science or whatever you want to call it - we’re just not there yet. There are areas where we’re starting to see multiple similar options, such as software that helps you run bioinformatics pipelines, but we haven’t settled on names for these categories. Everyone else seems to be a category of one.
But are they?
For every startup that I’ve done this exercise with, were were eventually able to place it into one or more categories. And we did it by looking past the explicit functionality - how it worked - and focusing on what it’s replacing.
If you’re building software that someone needs, that person is already doing something today to meet that need. It may not be efficient. It may not be pretty. It’s probably a Rube Goldberg machine of Excel sheets and post-it notes. But it’s not like they’re throwing up their hands and begging the universe for a solution that only you can provide. Your software may allow them to get the work done faster and better. But with or without it, the work is getting done.
(And if the work that your software enables is not important enough for them to hack together that Rube Goldberg machine, it’s probably not important enough to spend money on.)
So the way we come up with the categories for software in a category of one is to look at the problem the user is solving (the nail) and what they’ll no longer need to do once they adopt the software. What you’re replacing. Once you understand this, you can understand how potential users think about the problem and how you can communicate your solution.
Sure, having canonical categories might be easier. And we’ll get there someday. (More on that next week.) But until then, I’ve found that communicating about software in this space should start by thinking in terms of nails, not hammers.
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.