Before I get into a nuanced and borderline-philosophical discussion of what makes building a digital twin of your biotech lab so difficult, let me first address the biggest pain point for a lot of us: Many of the companies that sell lab data/informatics software rely on manipulative sales techniques whose only purpose seems to be to lock in customers and squeeze more revenue out of them.
I think there's a lot of vagueness on both sides (mostly unintentional). The vendor doesn't want to pigeonhole their product and limit potential customer base. They also may not have portions of it fleshed out yet and hope that interactions with customers will help with that. And they probably have limited resources to provide pilots/sandboxes for potential customers to kick the tires. On the customer side, the interest in a product may be serious and well-thought out. Or, it could be just someone looking around with a general idea of what they need. I've found mostly the latter - that the customer's actual need for a new system is often unclear. There's uncertainty about cost constraints, expected ROI, what works and does not work in the current system, current workflows that are not nailed down or documented, and the requirements for a new system are not fleshed out. When you layer on the realities of change management, validation, updated process and control docs, logistics and impact of the transition/go-live to a new system, etc., the limitations discussed in the article can be seen as expected.
Those are good points - It makes sense that the sales funnel is often genuinely intended to help customers who haven't fully figured out what they want. But it's unfortunate that it often manifests in a way that's just frustrating.
Having seen the sales and implementation side, I think there is a lack of trust that the customer knows how to evaluate the product. This "high touch" approach (Agreed not malicious or intentionally manipulative) can be to ensure each customer converts to a deal.
I hadn't seen that - I think Atlassian is a great model for biotech software companies to emulate. The software buyers in biotech are probably behind the curve relative to Tech, when it comes to appreciating this "low touch" sales model. But I think we're catching up fast and the vendors that recognize this will benefit in the long run.
The part about lack of specific details or demos on websites is spot on. After having been on the other side of sales/marketing both top and bottom of the funnel - the issue lies with lack of technical expertise in sales and marketing. Conventional salesmanship goes out of the window when your buyers are highly discerning phd/masters level lab scientists. But companies are catching onto this. And I am definitely advocating for more transparency in demos right out the gate/top-of-funnel.
Yes, please! For me, as a not-a-biologist who isn't as familiar with typical biology software, it's really hard to figure out what software actually does. Maybe this is why there's so much confusion about what ELNs and LIMS actually do...
I think every early stage software startup starts with good intentions and then most will require some investors in order to scale up, then those investors will require some return on that investment. I think the OpenAI model is interesting where they want to cap that profitability goal.
Sure, but I think software companies can be profitable without having to rely on manipulative (even if unintentionally) sales funnels. In fact, I think that as the market shifts to expect more reasonable sales processes, the only way to be profitable will be to be more transparent.
To avoid reiterating the excellent points made below, I agree and think there are two additional drivers:
* buying in biotech is often multi-stakeholder. You're Head of Data Science and Engineering, but solutions you buy have to fit in with wetlab, sometimes a clinical team, etc. Which means they need to have value propositions for these teams on the website, leading to customers that get confused and think..."...wait, what is it you do again exactly?"
* While we all spend inordinate amounts of time moving small volumes of liquid around and thinking about how we move small volumes of liquid around, the overarching science we do and questions we are trying to answer are pretty complex and diverse. We haven't yet figured out how to escape the tradeoff of fast versus customizable, and so we end up with a lot of back and forth.
But multiple meetings before a demo seems ridiculous. :\ I hope we have not been guilty of this! (someone, please tell me if we have)
I wonder if we just need a whole new role to understand and integrate everyone's needs and make these decisions, then deal with onboarding/customization. Normally I would imagine it's falling to IT, but this seems fundamentally different than a lot of what they handle (security is about the only proactive thing I can think of, a lot of it often feels reactive). The COO maybe?
I guess that's a question: Who should be leading these decisions in the first place?
That's a good point about who's driving decision making. Certainly in the past it's been IT for companies that are big enough to have an IT department, or the de facto IT (whoever knows about computers and is bad at saying no) otherwise. But I think technically-minded functional teams are starting to take on more of this responsibility, which should change the calculus around the sales funnel.
If you were to design a more buyer-friendly sales process that provides the selling company with all the relevant information they need to diagnose your unique situation so they can suggest (or prescribe) a better way of doing things, then what would that look like?
As a buyer, I want to understand 1) Where does the software fit into my organization from a process perspective? 2) Is it customizable in the ways that I need it to be, given how we want to work? 3) Is it compatible with our existing infrastructure on a technical level.
For (1), I want to see video demos of how it works, with screencasts of people using it for a wide range of tasks. For (2), I want to be able to spin up a sandbox instance and start configuring a prototype that my users can try out. For (3) I want publicly available and easily findable API documentation and other technical specs.
I think there's a lot of vagueness on both sides (mostly unintentional). The vendor doesn't want to pigeonhole their product and limit potential customer base. They also may not have portions of it fleshed out yet and hope that interactions with customers will help with that. And they probably have limited resources to provide pilots/sandboxes for potential customers to kick the tires. On the customer side, the interest in a product may be serious and well-thought out. Or, it could be just someone looking around with a general idea of what they need. I've found mostly the latter - that the customer's actual need for a new system is often unclear. There's uncertainty about cost constraints, expected ROI, what works and does not work in the current system, current workflows that are not nailed down or documented, and the requirements for a new system are not fleshed out. When you layer on the realities of change management, validation, updated process and control docs, logistics and impact of the transition/go-live to a new system, etc., the limitations discussed in the article can be seen as expected.
Those are good points - It makes sense that the sales funnel is often genuinely intended to help customers who haven't fully figured out what they want. But it's unfortunate that it often manifests in a way that's just frustrating.
Having seen the sales and implementation side, I think there is a lack of trust that the customer knows how to evaluate the product. This "high touch" approach (Agreed not malicious or intentionally manipulative) can be to ensure each customer converts to a deal.
Parallels this great overview on how Atlassian sells product: https://www.intercom.com/blog/podcasts/scale-how-atlassian-built-a-20-billion-dollar-company-with-no-sales-team/.
I hadn't seen that - I think Atlassian is a great model for biotech software companies to emulate. The software buyers in biotech are probably behind the curve relative to Tech, when it comes to appreciating this "low touch" sales model. But I think we're catching up fast and the vendors that recognize this will benefit in the long run.
The part about lack of specific details or demos on websites is spot on. After having been on the other side of sales/marketing both top and bottom of the funnel - the issue lies with lack of technical expertise in sales and marketing. Conventional salesmanship goes out of the window when your buyers are highly discerning phd/masters level lab scientists. But companies are catching onto this. And I am definitely advocating for more transparency in demos right out the gate/top-of-funnel.
Yes, please! For me, as a not-a-biologist who isn't as familiar with typical biology software, it's really hard to figure out what software actually does. Maybe this is why there's so much confusion about what ELNs and LIMS actually do...
I think every early stage software startup starts with good intentions and then most will require some investors in order to scale up, then those investors will require some return on that investment. I think the OpenAI model is interesting where they want to cap that profitability goal.
Sure, but I think software companies can be profitable without having to rely on manipulative (even if unintentionally) sales funnels. In fact, I think that as the market shifts to expect more reasonable sales processes, the only way to be profitable will be to be more transparent.
To avoid reiterating the excellent points made below, I agree and think there are two additional drivers:
* buying in biotech is often multi-stakeholder. You're Head of Data Science and Engineering, but solutions you buy have to fit in with wetlab, sometimes a clinical team, etc. Which means they need to have value propositions for these teams on the website, leading to customers that get confused and think..."...wait, what is it you do again exactly?"
* While we all spend inordinate amounts of time moving small volumes of liquid around and thinking about how we move small volumes of liquid around, the overarching science we do and questions we are trying to answer are pretty complex and diverse. We haven't yet figured out how to escape the tradeoff of fast versus customizable, and so we end up with a lot of back and forth.
But multiple meetings before a demo seems ridiculous. :\ I hope we have not been guilty of this! (someone, please tell me if we have)
I wonder if we just need a whole new role to understand and integrate everyone's needs and make these decisions, then deal with onboarding/customization. Normally I would imagine it's falling to IT, but this seems fundamentally different than a lot of what they handle (security is about the only proactive thing I can think of, a lot of it often feels reactive). The COO maybe?
I guess that's a question: Who should be leading these decisions in the first place?
That's a good point about who's driving decision making. Certainly in the past it's been IT for companies that are big enough to have an IT department, or the de facto IT (whoever knows about computers and is bad at saying no) otherwise. But I think technically-minded functional teams are starting to take on more of this responsibility, which should change the calculus around the sales funnel.
If you were to design a more buyer-friendly sales process that provides the selling company with all the relevant information they need to diagnose your unique situation so they can suggest (or prescribe) a better way of doing things, then what would that look like?
As a buyer, I want to understand 1) Where does the software fit into my organization from a process perspective? 2) Is it customizable in the ways that I need it to be, given how we want to work? 3) Is it compatible with our existing infrastructure on a technical level.
For (1), I want to see video demos of how it works, with screencasts of people using it for a wide range of tasks. For (2), I want to be able to spin up a sandbox instance and start configuring a prototype that my users can try out. For (3) I want publicly available and easily findable API documentation and other technical specs.