기능 요청은 늘어나는데, 정리는 안 됩니다

제품을 운영하다 보면 기능 요청은 끝없이 들어옵니다. 처음에는 하나씩 꼼꼼히 읽고 기록하지만, 50개, 100개, 300개로 늘어나면 어느 순간 목록 자체를 열어보지 않게 됩니다.

정리가 안 된 기능 요청 목록은 결국 아무도 보지 않는 문서가 됩니다. 이 글에서는 기능 요청을 살아있는 자산으로 관리하는 실전 방법을 소개합니다.

기능 요청이 관리 안 되는 3가지 이유

분류 기준이 없다: "기능 요청"이라는 하나의 카테고리에 모든 것이 들어갑니다. 온보딩 관련 요청과 결제 관련 요청이 뒤섞여 패턴을 파악하기 어렵습니다.
중복이 파악 안 된다: 같은 요청이 다른 표현으로 20번 들어와도 각각 별개로 기록됩니다. "다크 모드 추가해 주세요"와 "어두운 테마가 있으면 좋겠어요"가 별도 항목으로 존재합니다.
상태 추적이 안 된다: 검토했는지, 거절했는지, 개발 중인지 알 수 없습니다. 이미 완료된 요청이 목록에 그대로 남아있기도 합니다.

기능 요청을 제품 영역별로 분류하세요. 예를 들면:

이렇게 나누면 "온보딩 관련 요청이 40%나 차지하네?"와 같은 패턴을 발견할 수 있습니다. 패턴이 보이면 우선순위 판단이 훨씬 쉬워집니다.

"다크 모드 추가해 주세요", "눈이 아파요, 어두운 테마 없나요?", "야간 모드 지원 부탁드립니다" — 모두 같은 요청입니다. 중복을 하나로 합치고 요청 횟수를 카운트하세요.

요청 횟수가 곧 고객의 수요를 보여주는 데이터가 됩니다. 고객 투표를 도입하면 이 과정을 자동화할 수 있습니다.

모든 기능 요청에 현재 상태를 표시하세요.

상태가 있으면 고객에게 진행 상황을 안내할 수 있고, 팀 내부에서도 현황을 한눈에 파악할 수 있습니다.

매주 또는 격주로 새로운 기능 요청을 팀이 함께 리뷰하세요. 리뷰 없이 쌓아두기만 하면 결국 다시 죽은 목록이 됩니다. 15분이면 충분합니다. 새 요청을 훑어보고, 중복을 합치고, 상태를 업데이트하세요.

기능 요청을 정리했다면 다음은 우선순위입니다. 요청 횟수만으로 결정하면 안 됩니다. 비즈니스 임팩트, 구현 비용, 전략 정합성을 함께 고려해야 하죠.

데이터 기반으로 우선순위를 정하는 구체적인 방법은 제품 우선순위, 직감 대신 데이터로 결정하는 법에서 자세히 다루고 있습니다.

TownHall의 피드백 보드에서는 고객이 직접 기능을 요청하고 투표할 수 있습니다. 중복 요청은 자연스럽게 하나의 피드백에 합의로 모이고, 상태 변경 시 자동 알림이 발송됩니다. 무료로 시작해 보세요.

기능 요청 관리의 핵심은 쌓아두지 않고 흐르게 만드는 것입니다. 분류하고, 합치고, 상태를 추적하고, 정기적으로 리뷰하세요. 이 과정이 자연스러워지면 기능 요청이 제품 의사결정의 가장 강력한 무기가 됩니다.