90 “피드백 = 기능? 오해하면 망합니다”

서비스 운영을 하다 보면 꼭 듣는 피드백이 있죠.

“이 버튼 위치가 불편해요.”
“이런 기능 있었으면 좋겠어요.”
이건 왜 이렇게 복잡하죠?”

 

우리는 이 피드백을 최대한 빠르게 반영하려고 합니다. 고객 중심, 유저 퍼스트, 민첩한 대응… 다 맞는 말이죠. 그런데, 피드백을 곧장 기능으로 바꾸면 오히려 실패할 수 있어요.

왜일까요?

 

피드백 = 니즈일까?

고객이 말한 피드백은 대부분 ‘겉으로 드러난 불편’입니다. 하지만 그 말 뒤에는‘진짜 바라는 것’이 숨어 있어요.

 

예를 들어

“즐겨찾기 버튼이 있었으면 좋겠어요.” 라고 말했을 때, 정말 즐겨찾기 버튼이 필요한 걸까요?

 

사실 그 사람은 자주 쓰는 기능을 빠르게 접근하고 싶다는 의미일 수도 있어요. 즉, 해결책을 말한 게 아니라, 겪고 있는 문제를 말한 것일 수도 있는 거죠.

 

피드백 분석할 때 PM의 사고 순서

1. 사용자 배경 파악하기
   • 어떤 상황에서, 어떤 흐름 속에서 이 피드백이 나왔는지?
2. 반복성과 빈도 확인
   • 몇 명이, 얼마나 자주 이 문제를 겪고 있는가?
3. 기존 UX 흐름과 충돌 여부
   • 이 기능이 추가되면 전체 흐름은 유지될 수 있는가?

이 세 가지를 거치지 않으면, → 사용자가 요청한 걸 만들어줬는데 더 불편해졌다는 말도 듣게 돼요.

기능 반영 전 체크리스트

• 이 피드백은 일시적 상황에서 나온 건 아닌가?
• 전체 사용자 중 몇 %에게 해당하는가?
• 기존 흐름을 해치거나 혼란을 유발하지 않는가?
• 비즈니스 목표와 방향이 일치하는가?

실전 사례

고객 요청: “즐겨찾기 기능이 필요해요.”

 

초반엔 버튼을 추가할까 고민했지만, 데이터를 보니 고객은 ‘특정 기능을 자주 사용’하고 있었고, 그 기능으로 가는 동선이 너무 길었어요.

결론은 홈 화면에 ‘최근 사용 기능’을 노출시키는 걸로 해결. 버튼 하나 추가하는 것보다 더 효과적이었고, UI도 단순하게 유지할 수 있었죠.

 

정리하며

고객의 피드백을 바로 기능으로 만들지 마세요. 그 피드백을 진짜 니즈로 해석할 수 있어야 PM으로서 더 나은 제품 방향을 제시할 수 있습니다.

다음에 이런 피드백을 들으면, 이렇게 생각해보세요👇

“이 말 뒤에 숨은 불편은 뭘까?”

“이 기능이 진짜 필요한 이유는 뭘까?”