제품 로드맵: 고객 요청 100개 중 만들어야 할 3개를 고르는 법

고객 A가 말합니다. "엑셀 내보내기 기능 좀 넣어주세요." 고객 B가 말합니다. "다크 모드 언제 나와요?" 고객 C가 말합니다. "팀 기능이 없으면 못 쓰겠어요." 커뮤니티에는 요청이 쏟아집니다. 어느새 요청 목록이 100개가 넘었습니다.

100개를 다 만들면 되지 않냐고요? 인디 파운더에게 가장 부족한 자원은 돈이 아닙니다. 시간입니다. 혼자서 혹은 소규모 팀으로 모든 요청에 응하면, 아무것도 제대로 못 만들고 끝납니다. 로드맵은 "무엇을 만들 것인가"가 아니라 "무엇을 만들지 않을 것인가"를 결정하는 도구입니다.

"고객이 원하는 것"과 "고객에게 필요한 것"은 다릅니다

헨리 포드가 말했습니다. "고객에게 물었다면 더 빠른 말을 원한다고 했을 것이다." 과장된 인용이지만 핵심은 맞습니다. 고객은 자신의 문제를 알지만, 최선의 해결책은 모릅니다.

"엑셀 내보내기"를 요청한 고객이 진짜 원하는 것은 무엇일까요? 아마 "데이터를 다른 곳에서도 활용하고 싶다"일 것입니다. 그렇다면 API 연동이 더 나은 해결책일 수 있습니다. "다크 모드"를 요청한 고객이 진짜 원하는 것은? "밤에 눈이 편했으면"일 수도 있고, 단순히 "다른 앱에 다 있으니까"일 수도 있습니다.

요청의 표면이 아니라 이면을 파세요. "무엇을 만들어 달라"는 요청 뒤에 숨어 있는 진짜 문제를 찾는 것이 로드맵의 첫 번째 단계입니다.

NOW, NEXT, LATER: 인디 파운더의 로드맵은 3칸이면 충분합니다

대기업은 분기별 로드맵을 만들고, 간트 차트를 그리고, PM이 일정을 관리합니다. 인디 파운더에게 그런 건 필요 없습니다. 칸 세 개면 됩니다.

• NOW (지금): 이번 주에 만들 것. 최대 1~2개. 지금 당장 고객에게 가장 큰 가치를 줄 기능입니다.
• NEXT (다음): 다음 2~4주 안에 할 것. 3~5개 정도. NOW가 끝나면 여기서 꺼냅니다.
• LATER (나중에): 언젠가 할 수도 있는 것. 나머지 전부. 솔직히 대부분은 영원히 LATER에 남습니다. 그래도 괜찮습니다.

날짜가 적힌 로드맵은 거짓말입니다. 인디 파운더의 로드맵에는 "언제"가 아니라 "무엇이 먼저인가"만 있으면 됩니다.

ICE 프레임워크: 30초 만에 우선순위를 매기는 법

요청이 100개 있을 때, 어떤 기준으로 NOW에 넣을 3개를 고를까요? ICE 프레임워크가 가장 실전적입니다.

• Impact (영향력): 이 기능이 핵심 지표(매출, 전환율, 유지율)에 얼마나 영향을 줄까요? 1~10점.
• Confidence (확신): 이 기능이 정말 효과가 있을 거라는 증거가 있나요? 고객 5명이 요청했으면 높은 점수, 내 직감이면 낮은 점수. 1~10점.
• Ease (용이성): 얼마나 빨리 만들 수 있나요? 하루면 10점, 한 달이면 1점. 1~10점.

세 점수의 평균이 ICE 점수입니다. 높은 순서대로 NOW에 넣으세요. 완벽하지 않지만, 감으로 결정하는 것보다 10배 낫습니다. 구글 스프레드시트에 요청 목록과 ICE 점수를 정리하면 5분이면 됩니다.

"아니오"라고 말하는 기술: 거절이 제품을 살립니다

인디 파운더가 가장 어려워하는 것. 고객에게 "아니오"라고 말하는 것입니다. 고객이 소중하니까. 떠날까 봐 무서우니까. 하지만 모든 요청에 "예"라고 말하면, 제품은 누구의 문제도 제대로 풀지 못하는 괴물이 됩니다.

• "좋은 아이디어인데, 지금은 아닙니다": 거절이 아니라 우선순위의 문제로 프레이밍하세요. "LATER 목록에 추가했습니다. 감사합니다!"
• 공개 로드맵을 만드세요: Notion이나 Trello로 공개 보드를 만들고, 고객이 투표할 수 있게 하세요. 고객이 직접 우선순위에 참여하면 거절해도 이해합니다.
• 1명의 요청은 무시하세요: 같은 요청이 3명 이상에게서 나올 때 비로소 고려 대상입니다. 1명의 요청으로 로드맵을 바꾸면 안 됩니다.
• 유료 고객의 목소리에 무게를 두세요: 무료 사용자 50명의 요청보다 유료 고객 5명의 요청이 중요합니다. 돈을 내는 고객이 진짜 고객입니다.

기능 크립: 만들면 만들수록 제품이 죽는 이유

기능을 추가할 때마다 제품은 복잡해집니다. 복잡해질수록 버그가 늘어납니다. 유지보수 비용이 올라갑니다. 새 사용자의 학습 곡선이 가팔라집니다. 기능 하나를 추가하는 것은 영원히 유지보수할 짐을 하나 더 지는 것입니다.

최고의 제품은 기능이 많은 제품이 아닙니다. 핵심 기능 하나를 완벽하게 해내는 제품입니다.

Basecamp의 제이슨 프리드는 "기능을 추가하기 전에 기존 기능을 제거할 것을 먼저 고민하라"고 말합니다. 새 기능을 추가하고 싶다면, 먼저 질문하세요. "이 기능 없이는 고객이 핵심 문제를 해결할 수 없는가?" 대답이 "아니오"라면, 만들지 마세요.

한국 시장의 특수성: 카카오톡 알림톡 하나가 기능 열 개를 대신합니다

한국에서 제품을 만든다면, 로드맵에 한국만의 맥락을 반영해야 합니다.

• 카카오톡 알림톡: 이메일 알림 기능을 만드는 대신, 카카오톡 알림톡을 연동하세요. 한국 사용자의 이메일 확인율은 20% 미만이지만, 카카오톡 알림 확인율은 90% 이상입니다.
• 네이버 로그인: 소셜 로그인을 구현할 때, 구글/애플보다 네이버/카카오 로그인이 전환율에 더 큰 영향을 줍니다.
• 모바일 퍼스트: 한국의 모바일 사용 비율은 세계 최고 수준입니다. 데스크톱 기능을 고민하기 전에 모바일 경험을 완벽하게 만드세요.

로드맵은 문서가 아니라 습관입니다

로드맵을 한 번 만들고 서랍에 넣어두면 소용없습니다. 매주 30분, 로드맵을 리뷰하세요.

NOW에 있는 것이 정말 가장 중요한 것인지 확인합니다. 이번 주에 나온 고객 피드백을 반영합니다. 완료된 기능은 지우고, NEXT에서 NOW로 올릴 것을 결정합니다. 이 30분이 한 주의 방향을 결정합니다.

인디 파운더의 가장 큰 무기는 속도입니다. 대기업이 분기 계획을 세우는 동안, 당신은 이번 주에 만들고 다음 주에 고객 반응을 봅니다. 하지만 속도가 무기가 되려면, 방향이 맞아야 합니다. 100개 중 3개를 고르는 용기. 97개에 "아니오"라고 말하는 결단. 그것이 로드맵의 본질입니다.