모든 엔지니어에게 세일즈 콜을 강제했더니 2주 만에 플랫폼이 완전히 재작성됨

• 한 스타트업은 엔지니어들이 직접 세일즈 콜에 참여하게 하면서 제품 개발 방식을 근본적으로 바꾸게 되었음
• 세일즈 콜 과정에서 고객들은 경쟁사 제품이 비기술 사용자에게 너무 복잡하다는 점, 모니터링이 작동한다는 확인 표시(녹색 체크) 를 원한다는 점, 그리고 “누군가 대신 해줄 수 없냐” 는 요구를 드러냈음
• 이를 통해 백엔드 중심의 팀은 사용자 관점을 이해하게 되었고, PM의 개입 없이도 새로운 아키텍처를 스스로 구상하기 시작했음
• 단 2주 만에 플랫폼을 60% 기능 축소, 진행 상황을 보여주는 프로그레스 바 추가, Slack 연동, 대행 워크플로우 기능을 구축했으며, 결과적으로 지원 티켓이 70% 감소했음
• 이 경험을 통해 얻은 교훈은, 사용자는 문제 해결만 원하지 우아한 코드에는 관심이 없으며, 기능은 코드량이 아니라 사용자 혼란이라는 비용을 발생시킨다는 점이었음

배경과 실험

• DevOps 시니어 엔지니어는 세일즈 콜 참여에 반대했지만, 최소 5콜만 해보자는 조건으로 동의했음
• 창업자는 엔지니어들이 직접 고객의 언어와 문제를 들어야만 제품 설계가 달라진다고 판단했음

세일즈 콜에서 얻은 인사이트

• 경쟁사 제품이 비기술 사용자에게 너무 복잡하다는 지적을 확인함
• 고객은 복잡한 지표보다 단순한 녹색 체크마크 같은 직관적 확인을 원했음
• 다수의 고객이 “대행 서비스” 를 요구하며, 단순 사용보다 문제 해결 자체를 외주화하고 싶어함

제품 재작성 결과

• 팀은 기존 기능의 60%를 제거하고 필수 기능에 집중함
• 단순한 프로그레스 바를 추가하여 사용 경험을 개선함
• Slack 통합을 통해 문의 흐름을 간소화함
• Done-for-you 워크플로우를 제공하여 고객의 요구를 직접 반영함
• 최종적으로 지원 티켓이 70% 감소, 제품 사용성과 만족도가 크게 향상됨

핵심 교훈

• 사용자는 우아한 기술적 해법이 아니라 문제 해결 자체를 원함
• 기술적 정확성보다 사용자 이해가 더 중요함
• 모든 기능은 코드가 아니라 사용자 혼란이라는 비용을 동반함

팀 문화 변화

• 이후 회사는 모든 엔지니어가 분기마다 5회의 세일즈 콜에 참여하는 것을 의무화함
• 엔지니어들이 직접 고객의 피로감을 듣고, “그냥 잘 작동하기만 하면 된다”는 요구를 접하며 제품 직관을 키우는 것이 문화로 정착함

레딧 댓글 주요 요약

• PM 역할 논쟁
  • 일부는 좋은 Product Manager 부재가 문제라고 지적하며, 엔지니어가 고객 통화까지 하는 것은 비효율적이라고 주장
  • 반대로 “PM은 오히려 번역기 역할에 그치며 엔지니어가 직접 고객 문제를 소유할 때 최고의 결과가 나온다”는 반박도 존재
• 고객 접점의 가치
  • 여러 댓글에서 엔지니어가 직접 사용자 목소리를 듣는 경험이 강력한 인사이트를 준다고 강조
  • 초기 단계 스타트업이나 작은 팀에서는 엔지니어가 곧 PM 역할을 일부 수행하는 경우가 흔하다는 의견도 있음
• 비판적 시각
  • “이건 단순히 리더십/문화의 실패를 엔지니어에게 떠넘긴 것”이라는 비판
  • “기능을 잘라내고 단순화하는 게 진짜 개선이냐”라는 반론도 있으며, 장기적으로는 파워 유저와 고급 기능 요구를 외면할 위험을 경고
• 긍정적 사례 공유
  • 은행, 의료기기 등 여러 업계에서 비슷하게 모든 직원이 고객 지원·영업을 체험하는 제도가 있었다는 경험담 다수
  • “Dogfooding”이나 “직접 고객 앞에 서는 경험”이 제품 품질과 문화에 도움이 된다는 공감
• 종합 시사점
  • 고객 문제를 직접 체감하게 하는 것은 강력한 학습 도구지만,
  • 동시에 장기적으로는 전문적인 PM·UX·디자인 역량과 결합되어야 균형 잡힌 제품 전략을 만들 수 있다는 점이 논의의 핵심으로 드러남