고객 미팅이 끝나면 영업 담당자가 메모를 들고 옵니다. “이 기능만 있으면 계약한다고 합니다.” 고객센터에서도, 경영진에게서도, 개발팀 안에서도 요청은 매일 들어옵니다. 프로덕트 매니저가 이 요청을 모두 받으면 제품은 방향을 잃고, 모두 거절하면 고객과 동료의 신뢰를 잃습니다. 이 글에서는 기능 요청을 받았을 때 무엇을 먼저 확인하고, 어떤 기준으로 받거나 미루거나 거절하는지 정리합니다.
요청은 답이 아니라 단서다
고객이 말하는 기능은 고객이 생각해 낸 해결책입니다. “스프레드시트 파일로 내려받는 단추를 달아 주세요”라는 요청 뒤에는 “매주 상사에게 보고할 숫자를 손으로 옮기고 있다”는 문제가 숨어 있을 수 있습니다. 이 문제라면 내려받기보다 자동 보고서가 더 나은 답일 수도 있습니다.
그래서 요청을 받으면 먼저 “왜”를 묻습니다.
- 이 기능이 있으면 무엇을 할 수 있게 됩니까?
- 지금은 그 일을 어떻게 하고 있습니까?
- 그 일을 얼마나 자주 합니까? 못 하면 무엇이 곤란해집니까?
요청한 사람에게 직접 묻기 어려우면 영업이나 고객센터 담당자에게 이 질문을 대신 물어 달라고 부탁합니다. 요청 내용만 적힌 메모와, 그 뒤의 상황까지 적힌 메모는 판단의 질이 전혀 다릅니다.
한 곳에 모으고 문제별로 묶는다
요청이 메일, 메신저, 회의록에 흩어져 있으면 어떤 문제가 자주 나오는지 보이지 않습니다. 요청은 한 곳에 모읍니다. 도구는 스프레드시트든 이슈 관리 도구든 상관없습니다. 중요한 것은 칸입니다.
- 요청 원문과 요청한 사람(고객 유형, 내부 부서)
- 그 뒤에 있는 문제(위에서 물어 얻은 답)
- 같은 문제를 말한 다른 요청과의 연결
- 처리 상태(검토 중, 로드맵 반영, 보류, 하지 않음)와 그 이유
모인 요청을 기능 이름이 아니라 문제별로 묶으면, 서로 다른 말로 들어온 요청 열 건이 사실은 같은 문제 하나였다는 것이 드러납니다. 이렇게 묶인 문제가 로드맵 후보가 됩니다.
받을지, 미룰지, 거절할지
문제별로 묶은 뒤에는 세 가지를 봅니다.
제품 방향과 맞는가. 제품이 누구의 어떤 문제를 풀기로 했는지에 비추어 봅니다. 큰 고객 한 곳의 요청이라도 다른 고객 대부분에게 쓸모없고 제품을 복잡하게 만든다면, 그 기능은 그 고객만을 위한 맞춤 개발에 가깝습니다.
얼마나 많은 사람이 얼마나 자주 겪는가. 요청 건수만 세지 말고, 같은 문제를 겪으면서 말하지 않는 사용자도 생각합니다. 사용 데이터나 고객 인터뷰로 규모를 가늠합니다.
지금 할 수 있는가. 같은 문제라도 지금 진행 중인 일보다 급한지, 들어가는 노력에 비해 효과가 큰지 따집니다. 우선순위 프레임워크(RICE, ICE 등)를 쓰면 이 비교를 일관되게 할 수 있습니다.
이 세 가지로 보면 결론은 대개 넷 중 하나입니다. 지금 로드맵에 넣는다, 다음 검토 때 다시 본다(보류), 다른 방법으로 이미 풀 수 있다고 안내한다, 하지 않는다.
거절도 답이다
“검토하겠습니다”라고 말하고 아무 답도 하지 않는 것이 가장 나쁜 거절입니다. 요청한 사람은 기다리다 지치고, 영업 담당자는 고객에게 할 말이 없어집니다.
하지 않기로 했다면 이유와 함께 알립니다. “이 문제는 지금 우리가 집중하는 고객층의 문제와 달라 이번 분기에는 다루지 않습니다. 대신 이런 방법으로 지금 기능을 쓸 수 있습니다.” 이유를 들은 사람은 동의하지 않더라도 판단 기준을 이해하고, 다음에는 더 쓸모 있는 요청을 가져오기 쉽습니다.
보류한 요청은 다음 검토 날짜를 정해 둡니다. 같은 문제를 말하는 요청이 계속 쌓이면, 그 숫자가 다음 판단의 근거가 됩니다.
요청한 사람에게 끝까지 알린다
요청이 반영되어 출시되면 처음 요청한 사람에게 알립니다. 영업 담당자에게는 고객에게 전할 기회가 되고, 고객에게는 자기 말이 제품에 들어갔다는 경험이 됩니다. 요청을 모을 때 요청한 사람을 함께 적어 두어야 이 일을 할 수 있습니다.
마무리
기능 요청은 고객과 동료가 제품에 보내는 신호입니다. 요청을 그대로 만들지 않고 그 뒤의 문제를 찾고, 한 곳에 모아 문제별로 묶고, 제품 방향과 규모와 시점으로 판단하고, 결과를 이유와 함께 알리면 요청은 소음이 아니라 제품을 키우는 재료가 됩니다.
다음 글에서는 새 사용자가 처음 제품을 쓸 때 가치를 느끼게 하는 온보딩과 활성화를 다룹니다.
참고
- 이 블로그의 우선순위 결정 프레임워크 글(RICE, ICE, MoSCoW, Kano)을 함께 보세요.