Employee Works: zero to general availability in six months

Employee Works was a new surface inside ServiceNow's employee experience suite, aimed at the everyday employee rather than the HR administrator. That distinction mattered more than it sounds. Most of the suite had been designed for people who run processes. This was for people who are subject to them: finding a colleague, raising a request, reading a policy, getting something fixed.

I joined as Product Manager and owned the surface end to end, from early definition through general availability and into the customer pilots that followed.

The problem presented itself as a scope problem, but it was really a sequencing problem. There was a committed general availability date and no existing usage data to reason from, because nothing had shipped yet. Every feature anyone proposed looked reasonable in isolation.

• A fixed GA date, which made the scope of the first release a real constraint rather than a planning exercise.
• Ten enterprise pilot customers waiting behind it, each with a slightly different idea of what "employee experience" meant.
• No telemetry from a prior version, so prioritisation could not lean on behaviour. It had to lean on argument.

I argued for a deliberately narrow first release built around the few jobs almost every employee does regularly, and for holding the rest until after GA, even where that meant saying no to asks from the pilot accounts.

The instinct inside a large company is to answer every enterprise request before launch, because saying no to a customer is uncomfortable. I took the position that shipping a small set of things that work is worth more than shipping a broad set where half of it is thin, and that the customers would judge us on the first surface they actually used.

The alternative I rejected was a phased rollout where each pilot got its own configuration. It would have looked responsive. In practice it would have multiplied the surface area we had to keep working, at exactly the moment we had the least capacity to maintain it.

Most of the work was making the tradeoff explicit and then holding it under pressure.

• Ran the workshops with pilot customers. Separated what they asked for from the job they were trying to get done, which is where several of the loudest requests turned out to be workarounds for other problems.
• Wrote and owned the requirements for the first release and its boundaries, including the parts being explicitly deferred, so the gap was a documented choice rather than an oversight.
• Worked with engineering and design on the increment plan that got us to a GA-quality bar inside the window rather than a demo-quality one.
• Kept the pilot accounts engaged with the roadmap instead of with side agreements, so the reason for the sequencing was visible to them.

Employee Works reached general availability in six months, then scaled to ten enterprise pilots and more than a million end users.

The narrow-scope call also paid off in a way I had not fully anticipated. Because the first release was small, the team could respond to real pilot feedback quickly in the releases that followed, which is where the product took most of its shape. A broader first release would have left us defending it instead of improving it.

I would have instrumented the first release more aggressively. With no prior telemetry and a hard date, we leaned harder on qualitative pilot feedback than I would now be comfortable with. Instrumentation is cheap to add early and painful to retrofit, and it would have told us sooner which of the deferred items were genuinely the next most valuable thing to build.