로드맵은 베팅의 목록이며, 어려운 부분은 아이디어를 나열하는 것이 아니라 순위를 매기는 것입니다. 대부분의 팀은 처리할 수 있는 양보다 요청이 많고, 로드맵에 오르는 요청은 가장 중요한 것보다 가장 자주 반복된 것인 경우가 많습니다. 해결책은 더 나은 우선순위 공식이 아니라 더 나은 입력입니다. 요청 뒤에 어떤 문제가 있는지, 중요한 사용자 중 몇 명이 그 문제를 겪는지, 그리고 요청하기 전에 제품에서 실제로 무엇을 했는지 아는 것입니다.
이 아티클들은 로드맵 결정에서 거꾸로 거슬러 올라갑니다. 날것의 피드백을 증거로 바꾸는 방법, 투표 수가 대신 결정하게 두지 않으면서 공개 투표 보드를 운영하는 방법, 그리고 모은 응답이 애초에 순위를 매길 가치가 있도록 피드백 양식을 설계하는 방법을 다룹니다.
읽는 순서
어디서부터 읽을까
- 피드백을 로드맵 근거로 전환하세요
방법론을 한곳에 정리했습니다. 요청, 불편, 증거를 분리하고, 일화보다 패턴을 우선하고, 남은 것에 점수를 매기고, 결정한 내용을 사람들에게 알립니다.
- 기능 투표 보드에 끌려다니지 않고 운영하는 법
요청이 공개적으로 들어올 때. 투표는 지시가 아니라 신호입니다. 투표에 투표자에 따른 가중치가 붙는 이유와, 기능보다 문제를 묻는 편이 나은 이유를 설명합니다.
- SaaS용 고객 피드백 폼: 무엇을 묻고 답변을 어떻게 활용할까
두 글보다 앞 단계인 원재료를 모으는 양식입니다. 입구에서 질문이 좋아지면 로드맵 회의 전에 분류할 일이 줄어듭니다.
로드맵
이 주제의 모든 아티클
기능 투표 보드에 끌려다니지 않고 운영하는 법
공개 로드맵 투표는 목소리 큰 요청을 증거로 바꿔줍니다. 단, 투표가 무엇을 뜻하고 무엇을 뜻하지 않는지 미리 정했을 때만 그렇습니다.
SaaS용 고객 피드백 폼: 무엇을 묻고 답변을 어떻게 활용할까
SaaS 고객 피드백 양식은 또 다른 스프레드시트를 만드는 대신 응답을 사용자 행동, 세션 리플레이, 제품 분석에 연결해야 합니다.
피드백을 로드맵 근거로 전환하세요
사용자 의견을 세션, 이벤트, 그리고 영향을 미쳐야 할 제품 베팅에 연결하는 가벼운 방법.
관련