We were building a modern, AI-first ATS to replace clunky legacy systems. Our initial focus was optimizing the active pipeline where candidates move linearly from application to hire.

Our design partners kept flagging an inefficiency: starting every search from zero. They were burning budget on job posts and agency fees to re-acquire 'silver medalists' they already knew because when a new role opened, they couldn't find the runners-up from last month.

Our ATS lacked a way to track these high-potential candidates outside of active jobs. So, recruiters defaulted to spreadsheets and desktop folders.

This looked like the highest-value lever to improve efficiency. If we made saving and searching past candidates effortless, we would unlock the value of the network recruiters already owned.

We clearly needed a separate database where recruiters could park good talent. While this exists in other tools, we needed to validate our specific approach. We broke the hypothesis down into 6 core bets:

We needed to find the absolute minimum scope that delivered value on day one. To validate our assumptions, I talked to our design partners showing them lo-fi sketches.

The feedback revealed a clear hierarchy of needs. While features like 'Proactive matching' and 'Outreach' were exciting, they were classified as luxuries. The immediate pain was simply access.

Recruiters confirmed they were willing to tolerate duplicates in the short term if it meant they could stop using spreadsheets.

I sat down with our Lead Engineer to review the scope against this feedback. We identified that building the "Perfect Deduplication" logic was a massive technical risk that would delay shipping by weeks. Since users had explicitly given us permission to be imperfect here, we made a joint decision to cut it.

We agreed to accept the technical debt of a 'dirty database' in exchange for the speed of delivery, locking the V1 scope to three essentials:

Together with our PM we translated the sketches into logic flows. We mapped the data model, edge cases, and error scenarios. To ensure we didn't miss anything, we built a state matrix to stress-test the interaction flows linearly.

Then, we brought in the lead engineer to poke holes in the plan and negotiate constraints.

We tackled several problems, including:

Now, it was time to design.

Recruiters can add candidates to the Talent Pool either from an active application or directly through the Talent Pool page.

Adding from an active application, recruiter simply clicks on the 'Add to Talent Pool' button inside candidate's application profile. The button state toggles to provide immediate system feedback, creating a link to their new permanent profile without breaking the recruiter's review flow.

To add a candidate from the Talent Pool page, the recruiter uploads their resume or fills in the form in the drawer manually.

Talent Pool view starts with a high-density table layout that mirrors the spreadsheets recruiters familiar with. This format puts the most valuable data front and center without forcing a click. It also allows for quick scanning and sorting to help recruiters spot potential matches without using search.

Clicking a row opens the candidate drawer and this is the heart of the talent pool. It had to consolidate a candidate's entire history into a single, scannable view. I leveraged our existing application patterns to reduce the learning curve.

Key details and contacts are pinned at the top for a 5-second relevance check and easy access.

Resumes: A chronological view of every resume submitted. This links candidates to specific past jobs, giving recruiters context on previous rejections or offers.

Aggregated skills & XP: A unified, searchable tag cloud parsed from all uploaded documents using our source-specific logic.

Comments: A standard linear feed for async internal notes and feedback.

Generally, resumes are a nightmare to search. To solve this, we used AI to parse resumes into structured tags upon upload.

Because we solved the data-integrity issues upstream (identity match, source-specific tagging), we could trust the tag data enough to build a fast, precise search experience that relies exclusively on those tags, rather than a heavy full-text search.

Tags work well for now, but high volume recruiting needs more power. We are already planning to add saved searches so recruiters can stop repeating the same work every day. We also want to support all-fields search and complex queries for the power users. The long term goal is to let the system surface the right candidates in one click when a new job opens.

Moving from lo-fi sketches to high-fidelity prototypes allowed us to test the workflows with our design partners. We needed to verify that the new tools would actually save time in a real recruiting environment.

We avoided asking for opinions and focused strictly on behavior. We gave our partners specific jobs to be done. We watched them try to source a candidate from an active application and filter a talent pool list using tags. This approach highlighted exactly where the design supported their habits and where it caused friction.

The sessions revealed that users hesitated when search results felt opaque. They wanted to know why a specific person appeared at the top. We used this insight to add visible 'matched tags' to the results table.

My reality-check meeting with the lead engineer was a tough one. Looking at the timeline, we had to choose: there just wasn't enough runway to build both the complex backend that handles multiple resumes and the frontend identity check that stops users from making mistakes. We had to pick one.

We decided that messing up the data was not an option. We poured our resources into the backend logic to ensure that adding or deleting resumes never created 'ghost data' that would corrupt the talent pool. The price was cutting the identity check. We launched with a risk that a recruiter could accidentally upload the wrong file, but we chose a bulletproof data model over a hand-holding interface for V1.

I started testing in the staging environment as soon as features were built. I tested the complete user flows against the logic we agreed on at the start.

Bugs for visual issues like spacing or layout breaks, as usual. But the important part was sitting down with the lead engineer to review the list. We worked together to separate the showstoppers that had to be fixed immediately from minor polish that could wait for a fast follow-up.

This ensured we shipped a solid, usable tool on time without getting stuck on low-priority details.

Adoption didn't happen overnight. It took a few weeks for our pilot recruiters to build up enough candidates in the new pool for it to feel useful. But once the data was there, we saw a real shift in behavior.

Here are the three biggest takeaways from the launch.

This directly changed our roadmap. We confirmed the talent pool was our strategic advantage, but we realized our next move wasn't adding more features to it.

We scrapped the plan for outreach tools. The new, number-one priority was building a dead-simple data importer. We had to fix the next problem.

Big thanks to our design partners: Alisa, Jana, and Maria for their time and valuable feedback.