We Built the Wrong Feature
We built a dramatically improved search engine. The analyst looked at us and said, 'I don't want to search at all.' Here's what that Tuesday taught us about retrieval vs. orchestration, and why listening past the feature request matters.
TL;DR
We spent three months building an advanced search engine for equity research, only to have an analyst tell us "I don't want to search at all." The real problem was never retrieval speed -- it was the full twelve-step orchestration loop of turning a signal into a conviction, and we had optimized just one step while ignoring the rest.
The demo went perfectly. I didn't realize that was the problem until about ten minutes later.
We were in a conference room on a Tuesday afternoon: me, Pushkar & a senior analyst at a mid-size buy-side firm who'd agreed to be an early user. We'd spent three months rebuilding our search layer from the ground up. Semantic embeddings. Hybrid retrieval. Cross-document ranking that actually understood what analysts were looking for, not just what words they typed.
It was genuinely good. We ran it live. The results were fast, relevant, well-cited. Everything surfaced that should have surfaced.
The analyst watched the demo quietly. Then she said something I've been thinking about ever since.
"I don't want to search at all."
The Gap Between What Users Say and What They Mean
When we first started building, we asked analysts what slowed them down. The answer we heard most often was some version of: "Finding the right information takes forever."
We heard that as a search problem. We built a search solution.
What they actually meant was something closer to: "I spend most of my day doing work that isn't analysis."
Those two things sound related. They're not the same.
Search is about retrieval. You have a question, you go look for the answer. That's what we'd optimized. But when an analyst says finding information is slow, they're usually not describing the act of searching. They're describing the full loop: noticing something might matter, deciding what to look for, finding it, validating it, connecting it to three other things, forming a view, and then doing it again for the next signal in the queue.
That loop doesn't have a search problem. It has an orchestration problem.
We optimized one step in a twelve-step process and called it done.
What Analysts Actually Need
The analyst who stopped our demo wasn't being difficult. She was being precise.
She walked us through her morning. She'd started with a read of overnight filings. One number had looked off. A shift in deferred revenue that didn't match the cadence from the prior three quarters. To understand whether it mattered, she needed to check the footnotes from those prior quarters, cross-reference the segment breakdown, pull the management commentary from the last two earnings calls, and see whether any competitors had reported something similar.
That's not a search task. It's a workflow. And every step in that workflow requires judgment about what to look for next. At the time, only she could provide.
What she was describing, and what we slowly came to understand, is the difference between a tool that retrieves information and a system that understands what the analyst is trying to do and helps move the work forward.
At this point, every tool does retrieval. What she actually needed was something that could look at where she was in her research and tell her what to do next. Not answer her questions. Figure out what questions she should be asking.
That's orchestration. And it's a different kind of problem entirely.
What Three Months Actually Cost Us
I'm not going to pretend the three months we spent on search were wasted. We learned a lot about how analysts actually query information: the vocabulary they use, the way questions evolve mid-session, the difference between exploratory research and confirmatory research. That foundation ended up being useful later.
But we paid a real cost. Not just in engineering time. In the mental model we'd built around what the product was for.
When you spend months optimizing something, you develop an attachment to it. You start to see the whole problem through the lens of the solution you've been building. Search became our frame, and everything the analyst described: her frustrations, her workflows, her goals. We were filtering through that frame without realizing it.
The Tuesday demo broke the frame. And that was painful, but it was also the most valuable thing that happened to us that quarter.
We went back and re-interviewed six other analysts we'd spoken to early on. We asked different questions this time: not "what's hard to find" but "what do you do after you find it." The answers were consistent and clarifying. Every analyst described some version of the same multi-step orchestration problem. We'd been hearing it the whole time. We'd been translating it wrong.
The Lesson for Builders
I'm still not sure whether to call those three months wasted. We learned real things. But we also built a story in our heads about what the product was, and that story was wrong. The gap between what users ask for and what they actually need is not a new insight. Everyone knows this. And yet.
Analysts said "finding information is slow." We heard "search is broken." But the actual message, translated: "The full process of turning a signal into a conviction takes too long, and most of that time is work I have to do manually, step by step, without any system to hold the context or suggest what comes next."
That's not a search problem. That's a research infrastructure problem.
The lesson we took away isn't that we should have asked better questions at the start (though we should have). It's that feature requests are hypotheses, not specifications. When a user says "I need X," they're telling you what they think will solve their problem. Your job is to figure out what problem they're actually trying to solve, and then decide whether X is the right answer.
Sometimes it is. Often it isn't.
The analyst who stopped our demo didn't have a better search query in mind. She had a vision of a different kind of workday, one where the system understood the thread she was pulling and helped her follow it to the end. Where she could stay in thinking mode instead of constantly switching into retrieval mode.
We spent three months building something that made retrieval faster. We should have been building something that made retrieval unnecessary.
We're building that now.
Other posts in the Founder Stories series:
- Why I'm Betting on a New OS for Research, the personal bet behind the company
- We Taught Our AI to Say "I Don't Know", why we built honesty as a core feature
- Our Users Found Use Cases We Didn't Design, what happens when you build primitives
Enjoyed this article?
Get more insights like this delivered to your inbox weekly.
