Treating search as a product problem

The request behind the request

Users asked for more filters because they were spending too much time finding assets. Usage data showed a deeper issue: the search architecture was outdated and metadata was not being used consistently. Adding filters would have treated a symptom and extended the wrong foundation.

As Product Manager at 5th Kind, I investigated the request, analyzed search behavior and performance, clarified the customer problem, and aligned engineering, design, QA, and customer-facing stakeholders around a search overhaul.

The product trade-off

We chose to improve the search engine and metadata behavior instead of spending the planned effort on more filters. That choice required a clearer definition of relevance, faster query performance, and a plan to improve the information available to search. I used customer feedback and usage data together, treating neither as sufficient on its own.

The first plan also taught me to challenge optimistic estimates. Search work had been scoped too aggressively, so I revised the plan with more realistic estimates and contingency around the critical path. The change made the schedule more credible and gave the team room to solve the real retrieval problem.

The execution

I turned the diagnosis into a feature set, delivery plan, risk review, and monitoring approach. The work addressed search performance, ranking quality, and more intuitive discovery. I kept the team focused on the underlying retrieval problem while making the trade-off legible to stakeholders who had requested a visible filter feature.

I tracked query speed, relevance, usage patterns, and customer feedback after release so the team could distinguish an actual improvement from a feature that merely looked complete. The measurement plan kept the team connected to everyday user behavior rather than a checklist of shipped changes.

The work also required collaboration with QA and customer-facing teams. I made the revised estimates and acceptance criteria visible early, which gave the team a shared basis for discussing readiness and made it easier to escalate a risk before it became a release surprise. That rhythm kept quality discussion tied to customer behavior.

The outcome

Search became 60% faster and result relevance improved by 40%. Customer satisfaction improved after the overhaul. The decision also avoided spending several weeks on an add-on that would have left the core search experience weak.

The lesson is that product discovery is often a diagnosis problem. A request can accurately describe the frustration while still pointing at the wrong solution. The PM's job is to connect the request to the behavior, the system cause, and the outcome that matters.