Explore Method Feasibility Before Designing the Experiment

Feasibility questions land on a Field Application Scientist's desk before an experiment is even designed. A postdoc or a research lead wants a quick answer, and the honest answer is usually that nobody knows yet. Handling this conversation well means giving real information without turning a hunch into a guarantee.

Why this conversation goes wrong

Researchers under deadline pressure want certainty. They ask a broad question, something like whether a method will work for their sample, and they want a yes. If you give a yes before you know the sample type, the input range, and the objective of the study, you have made a promise the data has not earned. If the method later underperforms, that promise becomes the reference point, not the actual specifications you had access to at the time.

The opposite failure is just as common. Some scientists get so cautious that they refuse to say anything useful at all. They repeat that it depends and offer no direction, which leaves the researcher with nothing to act on and no reason to trust the conversation was worth having. Neither extreme serves the researcher. The useful middle ground is specific. You share what the documentation actually supports, you ask the questions that reveal whether the researcher's use case fits inside that documented scope, and you say plainly when something falls outside it.

How to prepare

Before you sit down with a researcher, pull the approved specifications for the method or instrument in question. You need the documented sample types, the validated input range, throughput limits, and any known interferences or exclusions. Do not rely on memory here, because a specification you recall from two versions ago may no longer match the current documentation.

Once you have that in hand, prepare questions that map directly onto the gaps in what you know about the researcher's project. Ask about the sample type and its source, the expected input concentration or range, the experimental objective the researcher is actually trying to answer, the planned workflow from sample prep through readout, and any constraints such as sample volume, timeline, or downstream assays that depend on the result.

Then compare the two sides. Where the researcher's answers sit inside the documented range, you can speak with confidence. Where they sit outside it, or where the researcher cannot yet answer the question, you have found the actual open item. That open item might need a technical specialist, or it might need a decision the research team has to make on its own, such as whether to run a small pilot before committing to a full study design. Naming which one it is, rather than leaving it vague, is what makes the conversation worth having. This same discipline, matching what is documented against what is still unknown, shows up in other conversations too, including the questions you define before one scientist trains another on a method, covered in Define Method Handover Questions Before One Scientist Trains Another.

What to say

Picture a postdoc who wants to move fast and asks you to confirm the method will work before they finalize their experimental design. They say, "Before I lock in this experiment, can you just tell me this method is going to work for my samples."

You do not have enough information to answer that yet, and saying so directly is more useful than hedging. You say, "I cannot tell you that yet, because I do not know your sample type or your expected input range. I can walk you through the documented specifications right now, and I have a few questions about your samples. Once I see whether your case fits inside the validated scope, we can talk about whether a focused evaluation makes sense."

The postdoc describes the sample source and the assay they plan to run downstream, but when you ask about the expected input concentration, they pause. They say, "Honestly, we have not pinned that down. We were hoping the method would just handle a wide range."

That answer is the real finding of the conversation. You say, "That is the piece we need before anything else. The documentation covers a specific range, and I cannot tell you your samples fall inside it until you have a number. Once your team defines that range, bring it back and we can check it against the specification in a few minutes." The postdoc leaves with a concrete task, not a vague promise, and you have not signed off on something you cannot support.

Mistakes to avoid

The most damaging mistake is answering a feasibility question with enthusiasm instead of evidence. A confident yes feels helpful in the moment and creates a real problem later if the method does not perform as expected. The second mistake is treating every gap in information as a reason to stall the whole conversation. If three out of five inputs fit the documented scope, say so, and isolate the one that does not.

A third mistake is quietly redesigning the researcher's study for them. Your job is to describe what the method can support, not to take over the choice of controls, replicates, or statistical approach. That decision belongs to the research team, and blurring that line creates confusion later about who is responsible for the study's validity. A fourth mistake is forgetting to write down what you agreed on. If you tell a researcher that a pilot run would answer the open question, note that in your account and in your correspondence, so nobody misremembers the conversation as a full endorsement.

Finally, resist the urge to fill an awkward pause with a hedge like probably or should be fine. Those words sound like reassurance but carry no real information, and a careful researcher will notice the gap between what you said and what you actually know.

How to practice and score it

A manager can turn this into a short practice drill. Give a trainee a broad feasibility request and have them convert it into five specific discovery questions covering sample type, input range, objective, workflow, and constraints. Then hand them a set of sample answers and ask them to sort each one into three categories. One, it fits the documented scope and they can speak to it directly. Two, it needs a technical specialist to weigh in. Three, it is a decision the research team has to make on its own.

Score the exercise on three things. Did the trainee stay inside what the documentation actually supports, without adding confidence that was not there. Did they ask questions specific enough to reveal a real gap, rather than generic ones that just restate the request. Did they leave the researcher with a clear next step instead of a shrug. Running this as a repeated exercise, the way you would practice a recovery conversation after something like the situation in Lead a Recovery Review After a Missed Service Visitbuilds the habit faster than a single training session ever will. DealSpeak's Biotechnology practice conversations give trainees a place to run this exact exchange against an AI counterpart and see where their answers drift from what the documentation actually supports.

Feasibility conversations reward patience over confidence. Say what the specifications actually cover, ask the questions that expose what is still unknown, and hand the researcher a clear next step. That is a better outcome for everyone than a fast yes that does not hold up later.