VoC Meeting Retrospective #1 — User Feedback, Raw and Unfiltered Please
Being "genuinely" user-centric
DelightRoom's Product Operation Group (hereafter POM group) is a team that acts as a bridge between our users and the product (team). We listen to users' voices and help solve their problems, while also delivering the insights we gather back to the team. We handle standard Customer Support (CS) and Customer Experience (CX) tasks, but we strive for much more than that. 🚀
If I had to pick the thing I'm most proud of about our company as a member of the POM group, it's that the company is genuinely user-centric. It's easy to claim "we care about our users," but I think it's extremely difficult for all members to actually internalize and practice it. (Just like it's easy to say "I'm a very honest person.")
Since we're the group working most closely with users, we would have suffered greatly if the company's words didn't match its actions here. However, DelightRoom genuinely always considers our users and listens to their voices. So, in this post, I'd like to share one part of that effort: the VoC (Voice of Customer) Meeting. Over a two-part series, this first post will walk you through the birth👶 of this meeting.
ㅤ
The snowball started by the Good Morning screen
Even before the formal VoC meeting process existed, there was still a workflow for conveying user voices and sharing opinions on them. Back then, to make it easier for other members to understand, the POM group utilized both qualitative and quantitative methods—sometimes sharing the original text as-is, and other times providing data on the volume of similar feedback categories. Because all our members paid close attention to this, we were able to respond quickly whenever we caught a problem.
But... earlier this year, an incident occurred during this process of the POM group delivering VoC to the rest of DelightRoom that gave us a burning thirst: we wanted to understand each other's thoughts better!
ㅤ
Back in February, while improving our Good Morning screen, we added an illustration of someone waking up refreshed to better emphasize the message of starting a good morning. The goal was to embody what Alarmy strives for: not just being a simple notification-level alarm app, but something that helps you kick off your morning right at the start of your day.
However... after deploying this update, user feedback started pouring in. From related bug reports to complaints about the copy, complaints about the screen brightness and image, to complaints about the sheer fact that this screen appeared at all—in the beginning, there was such a wide variety of issues that it was hard to clearly distinguish and categorize them.
ㅤ
Categorizing the issue symptoms and verifying the facts with the relevant teams went smoothly, just like usual. The problem was, "So, what do we do next?" From the POM group's perspective, we worried: We've conveyed that there are a lot of complaints, but what happens now? If our team has specific needs, how should we deliver them?
Other members were deep in thought as well. Some thought everything would be fine once the bugs were fixed, while others couldn't quite understand what exactly was making the users uncomfortable. Some also thought that even if the bugs were fixed, the screen itself needed a quick revamp.
Ultimately, everyone was left wondering, 'Who do we discuss this with, how do we discuss it, and how do we decide?' 🤔
ㅤ
This is where DelightRoom's user-centricity truly shines. Rather than just having the relevant members gather and hammer out a quick decision, we focused on the root of it: what exactly is the problem our users are experiencing? To ensure everyone grasped this without any discrepancy in urgency, the POM group set up a meeting where all relevant members gathered to "listen to the users' voices exactly as they are."
ㅤ
The power of being on the same page
The goals for that first meeting regarding the immediate Good Morning screen issue were to:
Understand the users' complaints,
Determine follow-up action items, and
Decide who would handle them and how.
These were our objectives.
To understand the users' complaints, the POM group compiled all the raw VoC data and shared it with the members. Aside from occasionally sharing a few striking reviews, it was our first time passing along all the raw data entirely unfiltered. (I was actually a bit worried because there was some pretty explicit swearing in there.)
Having read through the users' perspectives beforehand, the meeting felt quite different from usual. Because everyone read the feedback exactly as it was written—not filtered or summarized by anyone else—even those outside the POM group could deeply feel just how frustrated our users were. Naturally, we all began to feel the urgency of the problem at a similar temperature.
With the gap in our temperature narrowed down, defining the problem more specifically and setting up follow-up action items proceeded at lightning speed.
Should we keep this screen?
→ Right now, the complaints seem amplified by the bugs. There was a value we wanted to provide through this screen, so let's fix the bugs first and observe a bit longer.What should we do first to reduce complaints?
→ Users seem to feel it's displayed for too long, so let's show it for a shorter time.
→ The image might be perceived negatively depending on the country or culture. Let's swap it for a lower-risk image.
→ People are annoyed when it pops up at non-morning times, so let's only show it in the morning.
... and so on.
ㅤ
After that highly dense one-and-a-half-hour meeting wrapped up, progress on the action items kicked off smoothly. Since the engineers and designers executing the work also attended the meeting and heard what the users thought, their priorities perfectly synced up with what the managers or product planners had in mind. Thanks to everyone diving in with a sense of ownership, the issues were resolved incredibly fast considering their sheer number and impact.
Watching everyone tackle the issue with one mind like this, the POM group felt that previously inexplicable thirst fade away. We realized this must be the solution to those moments where we felt, 'We thought we conveyed how important this was... was it assigned a lower priority?'
Other folks gave similar feedback. They mentioned that when we just said, "We received this many pieces of feedback," it was hard to gauge how heavily they should weigh it. But after seeing the raw text and discussing it together, the problem became crystal clear.
ㅤ
And so, with its purpose clarified through validating our needs, the VoC meeting became a regular event—happening every single week!—where we share around 200 pieces of user feedback exactly as they are. Early on, we focused heavily on feedback regarding the Good Morning screen, but gradually, our goal shifted from resolving a single issue to listening to our users' voices as closely as possible.
ㅤ
The Good Morning screen today
Before wrapping up part one, it'd be a shame if I didn't tell you how the Good Morning screen ended up changing, right? 😏
After deep thought and rapid execution from everyone, the following changes were applied.
Shortened the screen display time to about 1.5 seconds,
Changed the illustration of a person and the morning sky to be much simpler, and
To deliver value beyond just an alarm app without being restricted to morning hours, we made it randomly display one of various encouraging messages.
Since then, the complaints pouring in about the Good Morning screen vanished, and we've seen an increase in praise from users saying they draw a lot of strength from the encouraging messages. Of course, there's always more room for improvement, but we confirmed that the value we intended could indeed be successfully delivered to our users.
In the next post, I'll dive deeper into how the VoC meeting has evolved since that twist-filled first meeting, and what lessons we've learned along the way.