Where do you meet your users?
In the last few posts, I’ve been exploring why it’s so hard to find the right off-the-shelf software in biotech, or conversely why it’s so hard for biotech software companies to communicate what their software does to the teams that need it. This week, I want to discuss a topic that is maybe more related to how the software is designed than to how teams find it, but I think it’s close enough to squeeze it into the series: How do you balance meeting your users where they are vs. where they need to be?
I want to illustrate this with a highly over-simplified analogy: Let’s say someone asks you for an extension cord so they can use their phone while it’s plugged in to the charger. You give them the cord, then you notice that they’re sitting next to a power outlet while the extension cord is plugged into an outlet on the other side of the room. You ask them why they didn’t just plug the charger into the closer outlet so they wouldn’t need the extension cord. “But,” they say, “we always plug in the charger in that outlet over there. I didn’t know we could use this one.”
In the biotech data world, we see this phenomenon often: Data scientists write elaborate scripts to parse plate maps in any conceivable format instead of giving bench scientists the tools to write them in a consistent format. Computational biologists scramble to squeeze information from experiments that could’ve been designed to produce better data in the first place. In both cases, they’re solving an immediate problem that arises from how someone else decided to solve a bigger problem.
Now, there’s nothing wrong with solving intermediate problems that arise from a plan to solve a bigger problem. In fact that’s how teams are supposed to work. The issue is when the plan for solving that bigger problem… isn’t good.
When you get into areas that are changing rapidly, or where new technology is being introduced, the person who’s trying to solve that bigger problem often doesn’t know they best way to do it. They don’t know what’s fixed and what’s flexible. (We always use that outlet over there.) They may have strong preferences about things. (You can pry my plate map schema from my cold dead hands.) Or they may just not be in a creative mindset.
So the problem they ask for help with isn’t the problem that they actually need solved. What they need is a better plan for the bigger problem.
In any role where you help people solve problems, you will inevitably run into this situation. In fact, it’s safe to assume that every problem you encounter will be an intermediate to a bigger problem. The question is whether to help them with the immediate problem or push them to rethink their plan for the bigger problem.
In other words, do you meet users where they are and solve the problem they want to solve? Or do you try and bring them to where they need to be, adopting a better plan with a different set of problems?
The best answer is usually somewhere in the middle. I tend to err on the side of nudging the folks towards where I think they should be, but that’s much easier to do as a consultant and newsletter author than a software vendor. Teams will tend to select software that meets them where they are. But that may not be what’s best for them in the long term.
How do you do what’s best for them in the long term, without going out of business?
I don’t know…
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.