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.

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.

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 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.

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.

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: 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 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.

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.

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.