From Search Tool to Briefing Agent: A Product-Judgment Story


The Request: "We Need a Better Search Tool"

A global pharmaceutical client's medical affairs organization came to us with a request that sounded, on its surface, like a straightforward search problem. Their medical science liaisons - the field-based scientists who meet with physicians and researchers to discuss clinical data on their company's therapies - were spending significant time trying to find relevant publications before each engagement. The ask was: build us a better way to search the literature.

It would have been easy to say yes and start scoping a search interface. Better indexing, better filters, faster retrieval against the published literature and internal publication databases. That is what was asked for, and a team eager to ship something would have shipped exactly that.

We did not start building. We started interviewing.

What the Interviews Actually Revealed

Over several weeks, we sat with a dozen medical science liaisons across therapeutic areas and watched them prepare for real engagements, not hypothetical ones. The pattern that emerged had nothing to do with search speed.

An MSL preparing to meet with a specific physician was not struggling to find that physician's publications. A name search against the literature takes seconds. What consumed hours - sometimes an entire evening before a high-stakes meeting - was what came after finding the papers: reading them, cross-referencing them against the company's own trial data, identifying where the physician's published positions aligned or conflicted with the therapy's evidence base, and synthesizing all of it into something the MSL could actually use in a fifteen-minute conversation.

The job to be done was never search. It was synthesis under time pressure, personalized to a specific person the MSL was about to sit across from. Search was the easy 10% of the task that happened to be the most visible, because it was the part that looked like typing a query into a box. The other 90% - reading, cross-referencing, synthesizing, and packaging into something conversational - was invisible in the way that all cognitive labor is invisible until you watch someone actually do it.

The Reframe

Telling a client that the thing they asked for is not the thing they need is a harder conversation than it sounds like it should be. The client had a budget line item for "search tool." They had stakeholders who had already described the initiative that way internally. Reframing the deliverable meant asking them to change how they talked about the project to their own leadership, which is a bigger ask than it looks like from the outside.

We made the case with the interview evidence itself rather than an abstract argument about jobs-to-be-done theory. We showed them the actual time breakdown from shadowing MSLs: minutes spent searching versus hours spent synthesizing. That distinction was persuasive in a way a slide about product philosophy would not have been. Once the client's medical affairs leadership saw where their MSLs' time was actually going, the reframe was not a hard sell. It was obvious in retrospect, which is usually how a good reframe feels once someone has already made it for you.

What We Built: A Pre-Call Briefing Agent

The system we shipped does not function like a search tool at all, even though it uses retrieval under the hood. Give it an upcoming engagement - a specific health care provider and, where relevant, the therapeutic area of the conversation - and it produces a synthesized pre-call brief rather than a list of results.

The agent pulls the HCP's publication history, identifies their stated clinical positions and areas of research focus, and cross-references that against the company's own trial and real-world evidence data to surface where alignment exists and where a genuine scientific tension might come up in conversation. The output an MSL receives before a call is not ten links to go read. It is a synthesized brief: who this person is as a researcher, what they have published and argued for, and where the company's evidence base speaks directly to their work - flagged as either reinforcing or worth being ready to discuss.

That reframing changed what "done" looked like for the product. A search tool succeeds when it returns the right documents. A briefing agent succeeds when an MSL walks into a room prepared in a way they were not before, and that meant the evaluation criteria, the interface, and the underlying agent design all had to be built around synthesis and personalization rather than retrieval speed.

Every brief the agent produces carries citations back to the specific publications and trial data it drew from, for the same reason a good analyst annotates their own work: an MSL walking into a scientific exchange with a physician cannot afford to repeat a claim they cannot immediately trace back to its source if challenged. That traceability was not a compliance requirement anyone handed us. It came directly out of watching MSLs in the field and noticing how often they double-checked their own notes before saying something out loud in the room.

Rolling It Out Without Breaking Trust

We did not roll the briefing agent out to the full MSL population at once. A reframed product still has to earn trust with the people who were promised something different than what they are now getting, and the fastest way to lose that trust is a bad brief on someone's highest-stakes engagement of the month. We piloted with a small group of MSLs across two therapeutic areas first, reviewed every brief against what an experienced MSL would have produced manually, and only expanded once the gap between the two had closed. That staged rollout took longer than a single company-wide launch would have. It also meant that by the time every MSL had access to the tool, the ones who had used it longest were the ones telling their peers it was worth trusting, which did more for adoption than any internal announcement could have.

Results

  • MSL coverage increased roughly 5x - the same team could prepare thoroughly for a substantially larger number of engagements per week once synthesis time collapsed from hours to minutes per brief.
  • Pre-engagement preparation cost dropped by roughly 60%, measured against the team's prior time-and-effort baseline for preparing a single high-stakes HCP engagement.
  • The tool that shipped bore almost no resemblance to the one that was originally requested, and the client's own internal description of the initiative changed to match it.

What I Would Do Differently

I underestimated, early on, how much of the reframing work was really change management rather than product discovery. Once we knew the real job-to-be-done, building the briefing agent was the more straightforward part. Getting the client's own organization to stop calling it "the search tool" internally - so that expectations, success metrics, and stakeholder buy-in all moved with the reframe rather than lagging behind it - took longer than the engineering did.

I would also start the shadowing earlier relative to any scoping conversation. We ran the interviews after an initial ask had already been framed as search, which meant part of our job was un-anchoring the client from their own first description of the problem. Getting into the field before any solution has been named, even informally, removes that friction.

The Broader Pattern: Product Judgment Over Building to Spec

The most expensive mistake in enterprise AI product work is not picking the wrong model or under-scoping the engineering effort. It is building exactly what was asked for when what was asked for is not what is actually needed. Clients are experts in their own pain, not in translating that pain into a well-specified product requirement. That translation is the job.

The tell is usually in the gap between what someone says they want and what they actually spend their time doing. A search request that turns out to mask a synthesis problem is not an unusual finding - it is close to the default pattern in knowledge-work automation, because search is the visible, nameable part of a much larger, mostly invisible cognitive task. The product judgment is in noticing that gap, having the evidence to make the reframe legible to a client's own stakeholders, and being willing to ship something that looks nothing like the original request because it is the thing that actually earns adoption.


Further Reading