"기능은 어떻게 고객 가치가 되고, 차별점은 어떻게 점수가 되는가?"
APMP EP09의 주제는 Features, Benefits, and Discriminators입니다.
지난 EP08에서 Theme Statement를 다뤘다면, 이번 EP09는 그 한 단계 앞의 문제를 다룹니다. 좋은 Win Theme는 무엇으로 만들어지는가, 그리고 평가위원의 점수와 어떻게 연결되는가 하는 질문입니다.
고객은 기능을 사지 않습니다. 기능이 만들어내는 혜택을 삽니다. 그리고 차별점은 고객이 누구의 혜택을 선택할지 결정하게 만듭니다. 이 한 문장에 EP09 전체가 압축되어 있습니다. 이번 글에서는 이 원칙을 한국 제안서 실무에 맞춰 다섯 가지 원칙으로 정리합니다. 마지막 한 섹션에서는 이 흐름을 제품 워크플로우에 박아 넣고 있는 Contrl 2차 클로즈 베타도 짧게 안내합니다.
1. Feature, Benefit, Discriminator는 다른 층의 개념이다
제안서를 쓸 때 가장 흔한 실수는 우리가 가진 것을 그대로 적는 것입니다. "우리는 이런 기능이 있습니다", "우리는 이런 경험이 있습니다", "우리는 이런 인력을 투입할 수 있습니다." 이 문장들은 사실로는 맞습니다. 하지만 아직 제안 전략은 아닙니다.
APMP 기준으로 보면 이런 문장은 대부분 Feature입니다. 우리가 가진 것입니다. 평가위원이 점수를 주는 지점은 그 위에 있습니다.
같은 출발점이라도 어느 층에서 멈추느냐에 따라 문장의 힘이 달라집니다. Feature에서 멈추면 제품 카탈로그가 되고, Benefit까지 가면 제안 문장이 되며, Discriminator까지 가야 점수의 근거가 됩니다.
평가위원이 정말 보고 싶은 것은 마지막 두 층입니다. Feature는 거의 항상 비슷비슷하기 때문입니다. 그래서 잘 쓰는 제안서는 Feature를 길게 늘어놓는 대신, 그 Feature가 만드는 Benefit과 Discriminator를 분명히 보여줍니다.
2. 고객은 Benefit을 산다, 그래서 문장의 주어가 달라져야 한다
APMP가 말하는 핵심을 한 줄로 옮기면 이렇게 됩니다. 고객은 Benefit을 산다. 이 한 문장이 제안서 문장의 주어를 바꾸라고 요구합니다.
많은 제안 문장은 Seller View로 작성됩니다. 우리가 무엇을 제공하는지 적는 시점입니다.
"당사는 AI 기반 문서 분석 기능을 제공합니다." "당사는 다수의 공공 입찰 제안 경험을 보유하고 있습니다." "당사는 표준화된 제안서 작성 프로세스를 운영합니다."
이 문장들은 우리 입장에서는 맞는 말입니다. 하지만 고객 입장에서는 한 번 더 해석이 필요합니다. "그래서 우리에게 뭐가 좋아지는데?" 이 질문에 평가위원은 본문에서 답을 찾지 못하면 점수를 머뭇거립니다.
APMP가 권장하는 방향은 Customer View입니다. 같은 사실을 고객 시점에서 풀어 적는 방식입니다.
"귀 기관은 AI 기반 문서 분석을 통해 요구사항 누락 위험을 줄이고, 검토 시간을 단축할 수 있습니다." "귀 기관은 유사 제안 경험에서 검증된 작성 구조를 활용해 초기 방향 설정 시간을 줄일 수 있습니다." "귀 기관은 표준화된 작성 프로세스를 통해 섹션별 메시지 편차를 줄이고 평가자가 핵심을 빠르게 파악하도록 만들 수 있습니다."
같은 Feature를 다루지만 문장의 주어가 우리가 아니라 고객으로 바뀌었습니다. 결과적으로 평가위원이 한 번 더 해석할 필요가 없어집니다. 제안서를 쓰는 동안 모든 문장의 주어를 점검하는 한 가지 작은 습관만으로도 본문의 톤이 크게 달라집니다.
3. Why를 묻지 않으면 Feature는 Benefit으로 번역되지 않는다
Customer View를 만들려면 한 가지 절차가 더 필요합니다. 고객이 말한 요구사항의 표면이 아니라, 그 아래의 진짜 이유를 묻는 일입니다.
요구사항은 대부분 수면 위에 보이는 표현입니다. 진짜 니즈는 그 아래에 있습니다. APMP가 EP09에서 강조하는 것도 이 지점입니다. 요구사항의 what만 알아서는 부족하고, why를 함께 봐야 한다는 것입니다.
예를 들어 고객이 "자료 검색이 쉬웠으면 좋겠다"고 말했다고 가정해봅시다. 겉으로 보면 검색 기능 이슈처럼 보입니다. 그런데 Why를 한 번만 더 물어보면 다음과 같은 답이 나올 수 있습니다.
- 담당자가 바뀔 때마다 과거 자료를 찾는 시간이 오래 걸린다.
- 유사 공고를 놓쳐서 대응이 늦어진 경험이 있다.
- 같은 내용을 반복 입력하느라 검토 시간이 줄어든다.
- 민원이나 질의 응답 이력이 흩어져 있어 운영 리스크가 생긴다.
이 시점에서 Benefit의 방향이 완전히 달라집니다. 기능 차원의 표현("검색 기능 제공")은 사라지고, 그 자리에 업무 인수인계 부담 감소·공고 누락 가능성 감소·반복 입력 시간 단축·운영 리스크 관리 같은 고객 가치가 들어옵니다. 같은 Feature라도 어느 Benefit과 연결하느냐에 따라 제안 문장의 힘이 완전히 달라집니다.
좋은 제안 작성자는 거의 항상 이 Why를 한 번 더 묻습니다. RFP에 적힌 요구사항을 그대로 받아들이지 않고, 그 요구사항이 왜 들어갔는지를 사전 영업 자료·인터뷰·지난 발주 패턴에서 추론합니다. 그 추론이 있어야 Feature가 Benefit으로 번역됩니다.
4. Discriminator는 3C가 겹치는 지점에서만 나온다
EP09에서 가장 중요한 개념 하나만 꼽으라면 Discriminator입니다. 그런데 이 단어는 제안서 실무에서 자주 오용됩니다. 보통 "차별점"으로 번역되면서 멋진 형용사로 채워지는 경향이 있습니다.
APMP의 정의는 다릅니다. Discriminator는 다음 세 조건을 동시에 만족하는 지점입니다.
- 고객이 중요하게 보는 문제일 것
- 우리가 실제로 제공할 수 있는 것일 것
- 경쟁사가 쉽게 따라 하기 어려운 것일 것
세 조건 중 하나라도 빠지면 그것은 Discriminator가 아닙니다. 고객이 중요하게 보지 않는 강점이면 차별화 자체가 무의미하고, 우리가 못 하는 것이면 거짓이고, 경쟁사가 쉽게 따라 할 수 있는 것이면 곧 차별점이 사라집니다.
이 세 조건을 동시에 보는 가장 흔한 도구가 3C 분석입니다.
세 원이 겹치는 지점이 APMP가 말하는 discriminator sweet spot입니다. 이 지점에서 출발한 Win Theme는 회의실의 의지가 아니라 시장 구도 위에서 만들어진 메시지가 됩니다. 그래서 평가위원에게도 설득력 있게 읽힙니다.
좋은 Win Theme는 "우리가 이걸로 가자"라고 회의실에서 정해서 나오지 않습니다. Customer, Competitor, Company가 만나는 지점을 먼저 찾고, 그 지점에서 Win Theme가 도출되는 순서입니다.
5. 브랜드·경험·인력은 그 자체로는 차별점이 아니다
한국 제안서에서 가장 자주 보이는 차별화 표현이 있습니다. "풍부한 경험", "전문 인력 보유", "검증된 프로세스", "다수의 수행 실적", "높은 브랜드 신뢰도" 같은 문구입니다.
문제는 이 표현들이 거의 모든 제안서에 들어간다는 점입니다. 평가위원 입장에서는 변별력이 없습니다. APMP도 이 부분을 분명하게 지적합니다. 브랜드·인력·지사·프로세스·경험은 그 자체로는 Discriminator가 아닙니다. Feature이거나 Proof일 수 있지만, Customer Benefit으로 번역되지 않으면 선택 이유가 되지 않습니다.
예를 들어 "유사 사업 경험이 많다"는 표현은 Feature에 가깝습니다. 이 문장이 차별점이 되려면 고객 가치로 한 번 변환되어야 합니다.
"유사 사업에서 축적한 요구사항 분류 기준을 적용해 초기 분석 시간을 줄이고, 누락 리스크를 낮출 수 있습니다."
이제 고객 Benefit이 보입니다. 여기에 경쟁사가 쉽게 따라 하기 어려운 구체 근거(예: 특정 분류 체계, 자체 보유 데이터셋, 인증)가 붙으면 비로소 Discriminator가 됩니다.
제안 검토 단계에서 한 번 점검해볼 만한 질문 두 가지가 있습니다. "이 문장이 경쟁사 다섯 곳의 제안서에도 똑같이 들어갈 수 있는가?" 그리고 "이 문장이 빠지면 우리 제안의 선택 이유가 사라지는가?" 두 질문에 첫 번째가 예이거나 두 번째가 아니오면, 그 문장은 차별점이 아닙니다.
6. 좋은 Win Theme는 다섯 가지 질문에 답한다
지금까지의 다섯 원칙을 종합하면 좋은 Win Theme가 답해야 하는 질문은 다섯 가지로 정리됩니다.
- 고객이 진짜 중요하게 보는 문제는 무엇인가
- 우리는 어떤 Feature로 그 문제를 해결할 수 있는가
- 그 Feature는 고객에게 어떤 Benefit을 만드는가
- 경쟁사와 비교했을 때 왜 우리 Benefit이 더 적합한가
- 그 주장을 무엇으로 증명할 수 있는가
이 다섯 질문에 모두 답이 채워지면 Win Theme는 슬로건이 아니라 의사결정의 근거가 됩니다. 다섯 칸 중 하나라도 비어 있으면, 그 빈자리는 본문에서 반드시 드러납니다. 형용사가 늘어나거나, 같은 말이 다른 단어로 반복되거나, "최선을 다하겠다"는 톤의 마무리가 늘어납니다.
좋은 Win Theme를 만든다는 것은 한 줄짜리 문구를 생성하는 일이 아닙니다. 위 다섯 질문을 순서대로 정리하고, Customer View로 번역하고, 3C에서 검증하는 과정 전체입니다. 이 과정이 정착되면 제안서의 본문도 자연스럽게 따라옵니다. 기능 소개가 줄고 고객 가치가 늘어나며, 모호한 차별화가 줄고 평가위원이 점수화할 수 있는 선택 이유가 분명해집니다.
마무리
기능은 어떻게 고객 가치가 되고, 차별점은 어떻게 점수가 되는가?
기능은 Why를 한 번 더 물을 때 Benefit으로 번역되고, 그 Benefit은 3C 분석을 통해 경쟁사 대비 선택 이유로 정리될 때 Discriminator가 됩니다. 그리고 좋은 Win Theme는 이 모든 과정의 결과로 도출됩니다.
다음 EP10에서는 이 주장들을 어떻게 믿게 만들 것인지 다룹니다. 평가위원이 결국 묻는 한 가지 질문은 "그걸 무엇으로 증명할 수 있습니까?"이기 때문입니다. 다음 글에서는 Proof Points 관점에서 제안서의 주장과 근거가 어떻게 연결되어야 하는지 이어서 정리하겠습니다.
