Solving the wrong problem, eight months in

In fall 2025, a reorg created a Sourcing Steering Committee over two efforts: an existing Sourcing team and a new AI Sourcing stream. The AI Sourcing work had been in motion for about eight months before I arrived, with an Alpha already designed and built. I joined as part of a small tiger team that was asked to rethink the product from first principles.

It became clear to me that the previous team had been trying to solve the wrong problem: outreach automation. However, employers wanted us to solve the tedium of finding qualified candidates.

This wasn't an abstract framing problem. In an Indeed/Harris Poll survey, 71% of hiring managers said rising application volume had made it harder to find qualified candidates, and 93% said they'd lost strong candidates because their hiring process took too long.

The goal was to automate enough of the sourcing workflow that an employer no longer needed to be a trained recruiter to find good candidates. The same users already had a manual, keyword driven sourcing product one tab away. Along the way, we challenged our assumptions and learned how employers built trust in automated products.

Halfway through the project, the CEO moved the timeline up by two months. That compressed our learning window and forced us to discover, design, and build a product with a new process playbook.

Define the UX strategy, then build the conditions around it

My responsibility was to define and hold the UX strategy for AI Sourcing from Alpha through GA and to build the conditions around it so the product could land and grow.

Concretely, that meant:

Turning Alpha signals into a trust framework

Alpha launched in mid November 2025 with thirty two customers across small, mid market, and enterprise segments. Within three weeks, we saw strong match quality and early hiring outcomes, but also clear friction for users who were not already comfortable with LLM based products.

When Alpha closed, I led the synthesis and translated what we had learned into three design bets that would anchor the Beta experience:

Individually these look like UX improvements. Taken together they formed a trust framework for an agent that sat next to a manual product. We used them to focus design and research investment for Beta and to align PM, engineering, and content around what it would take to earn autonomy rather than simply request it. Beta research later confirmed that these three areas were where we needed to invest, and that weak design in any of them created adoption friction, especially for customers without strong affinity for LLM tools.

Solving enterprise control in twenty-four hours

Late in Q1 FY26, a research readout from several enterprise customers surfaced a hard constraint. They would not adopt Sourcing Assistant if they could not see and approve the candidates the agent wanted to contact on their behalf. They wanted a shortlist inside the workflows they already used, not an agent sending cold outreach in their name without an approval step.

We were one week from GA feature freeze when this landed. Product leadership initially wanted to ship without addressing it to protect scope. The UX team argued that ignoring it would put GA metrics at risk, and we were given twenty four hours to find a direction that could ship.

In that window, I pulled the lead UX team into a working session and reviewed their first idea, which added a new candidate review paradigm on top of the three we already had. That would have fragmented the experience further. I rejected that route and redirected the team to solve for shortlist inside the existing Projects surface, which was already the primary candidate management space in the enterprise product.

That afternoon we produced three Projects based concepts and put them in front of users. Feedback was unanimous in favor of the Projects direction. After the sessions, engineering flagged a feasibility concern. I approved a small pivot that preserved the core concept and handled the constraint. At the end of the US work day, our lead designer handed the work to a lead in Tokyo, who fleshed out interaction details and edge cases overnight. We woke up to a complete, validated feature that engineering could pick up before freeze.

Shortlist shipped as part of Projects in GA. Enterprise customers got the approval control they had asked for in a surface they already trusted, and we avoided introducing another review paradigm into an already complex system.

Building Rapid Discovery so research
could keep up

Within the first month of Alpha, it was obvious that the existing research cadence could not keep pace with the product. Studies often took weeks from question to readout. The Sourcing Assistant surface could change multiple times in a week, and we were shipping new flows before we had meaningful feedback on the old ones.

I asked my UXR manager counterpart to help me build a Rapid Discovery process that compressed this into a forty eight to seventy two hour loop. We staffed a small pod with a designer and a researcher, then coached them on ways to move faster without compromising objectivity.

With the introduction of AI tools into the process, we were able to test concepts very quickly. In addition to rapidly creating wireframes and prototypes, we were able to create interactive interfaces that focused users on specific elements that we were testing. For example, we created a prototype that tested an activity feed to judge the level of detail and cadence that felt trustworthy and useful to employers.

Rapid Discovery filled the gap between traditional research and the pace of an AI product. It kept the agent tightly coupled to real behavior instead of assumptions and helped us avoid large, unvalidated bets. Over time, other teams adopted the same pattern for their own fast paced work.

The automation tradeoff, and the call I lost

The deepest tension in this cycle was around automation versus human-in-the-loop.

The decision went toward the all-or-nothing switch and Beta shipped that way. We tried to compensate through trust-building copy and visible agent activity, but it was not enough. Beta research confirmed what Alpha research indicated: customers require either heavy hand-holding or a strong affinity for LLM-based products to trust an all-or-nothing agent. Product leadership came around as soon as data and sentiment came in to support it. GA shipped without staged automation, but the team began exploring where and when to introduce human-in-the-loop moments.

I had the right instinct about the system, but I did not have the right behavioral data at the right moment to shift the decision.

In retrospect, a small, targeted pre-Beta study on how customers wanted to progress into automation would have given me stronger footing for a choice that affected trust, adoption, and risk across the entire product.

The situation

Advanced Sourcing had shipped its Alpha inside Talent Scout's chat surface and was scoping Enterprise Beta for March 2026. Smart Sourcing, S&C's flagship product, had a structural mismatch underneath it: it was organized around projects, while the rest of the platform was organized around jobs. That mismatch was costing the business roughly $4M a year in preventable churn and 5,000 avoidable support cases annually, had left subscription adoption stuck at 4%, and was blocking Advanced Sourcing, AI Screening, and every other next-generation product from having a coherent place to live. Unified Pipeline was S&C's initiative to fix it, rebuilding Smart Sourcing's data model from project-based to job-based.

Unified Pipeline's first milestone, M1, was scheduled for mid-Q4 FY26. Advanced Sourcing Enterprise Beta needed to launch before that.

The insight that reframed the argument

The strongest evidence I could bring to the Steering Committee came out of Alpha research. Our Alpha customers were carrying two mental models at once: the agentic sourcing product itself, and the chatbot modality we had wrapped it in.

They didn't complain about Advanced Sourcing. They complained about the chatbot.

Alpha had validated that the agent delivered real value. It had also shown that a sidebar chat window was the wrong container for a task as high-stakes as hiring. Advanced Sourcing Beta needed a home inside the employer's normal workflow instead of a surface they had to go learn. Unified Pipeline's job-based rebuild of Smart Sourcing was building that home. It just wasn't going to be ready in time.

Three ways forward

Three options were on the table.

Option A: Advanced Sourcing Beta ships on Smart Sourcing's legacy, project-based architecture. Both teams keep their planned timelines. Every design decision, engineering integration, and content pattern becomes rebuild work once Unified Pipeline eventually rolls out.

Option B: Advanced Sourcing waits for Unified Pipeline to land on its original schedule. Leadership had committed to a launch date, and losing months would have undone real field enablement work, so this was never a live option.

Option C: Unified Pipeline pulls its M1 milestone forward so Beta can launch on Smart Sourcing's modernized, job-based surface directly. This was the most invasive option of the three, and the one I argued for.

Making the case for Option C

Building Advanced Sourcing Beta on the legacy architecture meant building against a surface that was actively being replaced. My case for Option C rested on three points.

The resistance, and how it turned

Most of my peers on Steering Committee leaned toward Option A early, and their reasoning had little to do with the UX case. It came down to coordination cost. Each team keeps running its own race, and nobody has to argue with a peer team's leadership. They were the audience I actually needed to move. Steering Committee set S&C's priorities, so a decision there would settle the question regardless of what S&C wanted.

S&C wasn't arguing for Option A either. Building Advanced Sourcing on architecture they were actively retiring wasn't something they wanted, but they were wary of another team building anything further on that surface while they tried to wind it down, and re-sequencing M1 meant absorbing delivery risk and reshuffling priorities they'd already committed to. Steering Committee had the standing authority to direct that re-sequencing regardless of S&C's position, but spending it that way would have burned the relationship we needed for every platform decision after this one.

I didn't start advocating for Option C until late January. Most of the following weeks went into convincing Steering Committee peers rather than staging one decisive meeting. The frame that moved them was platform economics: Smart Sourcing's own churn and adoption numbers meant accelerating M1 served S&C's goals as much as Advanced Sourcing's, and I coordinated with Smart Sourcing's UX lead, who had already built that data set, to make the case land. Once Steering Committee aligned on directing the re-sequencing, the harder work was landing it with S&C diplomatically instead of by mandate. What brought S&C leadership around was the same architecture argument turned toward their own cost: Option A meant watching another team keep investing in the surface they were trying to retire. We backed it with two commitments: our engineers would assist with the M1 work, and Steering Committee would give S&C air cover to push some of their other priorities out.

On February 20, 2026, the Steering Committee moved to Option C. Enterprise Beta launched on Unified Pipeline's modernized surface the following month, at 100% of the rollout Unified Pipeline was already running.

The situation

The market was already moving past the chatbot modality. Gemini and similar products were shifting toward LLM intelligence embedded inside familiar workflows, where chat was one surface among many rather than the product itself. The companies doing chat well were increasingly building for consumers who had opted into that interaction model. Talent Scout's customers were enterprise hiring managers who had not.

Scaled against the roughly 1.3 million employers active on the platform each week, a few thousand weekly users was a stark number for a product that had been the centerpiece of our flagship conference. And even among employers who did engage, fewer than four in ten conversations resolved what they'd come to do. The question was what Talent Scout should actually be, and what shape it needed to take.

My role

I was the UX Director for Talent Scout across the FY26 planning cycle. My job was to reframe what the product needed to be, lead the UX team through that reframe, build alignment across product, engineering, research, and executive leadership, and secure the architectural investment to make it real.

The planning onsite

The FY26 planning onsite was where the direction had to be set. Going in, I wanted to change two things about how the session would run.

With those JTBDs on the table, I framed the product direction conversations around a single question: when is chat a superior interaction compared to a GUI, and when is it inferior? That moved the conversation away from "how do we improve the chatbot" and toward "what is the chatbot actually good for, and what does everything else need to become?"

The answer was clear enough. Chat worked well for back-and-forth explanation, complex multi-step reasoning, and connecting siloed systems. Against most of the highest-priority employer JTBDs, it fell short. Discovery ("what can this thing do for me?") is an inherent issue with chatbots, and a conversational interface couldn't match the information density a well-designed GUI could deliver at a glance. Four directions emerged from the conversations:

That conclusion had an architectural consequence. Talent Scout's existing single-agent chat architecture couldn't support embedded or contextual widget directions without a rebuild. I worked with engineering and data science leads to bring this forward. The CTO endorsed the move from a single-agent model to an orchestrator-plus-tooling model. Engineering would need about a month to build it.

Building the vision

Engineering needed about a month to build the new architecture, and product work would have to pause while they did. I used that window to have the lead UX designer work exclusively on a vision for what the new product could become. She had the product depth, the design craft, and the cross-functional relationships to own that work. My job was to stay close enough to sharpen her thinking without crowding it. I pushed back on framings that weren't landing, redirected when the work drifted, and made space for her best ideas to develop into something the organization could get behind.

The onsite had surfaced a dozen potential directions within the contextual widget frame. I worked with her to narrow to a small set of themes grounded in where Scout's intelligence could actually create value. That meant the job posting funnel, candidate review, hiring goal tracking, and the return-user experience. Her instinct was to design forward from what the product could already do. I pushed her to work backward from a specific persona's journey instead, using employer research as the anchor. That reframe produced the persona-driven structure that defined the vision.

I also worked to protect the conditions for the work itself. Despite the pause in the team's normal work, I worked with our PM partner to hold air cover so she could stay focused on vision rather than getting absorbed into every emergent request. Getting her in front of the adjacent teams whose products Scout would eventually depend on and build for kept the vision from developing in isolation from the surfaces it would actually live inside.

By April 2026, the framing had landed. Scout's intelligence would become infrastructure embedded across the employer platform, with chat as one surface among several rather than the product itself.

Testing the shapes with AI tools

To test whether the contextual widget direction could actually replace the chat interface, we needed prototypes with enough fidelity to surface real interaction problems, and static screens wouldn't get us there.

The team had been picking up AI tools as they came out, and we put them to use here. In Figma Make, we built interactive prototypes of all four product shapes, going deep enough to explore how each handled the job posting funnel, candidate review, and the return-user experience. Working across multiple directions in parallel without handoff overhead meant we could stay close to the ideas while they were still alive.

We moved to Cursor to build working website demos, which gave us a fidelity level Figma couldn't match. From there, we wired actual Talent Scout chatbot input and output directly to the new UI concepts through Claude Code, so research sessions ran against real Scout responses. When an employer asked the interface a question, Scout answered it. That grounded the research in actual product behavior rather than a simulation of it.

Clearing the path

External team alignment was the operational challenge. As Scout moved into pages it didn't own, it needed the partnership of teams who did. A handful of teams moved early and willingly, but others were a harder sell. They all had their own roadmaps and legitimate concerns about a cross-cutting product layer adding complexity to experiences they were accountable for.

Our approach was to show up as a partner rather than another initiative competing for space on someone else's roadmap. The plan was to build trust from strength to strength. Each team that integrated and validated the patterns from the vision became proof we could point to in the next conversation. We backed this with a shared interaction library, a set of components and patterns any team across the employer experience could adopt to bring Scout's intelligence into their own product on their own terms.

Building a bench before I needed one

Strong senior ICs on my bench had the craft to manage well. None of them had a place to practice before the job was live, which made every promotion into management a cold start. A colleague and I built the Emerging UX Managers program to fix that: a curriculum of sessions we designed and facilitated ourselves, covering the parts of the job that surprise new managers most, with guest speakers from across the design org who had lived them. Demand outstripped the room. We capped the pilot at six senior and lead ICs and ran it as a cohort so participants could learn from each other's situations, not just ours.

All six became managers. One has since been promoted to senior manager, and two now hold director roles.

Managing a manager whose team nobody could see

The hardest manager-coaching problem I've had involved a manager who was already good at his job. He ran a capable team in India, and both were invisible to UX leadership, absent from the roadmap conversations where their work was being committed for them. Coaching him on execution would have changed nothing. The team's problem was access to the rooms where their work was being decided.

So the work was distribution. I championed the team's work directly with UX leadership, put their outcomes in front of the forums that decide reputation, and made sure their voice was in the room when product set roadmaps rather than reading the conclusions afterward. I held skip-levels with his ICs so I could speak about the team's work specifically instead of generically.

The result was a team that felt supported and saw itself in the roadmap it was building against. Managing him well meant getting his team visibility, access, and a seat in the roadmap conversation. Building those conditions is most of what the job is at this level.

Managing a director across a product boundary

I directly managed the director who led UX for the existing Sourcing team in APAC, the org that owned Smart Sourcing. At the same time, I sat on the Sourcing Steering Committee coordinating the AI Sourcing work, the product positioned to change what sourcing on the platform would become. That put a delicate line through our one-on-ones: his product and the one I was coordinating had to move in ways that served each other, and he had to hear that from his manager without hearing that his roadmap mattered less.

Managing a director is different in kind from managing a manager. I wasn't reviewing his work product; I was aligning his goals, giving him the platform context he needed to steer Smart Sourcing's roadmap himself, and using his judgment to shape decisions I was carrying into the Steering Committee. The influence ran both directions, which is what made it work. Smart Sourcing's roadmap bent toward the platform's future without a mandate, and both teams hit their goals.

Three seats, one decision

When AI Sourcing's lead designer resigned mid-launch, the obvious succession was to promote the senior designer already on the team. She was good enough to grow into the role, but not yet the right shape of leader for a team in a launch window, and promoting her under that pressure would have risked both her and the team. Instead I proposed three coordinated moves: Talent Scout's lead designer moved to AI Sourcing, the senior designer expanded her scope with support instead of a title change, and a lead from an adjacent team took over Talent Scout.

Each move needed leadership alignment, scope negotiation with an adjacent org, and an individual career conversation. All three landed inside six weeks, and no delivery milestone slipped.

The conversation I put off too long

One of my senior designers was methodical and systems-focused, real strengths that weren't translating to velocity on a pre-PMF AI product. I coached her on pace for months, telling myself the next sprint would close the gap. It didn't, and the team had started working around her. Unfortunately, her methodical approach and a pre-PMF product were a poor fit for each other. I coordinated with leadership to move her onto a team that needed exactly that way of working. She was contributing there almost immediately, and her new manager went out of his way to tell me how well she was doing.

I had been her advocate for longer than I should have been. Earlier honesty would have served both of us.

That experience changed how quickly I have those conversations now.

A hiring process that spread beyond my group

When I took over hiring for my group in Job Discovery, the interview loop had more people in it than the decision required. Coordinating that many calendars pushed candidate interviews weeks out, and every extra panelist was time pulled away from product work. I rebuilt the loop around a smaller panel and standardized how that panel reached its decision at the end, so every candidate was evaluated the same way against the same bar. That paid off further once we widened the talent pool past the cities where we had offices. A consistent loop and a consistent decision meant candidates were measured the same way no matter where they lived, which made hiring fairer as the pool grew.

It worked well enough in Job Discovery that UX leadership adopted it across Indeed's design organization. I've hired over a dozen designers directly through that process and participated in hiring dozens more researchers and content designers.