기능, 혜택, 차별화 요소: What, So What, Why Us

이번 편의 질문입니다. 제안서가 우리가 무엇을 제공하는지 설명할 때, 고객은 그것이 왜 자기에게 중요한지, 그리고 왜 우리만 할 수 있는지까지 읽어낼 수 있을까요?

대부분의 제안서는 앞부분에만 답하고 멈춥니다. 역량, 제품, 인증, 업력을 나열하고 그 가치는 평가위원이 알아서 헤아리게 둡니다. APMP Body of Knowledge가 내놓는 해법은 세 단어입니다. 기능(Feature)은 우리가 제공하는 것, 혜택(Benefit)은 고객이 그로부터 얻는 것, 차별화 요소(Discriminator)는 고객에게 중요하면서 다른 입찰자는 따라올 수 없는 혜택입니다. 고객은 혜택을 사는데 그 가운데 우리 혜택을 고르게 하는 것이 차별화 요소입니다.

이 시리즈는 APMP Foundation Study Guide에 요약된 APMP Body of Knowledge를 하나씩 짚어봅니다. 이번 역량은 Focus on the Customer에 속하며 시리즈의 다른 편에서 다루는 테마 문장, 가치 제안, 윈 테마의 재료가 됩니다.

세 단어, 세 질문

Study Guide에 셋을 구분하는 간단한 방법이 나옵니다. 그대로 퇴고 도구가 되니 외워둘 만합니다.

간단히 말해 기능은 설명입니다. 혜택은 가치를 담고 차별화 요소는 선택할 이유를 줍니다. 제안서에는 셋이 모두 필요하지만 평가위원은 주로 뒤의 둘에 점수를 줍니다.

기능을 쓰지 말라는 뜻은 아니라고 Body of Knowledge는 분명히 해둡니다. 기능은 혜택을 실현하는 수단이고 평가위원은 혜택을 믿기 위해 기능을 봐야 합니다. 기능에서 멈추고 그것을 고객의 문제와 연결하는 일을 고객에게 떠넘기면 문제가 되는데 많은 조직이 바로 그렇게 합니다.

제안서가 기능에서 멈추는 이유

제안서를 쓰는 사람은 자연스럽게 공급자의 시각에서 출발합니다. 제품과 방법론과 팀을 잘 아니까 그것부터 떠오릅니다. 반대편에서 읽는 평가위원의 머릿속에는 질문 하나가 계속 돌아갑니다. 그래서 우리에게 뭐가 좋은데?

Body of Knowledge에 따르면 이 전환을 특히 어려워하는 사람들이 있습니다.

1. 기술 담당자와 SME(분야 전문가). 그 기능이 왜 대단한지 정확히 아는 만큼 기능이 곧 혜택처럼 느껴지지만 평가위원에게는 여전히 사양일 뿐입니다.
2. 기존 수행사. 몇 년 동안 사업을 맡다 보면 이번에 고객이 요청한 것과 다르더라도 고객이 "진짜로" 원하는 것을 안다고 생각하기 쉽습니다.
3. 자기 회사에 대해 쓰는 모든 사람. 어느 팀이나 자기 강점을 과대평가합니다. 사람이라면 당연한 일이니 고객의 시각은 짐작하지 말고 확인해야 합니다.

고객 니즈에서 출발한다

혜택은 우리가 생각하는 우리 제안의 좋은 점이 아니라 고객이 자기 문제를 해결해준다고 인정한 가치입니다. 그래서 Body of Knowledge는 이 주제를 글을 쓰기 훨씬 전인 영업과 사업 기회 관리 과정의 고객 이해에서 시작합니다.

사업 기회를 추진할 때 우리는 우리 역량이 고객 니즈에 맞는다고 가정합니다. Study Guide에서는 그 가정을 믿지 말고 확인하라고 조언합니다. 과정을 단순하게 정리하면 이렇습니다.

1. 쓰기 전에 니즈를 파악합니다. 고객을 만나 무엇을 고치거나 이루려 하는지 알아냅니다.
2. 우리 기능을 니즈에 대응시킵니다. 어떤 기능과 그 기능이 만드는 장점으로 각 니즈를 해결할 수 있는지 따져봅니다.
3. 고객과 아이디어를 검증합니다. 가능한 해법을 공유하고 고객이 어떤 것을 가치 있게 보는지 확인합니다.
4. 확인된 장점을 혜택으로 바꿉니다. 고객이 인정한 것은 제안서에 혜택으로 담습니다. 예를 들어 기능-혜택 표로 보여줄 수 있습니다.
5. 경쟁사와 비교합니다. 우리 혜택을 경쟁사가 제안할 법한 것과 나란히 놓고 어느 것이 차별화 요소인지 가립니다.

요구사항이 왜 들어갔는지 안다

놓치기 쉬운 점을 Body of Knowledge는 하나 더 짚습니다. 요구사항에 무엇이 적혀 있는지 아는 것으로는 부족하고 고객이 왜 그 요구사항을 넣었는지도 알아야 합니다.

제안요청서에 "실시간 모니터링"이 있다고 해봅시다. 그것은 What입니다. Why는 작년에 장애를 늦게 발견했기 때문일 수도, 운영자가 민원을 받고서야 문제를 알았기 때문일 수도, 성수기에 서비스가 두 번 멈췄기 때문일 수도 있습니다. 이유마다 혜택이 달라지는데 그중 이 고객이 사려는 혜택은 하나뿐입니다. 모니터링 기능은 어느 경우나 같지만 점수를 받는 문장은 다릅니다.

기능, 장점, 혜택

세 칸짜리 표를 쓰면 번역 과정이 눈에 보이고 아직 기능 단계에 머문 문장도 빠르게 잡아낼 수 있습니다. 문서 처리 솔루션을 예로 이 글을 위해 만든 표입니다.

첫 번째 칸이 내부의 언어라면 고객의 언어는 마지막 칸에 나옵니다. 초안의 문장이 첫 번째 칸에만 들어맞으면 아직 완성되지 않았습니다.

차별화 요소 찾기

기능을 혜택으로 바꾸면 일의 절반을 한 셈입니다. 나머지 절반은 어떤 혜택이 우리를 더 나은 선택으로 만드는지 찾는 일인데, 우리만 들여다봐서는 할 수 없고 비교해야 합니다.

고객의 자리에서, 정직하게 비교한다

차별화 요소를 찾으려면 고객 니즈 정보에 더해 경쟁사가 그 니즈에 어떻게 답할지에 관한 정보도 필요합니다. 캡처팀이나 영업팀이 모을 수도 외부 컨설턴트가 모을 수도 있습니다. 누가 모았든 꼼꼼히 분석하라는 것이 Body of Knowledge의 요구입니다. 쓸모 있는 경쟁 정보는 누가 입찰할지, 무엇을 얼마에 제안할지, 그리고 무엇보다 고객이 그들을 어떻게 보는지에 답합니다.

이어서 입찰자 비교 매트릭스로 우리를 포함한 주요 입찰자를 각 요구사항이 요구하는 것과 그 요구사항이 들어간 이유에 비추어 평가합니다. 이 도구가 쓸모 있으려면 불편한 규칙을 지켜야 합니다. 우리가 매기고 싶은 점수가 아니라 고객이 매길 점수를 적어야 합니다. 자기 점수를 후하게 주는 팀은 모든 칸에서 최고점을 받고 정작 보완해야 할 곳을 놓칩니다. 입찰자별 SWOT 분석은 경영진 교체, 법적 분쟁, 인수합병 소문처럼 매트릭스가 놓칠 수 있는 맥락을 더해줍니다. 경쟁사의 약점이 곧 우리의 기회이고 그들의 강점은 우리에게 위협이 됩니다. (두 도구는 5편 고객·경쟁사 인텔리전스에서 자세히 다뤘습니다.)

스위트 스폿

Study Guide는 차별화 요소를 고객 니즈, 경쟁사의 역량, 우리의 역량이 겹치는 영역으로 그립니다. 그중 차별화 요소가 있는 곳은 단 한 구역, 고객이 중요하게 여기는 것을 우리는 제공하고 다른 누구도 제공하지 못하는 곳이고 다른 조합은 온전한 차별화 요소가 되지 못합니다.

나머지 구역을 읽어두면 제안서를 계획할 때 쓸모가 있습니다. 아래 표는 이 개념을 적용하는 방법을 이 글을 위해 정리한 것입니다.

두 번째 줄은 좀 더 볼 만합니다. Body of Knowledge에 따르면 우리와 경쟁사에 같은 기능이 있더라도 그 기능을 우리만 줄 수 있는 혜택으로 감싸면 차별화 요소로 바꿀 수 있습니다. 두 입찰자 모두 헬프데스크를 운영할 수 있어도 이 고객의 시스템을 이미 아는 엔지니어로 헬프데스크를 채워 첫 통화에서 문제를 해결하는 곳은 한 곳뿐일 수 있습니다.

브랜드, 규모, 경험은 저절로 차별화 요소가 되지 않는다

여기서 가장 흔한 실수가 회사 이름을 믿는 일입니다. 우리 로고를 붙일 수 있는 회사는 우리뿐이지만 그렇다고 로고가 혜택이 되지는 않습니다. 인력 규모, 지사, 정해진 프로세스, 제품, 업력도 마찬가지입니다. 하나하나가 혜택으로 인정받기 전에 검증받아야 할 기능이며 차별화 요소는 그다음 이야기입니다.

수행 실적을 보면 올바른 방향을 알 수 있습니다. 유사 사업 목록은 주로 우리 주장을 뒷받침합니다. 그 혜택은 거기서 배운 지름길, 이제는 피해 갈 수 있는 리스크, 직접 만든 체크리스트 같은 것에 있습니다. 그 교훈 덕분에 이 고객의 요구사항을 더 빠르게, 더 잘, 더 안전하게, 더 적은 비용으로 수행할 수 있다고 설명하면 경험이 혜택으로 작동하기 시작합니다.

가치를 정량화하고 증명할 수 있게 한다

측정된 혜택은 형용사보다 힘이 있습니다. 시설 유지보수 입찰을 예로 이 글을 위해 만든 두 문장을 비교해보세요.

흔한 테마 문장인 "믿고 맡길 수 있는 회사"를 두고도 Body of Knowledge는 같은 이야기를 합니다. 이 문장은 리스크가 낮다는 뜻을 전하려 하지만 측정할 방법이 없으므로, 제대로 작동하게 하려면 구체적인 혜택을 밝히고 근거와 숫자를 붙여야 합니다. 예를 들어 실제로 내세울 것이 일정 준수인 입찰자라면 이렇게 쓸 수 있습니다(숫자는 설명을 위해 지어낸 것입니다).

"약속한 날짜에 개통하는 것을 믿으셔도 됩니다. 같은 유형의 이전 사업 18건이 모두 일정대로 개통했고, 그 과정에서 다듬어온 전환 절차서로 주말 중단 시간을 3분의 1 줄였습니다."

이 문장에는 구체적인 혜택, 그것을 뒷받침하는 근거, 고객이 확인할 수 있는 숫자가 모두 있습니다.

정량화를 정직하게 하려면 세 가지를 주의해야 합니다.

• 증명할 수 있는 숫자만 씁니다. 뒷받침하지 못하는 숫자는 없느니만 못합니다. 평가위원이 주장 하나를 의심하는 순간 다른 주장도 모두 깎여서 읽힙니다.
• 그 숫자로 평가받을 각오를 합니다. 결과로 맺을 계약이 성과 기반이라면 정량화한 혜택이 그대로 우리를 측정하는 지표가 될 수 있습니다. 근거와 함께 전반적으로 정량화하되 수행 단계에서 지킬 수 있는지 확인하세요.
• 측정할 수 없으면 연결합니다. 모든 혜택에 숫자가 있는 것은 아닙니다. 그럴 때는 고객의 미션이나 공표된 목표에 연결하고 고객이 쓰는 표현으로 설명하세요. 고객의 언어를 쓰기만 해도 니즈를 이해하고 있다는 신호가 됩니다.

So what? 테스트를 한다

이 주제에서 가장 단순한 도구가 가장 쓸모 있습니다. 혜택이라고 쓴 문장 뒤에 고객처럼 "그래서요?(So what?)"라고 물어보세요. 기능 문장은 답하지 못하지만 혜택 문장은 해결되는 고객의 문제나 얻게 되는 결과를 말하며 답합니다.

고객이 관심을 가질 지점에 닿을 때까지 사슬처럼 이어서 물어보세요. 이 글을 위해 만든 예입니다.

1. "우리 플랫폼에는 120개의 기본 커넥터가 있습니다." 그래서요?
2. "귀 기관의 기존 시스템을 별도 개발 없이 연결할 수 있습니다." 그래서요?
3. "연계가 몇 달이 아니라 몇 주 만에 끝나, 회계연도가 끝나기 전에 새 서비스를 열 수 있습니다."

첫 줄은 기능입니다. 세 번째 줄은 이 고객이 돈을 낼 만한 혜택이며 그 일정을 따라올 경쟁사가 없다면 차별화 요소입니다.

누가 테스트하느냐가 중요합니다. 기능을 설계한 사람은 그 기능이 혜택으로 읽히는지 판단하기에 가장 불리합니다. 그래서 Body of Knowledge는 기술 세부는 모르지만 고객의 관점을 이해하는 사람에게 맡기라고 권합니다. 혜택이 너무 분명해서 고객이 우리 기능의 가치를 스스로 추론할 필요가 없게 만드는 것이 목표입니다.

다음 제안서를 위한 체크리스트

1. 고객 니즈부터 적습니다. 핵심 요구사항마다 제안요청서에 들어간 이유까지 포함합니다.
2. 기능 / 장점 / 혜택 표를 만듭니다. 주요 솔루션 요소마다 채웁니다.
3. 예상 혜택을 고객과 검증합니다. 가능하면 공고 전에 하고 고객이 인정한 것을 남깁니다.
4. 모든 입찰자를 고객의 시각으로 평가합니다. 비교 매트릭스에서 우리의 약점도 정직하게 적습니다.
5. 스위트 스폿을 표시합니다. 우리는 충족하고 경쟁사는 못 하는 니즈를 앞세웁니다.
6. 브랜드, 규모, 경험 주장을 의심합니다. 각각을 이 고객에게 무엇이 바뀌는지로 다시 씁니다.
7. 증명할 수 있는 곳은 정량화합니다. 나머지는 고객의 미션에 고객의 언어로 연결합니다.
8. So what? 테스트를 합니다. 기술보다 고객을 더 잘 아는 검토자와 함께합니다.

Contrl에서는

이번 편의 핵심을 줄이면, 기능은 고객이 인정하는 혜택으로, 그리고 우리만 해낼 수 있는 이유로 바뀌어야 비로소 점수가 됩니다. Contrl에서는 이 번역이 슬라이드를 쓰기 전에 일어납니다. 전략 인터뷰에서 고객, 우리 회사, 경쟁사에 대해 이야기하면 제안되는 윈 테마마다 고객 니즈, 경쟁사 대비 우리의 강점, 고객이 얻는 효과가 적혀 나옵니다. 그래서 우리가 꺼낸 기능은 "그래서요?"와 "왜 우리인가?"에 대한 답으로 나타나야 합니다. 고른 테마는 섹션마다 핵심 문장으로 압축되어 각 페이지 맨 앞에 기능 목록이 아니라 혜택이 서게 됩니다.

다음 편 예고

혜택과 차별화 요소를 내세우면 평가위원은 모두 같은 것을 묻습니다. 그게 사실인지 어떻게 알죠? 10편은 증거 포인트(Proof Points)를 다룹니다. 어떤 증거가 우리 주장을 믿게 만드는지, 그리고 제안서의 어디에 두어야 하는지 살펴봅니다.

이 글은 APMP Body of Knowledge를 요약한 APMP Foundation Study Guide 4.2판(© 2025 APMP)을 바탕으로 한 독립적인 학습용 해설입니다. 원문을 풀어 쓰고 해설한 것으로, APMP의 승인을 받은 글이 아닙니다. 모니터링과 헬프데스크 문장, 문서 처리 솔루션 표, 네 구역 표, 지원 시간 비교, 일정 준수 문장, 커넥터 예시와 그 안의 모든 숫자는 이 글을 위해 쓴 것입니다. 공식 원문과 자격 정보는 apmp.org에서 확인하세요.