투표는 신호이지 지시가 아닙니다
기능 투표 보드를 망치는 가장 빠른 방법은 1위 항목을 반드시 만들겠다고 약속하는 것입니다. 한 분기면 가장 시끄럽게 캠페인을 조직한 사람을 위해 일하게 되고, 모든 로드맵 논의는 순위표를 둘러싼 협상이 됩니다.
유용한 관점은 더 좁습니다. 보드는 30초를 들여 클릭할 만큼 관심 있는 사람이 충분히 있는 문제가 무엇인지 알려줍니다. 그것은 분명 가치 있지만 우선순위 결정 체계는 아닙니다. 첫 표가 들어오기 전에 보드 설명에 이 점을 공개적으로 밝히세요.
표의 무게는 누가 투표했는지에 달려 있습니다
이탈한 체험 계정의 10표와 두 번 갱신한 고객의 10표는 같은 10표가 아닙니다. 단순 집계는 그 차이를 뭉개고, 남는 사람이 아니라 비교 중인 사람 쪽으로 로드맵을 조용히 기울입니다.
보드가 투표자를 식별할 수 있다면 숫자를 읽기 전에 세그먼트를 나누세요. 답할 가치가 있는 질문은 “몇 명인가”가 아니라 “더 늘리고 싶은 사람들 중 몇 명인가”입니다.
기능이 아니라 문제를 물어보세요
대부분의 제안은 해결책 형태로 도착합니다. “슬랙 연동을 추가해 주세요” 같은 식이죠. 근본 문제는 지표가 움직여도 아무도 알아채지 못하는 것일 수 있고, 요약 이메일이 더 빨리 해결할 수도 있습니다. 제출 양식에 “무엇을 하려고 하시나요”라는 필수 항목 하나를 두면, 기능 요청 대기열이 문제 백로그로 바뀝니다.
이렇게 하면 중복도 드러납니다. 표현이 다른 세 개의 요청은 그 뒤의 의도를 읽고 나면 하나의 문제로 합쳐지는 경우가 많습니다.
보드를 행동 데이터와 연결하세요
보드만으로는 사람들이 무엇을 말하는지 알 수 있습니다. 프로덕트 분석은 그들이 무엇을 했는지 알려줍니다. 흥미로운 지점은 둘이 어긋날 때입니다. 이미 출시했지만 쓰이지 않는 기능과 겹치는 요청이 많다면, 그것은 만들 일이 아니라 발견 가능성의 문제를 가리킵니다.
보드의 항목에 착수하기 전에 해당 화면에 실제로 도달하고 있는지 확인하고, 시도한 사용자의 세션을 몇 개 살펴보세요.
루프를 닫지 않으면 보드는 죽습니다
투표가 허공에 외치는 것처럼 느껴지면 보드는 쇠퇴합니다. 유지 비용은 작고 타협할 수 없습니다. 모든 항목에 상태를 부여하고, 상태가 바뀌면 한 문장을 쓰고, 투표한 사람들에게 알리세요. 답이 아니오라면 이유와 함께 분명히 아니오라고 말하세요.
정직한 상태가 달린 50개짜리 보드가 아무것도 달리지 않은 500개짜리 보드보다 유용합니다. 과감히 보관 처리하는 것도 잘 운영하는 일의 일부입니다.