▲

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

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

배경과 실험

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

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

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

제품 재작성 결과

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

핵심 교훈

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

팀 문화 변화

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

레딧 댓글 주요 요약

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

저점을 높이는게 목표인 조직이라면, 웹프론트 개발자로만 이루어진 팀, 앱개발자 팀처럼 역할 조직이 맞다고 인정한다.

하지만 고점을 목표로 하는 팀이나 조직에서는 역할 조직으로 구성하는 것은 반드시 한계가 있다.
본문의 내용과 같이, 굳이 기획자, 디자이너, PM, 엔지니어가 각각의 일을 맡아, 공장의 컨베이어벨트처럼 일해야하는가? 하는 의문이 생기는 것인데, 담당하는 몇 가지만 맡아서 일하는 전형적인 "담당자"식의 일이 아니라, 각 분야에 스페셜리티를 가진 구성원이 모여서 공통 목표를 함께 설정하고, 전 구성원이 서포트하는 형식이 이상적이다.

여러 회사에서는 분사, 팀 구성 등의 테스크포스 형태로 조직을 구성해 나가는데, 이 또한 사람(역할)만 묶어놨기 때문에 부적 강화(내가 무언가 하는데, 회사가 도와주질 않네, 그냥 포기해야지와 같은 패턴)가 발생해, 키 멤버와 같은 주요 인재만 잃을 수 있으니, 목적조직 또한 역할 조직의 적극적인 서포트가 반드시 필요하다.

답변달기
▲
GN⁺ 12시간전  [-]
Hacker News 의견
  • 마지막엔, 그들은 내 “PMing” 없이 완전히 새로운 아키텍처를 구상했음. 그 이유는 우리 제품을 실제로 사용하는 사람이 누구인지 드디어 제대로 이해했기 때문임. 이 경험을 전체적으로 보면, “엔지니어한테 세일즈 콜을 맡겨봤더니, 결국 문제는 PM들이 고객과 엔지니어링 사이 소통을 제대로 못 하고 있었고, DevOps 엔지니어가 오히려 고객 니즈를 실제 작동하는 솔루션으로 빠르게 전환하는 사람이었다”는 결론임
    • 엔지니어가 자신감에 차 있어서 사용자가 제품을 잘못 쓴다고 생각하는 경우가 있음. 이는 “사용자가 멍청하게 굴어서” 생긴 일이지, 내가 만든 복잡한 디자인에는 문제가 없다는 논리임. Desktop Linux 진영 사람들만 해도 사용자 불만을 무시한 경험으로 책 한 권 쓸 수 있을 정도임. 고집 센 엔지니어가 PM과 사용자보다 본인이 낫다고 여기면 아무 일도 진전이 없음. 하지만 그런 엔지니어를 사용자 직접 상대하게 던져놓으면, 평소 친근한 PM 대신, 실제 짜증 내는 유저들이 “이 멋진 창조물”이 마치 문제 많은 햄스터라도 되는 양 혹평을 쏟아냄. 이런 과정은 두려움도 주지만 엔지니어 자존감도 무너지게 함. 내 관점에선, 이건 PM이 멍청하다고 보여주려는 게 아니라 엔지니어를 겸손하게 만드는 일임. 시간이 지나면 또 엔지니어 자만심이 돌아와서 이 과정은 반복적으로 필요함
    • 나는 대형 기업의 기계공학팀에서 오직 코드를 쓸 수 있는 사람임. 사내 IT팀이 다양한 소프트웨어를 직접 만들지만 대다수는 팀원들 눈엔 별로임. 그래서 아예 이걸 새로 만들거나, 도저히 대체 못 하는 “별로인” 프로그램을 보완하는 툴을 직접 고안해서 일을 쉽게 함. 내가 인하우스 IT팀보다 개발을 잘한다기보다는, 실제 사용자 시각 때문에 본인, 즉 우리 팀에 진짜 필요한 게 뭔지 더 잘 파악한다는 생각임. 그리고 내가 바로 이 소프트웨어를 쓰는 사람이니 당연히 동기부여도 높음. 그래서 글 제목이 나한테 공감이 갔음. 단, 본문에서 말하는 부분도 현업에서 충분히 일어날 수 있다고 생각은 함. 나는 공식적인 소프트웨어 개발/프로젝트 관리 프로세스에는 익숙하지 않음
    • 나는 연 200만 달러 매출의 작은 테크 스타트업 경영 중임. 종종 지원 인력이 부족할 때 직접 며칠간 고객 지원을 맡기도 했음. 그럴 때마다 신기하게도 평소엔 엔지니어팀엔 전혀 안 전달되는 고객 불만 사항을 잔뜩 발견함. 지원 담당자들이 문제를 자체적으로 “해결”하는 데 집중해서 근본적인 개선이 엔지니어링까지 이어지지 않는 경향이 있음
    • 원래 소프트웨어가 왜 그렇게 엉망이었는지, 아무도 궁금해하지 않은 게 눈에 띔. 내 생각엔 PM 한 명에게 책임을 다 넘길 수는 없음. 사실은, Agile/Scrum 같이 책임이 흐려지고 개발자들이 엉성하게 만들어진 티켓들을 너무 빠른 주기로 처리하느라 결국 이렇게 어설픈 소프트웨어가 생기는 시스템 문제임. “현대” 소프트웨어 조직이 비대해지면 흔히 나오는 결과물임
    • 이 글을 보고 든 첫 생각이 “PM이 다 개입하기 전, 소프트웨어는 원래 이렇게 만들어졌었지”임. 엔지니어를 실제 운영하는 사람 옆에 앉혀두면, 사실 PM이 필요 없고 모두가 훨씬 행복해지는 경험을 자주 함. 물론 PM 중에도 대단한 사람들 있긴 한데, 내 경험상 PM들은 영역 싸움에 집착하는 경향이 있고, 놀랍게도 엔지니어링이나 고객 쪽 모두에 대해 잘 모르는 경우도 많음
  • 많은 곳에서 엔지니어가 제품과 엇박자가 난 경험을 여러 번 겪었음. 동료가 모르게 뭔가 추가해뒀다가 UI가 헷갈리거나, 웹사이트 내용이 제품 실제와 안 맞는 경우도 있었음. 또, [제품 -> PM -> 버그 트래킹 시스템 -> 엔지니어 -> 수정 -> QA -> 제품] 식의 긴 루프 때문에 중요한 건 고쳐지는데, 사소한 불편은 정말 오랫동안 안 고쳐짐. [제품 <-> 엔지니어]만 남기면 놀라울 정도로 생산성 향상 가능함. 많은 엔지니어가 실제로 제품 전체 경험을 직접 해본 적도 잘 없고, 올해와 작년의 차이도 잘 모르는 경우가 있음
    • 나도 비슷한 경험을 가졌는데, 신기하게도 PM이 많은 곳에서 이런 현상이 더 자주 있었음. 내가 겪은 최악의 경험은 한 회사에서 PM과 “Product Designer”를 엔지니어 숫자에 맞춰 강제 비율로 배정하려 한 경우임. 디자이너, 제품, 프로젝트, 프로그램 담당자 전부 합치면 엔지니어 수보다 더 많음. 결국 더 최악의 상황만 만들어졌음. PM들의 관료주의와 내 역할 침해 우려를 피해다니는 것도 일이었음. 뛰어난 PM은 정말 소중하지만, 요즘 Product Management라는 타이틀은 관료적이고 프로세스에 집착하는 사람이 너무 많이 모여든 느낌임. Product Management 인플루언서들도 문제를 심화시키고 있음
    • 그렇다고 엔지니어를 억지로 세일즈콜에 투입하는 것도 정답이라 생각하진 않음. 전화 한 통을 성공적으로 진행하려면 다양한 소프트 스킬이 필요하고, 엔지니어는 그런 분야로 훈련도 안 돼 있고, 채용 때도 고려 대상이 아님. (‘세일즈콜’이라 함은 데모나 PoC 전의 초기 상담콜 의미. 복잡한 프리세일즈 데모에는 엔지니어가 동행하더라도, 그 역할은 원칙적으론 제품 담당이 해야 맞다고 봄)
    • 잘못될 수 있는 경우가 정말 다양한데, 나는 그런 모든 사례를 직접 본 적 있음. 예를 들어, 모든 고객 소통을 PM이나 PO가 독점하게 하거나, 고객이 개발자와 대화 자체를 피하면서 사용자 매니저 요구사항만 해석해서 전달하는 경우, 개발자 본인이 오직 코드만 쓰고 싶어 하거나, 모든 소통을 PM과 버그 트래커로만 하도록 강요하는 경우 등 정말 다양함. 또, 상용 소프트웨어 플랫폼 쓸 때는 기술적 한계로 워크플로우가 무척 별로가 될 수 있음. 항상 어딘가 소통을 막는 요인이 있고, 고객/중간관리자/개발자 누구든 그걸 가로막을 수 있음. 심지어 잘못된 솔루션을 처음부터 정해놓고 개발자나 사용자는 세부 내용을 전혀 모른 채 시작하는 경우도 적지 않음. 사용자에게 진짜 좋은 시스템을 만들지 못하는 길이 정말 많음
    • 엔지니어들이 제품 자체를 깊이 이해하는 게 정말 중요하다고 생각함. 기본적인 엔지니어링보다 제품 측면이 맞아떨어지는 게 더 어려운 지점임. 내가 경험한 대부분의 제품이 결국 제품적인 이유 때문에 실패했기에, 팀의 강점을 이쪽에 맞추는 게 논리적으로 더 맞는 포인트라 봄
  • 반대로, 엔지니어가 결국 기술 지원팀의 역할로 전락하는 경우도 있음. 각 고객사를 직접 지원하다 보면 핫픽스와 개별 맞춤 솔루션만 쌓이게 되고, 이 모든 게 제대로 테스트도 못 하니 기술 부채만 쌓이고, 크고 제대로 된 투자받은 경쟁사가 더 멋진 제품 만들면 금방 도태됨. 이건 전형적인 제품 관리 실패라고 생각함. PM이 고객 니즈를 엔지니어에게 제대로 전달 못 하거나, 그 반대로도 Push를 못 한다는 얘기임. 엔지니어가 세일즈콜에 투입되는 건, 고객층이 어느 정도 커지고 성숙해지면 확장성 없는 방법임. 만약 제품 관리자가 엔지니어에게 세일즈콜 하길 진짜 원한다면, 그 엔지니어도 각 계정의 커미션 일부를 받아야만 공평함. 내가 커미션 없이 세일즈콜 맡는 일은 절대 없음
  • 스타트업처럼 모든 팀원이 고객 니즈에 깊이 공감이 필요한 환경엔 매우 뛰어난 전략임. 내가 제품 요구사항을 실제로 정의하는 데 참여해서 실무를 꿰뚫고 있을 때 프로젝트 성공률이 훨씬 높았음. 반면 요구사항만 “넘겨받아” 그대로 구현할 때보다 훨씬 더 좋은 결과물이 나옴
    • 내가 실제로 지침을 썼으니 따르기 더 쉬웠다는 뜻인가, 아니면 직접 참여해서 더 나은 UX가 나온다는 말인가 궁금함
  • “2주 만에 리라이트 완성, 기능 60% 제거, 단순 진행바 추가, Slack 연동 구축, ‘done-for-you’ 워크플로우 제공→ 지원 티켓 70% 감소” 이게 진짜면 뭔가 심각하게 잘못된 상황임
    • Reddit은 창작글 폭증으로 유명하고, 이 이야기 역시 실화에 영감을 받았든 완전 창작이든, 전형적인 Reddit식 글쓰기 요소에 LinkedIn식 비즈니스 스토리텔링 느낌이 가득함
    • 이건 B2B SaaS가 여러 번 피벗을 거치면서도 제품 관련 가이드가 빈약했던 경우라 봄. 물론 이런 방식으로 일이 꼬이는 경우가 생각보다 아주 흔함
    • LinkedIn 스타일의 짧은 문장 뒤 극적인 결말이 반복되는 어투 보면, 이건 창작임을 쉽게 눈치챌 수 있음
    • Reddit이니 당연히 창작임. 이런 글이 어쩌다 이런 화제가 되는지 모르겠음
  • 이런 결과라면 당장 PM, PO, 마케팅팀 다 해고해야 함. 두 가지가 분명함: 첫째, 그 사람들이 고객이 실제로 뭘 원하는지 파악도 못 했거나, 그 니즈를 개발팀에 제대로 전달 못 했거나, 둘 다임. 둘째, 머릿속이 너무 시스템적으로만 굴러가서, 차라리 고객과 개발팀 사이 모든 중간 단계를 없애버리는 게 나을 수도 있음
  • 예전 직장에서도 엔지니어가 영업콜에 꾸준히 들어가곤 했음. 어떤 고객이 뭘 원하는지, 우리 제품이 어떻게 팔리는지 체험하는 건 흥미로웠지만, 획기적이진 않았음. 고객이 원한 기능은 이미 로드맵에 있었고, 헷갈리는 기능 하나도 있었지만 그건 최대 고객사의 특수 요구 때문에 그렇게 설계됐었음. 개발팀은 좀 더 단순하게 만들고 싶었지만 그럴 경우 큰 고객사 요구를 충족할 수 없었음. 결국 쉽게 쓸 수 있는 “라이트” 버전을 따로 만들고, 큰 고객사 빼고 전부 그걸 쓸 수 있게 함. 그런데 이런 변화도 영업콜 동행 때문이 아니라, 모두가 어려운 줄은 처음부터 알았으나 로드맵에 반영될 때까지 바꿀 순 없었음
  • “실사용자가 누구인지 드디어 제대로 이해하게 됨”이라는 부분에 깊이 공감함. “대부분 엔지니어의 최대 문제는 오버 엔지니어링”이라고 하지만, 실상은 고객 사용사례를 제대로 이해 못 해서 오버 엔지니어링이 발생하는 경우가 더 많음. 이 부분이 더 본질적인 문제임. 나도 엔지니어로서 가장 자주 겪는 답답함은, 다른 엔지니어들이 실제로 팔리는 제품이 뭔지 알려고 들지 않는다는 점임. 이유는 업무적 적합성이든, 자존심이든, 대개는 조직 문화나 인센티브 구조 때문임
  • 예전에 CRM용 로보콜 솔루션 만드는 회사에 있었는데, 오프사이트 행사 때 모든 사람이 직접 콜드콜 해보고 대본대로 따라 해보자고 했음. 이게 비영업 인력한테 어떤 불안감을 주는지 이해도 없고 관심도 없음. 그 일 이후로 이직을 생각하기 시작했음
  • 예전에 비슷한 상황을 직접 본 적 있음. 모니터링팀이 “모든 경보를 프런트라인 엔지니어가 직접 티켓으로 등록해야 한다”고 주장함. 그런데 경보가 시간당 1만 개 이상임. 중요한 이슈가 다 ‘노이즈’ 속에 묻히다 보니, 관리진도 지치고, 한 번은 ‘모니터링팀 네가 한번 전부 직접 티켓 열어서 해결해 봐’라고 강제하게 됨. 그 다음 날엔, 중요도 낮은 알람을 배제하니 고유 알럿이 시간당 십여 개로 줄었고, 나머지도 순차적으로 다 닫힘. 이때야 비로소 “보드가 다 초록 불”이 진짜가 됐음(그 전엔 미디어랑 Gartner Group 보여주려고 억지 녹색을 칠했을 뿐이었음)
답변달기