신사업 스펙을 내부 기능 목록으로 시작하면 고객 없이 제품이 완성됩니다

알렉산더 오스터왈더의 가치 제안 설계(Value Proposition Design, 2014)에서 고객 세그먼트는 해야 할 일(Jobs), 불편(Pains), 기대 이익(Gains)의 조합으로 정의됩니다. 신사업 스펙은 이 세 가지 중 불편을 해소하는 방향으로 작성될 때 고객이 이해하는 언어로 만들어집니다.
내부 스펙 설계 과정에서 등장하는 우리가 할 수 있는 것과 고객이 말하는 지금 불편한 것이 일치하지 않는 경우가 많습니다. 이 불일치를 고객 접촉 전에 발견하지 못하면 완성된 제품이 고객의 현재 방식과 경쟁하지 못합니다.
스펙 설계 순서를 바꾸는 것은 개발 속도를 늦추는 것이 아닙니다. 첫 고객 계약 이전에 잘못된 방향으로 만든 기능을 버리는 비용을 줄이는 것입니다.

내부 기능 목록이 스펙이 될 때 생기는 문제

신사업 기획 회의에서 스펙을 정하는 방식은 대부분 이렇습니다. 팀이 경쟁사 제품을 분석하고 기능 목록을 뽑습니다. 내부에서 없으면 안 될 것들을 추가합니다. 출시 범위를 줄이고 v1 기능 목록을 확정합니다. 이 목록이 개발팀에 넘어갑니다. 고객이 이 과정에 없습니다.

이 방식의 문제는 스펙이 내부 판단의 언어로 쓰인다는 것입니다. 내부 팀이 중요하다고 생각하는 기능과 고객이 지금 불편해서 돈을 낼 기능은 다를 수 있습니다. 제품이 완성된 뒤 고객 미팅에서 처음으로 이 차이가 드러납니다. 이 시점에 방향을 바꾸면 개발 비용의 일부가 낭비됩니다.

CB Insights가 분석한 스타트업 실패 이유 1위는 시장 수요 없음(42%)입니다. 이 숫자가 중소기업 신사업에서도 반복되는 이유가 여기 있습니다. 수요가 없는 것이 아니라, 고객의 수요와 내부 스펙이 어긋난 것입니다.

고객 언어에서 스펙을 뽑는 방법

스펙 설계 전에 고객 인터뷰에서 물어야 할 것은 기능이 아닙니다. 지금 이 일을 어떻게 하고 있는지입니다. 엑셀로 합니까, 외부에 맡깁니까, 사람이 직접 합니까. 그 방법에 한 달에 얼마를 씁니까. 가장 불편한 부분이 어디입니까. 이 질문에 나온 답이 스펙의 출발 재료입니다.

오스터왈더의 가치 제안 설계 프레임에서 고객의 불편(Pain)을 완화하는 것이 제품의 핵심 기능이 되어야 합니다. 고객이 지금 이걸 수작업으로 하는데 두 시간이 걸린다고 말하면, 그 두 시간을 줄이는 것이 v1 핵심 스펙입니다. 고객이 말하지 않은 기능은 v2로 미룰 수 있습니다.

Ahn Partners 판단: 고객 언어에서 스펙을 뽑는 작업은 제품 완성 후 영업 단계가 아니라 스펙 확정 전 단계에서 이루어져야 합니다. 이 순서가 바뀌면 개발이 끝난 뒤 고객의 언어로 제품을 다시 설명하는 작업이 필요해지고, 그 설명이 잘 안 되면 제품이 아닌 영업력의 문제로 귀결됩니다.

스펙 설계 순서를 점검하는 방법

지금 개발 중이거나 기획 중인 신사업 스펙 문서를 꺼내십시오. 그 문서에서 고객 인터뷰를 직접 인용한 문장이 몇 개인지 세어보십시오. 고객이 이렇게 말했다는 문장이 없으면, 스펙이 내부 판단으로만 만들어진 것입니다.

반대로 고객 인터뷰에서 나온 말이 스펙 항목과 연결된 문서가 있다면, 그 스펙은 고객 언어로 쓰인 것입니다. 이 연결이 있어야 개발팀도 어떤 문제를 풀기 위해 이 기능을 만드는지를 압니다. 그 이해가 있는 팀은 스펙이 불완전할 때 더 나은 대안을 제안합니다.

이번 주 할 수 있는 것은 현재 신사업 스펙 항목 중 가장 핵심 기능 세 개를 꺼내 각각에 대해 어떤 고객이 어떤 불편을 이야기했는가를 찾는 것입니다. 그 연결이 없는 기능은 개발 우선순위를 다시 검토해야 합니다.

한 문장으로 정리하면

신사업 스펙은 내부가 할 수 있는 것으로 시작하면 내부가 원하는 것이 만들어지고, 고객이 지금 불편해서 돈을 내고 있는 것으로 시작하면 고객이 기다리는 것이 만들어집니다.

점검 목록

현재 신사업 스펙의 핵심 기능 항목에 고객 인터뷰를 직접 인용한 근거가 연결되어 있는가
스펙 확정 전에 실제 잠재 고객과 최소 세 건의 인터뷰를 진행했는가
고객이 현재 이 문제를 어떻게 해결하고 있는지, 그 방법의 비용과 불편 수준을 확인했는가