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 등 모든 회사가 매일 여러 번 사용자를 관찰하기를 바람.

• 큰 백로그의 무용성

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

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

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

• 제품 계획의 나무 구조

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