고객 피드백으로 제품 로드맵을 만드는 방법

제품 로드맵을 만드는 방법은 이렇게 요약된다. 고객이 이미 요청한 것을 모으고, 각 요청 뒤의 문제별로 묶고, 설명할 수 있는 규칙으로 묶음의 순위를 매기고, 각각에 얼마나 확신하는지 정하고, 읽는 사람에게 맞는 형식으로 결과를 공개한다. 순서가 중요하다. 레이아웃부터 시작해 아이디어로 채우는 팀은 완성된 것처럼 보이지만 근거가 없는 문서를 얻는다. 요청에서 시작하는 팀은 더 짧지만 모든 행에 이유가 있는 로드맵을 얻는다.

제품 로드맵을 만들 때 어디서 시작하는가

빈 페이지가 아니라 이미 가진 근거에서 시작하라. 열려 있는 기능 요청, 같은 불만으로 태그된 지원 대화, 영업 통화 메모, 자사 제품의 사용 데이터가 모두 입력이 된다. 이것을 한 목록에 넣고 각 항목이 어디서 왔는지 적어라.

요청은 쓸 수 있는 모양으로 오는 일이 드물다. “Slack 연동 추가”와 “작업이 바뀌면 팀에 알려 달라”는 같은 필요일 수 있다. 그래서 다음 단계가 묶기이고, 중복을 합쳐 주는 트래커를 갖출 가치가 있는 이유이기도 하다. 방법은 중복 기능 요청이 다룬다. 지원 티켓과 기능 요청이 서로 다른 종류의 신호를 담고 있다는 점도 기억하라. 둘 중 하나로만 만든 로드맵은 엉뚱한 쪽으로 기운다.

요청을 로드맵 항목으로 바꾸려면

요청을 문제별로 묶고, 묶음마다 결과로 이름을 붙이고, 개수를 유지하라. 새로고침하면 필터가 사라진다고 설명하는 열네 건의 요청 묶음은 “마지막에 쓴 필터가 유지된다”라는 항목 하나가 된다. 개수는 출처 열에 들어가므로, 로드맵을 읽는 누구나 그 뒤에 실린 무게를 볼 수 있다.

결과는 고객의 말로 써라. “저장된 뷰 영속성 구현”은 엔지니어에게는 무엇을 만들지 알려 주지만 고객에게는 아무것도 알려 주지 않는다. 결과로 표현하면 유용한 질문도 던져진다. 고객에게 무엇이 달라지는지 말할 수 없다면, 다른 목록에 속하는 내부 작업을 보고 있는 것일 수 있다.

무엇을 먼저 할지 어떻게 정하는가

점수 규칙을 하나 고르고, 적어 두고, 모든 항목에 적용하라. 도달 범위, 영향, 확신도, 공수에 점수를 매기는 RICE가 가장 흔하며, Intercom의 RICE 글이 원전이다. 설명할 수만 있다면 더 단순한 규칙도 똑같이 통한다. 요청 수에, 요청자가 활성 유료 계정인지에 따른 가중치를 곱하고, 대략적인 공수로 나누는 식이다.

중요한 것은 규칙이 명시되어 있다는 점이다. 자신의 요청이 왜 목록에 없느냐고 묻는 첫 고객이 답을 원할 것이기 때문이다. 규칙과 판단이 어긋나는 곳에서는 그 행에 그렇게 적어라. 기능 요청 우선순위는 점수 방법, 매출 가중치 문제, 추천 수가 알려 주는 것과 알려 주지 못하는 것을 다룬다.

각 항목에 얼마나 확신하는가

무엇이든 공개하기 전에 모든 항목에 확신도를 붙여라. 세 값으로 된 단순한 척도면 충분하다. 확정은 그 기간 안에 출시하지 못하면 팀이 놀랄 항목이고, 예상은 무언가 바뀌지 않는 한 그대로 가는 계획이며, 탐색 중은 약속이 없다는 뜻이다.

이 열 하나가 로드맵에서 생기는 대부분의 피해를 막는다. 이것이 없으면 고객은 탐색 중인 항목을 약속으로 읽고, 영업이 그것을 인용하고, 한 분기 뒤에는 불만이 된다. Marty Cagan의 로드맵의 대안에 관한 글이 근본적인 논지를 편다. 날짜가 붙은 기능 목록은 계획으로 포장한 추측의 목록이며, 해법은 아는 것을 분명히 밝히는 것이다.

로드맵은 어떤 형식을 취해야 하는가

레이아웃은 마지막에, 읽는 사람을 기준으로 고르라. 자신의 말이 전해졌는지 묻는 고객에게는 짧은 공개용 보기가 필요하다. 왜 이 일을 하느냐고 묻는 경영진에게는 주제나 결과가 필요하다. 매달 방향이 바뀌는 팀에는 날짜 없는 Now, Next, Later가 잘 맞는다. 제품 로드맵 예시는 현실적인 항목과 함께 여섯 가지 형식과 각각의 실패 방식을 보여 주고, 형식을 정한 뒤에는 제품 로드맵 템플릿이 복사할 필드를 제공한다.

대부분의 팀은 문서를 두 개 갖게 된다. 내부 독자를 위한 전략 로드맵과, 책임질 수 있는 것만 보여 주는 축소된 공개용 로드맵이다. 공개용을 둔다면 공개 로드맵이 이미 추적하는 issue의 라벨로 그것을 운영하는 방법을 설명한다.

로드맵이 낡지 않게 하려면

모든 행에 검토일을 주고 로드맵을 작업이 이미 있는 곳에 두어라. 별도의 도구에서 손으로 갱신하는 로드맵은 누구의 일상 업무에도 들어 있지 않기 때문에 낡는다. 각 열이 issue의 라벨에 대응한다면, 라벨이 바뀔 때 로드맵도 바뀐다.

항목이 출시되면 고리를 닫아라. 요청한 사람들이 소식을 들어야 하며, 보통 그 자리는 체인지로그 항목이다. 전체 경로는 고객 피드백 루프가 설명한다. 무언가를 만들지 않기로 했다면 그것도 알려라. 분명한 거절은 요청한 사람에게 쓸모가 있으며, 그 표현은 기능 요청 거절이 다룬다.

FAQ

제품 로드맵을 만드는 단계는 무엇인가? 요청과 데이터를 모으고, 각각 뒤에 있는 문제별로 묶고, 적어 둔 규칙으로 순위를 매기고, 각 항목에 얼마나 확신하는지 라벨을 붙이고, 읽는 사람에게 맞는 형식을 고르고, 검토일을 정한다. 근거에서 시작하면 로드맵이 짧아지고 옹호할 수 있게 된다.

제품 로드맵은 무엇을 바탕으로 해야 하는가? 고객 요청, 지원 주제, 사용 데이터, 전략을 바탕으로 하며, 빠뜨리는 빈도가 높은 순서대로다. 행 뒤에 출처가 없는 로드맵은 희망 목록이다.

제품 로드맵은 얼마 동안을 다뤄야 하는가? 쓸모 있을 만큼 길고 믿을 만할 만큼 짧아야 한다. 많은 작은 팀에는 이번 분기를 상세히, 다음 한두 분기를 주제로 다루는 것이다. 그보다 먼 것은 날짜 없이 “나중” 아래에 둔다.

제품 로드맵을 만드는 데 누가 참여해야 하는가? 제품 책임자가 결정하고, 엔지니어링이 실현 가능성과 공수를 확인하며, 지원과 영업은 자신들이 듣는 요청과 주제를 제공한다. 고객은 공개용 버전으로 결과를 보지만 직접 편집하지는 않는다.

이 글의 기술적 내용은 독립적으로 검토되지 않았습니다. 잘못된 부분이 있으면 알려 주세요. 바로잡겠습니다.

changeloop 관련 페이지: 개발자 문서, changelog 예시