프로덕트 데스 사이클: 고객이 원한다는 기능을 만들수록 제품이 죽는 이유

고객이 떠나고 있습니다. 이유를 물어봤더니 "이 기능이 없어서"라고 합니다. 그래서 만들었습니다. 그런데 또 떠납니다. 이번에는 "저 기능이 없어서"라고 합니다. 또 만들었습니다. 6개월 뒤, 기능은 30개가 됐는데 활성 사용자는 반으로 줄었습니다.

이것이 프로덕트 데스 사이클입니다. 고객의 요청을 충실하게 따르는데 제품이 죽어가는 역설적인 악순환.

데스 사이클의 해부학: 세 단계로 무너지는 제품

프로덕트 데스 사이클은 David Bland가 정의한 개념입니다. 세 단계로 구성됩니다.

1단계: "아무도 이 제품을 안 쓴다." 사용자가 부족하거나 이탈이 발생합니다. 당연히 불안합니다.

2단계: "고객에게 뭘 원하는지 물어보자." 합리적인 접근입니다. 설문조사를 돌리고, 인터뷰를 하고, 피드백을 수집합니다. 고객이 원하는 기능 목록이 나옵니다.

3단계: "요청한 기능을 만들자." 그리고 만듭니다. 출시합니다. 그런데 아무도 안 씁니다. 다시 1단계로 돌아갑니다.

고객이 "이 기능이 있으면 쓸 것 같다"고 말하는 것과 실제로 그 기능 때문에 결제하는 것은 완전히 다른 일입니다.

"비싸요"가 진짜 이유가 아닌 것처럼, "기능 부족"도 진짜 이유가 아닙니다

고객이 이탈할 때 물어보면 대부분 구체적인 이유를 댑니다. "엑셀 내보내기가 없어서요." "슬랙 연동이 안 돼서요." "다크 모드가 없어서요."

이 답변을 액면 그대로 믿으면 안 됩니다. 고객은 자신의 진짜 이유를 모릅니다.

이탈의 진짜 원인은 보통 이런 것들입니다.

• 핵심 가치를 경험하지 못했습니다. 온보딩에서 Aha 모먼트에 도달하지 못한 채 떠났습니다.
• 문제 자체가 급하지 않습니다. "있으면 좋겠다" 수준이지, "없으면 안 된다" 수준이 아닙니다.
• 경쟁 제품이 더 싸거나 더 익숙합니다. 기능 차이가 아니라 전환 비용의 문제입니다.

엑셀 내보내기를 만들어 봤자, 진짜 문제는 온보딩에 있었던 겁니다.

기능이 많아질수록 제품이 약해지는 역설

직관에 반하는 사실이 있습니다. 기능을 추가할수록 제품은 약해집니다.

기능이 10개일 때, 사용자는 핵심 3개를 바로 찾습니다. 기능이 50개가 되면, 핵심 3개를 찾기까지 5분이 걸립니다. 새 사용자에게 5분은 영원입니다.

Basecamp의 Jason Fried는 이것을 "기능 수렁(feature swamp)"이라고 부릅니다. 하나하나는 합리적인 추가였지만, 전체를 보면 수렁입니다. 방향도 깊이도 없이 넓어지기만 한 늪.

Notion이 처음부터 지금만큼의 기능을 가지고 출시했다면 아무도 안 썼을 겁니다. 사용자가 먼저 핵심 가치를 경험한 뒤에, 사용자의 성장에 맞춰 기능이 확장된 것입니다.

진짜 신호와 가짜 신호를 구분하는 3가지 필터

모든 고객 피드백이 쓸모없다는 말이 아닙니다. 핵심은 실행할 가치가 있는 피드백을 가려내는 것입니다.

• 돈 필터: "이 기능이 있으면 유료로 전환하시겠습니까?"가 아니라, "이 기능에 얼마를 더 내시겠습니까?"라고 물어보세요. 금액을 말하는 사람만 진짜입니다.
• 빈도 필터: 한 명이 10번 요청한 기능과 10명이 각각 1번씩 요청한 기능은 다릅니다. 후자가 진짜 수요입니다.
• 행동 필터: 기능 요청을 한 사용자가 기존 기능을 얼마나 쓰고 있는지 확인하세요. 기존 기능도 안 쓰는 사용자의 요청은 노이즈입니다.

빼기의 용기: 기능을 줄이면 성장이 시작됩니다

인디 파운더에게 가장 어려운 결정은 기능을 추가하는 것이 아닙니다. 기능을 빼는 것입니다.

당신이 3주 동안 만든 기능을 아무도 안 쓰고 있다면, 그것을 삭제해야 합니다. 그 기능이 UI를 복잡하게 만들고, 새 사용자를 혼란스럽게 하고, 유지보수 비용을 늘리고 있습니다.

제품의 가치는 가진 기능의 수가 아니라, 핵심 기능의 완성도로 결정됩니다.

실전 방법은 간단합니다. 제품 분석 도구에서 기능별 사용률을 확인하세요. 전체 사용자의 5% 미만이 쓰는 기능은 삭제 후보입니다. PostHog, Mixpanel, 심지어 Google Analytics의 이벤트 추적만으로도 충분합니다.

데스 사이클을 끊는 프레임워크: "문제 먼저, 기능 나중에"

고객이 "X 기능을 만들어 주세요"라고 말하면, 바로 백로그에 넣지 마세요. 대신 이 질문을 던지세요.

• "어떤 상황에서 그 기능이 필요하셨나요?" 상황을 이해하면, 기능이 아닌 더 나은 해결책이 보일 수 있습니다.
• "그 기능 없이 지금은 어떻게 해결하고 계신가요?" 이미 우회 방법이 있다면, 급하지 않은 겁니다.
• "그 문제가 해결되면 무엇이 달라지나요?" 기대 효과가 모호하면, 만들어도 만족도가 낮습니다.

이 세 질문만으로도 기능 요청의 80%는 "만들지 않아도 되는 것"으로 분류됩니다.

하나를 깊게 파는 것이 열 개를 얕게 만드는 것보다 낫습니다

당신의 제품에서 사용자가 가장 많이 쓰는 기능 하나를 찾으세요. 그리고 그 기능을 세계 최고 수준으로 만드세요.

Superhuman은 이메일 앱입니다. 기능이 적습니다. 캘린더도 없고, 노트도 없습니다. 대신 이메일 검색 속도가 100ms입니다. 키보드 단축키가 완벽합니다. 하나의 핵심 경험을 극단적으로 만들었습니다.

인디 파운더로서 리소스가 제한되어 있다면, 이것이 유일한 전략입니다. 10개의 평범한 기능보다 1개의 놀라운 기능이 사용자를 잡습니다. 그리고 그 1개가 입소문을 만듭니다.

오늘 당장 제품 분석 도구를 열어보세요. 사용률 상위 3개 기능이 무엇인지 확인하세요. 다음 스프린트에서는 새 기능을 추가하는 대신, 그 3개를 더 빠르고, 더 쉽고, 더 만족스럽게 만드세요. 그것이 데스 사이클을 끊는 첫 번째 행동입니다.