문제를 공유하고, 솔루션을 찾아나가기 위한 협업 방법

---

1. Stakeholder(Sales, Marketing, C/S, 운영부서) 와 협업

- PO는 협의체의 리더가 되어야 됨

- 데이터 기반으로 논의하고 의사결정

- PO는 Stakeholder들에게 Expected Result를 수치로 받아야 합니다.

- 공통의 Success metric / KPI를 수립할 수 있어야 한다.

- 사용자 리서치의 적극적인 참여를 하게 하는 것도 Stakeholder들과 협업을 더 잘하게 할수 있는 방법 입니다.

On-Site Marketing

마케팅과 PO과 협업 할수 있는 대표적인 분야는 On-Site Marketing이 있습니다.

그림처럼, 전반적인 Product Funnel에 대해서 On-Site Marketing은 영향력을 행사할수 있습니다.

 

 

2. Makers(개발자, 디자이너, UX, BA)

- 비즈니스/고객의 Pain Point를 공유하고 같이 솔루션 찾기

- 공통의 Success Metrix / KPI / OKR   ->   UT / Reserch / VOC / 앱 리뷰 등 고객의 니즈를 파악하고, 고객에 대한 관심을 유도하면 좋을거 같습니다. 내가 개발 하고있는 기대효과를 수치화 하여, 자연스럽게 OKR로 연결하면 좋을거 같습니다.

- 직원들에게 자사 제품의 쿠폰/포인트를 주어, 자사 제품을 사용해 볼수 있는 기회를 주어도 좋습니다. 따라서, 직원들이 고객에 입장을 이해하게 됩니다.

- 디자이너들에게는 Engineering 관점에서의 Product Design 이라는 공감대 형성이 중요 합니다. 디자이너 마다 서로 다른 컬러, 폰트 사이즈를 사용한다고 하면, 일관성(사용자 경험)에 있어서 문제가 생길수 밖에 없습니다. 따라서, 일관성이나 컬러 스킴 등을 정의 하는 디자인 시스템을 갖추어서 Product Design을 구현할수 있으면 좋겠습니다.

 

 

3. PO와 협업시 개발자들이 부담스러워 하는 것

- Estimation(견적)

마케팅/세일즈는 Release 일정이 중요합니다. 그리고 Estimation이 없다면, 우선순위 수립이 불가능 합니다. Story, AC를 명확하게 하여 Estimation을 하고, 스크럼을 통해서 Estimation을 정교화 해나가고, 릴리즈 일정에 대해서도 튜닝해 나가는 과정을 같이 가져갈수 있습니다.

 

- Incident Review(장애 보고)

개발자들을 비난하려는 것이 아니라, 개발자가 실수를 하게 만드는 근본 원인을 찾아서 해결하므로써, 개발자의 실수를 방지하는 것을 목적으로 하고 있습니다. 동일한 문제 재발을 막는 것 입니다. Incident Review의 목적은 결국, 장애를 줄여, Incident Review를 없애는 것 입니다.

- Incident Review는 손실을 정량화 해야 합니다.

- Incident Review는 5Why 기법을 이용한 심층 원인 분석도 해야 합니다.

 

 

4. 5Why

"왜?" 를 5번 되풀이하고, 답을 질문으로 되풀이 하면서, 근본 원인을 알아내는 방법 입니다. 

 

- 예시(장애 현상 : 기계가 멈췄다.)

1. 왜 기계가 멈춰 섰지?            -> 과중 부하가 걸려 퓨즈가 끊어졌기 때문이다.

2. 왜 과중부하가 발생 했지?    -> 베어링 부분이 너무 뻑뻑했기 때문이다.

3. 왜 뻑뻑해졌지?                       -> 윤활 펌프가 제대로 작동하지 못했기 때문이다.

4. 왜 충분히 작동하지 못했지? -> 펌프의 축이 닳아서 덜컹 거리기 때문이다.

5. 왜 닳았지?                                -> 여과기가 달려있지 않아 가루가 들어갔기 때문이다.

(출처 : 도요타 생산방식 - 오노 다이이치 지음)