"우리가 하지 않을 일" 문서 설계하기(Design a "what we are NOT doing" document)

No라고 말하는 것이 산출물이다

대부분의 제품 리더는 자신이 무엇을 하는지는 설명할 수 있습니다. 그러나 무엇을 하지 않을지와 그 이유를 명확히 설명할 수 있는 사람은 드뭅니다. 이 비대칭 때문에 로드맵은 서서히 부풀어 오릅니다. 새 요청이 "비어 있는 공간"을 기준으로 평가되지, 유지 관리되는 deliberate cut 목록을 기준으로 평가되지 않기 때문입니다. Marty Cagan의 "most important thing"은 집중이 가장 희소한 제품 자원이라고 말하고, Paul Graham의 doing great work 글은 "하지 않을 일" 목록을 유지하는 일이 종종 무엇을 할지 고르는 것보다 더 어렵다고 말합니다. 나중에 다시 참조할 수 있도록, 명시적인 추론을 남겨야 하기 때문입니다.

이 프롬프트의 작동 방식

이 프롬프트는 모든 "not doing" entry에 대해 요청의 steelman, 네 가지 거절 사유 중 하나, 명시적인 revisit trigger를 반드시 포함하게 만듭니다. Revisit trigger는 이 문서를 무덤이 아니라 살아 있는 artifact로 바꿉니다. 특정 metric threshold가 발동하면 항목이 다시 들어오고, 아니면 계속 빠져 있는 식입니다.

언제 사용할까

• 로드맵이 planning cycle 사이사이에 계속 새 항목을 흡수할 때
• 반복되는 scope 논쟁이 매 exec sync마다 30분 이상을 잡아먹을 때
• 새 제품 리더로 들어와서 내가 잘라낸 항목을 문서화하고 싶을 때
• QBR를 앞두고 "왜 X는 안 하나요" 질문을 선제적으로 막고 싶을 때
• 팀이 컷이 자의적이라고 느끼며 신뢰를 잃고 있을 때

흔한 함정

• 요청의 steelman이 없는 것. Entry가 dismissive하게 읽히면, 요청한 사람은 다시 같은 주장을 꺼내고 논쟁은 반복됩니다.
• Revisit trigger가 없는 것. Trigger가 없으면 "하지 않음"이 영구 결정처럼 느껴집니다. 그러면 사람들은 문서를 우회하려고 듭니다.
• Entry마다 owner가 없는 것. 주인이 없는 entry는 금방 낡습니다. 누군가는 분기마다 trigger metric을 확인해야 합니다.

참고 자료

• The Most Important Thing — Silicon Valley Product Group
• Product Strategy Overview — Silicon Valley Product Group
• How to Do Great Work — Paul Graham
• The Product Strategy Stack — Reforge