▲

GN⁺: Backlog의 크기는 고객과의 대화 빈도에 반비례합니다

 (bitbytebit.substack.com)
13P by neo 10달전 | favorite | 댓글 1개
  • 고객과 자주 대화할수록 백로그의 크기는 줄어듦
  • 계획 시간을 고객과의 대화로 대체하는 것이 중요함
  • 개발자와 고객 사이의 중개자가 많을수록 제품이 고객의 요구를 충족시키지 못함
  • 큰 백로그는 검증되지 않은 가정이 많고 고객 가치를 창출할 가능성이 낮음을 의미함

UI 디자인보다 기술적 구성 요소 디자인에 집중할 것

  • UI 디자인에 너무 많은 시간을 할애하지 말고 기본적인 UI를 빠르게 출시하고, 고객 피드백을 통해 UI를 개선하는 것이 중요함
  • 기술적 부채를 낮게 유지하여 고객이 필요로 하는 변경을 신속하게 수행할 수 있어야 함

사람들이 생각하는 앱 사용 방식과 실제 사용 방식은 다름

  • 고객이 앱을 사용하는 모습을 관찰하는 것이 중요함
  • 사용자의 행동을 직접 관찰하면 양적 지표만으로는 파악할 수 없는 인사이트를 얻을 수 있음

계정 스푸핑 구현

  • 특정 고객이 실제로 어떤 화면을 보고 있는지 이해하기 위해 계정 스푸핑 기능에 대한 투자가 중요함
    • 계정 스푸핑(Account Spoofing) 관리자가 특정 프로덕션 사용자처럼 앱을 사용할 수 있는 기능
  • 이를 통해 문제를 효과적으로 진단하고 테스트 데이터에 대한 의존도를 줄일 수 있음

첫 페이지의 중요성

  • 앱에 처음 접속한 고객에게 가장 관련성 높은 정보를 간결하게 제공해야 함
  • 첫 페이지에 너무 많은 정보를 담으려 하면 사용자의 인지 부담을 증가시킴

고객은 가장 중요한 마케터

  • NPS(Net Promoter Score)는 고객이 제품을 추천할 만큼 강한 호감을 가지고 있는지를 나타내는 좋은 지표임
  • 광고 비용을 지출할 수도 있지만, 만족한 고객으로부터 시작하는 것이 효과적인 마케팅 전략임

MVP는 반복 개선 없이는 의미가 없음

  • MVP는 단순히 날짜 압박을 이유로 저품질의 고객 경험을 제공하는 핑계가 되어서는 안 됨
  • MVP는 추가 반복이 필요한지, 필요하다면 어떤 점을 개선해야 하는지를 결정하는 데 도움을 줌

GN⁺의 의견

  • 이 글에서 가장 중요한 것은 고객과의 지속적인 대화를 통해 실제 사용자의 요구를 반영하는 제품 개발의 중요성임
  • 고객의 피드백을 신속하게 반영할 수 있는 유연한 UI 디자인과 기술적 구성 요소의 중요성을 강조함
  • MVP를 넘어 지속적으로 제품을 개선하고 고객의 만족도를 높이는 것이 장기적인 성공으로 이어질 수 있음을 보여줌
  • 이 글은 스타트업 생활에서 얻은 교훈을 공유하며, 창업자나 개발자들에게 실질적인 인사이트를 제공
▲
neo 10달전  [-]
Hacker News 의견

  • 기능/개선사항 조직 방법에 대한 의견

    • 경험에 따르면, 모든 아이디어를 티켓으로 만드는 전략은 비효율적임. 이렇게 하면 결코 사용하지 않을 아이디어들로 가득 찬 '아이스박스'가 생김.
    • 중요한 거래를 위해 아이스박스에 있는 아이디어가 필요할 때조차, 그 아이디어가 존재하는지 기억하지 못해 새 티켓을 만들게 됨.
    • 단기적으로나 중기적으로 실현 가능성이 있는 티켓을 선호하며, 다른 아이디어들은 별도로 저장함.
    • 엔지니어링 팀은 해결하고 싶은 기술 부채 목록을, PM은 프로젝트별 개선 가능성 목록을 유지함.
    • 새 기능/제품에 대해서는 PRD를 작성하지만, 바로 티켓으로 전환하지 않음.
    • 대부분 처리되지 않을 거대한 백로그는 '아니오'라고 말하는 것을 두려워하는 약한 PM의 신호임.

  • 백로그 크기와 PM 교체율의 관계

    • 백로그의 크기는 PM 교체율과 반비례함.
    • 오래된 PM에게 백로그는 과거 제품 대화의 기억 보조장치임.
    • 새로운 PM은 백로그를 보고 혼란스러워하며, 이해할 수 없는 것들을 정리하려고 함.

  • 고객 기반 백로그 유지에 대한 반대 의견

    • 백로그 유지하는 팀은 대부분 고객으로부터 백로그를 얻음.
    • "고객의 삶을 개선할 기능을 찾아 다음 기능으로 만들라"는 것은 간단하지 않음.
    • 여러 고객이 있고, 각각의 삶을 개선할 기능이 서로 관련 없고 복잡할 때 어떻게 할 것인가?
    • 고객의 요청을 항상 들어야 하지만, 그들이 요청한 것을 거의 만들어서는 안 됨.
    • 고객은 UX 구현뿐만 아니라 문제와 현재 사용 중인 업무 프로세스를 암시하는 기능을 요청함.
    • 비즈니스 문제를 파악하고, UX 구현 아이디어와 프로세스 특정 사항을 버려야 함.
    • 비즈니스 문제를 해결하는 최소한의 기능을 경제적으로, 좋은 UX 디자인과 일관성 있게 구축해야 함.

  • 고객 요구 사항 등록에 대한 PM의 필요성

    • PM은 고객의 요구 사항을 등록할 장소가 필요함.
    • 전용 도구가 없으면, 요구 사항이 대부분 Jira 티켓으로 끝남.
    • ProductBoard와 Jira Product Discovery 두 가지 접근 방식이 있음.
    • ProductBoard는 CRM 접근 방식으로, 모든 고객 상호작용을 기록하고, 나중에 이를 요구 사항과 희망 사항으로 분해함.
    • Jira Product Discovery는 아이디어로 시작하여, 고객으로부터 들은 모든 것을 즉시 긴 요구 사항 및 희망 사항 목록으로 분해해야 함.
    • Jira Product Discovery의 장점은 개발자 백로그에서 아이디어 목록을 분리하지만, 또 다른 긴 목록을 만듦.
    • 고객 대화를 기반으로 제품 우선 순위를 분석하려면 ProductBoard가 더 나은 제품 발견 도구임.

  • 고객 피드백에 의해 정제된 백로그의 중요성

    • 거의 매일 고객과 대화하므로, 고객 피드백에 의해 직접적으로 정보를 얻고 정제된 기능 및 개선사항이 백로그에 있음.
    • 할 일은 항상 많지만, 백로그가 고객 피드백에 의해 정보를 얻고 정제되었는지 여부가 차이를 만듦.

  • 고객과의 일상적인 대화를 통한 백로그 관리

    • 기술적인 사람으로서 매일 고객과 대화하며, 이론은 매력적이지만 몇 가지 문제가 있음.
    • 최근성 편향 및 기회 비용: 더 높은 우선순위로 인해 의도적으로 작업하지 않는 문제 공간에 대한 피드백을 계속 수집해야 함.
    • 반응적 개발: 피드백 로깅을 건너뛰면 가장 최근에 가장 쉽게 접근할 수 있는 작업에 집중하게 되며, 오래된 문제를 간과하게 됨.
    • 팀 지식 기반: 피드백을 수집하고 솔루션을 제공할 단일 책임자가 있다면, OP의 주장이 유효할 수 있음.
    • 팀이 관련되어 있다면, 비동기적으로 데이터 포인트를 기록하고 검색할 수 있는 공유된 데이터베이스가 필요함.
    • 백로그는 빠르게 커질 수 있지만, 복잡한 시스템과 사람들을 다루는 것은 어려움을 수반함.
    • 잘 조직된 팀에게는 백로그의 좋은 관리가 필요하며, 이는 관련 없는 작업을 보관하고, 중복 작업을 제거하고, 정기적으로 우선순위를 정하고, 도구를 최상으로 활용하는 것을 포함함.
    • 백로그를 관리하는 것이 도구 자체보다 중요하며, 필요할 때 더 깊이 파고들 수 있는 정보를 표면화하는 백로그 위의 '파사드'가 필요할 수 있음.

  • 앱 사용자 관찰의 중요성

    • 고객이 앱을 사용하는 모습을 관찰하는 것이 중요함.
    • 모든 측정치를 추적할 수 있지만, 사용자가 무언가를 찾기 위해 스크롤하거나, 뒤로 가기 버튼을 누르거나, 클릭할 수 없는 것을 클릭하려고 하는 모습을 보는 것은 실감나는 경험임.
    • Apple, Google 등 모든 회사가 매일 여러 번 사용자를 관찰하기를 바람.

  • 큰 백로그의 무용성

    • 큰 백로그는 불확실한 가정이 많고, 고객 가치 창출 가능성이 낮음.
    • 무언가가 가치 있다고 가정하는 실수를 많이 했으며, 아무도 신경 쓰지 않을 때가 많음.
    • 큰 백로그는 고객과의 대화 빈도가 낮다는 것을 반영하므로, 매우 회의적인 시각으로 바라봐야 함.

  • 계정 스푸핑 구현에 대한 경고

    • 계정 스푸핑은 생산 환경에서 문제를 테스트하는 쉬운 방법이지만, 지원 및 개발 팀이 생산 데이터에 대한 신뢰를 필요로 함.
    • 일부 산업에서는 고객에게 큰 문제가 될 수 있음.
    • 마지막으로 일한 스타트업은 개발자가 전혀 생산 데이터에 접근하지 못하게 함.
    • 이는 보안 측면에서 최후의 수단으로 간주되어야 하며, 고객 데이터에 접근할 수 없다고 가정하고 작업하는 것이 더 낫음.

  • 제품 계획의 나무 구조

    • 제품 계획은 항상 나무 구조로 이루어져야 함.
    • 최상위 노드는 비즈니스 목표이며, 그 아래에 제품, 그 아래에 고객 문제, 그 아래에 백로그 항목이 있음.
    • 너무 많은 백로그 항목을 가지고 있다는 것은 적절한 구조가 설정되어 있지 않고, 우선 순위가 지정된 비즈니스 목표 목록이 없다는 것을 의미할 수 있음.
    • "고객과 대화하기"는 고객 문제를 이해하는 데 유용하지만, 비즈니스 목표를 먼저 알아야 함. 그렇지 않으면 어차피 작업하지 않을 영역에서 피드백을 수집하는 데 시간을 낭비하게 됨.
답변달기