In my last few posts, I described a situation in which we wanted to roll out a new predictive model to the wet lab team to define the compound concentrations that would be used in upcoming experiments. When we left off, I suggested that there were two different approaches, depending on what you would do if the predictive model turns out to be junk. Last week I explored the first option - how we would proceed if a failed model meant we would scrap the project. This week, it’s option 2: When we’re planning to make this work one way or another, not matter what.
For context, you may want to read the previous posts, Part 1 Part 2 and Part 3, before you read this one.
In the previous approach, there were two things we wanted to accomplish: 1) Get quick feedback on the model so we could validate it and align it with wet lab needs. 2) Get the wet lab team in the habit of using the model to define experiment parameters. In that approach, the priority was (1) but we noted that the process would set the foundation for (2). That made sense because if we end up scraping the project, the effort we put into (2) would be a waste.
In our new setting, we’re determined to make this work, so it makes sense to invest in (2) from the beginning. We’ll still do everything that we did in the previous post to involve the wet lab teams in quickly iterating on the new model. But there are also things we can do to iterate directly on the process itself.
We could start working on how the wet lab scientists will interact with the model before it’s complete by putting in a dummy model. For example, if we plan to have them use a web app, we can create an app that calculates the concentrations using whatever heuristics they’re currently using. In the short run, this will ensure that those concentrations are consistently defined and will allow us to automatically record them, not to mention it will force the data team to really understand the process that they’re improving on.
This app should start as a quick prototype. (Maybe even an Excel macro, though that might be a bridge too far.) The goal isn’t to develop the app itself but to understand how it can fit into the wet lab teams’ processes and start shifting them to where an app like this can fit in seamlessly. Once the space is created for the app, you can replace the prototype with a production system. If you’ve done it right, rolling out this new system will be seamless.
Some good points.
"rolling out" can be painful, so "seamless" is an excellent guideline. Seems hard to be be seamless on both ends tho. One of the most aggravating aspects for the end user, the "WET", is when the production system has deprecated and removed features/methods which were present in the prototype. Another is the effort to port over and populate the historical data from the prototype.
Dev sometimes will have two teams, a small for the prototype and a second much larger one for production. "deliberate empathy" (https://scalingbiotech.substack.com/p/empathy) could be useful here, too.