Before Someone Posts “This App Is Slow” ─ How to Notice Unspoken Discomfort

Introduction: How a Single Short Comment Can Make Your Heart Skip a Beat

One day, I happened to see a post on social media.
“This app’s been a bit sluggish lately, hasn’t it?” ─ just that, a short, simple comment.

It’s not a harsh criticism of anyone, nor is it a clear complaint.
And yet, the moment you see that post, you sometimes feel a strange sense of panic, like something churning deep in your chest.

“If only we’d noticed earlier.”
“Couldn’t we have picked up on the dissatisfaction this person is feeling, somewhere along the way?”
Those thoughts start to slowly well up afterward.

---

In fact, we ourselves have had similar experiences many times.

For example, there was a time when the CS team shared:
“Among the inquiries, someone mentioned that ‘it feels a bit slower lately.’”

At that time, monitoring on the development side looked normal. We couldn’t reproduce the issue, so it was brushed off with, “Hmm, maybe it’s just their imagination.”
Later on, however, we finally discovered that animation processing had become a bottleneck under certain older devices and network conditions, and we were able to trace the cause of the slowness.

---

“We probably could have acted sooner” ─
But why was it that we “failed to notice” at the time?

Starting from that vague frustration,
we’d like to explore together how we can notice the “early signs of dissatisfaction” before they turn into explicit complaints.

Dissatisfaction Doesn’t “Suddenly” Appear; It Builds Up “Gradually”

When someone says, “The app is slow,” we instinctively want to ask, “Since when?”
But in reality, in most cases it’s not that “it suddenly became slow from a certain day onward.”

Dissatisfaction gradually accumulates inside the user.

At first, it might just be a feeling of “Well, maybe it’s a bit slow?”
But if that happens a few times, it turns into “It feels heavier than before,” and eventually into “This is starting to get a bit irritating.”
Finally, dissatisfaction appears in a visible form, such as on social media or in reviews.

What makes this difficult is that many people simply leave without ever speaking up.

• “It’s not a deal-breaker, so it’s not worth the trouble of saying anything.”
• “It was probably just a one-off.”
• “There are other options, so I’ll just use those.”

In this way, a “quiet discomfort” lingers inside the user, and one day they just drift away.
The people who actually voice their dissatisfaction might, in fact, be the precious ones.

---

That’s exactly why it’s so important to catch the “early signs” before they surface.
The moment someone thinks, “This feels a bit slow lately…,” can someone else pick up on that discomfort?
Or, even if they do pick it up, is there an environment where it actually gets communicated?

It feels to us that this isn’t just a technical issue; it’s also deeply tied to the organization and the relationships within the team.

From Each Standpoint: What Was Visible, and What Wasn’t?

When we think, “Couldn’t we have noticed this earlier?”, we tend to look for “who missed it.”
But in reality, in many cases someone has noticed some kind of discomfort.
It just didn’t get through the team or organization, or it wasn’t picked up, or it wasn’t prioritized.

Here, let's organize what roles each standpoint plays, what perspectives they have, and what kinds of misalignments tend to occur.

🧑‍💼 Customer Support (CS)

This is the team that receives customer inquiries and complaints on the front line.
Because they respond carefully to each individual voice, they can be the first to notice “lightweight discomfort” such as “It seems to be running a bit slow lately.”

However, because this kind of information “doesn’t have quantitative backing,”
it often gets brushed aside by the development team or other departments.

🗯 Inner voice:

“Maybe I didn’t explain it well… but I did say it, right? Properly.”
“How much are they really going to pick up on this kind of vague, subjective feedback…?”

🤝 Sales / Customer Success

They are in daily communication with clients.
In regular meetings or proposal discussions, they can directly pick up on users’ gut feelings and small dissatisfactions.

However, when it’s more like “a complaint that came up in casual conversation” rather than a “formal request,”
it often never makes its way back to the product side.

🗯 Inner voice:

“Should I report this…? Eh, it sounded like just small talk.”
“They’re just going to say, ‘Can you get more details?’ anyway, I bet.”

🧑‍💻 Developers (Engineers)

They are the technical staff responsible for developing and maintaining the app.
When there are bugs or performance issues, they investigate and fix them.
But because they usually act based on numbers (monitoring results) and reproducible phenomena, vague feedback like “It feels slow” is, honestly, hard to deal with.

🗯 Inner voice:

“But the data all looks normal…”
“What am I supposed to do with ‘it feels that way’…? I can’t reproduce it here…”
“We’ve got a mountain of tasks with higher priority than this…”

🧑‍💼 Engineering Manager (EM)

They manage the progress of the development team.
They handle sprint progress, technical decision-making, and resource allocation.

For EMs, how to handle “discomfort” information coming from PdM, CS, or management is a key judgment call.
If on-site developers say, “We can’t reproduce it,” the priority tends to drop.
On the other hand, if the problem surfaces later, they’re the ones who get asked, “Why didn’t you address this?”

🗯 Inner voice:

“How seriously should we take ‘it feels slow’?”
“The team has no slack, and I’d really like more concrete evidence…”
“But if management brings it up later, they’ll say, ‘Why didn’t you act on it?’…”

📈 Product Manager (PdM)

They decide the direction and priorities of the product.
To decide which features to build or improve, they coordinate input from CS, development, sales, marketing, and others.
How to handle vague feedback like “It seems a bit slow” is a tough call.

• There’s no quantitative data
• It doesn’t directly tie to KPIs
• The scope of impact is unclear

Because of that, it’s an area that tends to be put off with, “Let’s wait and see for now.”

🗯 Inner voice:

“How big of a problem is ‘it might be a bit heavy’…?”
“Without numbers, it’s hard to explain to management, and we’re already packed with other improvements…”
“But what if it turns into something irreversible later…?”

🧑‍💼 Management

They are responsible for the overall direction and accountability of the company.
Even if they don’t interact directly with users, they are sensitive to voices on social media and negative reviews.
Sometimes they only notice when it becomes a topic outside the company and think, “Are we okay?”

🗯 Inner voice:

“Why is no one noticing that people are saying it’s ‘slow’?”
“Couldn’t we have noticed before it went public…? No, but surely someone had a bad feeling about this, right?”

Isn’t This “We Failed to Notice” Problem Happening Elsewhere Too?

We failed to notice before someone wrote “The app is slow” ─
Looking back, we feel there are several other cases with a similar structure that we’ve overlooked.

For example, do any of these situations sound familiar?

---

📋 Low completion rate on the contact form

On the surface, it just looks like “the submit button isn’t being pressed,” so the problem is hard to see.
But in reality, the form is too long, input is a hassle, people drop off midway ─
Unspoken dissatisfaction is quietly piling up.

🗯 Early signs that are easy to miss:
The CVR hasn’t changed that much. But if you look closely, many people start filling it out and then leave.
You’re seeing more and more inquiries that feel like “They wanted to say something, but in the end they didn’t send it.”

🛠 The “subtly inconvenient” internal tools

No one is complaining. But somehow the operations are complicated, or loading is slow.
There are many problems that don’t surface because users (i.e., people inside the company) are “putting up with it.”

🗯 Early signs that are easy to miss:
In regular meetings, someone says, “This is a bit hard to use…,” but it ends there.
During onboarding for new hires, you’re seeing more moments where they stumble over how to use it.

Lining these up, they all share a common structure of “the function works, but the experience is gradually degrading.”

• Dissatisfaction is rarely voiced
• But once it piles up, it eventually appears as “churn” or “negative reactions”
• By the time you notice, it may already be almost too late

We too have failed to notice these kinds of early signs many times.
While we think, “If only they’d told us, we would have fixed it…,”

we’ve also come to feel it’s important to step back and ask, “Did we have the mechanisms and relationships in place for them to say something in the first place?”

What We Tried to Notice the “Early Signs”

“How could we have noticed this earlier?”
We’ve asked ourselves that question many times.

Among our attempts, here are some examples of things that, while not perfect, have made it easier to notice early signs.
We’re still in the middle of trial and error with all of them, but we’d be glad if you find yourself thinking, “Maybe this kind of approach could work too.”

📊 Turning performance indicators into “numbers we can visualize”

Users’ sense that “it feels a bit slow” is hard to capture numerically… but that doesn’t mean it’s impossible to measure at all.

For example:

• LCP (Largest Contentful Paint): Time until the main content of the screen is displayed
• FID (First Input Delay): Speed of response to user input
• TTFB (Time to First Byte): Time until the first response is returned

We started continuously watching these and making it easier to catch changes like, “Huh, haven’t things been getting worse lately?”

Note: Even just tracking these indicators in graphs brings you closer to “shared facts” rather than just “feelings.”

🔄 Automatic performance comparison before and after releases

At one point, we had an incident where “after changing a specific UI component, people said it got ‘slower.’”
In response, we introduced a mechanism to automatically measure the release build with Lighthouse and compare it with the previous one.

• Regularly save scores
• Notify Slack if there’s a major regression

By changing our operations this way, we were able to reduce the number of times we only noticed when “it was already too late.”

💬 Creating a channel where even vague discomfort can be shared

We once created a “#ux-feedback” channel in our internal Slack.
There, we allowed posts like:

• “This screen kind of feels like it takes a long time to load every time.”
• “Lately it feels like the click response is slower.”

even if they were just vague, non-quantified discomfort.

At first, posts were sparse, but over time the culture took root, and we started seeing more cross-department connections like, “Actually, we heard something similar from Company X as well.”

🧭 Creating an atmosphere where people feel “It’s okay to say this out loud”

In the end, the atmosphere might be even more important than the mechanisms.

• People don’t feel, “There’s no point in saying this”
• Even “fuzzy discomfort” is accepted
• There’s a sense of safety that someone will say, “You’re right!” and pick it up

With this kind of culture, early signs finally start to take shape as words.

---

Of course, these are just examples.
It’s hard to adopt everything all at once, and they’re not necessarily the perfect solution.
But we feel that having mechanisms to keep an antenna up for “dissatisfaction before it becomes a complaint” will surely help any team.

Summary: Becoming a Team That Can Notice “Early Signs” Through Technology and Organization

Someone posts on social media, “This app’s been a bit sluggish lately.”
Before that, someone, somewhere, must have felt something was off, but it never got through.
We’ve had that experience many times ourselves.

---

When we think about this problem, the conversation often turns to “relationships” and “organizational culture.”
Those are certainly very important.
But there are also situations where that alone isn’t enough.

Subjective “slowness” or “hard-to-use-ness” is inherently hard to notice.
Even if you notice it, it’s hard to share, and hard to judge.

How can we reduce these three kinds of “hard”?
To tackle that, we feel we need both cultural groundwork and technical mechanisms.

Examples of what can be done as technical mechanisms

• Continuous monitoring and visualization of performance indicators (LCP, FID, etc.)
• Automatic performance tests per release (Lighthouse, etc.) to detect regressions
• Visualization of user behavior logs with analytics tools (drop-off rates, skew in mid-flow actions, etc.)
• Setting up feedback channels (Slack, GitHub, etc.) where even “light discomfort” can be recorded

With these mechanisms, it becomes easier to visualize, accumulate, and share “vague discomfort.”

Organizational aspects to keep in mind

• Having an atmosphere where it’s okay to voice ambiguous discomfort
• A sense of trust that the feedback you raise won’t be “swept under the rug”
• Communication that consciously “translates” between technical teams and non-engineering teams like CS/sales

In other words, mechanisms to catch early signs, and relationships to nurture them. Only when both are in place can an organization gradually take shape that notices issues before they’re pointed out from the outside.

We’re still in the middle of trial and error ourselves.
But rather than just regretting what we “failed to notice,” we believe the most important thing is to keep asking, “How can we become able to notice?”

💡Note: We Also Support This Kind of Initiative

In this article, we’ve explored the theme of “How can we notice discomfort before it turns into explicit feedback?” from an on-the-ground perspective.
We feel this is a challenge that everyone faces as their product grows.

Our company supports building “teams, mechanisms, and cultures that can catch early signs” from both the technical and organizational sides.

🛠 Examples of technical support

• Building mechanisms for automatic detection and visualization of performance degradation
• Designing the collection and analysis of user behavior logs
• Building integration foundations for feedback with Slack, Notion, BI tools, etc.

👥 Organizational support

• Designing Slack operations and mechanisms that can pick up “discomfort” within the team
• Designing regular cross-functional meetings that connect CS/development/sales
• Designing and workshopping “early sign judgment frameworks” for PdMs/EMs

By bridging technology and organization, we provide hands-on support to reduce “we failed to notice” and increase “we’re able to notice.”

If you’re interested, feel free to contact us.
Even if, after talking, you feel “It might be too early for us,” that’s totally fine. We’d be happy to start by thinking together about how we can nurture healthy products side by side.