Build for Scientists, Not Around Them

I have watched scientists spend time fighting with a tool that was built to save time. But, finally, abandoning it and going back to Excel or something similar. And slowly, they stop using the tool.

This happens more than you think. Most scientific tools don't fail because the tool was wrong or slow. They fail for a simpler, more painful reason, it was never built for how scientists actually think or work.

I started my product journey, like many others, by reading Inspired by Marty Cagan. My key take away which I think is the most relevant to Biotech is that teams build what users say, not what they need. In science, that gap becomes a chasm. 

Start Where Scientists Start

Here's what most product teams miss, the difference in terminologies and units of thinking Scientists think in terms of plates, replicates, controls. They have a mental model shaped by years at the bench. When your tools forces them to translate that mental model to fit a new interface and data requirements, you've already lost. They'll try it once, maybe twice. Then they'll go back to what works, even if "what works" is a bunch of notes and spreadsheets.

The products that succeed don't abstract the experiment away. They mirror it. They feel like an extension of how scientists already think. It's understanding the real problem before you design anything.

The Truth Lives in the Workflow

I have interviewed scientists to understand their workflow. I took notes and felt confident and built tools. But what I missed, small changing thresholds based on experimental factors, protocols that have slight variations, knowledge built from years of knowing when something looked "off." None of this came up in the interview. Interviews tell you what people think they do. Observation shows you what they actually do. And the gap between those two things? That's where the insights live. That's where you find the friction, the workarounds, the unspoken needs. That's where you build something that actually helps.

Prototype Like You Mean It

Users cannot predict what feels intuitive until they see it in front of them. That's why you prototype early and keep it simple. Demonstrate these prototypes and watch where they hesitate. Listen to what they expect to happen versus what actually happens. Does the flow match how they think? Do the defaults reflect how they actually run experiments? Where do they expect flexibility? You won't know until you put something in front of them. And the faster you do that, the faster you learn. Prototypes let you fail cheap and learn fast. It's the shortest path to something scientists will actually adopt.

Trust through Transparency

A data analysis tool says “Sample failed QC” without an explanation on why, how the threshold was chosen, and what data shaped it. These aren’t just technical steps, they are scientific decisions. Scientists need to see the method or  the parameters. When you expose this logic, it builds trust in the tool. It proves the tool understands the domain and respects their need to verify and question.

This is the real balance, reduce the workload, but explain the work or the logic behind the decision. Especially in machine learning based tools, explainability isn’t an extra feature, it’s the foundation of usability.

Built for Evolution

Here's what no one tells you when you're building tools for science. The protocols will change, the assay will get updated, the QC logic will evolve, the format will change, the naming conventions will be different, there will be multiple novel one off cases.

If your tool is rigid, it will keep breaking. Flexibility isn't a nice-to-have. It's the most important feature to make any tool successful. Continuous feedback along with ahead of time discussions can help tools to be ready for any new incoming data.

Build Together

The best products come from deep empathy, continuous discovery, and fast iteration. In life sciences, that means getting close to the work. Understanding experiments, not just data. Observing real workflows, not ideal ones. It means earning trust through transparency. Designing for collaboration, not silos. Anticipating change, not resisting it. Most of all, it means building with scientists, not around them. Because the moment you forget how they think, you've lost.

References:

• Inspired by Marty Cagan

• GPT 5 and Sonnet 4.5 for editing