-
소프트웨어 제품에서 고객 피드백을 요청하는 방법
사용자가 무언가를 막 끝낸 직후, 그 자리에서 구체적인 질문 하나를 던져라. 순간별로 쓸 수 있는 문구와 피해야 할 나쁜 요청 방식을 정리했다.
피드백 루프6분 분량
-
제품 로드맵 예시 여섯 가지와 각각이 실패하는 이유
Now/Next/Later, 분기별, 테마, 성과, 공개, 릴리스 로드맵까지 여섯 가지 제품 로드맵 예시를 보여주고, 각각 어떤 팀에 맞고 어디서 무너지는지 정리한다.
피드백 루프5분 분량
-
중복된 기능 요청, 목소리를 잃지 않고 병합하기
중복된 기능 요청을 묶으면 개수는 지키지만, 부주의하게 병합하면 유용했던 표현이 사라진다. 표현을 지키는 병합과 잘못된 일치를 가려내는 법을 다룬다.
피드백 루프4분 분량
-
고객을 잃지 않고 기능 요청을 거절하는 방법은 무엇인가
루프를 닫는다는 것은 보통 요청이 출시되었다고 알리는 일이다. 더 어려운 쪽은 관계를 해치지 않고 거절하는 일이며, 좋은 거절이 말해야 할 것을 설명한다.
피드백 루프4분 분량
-
기능 요청을 놓치지 않고 추적하는 방법
기능 요청 추적은 어디에도 도달하지 못하거나 아무도 보지 않는 곳에 쌓여서 실패한다. 두 실패를 견디는 체계와 쓸모 있는 라벨 붙이는 법을 설명한다.
피드백 루프4분 분량
-
기능 요청이 실제로는 버그 신고일 때
새 설정을 요청하는 지원 티켓은 숨겨진 버그를 우회하는 방법일 수 있다. 잘못된 라벨은 티켓을 엉뚱한 담당자와 대기열로 보낸다. 구별법과 판단할 사람을 다룬다.
피드백 루프4분 분량
-
피처 플래그 릴리스 노트: 무엇을, 언제 말하는가
피처 플래그 릴리스 노트는 머지와 출시를 구분해야 한다. 잘못된 시점에 루프를 닫으면 사용자가 아직 볼 수 없는 기능을 알리게 된다. 판단 기준을 짚어본다.
피드백 루프4분 분량
-
지원 티켓 대 기능 요청: 무엇을 신뢰해야 하는가
지원 티켓과 기능 요청 게시판은 서로 다른 것을 측정한다. 한쪽의 급증을 다른 쪽의 급증과 똑같이 취급하면 자신만만하지만 잘못된 우선순위가 나온다.
피드백 루프4분 분량
-
계속 쌓이는 기능 요청에 우선순위를 매기는 방법
백로그를 추적하고 묶고 라벨을 붙여도 어떤 요청을 먼저 내보낼지라는 질문은 남는다. 쓸 만한 프레임워크와 한계, 투표 수가 감추는 것을 짚어본다.
피드백 루프4분 분량
-
체인지로그 쪽에서 고객 피드백 루프를 닫는 방법
피드백 루프는 요청한 사람에게 출시되었다고 알릴 때 닫힌다. 네 단계의 루프가 어디서 끊어지는지, 왜 체인지로그가 그것을 닫기에 알맞은지 설명한다.
피드백 루프6분 분량
-
체인지로그 항목이 되는 기능 요망 템플릿
기능 요청은 출시되는 순간 다시 찾을 수 있어야 쓸모가 있다. 요청을 올바른 곳으로 보내는 라벨과 나중에 체인지로그가 읽을 필드를 살펴본다.
피드백 루프4분 분량
-
issue 트래커로 만드는 세 개의 열로 이루어진 공개 로드맵
공개 로드맵은 미래에 대한 약속이므로 작게 유지하고, 이미 추적하는 issue로 만들며, 항목은 issue에 붙인 라벨 하나로 열 사이를 옮기는 편이 좋다.
피드백 루프4분 분량
