build-buy-partner decision matrix 설계하기(Design a build-buy-partner decision matrix)

Core vs. context: build-buy-partner를 실제로 가르는 질문

Build-buy-partner 논쟁은 비용보다, 이 capability가 core인지 context인지에 의해 더 자주 결정됩니다. Geoffrey Moore의 구분을 빌리면, core는 반드시 소유해야 할 차별화이고, context는 필요하지만 차별화되지는 않는 영역입니다. Marty Cagan의 product strategy 글은 context capability를 사내에서 직접 만드는 팀이 core capability에 써야 할 엔지니어링 집중력을 잃는다고 지적합니다. Reforge의 product strategy stack도 이를 자원 배분 문제로 봅니다. 무엇을 category-leader 수준으로 직접 키울 것이고, 무엇을 외부에서 소비할 것인가의 선택입니다.

이 프롬프트의 작동 방식

이 프롬프트는 명시적인 weight가 붙은 6개 기준 scorecard를 만들고, strategic fit과 time-to-market에 기반한 네 가지 default decision rule을 적용해 팀이 매번 프레임워크 자체를 재논쟁하지 않게 합니다. Second-order effect 단계, 즉 talent, customer perception, competitive signal은 cost-benefit 분석이 반복적으로 놓치는 항목을 끌어냅니다.

언제 사용할까

• 큰 capability gap이 전략적 bet을 막고 있을 때
• 당신의 영역에 있는 스타트업이 적정 가격에 인수 가능할 때
• incumbent가 출시를 빠르게 만들 파트너십을 제안하고 있을 때
• 엔지니어링 capacity가 꽉 찼고 리더십이 대안을 묻고 있을 때
• 이전 build-buy-partner 결정이 실패했고 팀이 재사용 가능한 틀을 원할 때

흔한 함정

• 비용부터 논쟁하는 것. 비용은 core/context 판단 이후의 문제입니다. 싸게 만들 수 있는 context도 core를 굶깁니다.
• Buy의 integration cost를 과소평가하는 것. 인수는 보통 purchase price보다 integration time에서 2-3배 더 많은 비용이 듭니다. Purchase price가 아니라 18개월 TCO를 봐야 합니다.
• Core를 파트너에게 맡기는 것. 핵심 차별화 capability를 파트너가 쥐고 있으면 사실상 hostage 상황입니다. Differentiator는 파트너십으로 두지 마세요.

참고 자료

• Product Strategy Overview — Silicon Valley Product Group
• The Product Strategy Stack — Reforge
• The Product Manager — Silicon Valley Product Group
• Transformed — Silicon Valley Product Group