피드백은 로드맵이 아닙니다 — 로드맵을 위한 원재료입니다
모든 제품 팀은 피드백에 빠져 허우적대면서도 증거에는 굶주려 있습니다. 요청은 받은 편지함, 지원 스레드, 영업 통화, 설문 내보내기에 쌓이고, 가장 중요한 것이 아니라 가장 목소리가 크거나 가장 최근의 것이 이기는 경향이 있습니다. 해결책은 더 많은 피드백을 모으거나 무시하는 것이 아니라, 흩어진 의견을 로드맵을 실제로 구축할 수 있는 종류의 증거로 바꾸는 가벼운 정제 프로세스를 거치게 하는 것입니다.
그 과정에는 세 가지 동작이 있습니다: 요청을 근본적인 고충과 분리하고, 모든 의견에 행동을 붙이고, 일화보다 패턴을 격상하는 것. 그 어느 것도 무거운 시스템이 필요하지 않습니다 — 그저 일관된 습관이면 됩니다.
요청, 고통, 증거 분리
기능 요청은 그 밑에 깔린 고충과 같지 않습니다. 사용자가 내보내기 버튼을 요청할 때, 그 고충은 관리자에게 보고하는 것, 데이터를 다른 워크플로로 옮기는 것, 또는 오프라인 아카이브를 유지하는 것일 수 있습니다. 각각은 서로 다른 해결책을 가리키며 — 내보내기 버튼은 그중 최악일 수도 있습니다. 로드맵은 요청된 형태가 아니라 고충에 응답해야 합니다.
간단한 원칙이 도움이 됩니다: 모든 요청에 대해 세 개의 별도 줄을 적으세요 — 요청 (그들이 요청한 것), 고충 (그들이 하려던 작업), 그리고 증거 (그것을 확인해 주는, 당신이 관찰할 수 있는 것). 증거 항목을 채울 수 없다면, 그것은 확신하기 전에 직접 확인해 보라는 신호이지 믿음에 기대어 진행할 이유가 아닙니다.
댓글에 행동 첨부
피드백 항목은 다음과 결합될 때 훨씬 더 강력해집니다 세션 그것을 만들어 낸. 우선순위를 바꾸는 질문은 행동에 관한 것입니다:
- 사용자가 먼저 오류나 막다른 길에 부딪혔나요?
- 그들이 요청한 작업을 이미 수행하는 기존 컨트롤을 놓쳤나요?
- 같은 계정의 여러 사람이 그 행동을 반복했나요?
- 어디에서 퍼널 마찰이 발생했나요 — 그리고 그것이 이탈과 상관관계가 있나요?
“대시보드가 혼란스럽다”라는 댓글은 의견입니다. 사용자가 잘못된 필터를 세 번 클릭하는 녹화에 첨부된 같은 댓글은 증거입니다. 전자는 논쟁을 시작하고, 후자는 논쟁을 끝냅니다.
일화가 아닌 패턴을 홍보하세요
일화는 간직하세요 — 생생하고 스토리텔링에 유용합니다 — 하지만 패턴을 격상하기. 부실한 로드맵 메모는 “사용자가 내보내기를 원한다”고 적습니다. 좋은 메모는 이렇게 적습니다:
여섯 개의 체험 팀이 첫 보고서를 만든 후 내보내기를 요청했습니다; 네 팀은 이미 대시보드 링크를 공유했고(따라서 진짜 필요는 내보내기가 아니라 공유입니다); 두 팀은 규정 준수로 막혀 있었습니다. 추정 영향: 이것이 발생하는 활성화 단계에서 체험의 18%가 새어 나갑니다.
그것은 팀이 다른 베팅과 비교해 우선순위를 정할 수 있는 증거입니다. 빈도, 실제 근본 과업, 측정 가능한 비용을 담고 있기 때문입니다. 그런 것이 전혀 없는 설득력 있는 단일 의견은 가설입니다 — 테스트할 가치는 있지만 스프린트를 들일 가치는 없습니다.
점수를 매기고 루프를 닫기
피드백이 증거로 정제되면 우선순위 지정이 훨씬 간단해집니다. 다음의 대략적인 점수 매기기: 도달 (몇 명의 사용자인지), 심각도 (그것이 사용자를 얼마나 심하게 막는지), 그리고 전략적 적합성 (당신이 중요하게 여기는 목표를 움직이는가)만으로도 보통 40행짜리 스프레드시트 없이 목록의 순위를 매기기에 충분합니다. 기능 투표 보드 요청이 투표를 쌓아 감에 따라 도달 신호를 자동으로 제공할 수 있습니다.
그런 다음 루프를 닫으세요. 각 주제를 제기한 사람들에게 출시할 때 — 그리고 출시하지 않기로 결정할 때와 그 이유를 — 알려 주세요. 루프를 닫는 것이 이 전체 과정이 의존하는 고품질 피드백을 사용자가 계속 주게 만드는 것입니다. 한 번도 회신하지 않는 피드백 프로그램은 조용히 말라붙습니다.
자주 묻는 질문
상충하는 피드백의 우선순위를 어떻게 정하나요?
각 항목을 도달, 심각도, 전략적 적합성으로 정제하고 행동 증거로 뒷받침하세요. 충돌은 보통 각 개별 의견이 얼마나 설득력 있었는지가 아니라 패턴과 측정 가능한 비용을 비교하면 해소됩니다.
행동에 옮기기에 충분한 피드백은 얼마인가요?
행동으로 확인된 반복 패턴을 찾으세요 — 같은 고충을 설명하는 여러 사용자가 눈에 보이는 마찰이나 이탈과 맞아떨어지는 것. 아무리 설득력 있어도 단일 요청은 먼저 검증해야 할 가설입니다.
영업과 지원의 피드백이 사용자의 것과 동일하게 취급되어야 하나요?
그것들을 가치 있지만 편향된 입력으로 다루세요 — 그것들은 거래와 목소리 큰 사람에 과도하게 치우쳐 있습니다. 동일한 요청-고충-증거 정제를 거치게 하고, 누가 가장 크게 외쳤는지가 아니라 행동 데이터로 가중치를 두세요.
기능 요청과 로드맵 증거의 차이는 무엇인가요?
요청은 사용자가 원하는 것입니다. 로드맵 근거는 그 밑에 깔린 고충에 더해 빈도, 행동 맥락, 측정 가능한 영향입니다. 로드맵은 후자로부터 구축되어야 하며, 전자가 그것을 보완합니다.