A Customer Asked for One Thing. It Became Our Most-Requested Feature.

We got a message a while back from someone running a site for a local government organization. Years of council agendas, minutes, ordinances, all uploaded as PDFs. Search worked. People could find the right document.

But one of them was 120 pages long, and finding the document was only half the job.

He described it like this: someone searches for a specific term, gets the right PDF, and then has to scroll through a document the length of a small book to find the actual answer. Search had technically done its job. The person using it still had to do all the work themselves.

His ask was simple. Don't just find the file. Open it on the page where the answer actually is.

We hadn't thought about it that way before.

We'd been thinking about search as "find the document"

That's the whole mental model most search tools use. You search, you get a result, you click, you're looking at a file. Job done, as far as the search is concerned.

But for anyone dealing with long PDFs, handbooks, bylaws, or meeting minutes, that's not actually where the job ends. It's where a second, unassisted search begins, except now they're doing it manually inside a PDF viewer instead of a search box.

We'd built something that solved the first half of a two-part problem and just never noticed the second half was still there.

What we ended up building

Once we actually looked into it, the fix was more within reach than we expected. We already tracked which page content lived on during indexing. We just weren't using that data for anything past internal bookkeeping.

So we exposed it. Search results now link straight to the page where the match was found, not just the file. Someone searching a long bylaw for one term lands exactly where that term shows up, not on page one of something they didn't ask to read in full.

Small change on paper. But it's the difference between "we found it" and "you still have to find it yourself."

What this taught us

The most useful feedback wasn't a bug report or a feature request phrased as a feature request. It was someone describing a moment of friction in enough detail that we could feel it ourselves.

We're a small team building something narrow on purpose. We don't get huge volumes of feedback. But the feedback we do get tends to be specific, because the people using this plugin usually have a real, concrete problem they're trying to solve, not just curiosity.

That's probably the actual lesson here. One detailed message from someone who really felt the problem was worth more than a dozen generic "this would be nice" requests.

Curious how others here think about this. Do you find your best feature ideas come from direct requests, or from watching how people actually get stuck?