<aside> 💬 안녕하세요. 저는 크리에이터 커뮤니티 관련 서비스를 담당하고 있는 Product Owner 이고요. 에이전시에서 서비스 기획을 시작으로 현재는 스타트업에서 9년 넘게 재직하며 다양한 사용자를 접하며 서비스를 만들어가고 있습니다. 프로덕트 관점에서 사용자 피드백을 어떻게 대응하고 있는지 열심히 풀어보겠습니다!
</aside>
뉴스레터에 포함된 메이커의 답변에 대한 추가 질문은 물론, ‘고민상담’을 신청하실 수 있어요!
이런 분들에게 추천해요!
사용자 피드백과 데이터 분석 결과가 다를 때, 어떻게 의사결정을 하시나요?
<aside> 💡
피드백과 데이터가 다른 부분이 있다면, 그 다른 점이 발견되는 지점의 기능과 지면 주요도를 먼저 파악해봅니다. 그리고 그 지면과 기능이 현재 팀에서 집중하고 있는 포인트와 다른 점이 없는지 먼저 찾아봅니다.
프로덕트 전반적인 흐름에서 피드백과 데이터 인사이트가 다른 지점이 비교적 주요도가 낮고 팀이 집중한 포인트와 다르다면 피드백과 데이터 비교 분석한 결과 자체를 낮은 우선 순위로 백로그에 저장해두고, 추후 고려하는 정도로만 대응을 진행합니다. 아무래도 리소스가 한정적이고 달성해야 하는 KPI에 집중을 하기 위해서 백로그에 저장하는 편입니다.
다만, 팀이 집중하고 있는 지면인데 피드백과 데이터가 다르다면 사용자 피드백을 중심으로 다시 데이터를 분석하는데요. 우리가 누락하는 데이터가 없는지 다시 분석해 본 후 해당 피드백이 기능적 오류인지, 안내 멘트로 인해 사용자가 착각할 수 밖에 없는 구조인지 재차 확인해봅니다.
</aside>
수집된 사용자 피드백이 대세의 의견인지 아닌지 구분하는 법이 있을까요?
<aside> 💡
대세 의견을 구분하는 기준은 다수의 사용자에게 유사한 피드백이 오는지를 기준으로 합니다. 특히 신규 기능은 배포 직후 2주정도 CS 이메일 등 사용자 피드백이 들어오는 채널을 꼼꼼히 살펴보는 편이에요. 서비스 변화 직후의 사용자 피드백은 그만큼 서비스 변화에 민감하게 받아들이는 사용자로 판단하여, 충분히 대세의 의견으로 귀 기울일 수 있다고 생각합니다.
물론 의도적으로 개선한 부분에 대해 롤백의 피드백이 오는 경우도 있는데, 이 경우 서비스가 가고자 하는 미래 지향점을 감안하여 피드백을 접수하는 편입니다. 그리고 추가적으로 제가 만든 서비스더라도 자주 써보려 하는 편이에요. 쓰다보면 예상 외로 기획할 때 발견 못한 포인트나 추가 개선사항을 발견할 수 있는데 직접 느낀 부분이 피드백으로 들어오면 적어도 고려해볼 가치가 있다고 판단하는 편이에요.
</aside>