기능 요청 거절 템플릿(Feature Request Rejection Template)

"아니오"라고 말하는 능력은 가장 과소평가된 PM 역량이다

Intercom의 공동창업자 Des Traynor가 2014년에 "Product Strategy Means Saying No"를 썼을 때, 그 글은 그 해 가장 많이 공유된 제품 에세이 중 하나가 됐습니다. 요지는 단순했습니다. 모든 기능 요청에 yes라고 말한다면, 당신에게 제품 전략은 없고 단지 가장 시끄러운 고객이 써준 할 일 목록만 있을 뿐이라는 것입니다.

그는 맞았습니다. 하지만 no라고 말해야 한다는 걸 아는 것과, 어떻게 no라고 말해야 하는지를 아는 것은 전혀 다른 기술입니다. 대부분의 PM은 후자에 서툽니다.

나쁜 거절이 만드는 비용

밤잠을 설치게 할 만한 숫자가 하나 있습니다. Zendesk의 2023 Customer Experience Trends Report에 따르면 고객의 61%는 단 한 번의 나쁜 경험만으로도 경쟁사로 갈아탈 수 있습니다. 기능 요청을 서툴게 거절하는 일은 바로 그런 종류의 경험입니다. 특히 시간을 들여 진지한 요청을 보낸 고객에게는 더 그렇습니다.

전형적인 거절은 이렇게 들립니다. "피드백 감사합니다! 백로그에 추가해둘게요." 누구나 압니다. 그 백로그는 기능 요청이 죽으러 가는 곳이라는 걸요. 고객은 무시당했다고 느끼고, 요청을 전달한 세일즈 담당자는 지원받지 못한다고 느낍니다. 신뢰가 닳아갑니다.

내부에서도 피해는 다르지만 마찬가지로 큽니다. PM이 왜 no라고 말하는지 설명하지 못하면, 세일즈는 PM을 우회해 엔지니어링에 직접 요구하기 시작합니다. Customer success는 줄 수 없는 기능을 약속합니다. 조직은 제품팀의 판단에 대한 신뢰를 잃습니다. 반대로 좋은 거절은 오히려 신뢰를 만듭니다. 상대의 underlying need를 이해했고, 충분히 진지하게 고민했고, 우선순위화에 일관된 이유가 있음을 보여주기 때문입니다. Stripe는 이런 점으로 유명합니다. 그들의 PM은 기능 요청에 대해 현재 우선순위와 전략 방향 안에서 그 요청이 어디에 맞는지, 혹은 맞지 않는지를 상세히 설명하며 응답합니다.

이 프롬프트가 돕는 방식

이 프롬프트는 고객, 세일즈팀, 임원, 파트너 등 상황별로 전문적인 거절 템플릿을 생성합니다. 각 템플릿은 요청을 인정하고, 이유를 설명하고, 가능하면 대체 경로를 제시합니다. 또한 가장 흔히 받게 되는 objection에 대한 대응 문구도 포함합니다.

목표는 상대를 shut down시키는 것이 아닙니다. 관계를 유지하고 제품 판단에 대한 신뢰를 강화하는 방식으로 no라고 말하는 것입니다.

언제 꺼내 쓸까

• 핵심 고객이 로드맵과 맞지 않는 기능을 요청했고, 관계를 해치지 않고 응답해야 할 때
• 세일즈가 일회성 커스터마이징을 강하게 밀고 있고, 왜 나쁜 precedent인지 설명해야 할 때
• 분기 로드맵 리뷰에서 무엇이 빠지는지와 이유를 커뮤니케이션해야 할 때
• 임원이 전략적으로 맞지 않는 pet feature 아이디어를 밀고 있고, 외교적인 응답이 필요할 때
• 팀 전체에서 일관되고 전문적인 거절 템플릿을 정착시키고 싶을 때

좋은 결과물의 모습

좋은 거절은 특정 기능만이 아니라 그 뒤의 underlying need를 인정하고, 우선순위 로직을 투명하게 설명하며, 가능하다면 대안이나 workaround를 제시하고, 미래에 다시 검토할 여지를 남깁니다. 절대 dismissive하게 느껴지면 안 됩니다. 최고의 거절은 상대가 no를 듣고도 "설명을 진지하게 해줘서 고맙다"고 느끼게 만듭니다. 그렇게 되면 잘한 것입니다.

참고 자료

• Customer Experience Trends Report 2023 — Zendesk
• Product Strategy Means Saying No — Intercom (Des Traynor)
• How Stripe Says No — The Pragmatic Engineer