What's Wrong With Lab Software?
Inspired by reading “What’s Our Problem” by Tim Urban, and by ongoing biopharma client engagements helping to identify implement new or fix existing R&D informatics systems, I thought I’d take a stab at a cartoonish approach to explain where we are as an industry.
Current State
Selecting commercial products is challenging because many disparate tools are required to execute the scientific operations throughout biopharma R&D. In the interest of keeping this article focused on how we got here, I will sum up the current state by sharing the sentence that my clients and I say multiple times throughout any implementation or update project:
“All this effort to find the least bad option and then it will cost us a fortune to be locked into these vendors”
This is 100% True. Time and again, this is the case. If you are a consumer in this world, you are nodding your head. So how did we end up in this situation? After many years as a customer and a few years as a vendor in this space, I have arrived at this hypothesis which I’ll share in a cartoon-ish format:
The Flywheel Effect We Don’t Want
Many are familiar with the flywheel effect which perpetuates company productivity or growth, but the flywheel that biopharma customers and lab software companies participate in slows progress and perpetuates mediocrity.
A Widget is Born
A technical founder (who may have even spent a decade within an R&D team) identifies a widget needed in a disparate industry. The life sciences R&D software is a very red ocean, yet opportunities abound for a widget which performs some function in a “newer way”. Due to the fact that every company does everything slightly differently…actually, expand that statement…every function within every company does their process differently. Impact: making a product which does the same function as an existing one but with a different user flow and style can find customers willing to buy. The complexities of market fit in such a heterogeneous customer landscape are not clear in the market analysis we use for funding, so the TAM is always good.
Sales: Lost in Translation
The product reaches a (subjectively determined by investors like any startup) state where sales occur. This is a very challenging sales environment for several reasons.
- Each set of users has a slightly (or significantly) different process where your product needs to fit.
- The sales engagements are to people with a very narrow point of view. Extensive details about their specific function and no attention to how this product will fit into the broader organization. If there is a scoring rubric, the latter is an afterthought filled out by someone in IT who likely is fighting 20 other bigger battles and won’t push back on this one.
- Your product enables a certain process within R&D. Often it is a far more efficient process than what the buyers have. Unfortunately, the buyers are NOT willing to modify their process because that takes much more effort than demanding you modify the product.
At the end of the day, let’s remember what sales is. A sales team has the job of increasing the revenue number on the product company’s profit and loss statement. They get paid commission to do that. NO incentive exists, and likely it would be impossible given today’s biopharma culture, to tell the customer that the product was made for an optimized process which the customer needs to adopt.
Burning Down the Backlog
First, let’s set the cast of this scene. A sales representative who works on incentive compensation which is earned only when a sale closes (no math for post-sales effort or impact). A product manager who must balance all customer needs incoming from sales and customer support. A “barely enough” or “barely insufficient” software development team who still has “MVP technical debt” they can’t get to. The impact of this environment, which is true of every enterprise software org I’ve ever had deep exposure to, is that the backlog (the prioritized list of tasks which software development works on for the product being sold) is prioritized into two categories:
- The “Fires” - the biggest, newest sales followed by the biggest threats for non-renewal make up this portion of the backlog.
- The rest - the rest of the backlog is made up of features to address technical debt (tradeoffs made to accelerate the delivery speed of the existing product knowing it would cause problems eventually), existing customer feature requests, sales enablement features (typically UI enhancements or features to unlock new market segments).
It is easy to imagine what happens here. The “Fires” are addressed in the fastest way adding to the technical debt. Consequence - products which meet the needs of a customer for the first year after sales then never change or improve (sounds like our current state, right?)
Non-accountability
First, I must acknowledge that enterprise lab software customer success teams are a phenotype I respect tremendously. I’m not sure how people handle walking into “battle” multiple times per day with no armaments. What do I mean? They have no control over product development resources, they have no control over what a customer was or wasn’t promised during the sales process, and they typically have no control over the pre-release testing process for the software. Second, I must also point out that their role is effectively to prevent customer attrition without actually resolving the reasons why a customer wants to leave. Effectively the role of customer success is to absolve the product company from any commitments to improving the product. The thing is, this is fully accepted by the customers because the users use their problematic software as accountability shields themselves internally and they certainly don’t want to be accountable for such disruption as switching software products. The system is designed to maintain the status quo of bad software products.
Our Tools Block Our Science
More than anything, R&D is about data. The entire scientific method relies upon creating a hypothesis, testing that hypothesis, and learning from the conclusion. Also known as the Design-Make-Test-Analyze (DMTA) cycle, scientific success depends upon the quality of each cycle and executing the cycles rapidly to meet your goals. To make matters more complex, the global structure of research where new ideas are created in tens of thousands of academic institutions then adopted by a few hundred industrial biopharma companies, means that this cycle changes rapidly. I often say that the only guarantee in science is change (and no, the irony that science is based upon principles which have not changed in centuries is not lost on me). The problem is that the tools we use to manage the most important asset (data) are outdated when released and don’t evolve with the scientific methods and procedures. I find time and again in organizations that their tools are preventing scientists from doing the experiments they really need to do.
Groundhog Day
Despite the discussion above, we do still see new products showing up in the market. The typical way in which these start; however, is not reducing complexity or cost in our industry. A narrowly scoped product space is identified. A technical founding team is invited to build a company to solve this problem for a small team or even a single person with one perspective on the problem being solved. This is purely a technical improvement for one specific problem. Not a fix of the process, not a broadly scoped product to simplify the software ecosystem, just another widget. Groundhog day all over again.
Change is on the Horizon
If you have read to this point in the article, you are well aware that AI has upended the software development world. As a consequence, the algebra behind the “Build vs Buy” debate has changed. Look forward soon to another blog with my peers looking into exactly what the new math looks like for life sciences software.
Secondly, if you’ve poked around on my website, you will notice some very early information about a project of mine to replace all of these dysfunctional widgets with a single solution built upon a novel architecture and with productivity at the forefront and profit an irrelevant factor. Please don’t consider this a form of advertisement as this project will take years to do right and to do without following the path of software success (to build a profitable product which fails your customers…but that’s another story too).
Lastly, a hybrid of these two points is in my mind and presumably in the minds of others. AI is really good at writing software and enabling very effective user experience. AI (because it has learned from existing capabilities and typical patterns) will not (currently) solve our foundational data architecture and carbon efficiency problems in software development. So perhaps the new world of software products is a hybrid. Build a robust foundation which enables AI assisted bespoke software user interfaces to be built rapidly by each customer to fit their individualized processes. Just a thought for now, we’ll see if this evolves, but I would love your feedback.
Art: Gemini Nano Banana