기능 요청

제품을 쓰는 사람은 늘 무언가를 더 해 달라고 말합니다. 문제는 그 말이 들어오는 자리가 제각각이었다는 데 있습니다. 상담 창구로 들어온 요구는 답장을 쓴 담당자의 기억에만 남고, 미팅에서 나온 요구는 영업 담당자의 노트에 적히고, 커뮤니티에 올라온 글은 며칠 지나면 아래로 밀려 내려갔습니다.

그래서 무엇을 만들지 정하는 자리는 기억력 대결이 됐습니다. "폴더를 한꺼번에 옮기게 해 달라는 말, 많이 나오지 않았나요" 하고 물으면 "저도 그렇게 들었어요" 라는 답이 돌아오고, "몇 건인가요" 하고 물으면 아무도 답하지 못했습니다. 세어 본 적이 없기 때문입니다. 근거가 없으니 지난주에 만난 고객 한 명의 말이 반년 동안 백 명이 남긴 말보다 무겁게 다뤄졌습니다.

기능 요청은 이 말들을 한 건씩 셀 수 있는 형태로 바꾸려고 만든 기록 단위입니다. 들어온 말 가운데 무엇을 만들어 달라는 형태로 온 것만 골라 정해진 칸에 적어 둡니다.

한 건은 여섯 칸으로 적습니다. 도구는 스프레드시트 한 장이어도 되고 이슈 트래커의 항목 하나여도 됩니다. 어디에 적느냐보다 무엇을 적느냐가 오래 갑니다.

1. 원문 — 고객이 쓴 문장을 그대로 옮깁니다. 요약하는 순간 옮기는 사람의 판단이 섞여 들어갑니다.
2. 들어온 곳 — 어느 피드백 채널로 왔는지 적습니다. 문의가 한 건씩 쌓이는 지원 티켓인지, 추천 의향을 0에서 10으로 묻는 순추천지수 설문의 자유 서술 칸인지, 영업 미팅 메모인지에 따라 말한 사람의 처지가 다릅니다.
3. 말한 사람 — 어느 고객인지, 어떤 플랜을 쓰는지, 몇 명이 쓰는지를 붙입니다. 같은 요청 스무 건이 전부 무료 플랜 개인 사용자에게서 왔는지, 그중 넷이 스무 석짜리 유료 팀에게서 왔는지는 전혀 다른 숫자입니다.
4. 막힌 상황 — 이 말을 하기 전에 무엇을 하려다 막혔는지를 적습니다. "엑셀로 내보내게 해 주세요" 옆에는 "월말 보고서를 손으로 옮기느라 두 시간이 든다" 가 들어갑니다.
5. 영역 꼬리표 — 제품의 어느 부분에 대한 말인지 분류합니다. 꼬리표 목록은 먼저 합의해 두고 시작합니다. 붙이면서 만들면 사람마다 다른 이름을 쓰게 되어 다음 분기에 두 분기를 견줄 수 없습니다.
6. 상태와 날짜 — 접수·검토 중·반영함·하지 않기로 함 가운데 어디인지와 그 날짜를 답니다. 이 칸이 있어야 나중에 요청한 고객에게 돌려줄 말이 생깁니다.

가장 자주 비는 칸은 4번이고, 비었을 때 가장 비싼 칸도 4번입니다. 요청은 문제가 아니라 고객이 혼자 세운 해법이기 때문입니다. 엑셀 내보내기와 자동 보고서와 외부 도구 연동은 적힌 글자로 보면 서로 다른 세 가지 요청이지만, 4번 칸을 채워 두면 월말 보고서라는 한 가지 문제로 묶입니다.

적는 사람은 대개 고객이 아닙니다. 제품 안에 요청 버튼을 달아 두면 고객이 직접 쓰기도 하지만, 실제로 쌓이는 항목의 대부분은 고객의 말을 받은 사람이 대신 옮겨 적은 것입니다. 상담을 처리한 담당자, 미팅에서 들은 영업 담당자, 정기 점검 자리에서 들은 고객 성공 담당자입니다.

대신 적기 때문에 4번 칸을 채울 기회는 그 자리에만 있습니다. 고객이 "엑셀 내보내기요" 라고 말했을 때 "지금은 그 숫자를 어떻게 쓰고 계세요" 하고 한 번 더 물을 수 있는 사람은 그 대화에 있던 사람뿐입니다.

읽는 사람은 셋입니다. 무엇을 먼저 만들지 정하는 프로덕트 매니저가 우선순위 결정 자리의 입력으로 봅니다. 같은 요청을 또 받은 상담 담당자가 이미 접수된 건인지 하지 않기로 한 건인지 확인하려고 봅니다. 마지막은 요청한 고객 자신인데, 표를 직접 열어 보지는 못해도 피드백 루프의 회신을 통해 자기 요청이 어떻게 됐는지를 전달받습니다.

만들기로 한 요청은 여기서 끝나고 유저 스토리나 PRD로 옮겨 적힙니다. 그 순간부터는 고객의 말이 아니라 만들 것의 명세입니다.

"말씀하신 건 기능 요청으로 남겨 두겠습니다. 이번 분기 계획에는 못 들어가고요."

접수는 하되 지금은 하지 않는다는 뜻입니다. 뒤 문장이 붙지 않으면 고객은 곧 해 준다는 말로 알아듣습니다.

"요청 건수만 보지 말고 누가 요청했는지 같이 보세요."

같은 스무 건이라도 말한 사람의 구성에 따라 무게가 달라진다는 지적입니다.

"이건 기능 요청이 아니라 버그예요."

새로 만들어 달라는 말이 아니라 되기로 한 것이 안 된다는 말이니, 우선순위 회의를 기다리지 말고 바로 고치라는 뜻입니다.

페이지덱에서는 수아가 고객 미팅을 마칠 때마다 요청을 한 줄씩 적어 넣습니다. 적을 때 막힌 상황 칸을 함께 채우는 것이 팀의 약속이라, "승인 단계를 두 단계로 나눠 달라" 옆에는 "팀장이 자리에 없으면 결재가 멈춘다" 가 같이 적힙니다. 지현은 분기 시작 전에 이 표를 통째로 훑고 꼬리표별로 묶어 우선순위 회의에 들고 들어갑니다.

건수가 많은 요청부터 만들면 된다고 읽는 경우가 가장 많습니다. 표에 숫자가 있으니 위에서부터 처리하면 될 것처럼 보입니다. 그런데 요청을 남기는 사람은 전체 사용자 가운데 극히 일부이고, 제품을 이미 깊이 쓰는 쪽에 치우쳐 있습니다. 건수만 따라가면 쓰던 사람이 더 쓰기 편해지는 기능만 쌓이고, 처음 들어와 사흘 만에 떠난 사람이 무엇에 막혔는지는 표에 한 줄도 남지 않습니다. 그 사람들은 요청을 쓰지 않고 그냥 나가서 이탈 사유 기록에만 흔적을 남깁니다.

요청을 적힌 그대로 만들면 된다고 읽는 것도 흔합니다. 고객이 해법까지 말해 주니 편해 보입니다. 그런데 고객은 자기가 아는 도구의 범위 안에서 해법을 떠올립니다. 엑셀을 쓰던 사람은 엑셀 내보내기를 말하고, 다른 제품을 쓰던 사람은 그 제품의 버튼 이름을 그대로 말합니다. 적힌 대로 만들면 요청한 사람은 만족하지만 같은 문제를 가진 나머지 고객은 여전히 막혀 있고, 제품에는 쓰임이 좁은 기능이 하나 늘어납니다.