Product discovery when your users are scientists

Scientists are some of the hardest users to do product discovery with. They are experts in a domain you probably understand only partly, their calendars are packed with experiments and meetings, and many of them have already solved the problem themselves, with a Python or R script, a MATLAB function or a spreadsheet with forty tabs that does exactly what they need.

That last point matters most. When your users are scientists, your real competitor is rarely another vendor. It’s the script on their laptop.

I spent more than six years on the other side of this table, as the scientist writing my own analysis pipelines in academic labs. Today I build data products for expert users in finance. In this article I want to think through how I would approach discovery with scientists in R&D, using what I know from the bench and from industry, and what the product discovery literature recommends.

Industry R&D is not academia. There are standard operating procedures (SOPs), quality systems, validated software and release cycles. But the people at the bench are still the same kind of user. They are highly trained, short on time, and quite rightly skeptical of tools that don’t fit the way the science is actually done.

Start with the basics

Every product team is managing the same four risks. Marty Cagan calls them value (will people choose to use it?), usability (can they figure out how?), feasibility (can we build it with the time, skills and technology we have?) and business viability (does it work for the rest of the organization?)¹. IDEO describes a similar balance between what is desirable for people, feasible with technology and viable for the organization².

Cagan applies these risks to the solutions a team is considering, but they are worth asking much earlier, as soon as a feature request comes in. A request is usually a solution in disguise, and questioning it early helps uncover the outcome behind it (step 1). Later, the same four risks come back when testing each solution’s assumptions.

With scientific users, the weight shifts. The engineers and managers in the room usually understand feasibility and viability well. Value is where scientific tools tend to fail. A tool can be technically excellent and still never replace the script, simply because it doesn’t fit how the experiment is run.

So most of the discovery work with scientists is about finding out, early and cheaply, whether what you want to build is something they will actually use.

1. Start from an outcome, not a feature request

Scientists often come with the solution already in mind: “we need a dashboard”, “can you add an export button?” I’ve seen the same in finance, where domain experts often arrive with exactly these kinds of requests. These requests are useful information, but they are not the problem.

Teresa Torres’s opportunity solution tree helps keep the two apart. You put the outcome you want at the top, then the opportunities you discover in research underneath it (needs, pain points, desires), then the possible solutions for each, and finally the assumption tests that show which of those solutions are worth building³.

For an internal scientific tool, good outcomes might be “less time from raw instrument data to a reviewed result” rather than “build a dashboard”, or “a specific group of people starts each week with the latest results” rather than “add an export button”. The dashboard and the export button go into the tree as possible solutions, and they have to compete with others, such as automating the review step or generating and sending the latest result automatically.

Before moving forward with any of the solutions, however, Torres suggests assessing the opportunities to decide which ones to prioritize to reach the desired outcome. She proposes five criteria for comparing them⁴:

• Opportunity size: how many people are affected, and how often. Here, one group, every week.
• Market factors: how solving it affects your position in the market. For an internal scientific tool, this usually matters less. If the group is an external client, though, it can matter a lot. Results that reliably arrive on time strengthen the relationship, while a missed Monday is something the client notices. A service that works well for one client can expand to other clients, which strengthens the company’s position in the market.
• Company factors: how well it fits the company’s strategy and rules. This is also where I would ask the most basic question first: is the group allowed to receive these results at all? If compliance says no, none of the solutions matter.
• Customer factors: how important the need is, and how satisfied people are with what they have now. The pain points (opportunities 2 and 3) would likely score high, while the desire (opportunity 4) may turn out to be a habit. Even the need (opportunity 1) is worth checking: is 10:00 a hard deadline? Will the data be ready by then in the first place?
• Impact on outcome: how much solving it would move the outcome. Here, removing the manual work does the most.

Other questions only come up once the solutions are on the table, such as who will own and maintain each one: IT, a data team, or the group itself. Those belong in each solution’s feasibility and viability assumptions. I won’t go deeper into them here, since the example is only meant to show how the tree works on a simple use case.

2. Ask about the last experiment, not the ideal tool

One of the least useful questions one can ask any user is “What would you like the tool to do?” You will usually get a wish list, and much of it will never be used.

Rob Fitzpatrick’s The Mom Test has three rules that I think would suit researchers, since they ask for evidence rather than opinions: talk about their life not your idea, ask about what they did not what they might do, and ask for commitments not compliments⁵. Torres recommends something similar, story-based interviewing: collecting specific stories about what a person actually did instead of asking for their general opinion⁶.

The questions might sound like this:

• “Walk me through the last time you processed a batch from this instrument.”
• “Where did the data go next? Who looked at it after you?”
• “What took longer than it should have, and what did you do about it?”
• “Can you show me the script or spreadsheet you use for that step?”

I’d put the most weight on the last one. Someone’s home-made tool is a perfect specification of what they actually need, including the edge cases nobody would mention in a meeting. Even if its calculations are eventually replaced, the decisions built into it, such as which values matter and how the final one is chosen, are what the new tool has to reproduce. In a regulated setting, a home-made tool is often also a quality risk, which gives a second good reason to understand it.

The second question deserves a follow-up of its own. If the outcome is “time to a reviewed result”, the reviewer is part of the workflow too. A tool that saves the scientist an hour but adds an hour of checking for the reviewer has not moved the outcome at all. So I would interview the reviewer as well, and ask what they look for, what makes them send results back, and what would make them trust a result faster.

3. Go to the bench

Scientists often can’t describe their own workflow accurately, and that’s not a criticism. A lot of expert work is tacit, and people leave out the steps that feel obvious to them. I see it in myself. Back in my lab years, the steps I thought were too obvious to mention were often the ones that took the most skill. Making that invisible work visible, for the people we build for and for ourselves, is a skill of its own, and one I am still practicing.

In industry, many workflows are written down in SOPs. But an SOP describes how the work should be done. It doesn’t capture every judgment call an experienced scientist makes along the way, and that gap is exactly what discovery needs to uncover.

Contextual inquiry is the method I would consider: observing and interviewing people in their real work environment, while they do the work. Karen Holtzblatt and Hugh Beyer, who developed this method, compare the relationship to a master and an apprentice. The user is the expert and teaches, while the researcher learns by watching and asking questions⁷.

That suits scientists. They’re used to training new colleagues, they appreciate curiosity, and from what I’ve seen in labs, they’ll often give you more time next to an instrument than in a meeting room. Half an hour at the bench can bring more than a series of workshops.

Observing several labs brings up another question: what happens when scientists disagree? Different labs often do the same step differently, and each scientist considers their own way the right one. I would not try to pick a winner. Instead, I would map the variants side by side and separate the shared core from the local preferences. The core is what the tool standardizes, and the preferences become settings. Where the variants actually produce different results, that is a scientific question rather than a product decision, and the fairest way to settle it is the way scientists settle everything else: compare the results on the same data, together.

4. Make them co-designers, not reviewers

In a user-centered design study with combustion scientists, Ye and colleagues found that treating the scientists as part of the team, not as clients, helped close the knowledge gap. When the scientists suggested ideas before anyone worried about feasibility, the directions were more practical, and the project’s focus shifted once early prototypes showed what was really useful⁸.

A team at the University of Dundee came to a similar conclusion when they applied user-centered design to the development of scientific software for cell biologists. Even building for a small group of scientific users turned out to be hard, and academic settings rarely had the design methods commercial teams take for granted⁹. Industry teams usually do have those methods. The lesson still applies: building for a small group of very specialized users is difficult, and it only works if they’re involved.

The takeaway: I would invite one or two scientists into the discovery work itself. Let them sketch, question assumptions and look at prototypes along the way, not just at the final demo.

Co-design has one difficult side effect: co-designers will suggest things you won’t build. Saying no to an expert is uncomfortable, but avoiding it is worse. What protects the partnership is explaining the decision in terms scientists respect, such as the evidence from interviews, the results of a test, or the outcome the team agreed on in step 1. A clear “not now, and here is why” keeps them engaged. Ignoring the idea does the opposite.

5. Prototype with their data, not with lorem ipsum

Scientists judge a tool by whether the numbers are right. A polished mock-up full of placeholder values gets polite nods and very little real feedback.

In the combustion study by Ye and colleagues mentioned earlier, the team moved early to prototypes running on the scientists’ own simulation data, which made the experience much more realistic for the experts. They also ran into a domain convention nobody had anticipated, the sign of a physical quantity, which confused several experts until someone explained it⁸. You only find problems like that when real data is on the screen.

If confidentiality allows, I’d use a real or realistically anonymized dataset from the users’ own work in every prototype test. If it doesn’t, the next best option is to ask the scientists for a simulated dataset. They know their data best, so a dataset they build themselves will be much more realistic.

6. Respect their time with small, regular touchpoints

Torres argues for continuous discovery: the product trio (product manager, designer and engineer) talking to customers at least once a week, in small steps, instead of one big research project before anything gets built⁶.

In industry there is a step before any of this: getting the time approved. A scientist’s time belongs to their manager and their project, and an hour a week of co-design competes with experiments and deadlines. Making the case to lab heads, ideally with the outcome from step 1 and what their team gets in return, is often what makes everything else in this article possible.

Even with approval, weekly interviews can be hard to schedule. Thinking back to my own lab days, I expect a few things to work better:

• Join existing rhythms: ten minutes at the end of a lab meeting or a team stand-up.
• Keep it small and concrete: one question, one screen, one decision.
• Close the loop: show people what changed because of their input. Scientists are generous with their time when they can see it made a difference.

7. Treat assumptions like hypotheses

This is the part where scientists are naturally better at discovery than most product teams. Every experiment begins with a hypothesis and a way to prove it wrong, and product assumptions deserve the same treatment.

Before building, write down what has to be true for a solution to work. If the solution is a shared analysis tool, for example, several assumptions sit underneath it: the tool automates the analysis reliably, it gives the same accurate results with fewer steps, and scientists can explore the data easily, for instance with simple drag-and-drop plots. Speaking as a former scientist, that is roughly what it would have taken to win me over. Reliable automation that lets me focus on the science instead of the pipeline would have been an easy win.

As in any good experiment, test one hypothesis at a time and start with the riskiest. Here that is probably accuracy: “the tool’s automated results match what the scientists’ own scripts produce on their past data.” If that fails, nothing else matters. A small test could be to run the prototype on a handful of past datasets and compare the results side by side with the scientists. That’s what the bottom level of the opportunity solution tree is for³.

When discovery is framed this way, scientists tend to stop seeing it as “product process” and start seeing it as good science. I believe that’s where a real partnership starts: discovery becomes something you do together, not something that’s done to them.

Case study

Automating a data product that was "not possible"

Most of this article is about how I would approach discovery with scientists. One project in finance showed me that the same steps work with domain experts in general.

A team of domain experts produced a monthly report from a set of Excel sheets. They processed raw data and turned it into a list of instruments with the values they cared about. Their data came from a legacy primary market source. Our data warehouse had neither that source nor any primary market data, only secondary market data. Hoping the legacy source would eventually be integrated, for several years they asked whether the report could be automated within our data pipelines, and for several years the answer was that it was not possible. On paper, that answer was entirely logical.

When they came to me, I didn’t start from the feature request but from the outcome: could the data in their final report be extracted from our data at all (step 1)? To find out, I first asked to see their reports from the past two months and the Excel sheets themselves (step 2). Then I asked them to walk me through the sheets: what the raw data looked like, which values they cared about, and how they selected and labeled each instrument (step 3).

That made the assumption behind “not possible” visible: the team needs primary market information, so it cannot come from secondary market data. As a general rule, that is reasonable, since not all primary market information can be derived from the secondary market. But for this particular use case, I suspected it could be: our data model, combined with the market activity of those instruments, might reveal exactly what the team was looking for. So I turned the assumption into a hypothesis we could test: the values the team needs can be derived from the market activity in our secondary market data (step 7).

From the beginning, I involved the team in the analysis rather than presenting them with a finished result (step 4). I asked for one person from their team to work with me through the iterations and validate the logic and the output. We made it explicit that this was part of his daily work, so he could take the time without having to justify it (step 6). For four weeks we tested the hypothesis together, comparing the pipeline’s output with their past reports (step 5).

The hypothesis held. Our data model, combined with the market activity of those instruments, made it possible to extract the information the team needed. Since the data now came from a different source, their Excel calculations no longer applied, but the walkthrough still paid off: knowing how and why they chose the final value out of many candidates was what made our logic match theirs. Where the two outputs differed, we checked each instrument against publicly available information, going back two years. The legacy reports turned out to contain instruments that were no longer available, incorrect values, and dates that differed from the reality. Our output matched the public information, which made it more accurate than the legacy reports.

We then spent the next three months validating the pipeline for consistency, month by month. As expected, a few apparent edge cases came up. In each case, the expert could explain what was behind it, which let us turn that explanation into a general rule in the pipeline rather than a one-off fix.

The output now runs as part of our automated pipeline and has become a central data source. It feeds visualized reports that support business decisions and are shared with clients. The team no longer spends days each month extracting this information by hand. A request that had been “not possible” for years became possible once we questioned the assumption behind it.

A one-page summary

Have you built tools for scientists or other expert users? What worked for you, and what didn’t? I’d love to hear in the comments or on LinkedIn.