The Survey That Wasn't There

The problem

After we put help center search inside Retain, our employee retention product, people finally started using it. And once people were actually searching the help center, the searches started telling me things. One topic climbed into the top five that shouldn't have been there at all: employees looking for a survey they didn't have.

It was generating a lot of support load and a lot of frustration, and none of it was showing up anywhere the product team would see it.

My role

In 2026, while I was Product Owner for the awards portfolio, I started moving into the Product Owner role for Retain and Recruit too. It was the kind of work I'd been hoping to do, and I jumped in. Part of that was learning Engineering's ticket process with our VP of Engineering, and together we wrote about 20 tickets. This was one of them. I diagnosed the problem, proposed the fix, and wrote it up.

Finding the cause

I traced it back to the employee profile page. When someone had an open survey, the page showed a message about it. When they didn't, the message just disappeared. The "you have nothing open right now" case just hadn't been designed yet, so the blank space read as a missing task. Employees assumed they had a survey hiding somewhere and went hunting for it, and some of them ended up in the help center, or in their manager's inbox, frustrated.

The fix

I could have written another help article, but that would only have treated the symptom. Instead, I proposed an empty-state message that tells employees plainly when they don't have an open survey, so the page confirms where they stand instead of leaving them to guess. I wrote it up as a ticket with our VP of Engineering.

Recreated mockup of the three states. The middle one is the problem: an empty space where people expected a task.

Another ticket from the same batch: the peer-to-peer toggle

Not every ticket came from search data. I was sitting in on a customer demo with our customer success team, and peer-to-peer recognition was on by default, with no way to turn it off. Watching the customer react, it clicked that open peer recognition isn't what every organization wants. Some want recognition to come only through structured moments, like finishing a survey or hitting a work anniversary.

The customer asked if they could turn it off. The need underneath that was a bigger one: these organizations care most about survey participation, but surveys are anonymous, and rewarding people for taking one without compromising that anonymity is genuinely hard.

So I proposed making peer-to-peer configurable. An admin can switch it off and let recognition come only from completion triggers, which means rewarding people for finishing a survey, with the same anonymity protections we already use, inside the same system they take the survey in. No separate program to fund or talk people into.

It shipped. Turning peer-to-peer off is now a supported setup, and it opens a two-step rollout: an organization can start with participation rewards and add peer-to-peer later, once people are used to recognition showing up at all.

Making support data a habit

Support data is one of my favorite product research tools, because customers tell you exactly where they're stuck. So I made reviewing it a routine. I pulled every support ticket from Salesforce for the quarter, across all our products, and reviewed them all, using AI to spot the patterns that are hard to see one ticket at a time.

The review showed which products generated the most ticket volume, which ones customers felt most negatively about, and the specific friction behind it. Customers using Connect, for example, kept telling us billing information was hard to find. I brought the findings to the product team as input for planning, and the plan was to rerun the review every quarter so we could track which issues improved and catch new ones early.

For the help center work that made the search data possible, see Putting Answers Where People Get Stuck.