Putting the employee in the driver's seat.
Journeys could guide employees through their most important moments, but only the ones the system already knew were coming.
Background
Workday Journeys is a platform built for the moments that matter most at work: onboarding, parental leave, a job change. HR teams use it to guide employees through complex, personal transitions at scale, delivering the right guidance at the right time without doing it manually for each person.
The problem
The product had a hard constraint: it could only trigger when the system already knew an event had occurred. Onboarding started when a hire was entered, and leave guidance went out when a leave was filed. An employee considering family planning, wanting to understand what support her company offered before making any decisions with her partner, had no path in.
Outside the system, that guidance lived scattered across intranet pages, Google Docs, and emails: outdated, hard to find, and impossible to trust. The fallback was reaching out to HR and waiting for an answer.
HR teams were absorbing that noise, spending time on reactive questions that should have been self-serve, and without a way for employees to reach the product on their own terms, product adoption had a ceiling.
How I approached it
I pushed for this problem space when the team's instinct was to stay focused on the administrator experience. My case was: if employees couldn't self-serve, HR couldn't scale, and building for the employee was the path to making the admin more effective.
Before defining any solution, I launched a Design Partner Group, a structured customer advisory program with a diverse mix of customers meeting 2×/quarter. That process, combined with market research and company investment priorities, shaped what self-service actually needed to mean and what the strategy would look like.
The bet
Self-service was an entire product area, which meant the roadmap was years long, not months. We made a deliberate call: ship the minimum, create a live experiment, and let customer behavior tell us what to build next. That meant base functionality, a single share link, administrator-created, zero new UX.
There was trade-off pressure and the team was resource-strapped, but our customers were screaming for this functionality and the product needed it for adoption. The way I saw it, we'd learn more from customers actually using the thing than from any amount of pre-launch research.
What changed
50% of requesting customers implemented within the first 6 months. More importantly, post-launch feedback surfaced something pre-launch research had only hinted at: customers needed audience segmentation, the ability to limit a journey to a targeted group, like to executives or to engineers in a specific region.
We had heard some signal for this before launch, but not enough to move it above other investment areas. Going live made the scale of that demand immediately clear, and it reordered what followed.
The launch also created a roadmap for Journeys that hadn't been possible before: AI-driven suggestions, case deflection, adoption growth across the Workday platform. Those were the opportunities on the table when I left.
What I'd do differently
Internal alignment took more time than it needed to. Living prototypes and documentation eventually got things moving, and both should have started earlier before the politics set in.