팀 단위 디자인 협업 SaaS를 운영한다.
핵심 기능은 디자인 파일 공유, 댓글, 버전 관리다.
현재 로드맵에는 실시간 공동편집 기능이 예정되어 있다.
사용자 조사에서 가장 많이 요청된 기능이고, 신규 고객 확보에도 도움이 될 것으로 예상한다.
그런데 ARR의 22%를 차지하는 대기업 고객이 갑자기 '감사 로그' 기능을 요구한다.
개발 리소스상 이번 분기에는 둘 중 하나만 가능하다.
감사 로그(Audit Log)
시스템에서 일어난 중요한 행동을 나중에 검토할 수 있도록 누가, 언제, 어떤 작업으로, 어떤 결과를 냈는지 시간순으로 남긴 기록
| 공동편집 | 감사 로그 | |
|---|---|---|
| 요청 고객 | 전체의 38% | 전체의 6% |
| 해당 고객 ARR 비중 | 29% | 41% |
| 개발 기간 | 10주 | 7주 |
| 신규 영업 기회 | 높음 | 엔터프라이즈 중심 |
| 미개발 리스크 | 성장 둔화 가능성 | 일부 계약·갱신 차질 가능성 |
ARR(Annual Recurring Revenue)
= 연간 반복 매출
대기업 고객은 “감사 로그가 내부 보안심사 통과에 필요하다”고 했다.
아직 계약 해지를 언급하지는 않았다.
영업팀은 감사 로그가 있으면 현재 협상 중인 대기업 4곳 중 2곳의 계약 가능성이 크게 올라간다고 주장한다.
반면 사용자 인터뷰에서는 일반 사용자들이 공동편집을 가장 많이 요구했다.
이번 분기 무엇을 개발해야 할까?
다음 세 가지를 구분해 판단하라.
요청 고객 수와 매출 영향 중 무엇을 우선할 것인가?
“많이 요청한다”와 “없으면 구매하지 않는다”는 어떻게 다른가?
이 결정을 내리기 전에 딱 하나의 사실만 추가로 확인할 수 있다면 무엇을 확인할 것인가?
38%가 공동편집을 원한다는 숫자에 현혹되면 안 된다.
요청 빈도가 Willingness to Pay(WTP)를 보여주는 게 아니기 때문이다.
감사 로그는 사용자가 즐겨 쓰는 기능은 아니지만 보안심사를 통과하지 못하면 제품 자체를 구매할 수 없다.
공동편집은 가치 증대 기능이고, 감사 로그는 구매 차단 요인을 제거하는 기능일 수 있다.
"ARR 41%가 감사 로그를 원한다"와 "ARR 41%가 감사 로그 미도입으로 인해 위험해진다"는 말은 의미가 전혀 다르다.
현재 확실한 건 22% 고객 한 곳이 보안심사를 언급했다는 것뿐이다.
영업팀의 ‘2곳 계약 가능성 상승’도 아직 예측에 불과하다.
반면 공동편집 수요는 여러 고객에게서 반복 확인됐다.
먼저 감사 로그 부재로 실제 계약이 막힌 사례와 예상 ARR을 확인하면 어떨까?
그 증거가 없다면 기존 로드맵을 유지하면 된다.
고객 요구의 빈도만 세면 안 된다.
몇 명이 원하는지?
얼마나 중요한지?
없으면 어떤 행동을 하는지?
사업에 얼마의 가치가 있는지?
등을 따져봐야 한다.
B2B에서는 사용 빈도가 거의 0인 기능도 구매 결정에는 결정적일 수 있다.
감사 로그가 그럴 수 있다.
매일 쓰지는 않지만, 그것이 없어서 보안심사를 통과하지 못한다면 특정 고객에게는 구매 자체가 불가능해질 수 있다.
감사 로그를 높은 우선순위로 두되, 바로 개발을 확정하지는 않겠다.
공동편집은 38%의 고객이 요청했지만, 많이 원한다는 것과 없으면 구매하지 않는다는 것은 다르다.
반면 감사 로그가 보안심사를 통과하기 위한 필수 조건이라면 구매와 갱신 자체를 막는 요소가 될 수 있다.
가장 먼저 ‘감사 로그가 없어서 실제로 갱신이나 신규 계약이 막히는 ARR이 얼마인지’를 확인하겠다.
그 금액과 가능성이 충분히 크다면 이번 분기에는 감사 로그를 개발한다.
그렇지 않다면 기존 계획대로 공동편집을 진행한다.