ServiceNow · Platform scale · Product Manager
Notifications at 250 million sends a month, and a feedback product people chose to use
Two products with opposite problems. Notifications is a platform where the hard part is restraint at scale. Feedback is a product where the hard part is persuading people to use it at all. I owned both.
Context
Notifications sat underneath a large part of the employee experience suite. Almost every other surface depended on it to tell users that something had happened, which made it a platform in the real sense: the people affected by its decisions were mostly other teams, not end users.
Feedback was the opposite kind of problem. A voluntary product, competing for attention, where the only measure that mattered was whether employees bothered.
Problem
The notification problem was volume. At hundreds of millions of sends a month, every decision compounds. A slightly noisy default becomes a company-wide problem, and once users start ignoring notifications, no amount of new ones brings the attention back.
The feedback problem was indifference. Employees had no strong reason to engage and plenty of reasons not to, including a reasonable suspicion that nothing would come of it.
- Notification defaults were set per integration, so noise accumulated without anyone owning the total.
- Volume was a distributed consequence of many teams' individual choices, which is the hardest kind of problem to fix.
- Adoption in a voluntary product depends on trust, and trust is slow to build and fast to lose.
The decision
On notifications, I treated volume as a product feature to be governed rather than a byproduct to be tolerated. That meant pushing defaults toward quieter, making the total visible, and accepting that some integration owners would be unhappy about their send counts dropping.
On feedback, I prioritised closing the loop over collecting more input. The instinct is to make the ask easier. The better move was to make the response visible, because adoption in a voluntary product is driven by whether people believe it changes anything.
The alternative I rejected on notifications was to keep adding channels and preferences and let users manage their own noise. Preference management shifts the cost to the person least able to see the whole picture, and most people never touch the settings.
What I did
- Owned the notification platform as a product, including the defaults that determine most of the volume.
- Worked with the integration owners across teams, since the send volume was under their control rather than mine.
- Ran the feedback product end to end, from the collection experience through to making the follow-up visible.
- Kept the two products separate in framing, because the metrics that define success for a platform and for a voluntary product pull in different directions.
Result
Notifications ran at more than 250 million sends a month across the suite. Feedback reached roughly sixty percent employee adoption, which for a voluntary internal product is the number that matters most.
What I'd change
I would have instrumented notification quality earlier, not just volume. Send counts tell you how loud the platform is. They do not tell you whether the right messages are landing. Those are different questions and the second one is the one users actually feel.