임팩트 매핑으로 제품 기능의 우선순위 정하기

기능 목록만으로는 왜 어떤 아이디어를 다른 아이디어보다 먼저 살펴봐야 하는지 알기 어렵습니다. 대시보드, 이메일 알림, 새로운 온보딩 화면은 모두 유용해 보여도 서로 다른 목표를 위한 것일 수 있습니다. 이를 한꺼번에 점수화하면 목표의 차이는 해결하지 못한 채 순위만 깔끔하게 나올 수 있습니다.

임팩트 매핑은 사람들의 행동 변화를 통해 기능 선택을 사업 목표와 연결하는 방법입니다. 백로그의 우선순위를 확정하기 전에 활용해 보세요. 특히 이해관계자들이 해결해야 할 문제에는 합의하지 않은 채 해결책만 계속 추가할 때 유용합니다.

네 가지 단계를 구분해서 사용하세요

Gojko Adzic의 임팩트 매핑 안내는 목표, 행위자, 임팩트, 산출물을 중심으로 대화를 구성합니다. 행위자는 결과에 영향을 줄 수 있는 사람이나 집단입니다. 임팩트는 그들의 행동이 어떻게 바뀌어야 하는지를 뜻합니다. 산출물은 조직이 그 변화를 지원하기 위해 제공할 수 있는 것입니다.

이 구분은 중요합니다. “온보딩 체크리스트를 만든다”는 산출물입니다. “신규 관리자가 도움 없이 첫 설정을 완료한다”는 행동 변화입니다. “성공적인 초기 사용을 늘린다”는 목표이지만, 아직 측정 가능한 정의가 필요합니다. 이 단계들을 섞으면 맵은 완성되어 보여도 판단의 근거는 불분명한 채로 남습니다.

임팩트 매핑의 전반적인 개념을 익혔다면, 여기서는 범위를 좁혀 여러 기능 제안 중 무엇을 선택할지 결정하는 데 맵을 활용해 보겠습니다.

목표 하나와 그 범위를 정하세요

제품 의사결정자, 사용자를 이해하는 사람, 구현상의 제약을 이해하는 사람을 모읍니다. 대상 집단, 관찰할 수 있는 결과, 기간을 포함해 목표 하나를 적으세요. 신뢰할 수 있는 데이터가 있다면 현재 기준값도 추가합니다. 데이터가 없다면 숫자를 추측해서 넣지 말고 기준값을 확인하는 일을 별도 작업으로 정하세요.

가상의 일정 예약 제품을 예로 들어 보겠습니다. 이 팀은 더 많은 신규 팀 관리자가 첫 주 안에 실제 예약을 완료하도록 하려 합니다. 테스트 예약은 “실제 예약”에서 제외하고, 관찰할 수 있는 고객군을 명시합니다. 지원 업무량을 급격히 늘리지 않고, 사용자가 원하지 않는 알림을 받도록 압박하지 않는다는 제한 조건도 둡니다.

맵의 중심에 “대시보드 출시”를 놓지 마세요. 해결책을 미리 골라 버리는 셈입니다. 프로젝트 후원자가 특정 산출물을 고집한다면, 어떤 결과가 나와야 만들 가치가 있는지 물어보세요. 이 질문을 통해 반드시 이행해야 하는 계약 요건이 드러날 때도 있습니다. 이런 일은 원하는 성과를 위해 선택적으로 시도하는 일과 구분해야 합니다.

해결책보다 행위자를 먼저 배치하세요

목표 달성을 돕거나 방해할 수 있는 사람들을 적습니다. 일정 예약 제품에서는 신규 관리자가 예약 가능 시간을 설정하고, 초대받은 사람이 예약을 완료하며, 지원 담당자가 설정 문제를 해결하도록 돕습니다. 데이터 관련 제약이 구현에 영향을 줄 수는 있지만, 여기서 “데이터베이스”는 행위자가 아닙니다.

각 행위자에 대해 목표에 도움이 될 구체적인 행동을 적으세요. “더 적극적으로 참여한다”보다 “예약 가능한 시간대를 공개한다”가 낫습니다. 관찰, 대화, 제품 내 이벤트 중 무엇을 통해 변화를 알아볼 수 있을지 질문합니다.

가능하면 이미 파악한 사용자의 어려움에서 출발하세요. 고객 피드백을 종합하면 뒷받침하는 관찰 내용을 정리할 수 있지만, 아직 확인하지 못한 가정은 표시해 두어야 합니다. 그럴듯해 보이는 가지도 인과관계에 대한 가설일 뿐, 입증된 결과는 아닙니다.

예시: 네 가지 요청에 담긴 서로 다른 이유

일정 예약 제품팀에는 분석 대시보드, 단계별 설정 안내, 초대 알림, 고객 지원용 응답 매크로 요청이 들어와 있습니다. 기능에 바로 점수를 매기지 않고, 각 기능이 어떤 행동에 영향을 주려는지 맵으로 정리합니다.

대시보드가 가치 있을 수는 있지만, 팀은 아직 이 목표에 어떻게 기여하는지 설명하지 못합니다. 따라서 별도의 검토 후보 목록으로 옮깁니다. 분석이 중요하지 않다는 판단이 아니라, 지속 사용을 위한 일과 초기 사용을 돕는 문제를 섞지 않겠다는 결정입니다.

맵을 보면 단계별 설정 안내와 짧은 설정 지원 통화가 같은 행동을 이끌어 내기 위한 대안이라는 점도 드러납니다. 둘 다 자동으로 실행이 확정된 백로그 항목이 되어서는 안 됩니다.

산출물보다 가지의 우선순위를 먼저 정하세요

어떤 행동 변화가 목표에 가장 중요해 보이는지, 무엇을 뒷받침하는 근거가 가장 탄탄한지 논의합니다. 그다음 가능한 개입 방법의 불확실성, 필요한 노력, 되돌리기 쉬운 정도를 살펴보세요. 보드에서 차지하는 공간이 같다는 이유로 모든 가지에 같은 관심을 기울일 필요는 없습니다.

고객 지원 상담에서 관리자가 예약 가능 시간 설정을 이해하지 못한다는 문제가 반복된다고 가정해 보겠습니다. 팀은 먼저 몇 번의 설정 과정을 관찰하고 더 명확한 예시를 시험해 볼 수 있습니다. 반대로 초대받은 사람이 예약 페이지에 도달하지도 못한다면 페이지를 간소화하는 것은 엉뚱한 문제를 해결하는 일이 될 수 있습니다. 어느 기능의 작업량을 추정하기 쉬운지가 아니라, 근거에 따라 순서를 정해야 합니다.

대략적인 점수를 정밀성 경쟁으로 만들지 마세요. 점수로 논의를 요약할 수는 있지만 숫자를 빼도 설명은 성립해야 합니다. 선택한 가지 옆에 핵심 이유를 적습니다. “예약 가능 시간 설정 때문에 관리자가 예약 링크를 공유하지 못하므로 이 부분을 먼저 조사한다”처럼 쓸 수 있습니다.

판단을 검증할 수 있는 작은 산출물을 선택하세요

선택한 가지에서, 제안한 행동 변화가 가능한지 알아볼 수 있는 가장 작은 개입 방법을 찾습니다. 프로토타입, 사람이 직접 제공하는 서비스, 더 명확한 안내, 제한적인 제품 변경일 수 있습니다. 반드시 새 기능일 필요는 없습니다.

일정 예약 사례에서는 신규 관리자에게 예약 가능 시간의 설정 예시를 제공해 봅니다. 적절한 시간대를 만들 수 있는지, 초대받은 사람에게 무엇이 보일지 설명할 수 있는지 관찰합니다. 만들어진 링크가 실제 예약으로 이어지는지도 확인합니다. 설정을 완료했다는 사실만으로 최종 목표를 달성했다고 볼 수는 없습니다.

어떤 결과가 나오면 이 대안을 계속 진행하거나 수정하거나 포기할지 적으세요. 근무 일정이 단순한 사용자에게만 효과가 있다면 그 한계를 표시합니다. 일부 근거만으로 모든 사용자에게 성공했다고 표현해서는 안 됩니다.

맵과 백로그를 구분하세요

맵에는 대안과 인과관계에 대한 판단이 담기고, 백로그에는 팀이 검토 중이거나 실행을 준비하는 작업이 담깁니다. 맵의 모든 말단 항목을 백로그로 옮기면 선택지가 사실상의 약속이 됩니다. 선택한 작업만 옮기고, 그 작업이 어떤 행동을 지원하려는지 연결을 남겨 두세요.

임팩트 매핑 템플릿에서 시작하거나 Boardmix를 열고 빈 캔버스에 네 단계를 그립니다. 일정 예약 사례에서는 첫 주 예약 목표를 신규 관리자와 연결하고, 그다음 사용 가능한 예약 링크 공개라는 행동으로 연결합니다. 여기서 예약 가능 시간 예시, 단계별 설정 안내, 짧은 설정 지원 통화로 가지를 나눕니다. 예약 가능 시간 예시에 “우선 검토”라고 표시하고 다른 대안은 아직 실행을 확정하지 않습니다. 관련 없는 분석 요청은 별도 영역에 두어 잊지 않되, 이번 목표에는 섞이지 않게 하세요.

결과가 나오면 기능을 확대하기 전에 산출물과 행동의 연결을 다시 살펴보세요. 더 간단한 초대 문구로 문제가 해결된다면 맵은 알림 시스템을 만들지 않아도 되는 이유를 보여 줍니다. 할 일을 줄이는 것이 우선순위 회의에서 얻는 가장 유용한 결과일 수도 있습니다.