90%의 기능이 실패 — 팀은 이 한 가지 질문을 하지 않을 가능성이 높다
Source: Dev.to
The Problem
나는 팀이 원하지도 않는 기능을 만들며 몇 달을 태워버리는 모습을 봐왔다. 뛰어난 엔지니어, 탄탄한 코드, 깔끔한 아키텍처 — 하지만 출시 후 완전한 침묵. 채택률 0. 그 기능은 그냥… 거기에 남아 있다.
실패율은 끔찍하다. MIT에 따르면 신제품의 약 95 %가 목표에 못 미친다. Pendo의 연구에 따르면 평균 SaaS 제품의 80 % 기능이 거의 사용되지 않거나 전혀 사용되지 않는다. 이것은 반올림 오류가 아니다. 체계적인 문제다.
Why Features Fail
대부분의 팀은 가장 기본적인 질문을 건너뛴다: 왜 누군가가 실제로 이걸 사용할까?
- “이거 멋지겠지?”가 아니다.
- “고객이 요청했으니까?”가 아니다.
- “우리 경쟁사가 가지고 있잖아?”가 아니다.
진짜 질문은 더 깊다 — 이 기능이 누군가에게 어떤 일을 해주는가, 그리고 그 일이 충분히 고통스러워서 행동을 바꿔서라도 사용하게 만들 수 있는가?
내가 존경하는 CPO는 이렇게 말했다: 코드가 완성됐을 때가 아니라 “왜”를 알 때 배포하라. 실제로는 거의 아무도 그렇게 하지 않는다.
전형적인 시나리오:
- 영업팀으로부터 요청이 들어온다.
- 엔지니어링이 두 스프린트 정도 걸린다고 추정한다.
- 리더십은 이를 분기 로드맵에 넣고 싶어한다.
200명의 사용자가 혜택을 받을 것이라 가정하고도 실제 채택 여부를 검증하는 사람은 없다. 두 달 뒤 사용 데이터가 들어온다: 채택률 3 %. 그 기능은 조용히 서브메뉴에 묻히고, 팀은 다음 작업으로 넘어간다.
Pendo는 평균 SaaS 앱에 $2 M 이상의 비용이 드는 기능이 완전히 사용되지 않고 있다고 발견했다. 조직 전체 제품 표면에 걸쳐 이를 곱하면 엄청난 낭비가 된다.
Habits of Teams That Beat the 90 % Failure Rate
-
코드를 작성하기 전에 사용자와 대화한다
설문이 아니라 실제 대화. 다섯 번의 인터뷰는 5,000개의 설문 응답보다 더 많은 정보를 제공한다. 왜냐하면 주저함, 우회 방법, “사실 내가 하는 일은…” 같은 순간을 들을 수 있기 때문이다. -
성공 기준을 미리 정의한다
예시: “이 기능은 60일 이내에 파워 유저의 30 %가 채택하면 성공한다.” 이 기준이 없으면 모든 기능이 동시에 성공이자 실패가 된다. 왜냐하면 누가 승리를 어떻게 정의하는지에 대한 합의가 없기 때문이다. -
기능을 죽인다
3개월 걸린 기능을 제거하는 것이 낭비처럼 보일 수 있지만, 아무도 사용하지 않는 기능을 유지하는 것이 실제 낭비다—복잡성을 더하고 코드베이스를 느리게 하며 신규 사용자를 혼란스럽게 만든다. -
의견이 아니라 행동을 측정한다
사용자는 설문에서 뭔가를 원한다고 말하지만 실제로는 사용하지 않는다. 사람들이 하는 일을 추적하라, 그들이 할 것이라고 말하는 것이 아니라.
최고의 Chief Product Officer들은 간단한 필터를 사용한다: 모든 기능은 명확한 사용자 문제, 측정 가능한 결과, 그리고 삭제 기준을 가져야 한다. 세 가지를 각각 한 문장으로 표현할 수 없다면, 그 기능은 엔지니어링에 넘길 준비가 되지 않은 것이다.
How to Apply This
- 이것은 느리게 하라는 것이 아니라, 신중하게 하라는 것이다.
- 구축 전에 검증하는 팀은 실제로 더 빨리 배포한다. 왜냐하면 중요하지 않은 일에 낭비되는 시간이 적기 때문이다.
- 대부분의 기능이 실패하는 이유는 생각하는 것이 코딩보다 쉽기 때문이다. 코드를 작성하는 것이 생산적으로 느껴지고, 사용자 인터뷰를 진행하는 것이 느리게 느껴진다. 수학적으로도 명확하다—일주일간의 검증이 몇 달간의 낭비된 개발을 절약한다.
다음에 팀이 무언가를 만들려고 할 때, 이렇게 물어보라:
“내일 이걸 배포한다면, 구체적으로 누가 사용할 것이고, 대신 무엇을 멈출까?”
그 답을 이름과 구체적인 상황으로 제시하지 못한다면, 당신은 90 % 실패하는 기능 중 하나에 합류하려는 것이다.
팀이 배포했지만 아무도 사용하지 않은 가장 최악의 기능은 무엇인가요? 진심으로 궁금합니다—댓글에 남겨 주세요.