기능 거절 응답 작성하기(Write a feature rejection response)

관계를 지키는 거절문

Dismissive하게 들리는 기능 거절은 미래의 signal을 잃게 만듭니다. 고객은 다음 아이디어를 더 이상 보내지 않게 됩니다. Intercom의 고객 커뮤니케이션 글과 First Round Review의 제품 커뮤니케이션 글은 모두 explicit revisit trigger의 중요성을 강조합니다. 고객은 자신의 요청이 들렸고, 영구 기각이 아니라 조건부 보류라는 신호를 받아야 합니다.

이 프롬프트의 작동 방식

이 프롬프트는 거절문을 여섯 개 섹션으로 나누고, 과한 사과 금지, priority 핑계 금지, vague future 약속 금지 같은 톤 규칙을 세웁니다. 특히 "가장 dismissive하게 들릴 문장"을 찾아 다시 쓰게 하는 부분이 공감 체크 역할을 합니다. 대부분의 나쁜 거절문은 한 문장이 전체 톤을 망칩니다.

언제 사용할까

• 주요 고객이 scope 밖 기능을 요청했을 때
• 시니어 이해관계자가 기능을 밀어붙이고 있어 정중히 되밀어야 할 때
• CS 팀이 반복 요청에 대한 rejection template를 원할 때
• 새 PM이 No를 잘 말하는 법을 익히는 중일 때
• 로드맵 커뮤니케이션에서 명시적인 non-commitment가 필요할 때

흔한 함정

• Priority 탓으로 돌리는 것. "우선순위가 아닙니다"는 곧 "당신은 우선순위가 아닙니다"처럼 들립니다. Strategy fit으로 설명하세요.
• Revisit trigger가 없는 것. Trigger가 없으면 고객은 영구 기각으로 받아들입니다. 조건부 재검토 신호를 주세요.
• 과도하게 사과하는 것. 지나친 사과는 자신감을 깎습니다. 직접적이되 친절하게 말하세요.

참고 자료

• Intercom Blog — Intercom
• First Round Review — First Round
• Radical Candor — Kim Scott
• Kim Scott — Kim Malone Scott