[월간 글쓰기] 한 달에 한 편, 글을 씁니다. 기획자로 커리어를 밟아가며 느낀 점들을 가감없이 풀고, 기록합니다. 작성일 : 2022. 3. 4 Title 19. PO는 이래야 합니다. 제 팀원은 이랬으면 좋겠어요. 서비스 기획팀장으로 agile 조직을 만들기 위해 PO를 뽑았는데, 뽑고 보니 조금씩 아쉬운 점이 있었다. 제 못난 것이나 잘 파악하고 고칠 것이지. 남 못하는 건 귀신같이 잘 본다. PO로서 이런 역량들을 키워나갔으면 좋겠다고 작성한 글이 있어서 공유한다. 현 회사의 상황을 고려해 쓴 거라 주관적인 요소가 있겠다. 그래도 다들 이렇게 생각하지 않을까..? - 기획팀 개개인은 PO다 기획팀 구성원은 팀장/팀원 할 것 없이 모두가 PO입니다. PO는 Product Owner로서 맡은 프로덕트에 대한 책임을 가지고 있습니다. 회사에서 실질적으로 모든 책임을 PO에게 묻지는 않을 것입니다. 혹여 책임을 묻는다 한들, 그것 또한 PO가 감당해야 할 것일 수도 있습니다. 하지만 가장 피해야 할 것은 전사적으로 PO가 무슨 일을 하는지 인지하지 못하고, 지원 부서 성격으로 인지하거나 아무것도 기대하지 않게 되는 것입니다. 전사 구성원들은 PO에게 의지하고 따르는 그림이 만들어져야 합니다. PO가 모든 것(사업, 운영, 기술, 고객)을 리드하고 있다는 인식을 심어줘야 합니다. 그러기 위해서는 행동과 결과로 보여줘야 합니다. 내 일이 아님에도 내 일처럼 생각해 도와주고, 해결 방안을 제시해 줄 때 구성원들은 믿음을 가지고 PO에게 의지할 것입니다. PO는 퍼실리테이터형 리더입니다. 그러기 위해서는 4가지 역량이 필요합니다. 그 역량은 프로덕트 오너쉽, 문제해결능력, 논리력, 커뮤니케이션 능력입니다. PO가 역량을 기반으로 훌륭한 결과를 만들어 낼 때 권한이 따라옵니다. 그 권한은 누가 지정해 준 것이 아닙니다. PO의 말에 힘이 실리는 것입니다. 모두가 PO의 말에 귀 기울이고, 응답할 것입니다. - 프로덕트 오너쉽 '프로덕트(서비스/사업/기능)는 내가 이끌어 간다'라는 태도가 전제되어야 합니다. 협업이 무엇보다 중요한 조직 안에서 PO는 협업을 먼저 이끌어내고, 프로젝트를 주도할 수 있어야 합니다. '저 팀에서 해줘야 하는 일을 안 해줘서 내가 일을 진행하지 못해'라는 생각은 오너쉽에 위배됩니다. 오너쉽은 해당 팀이 왜 일을 못하고 있는지 살펴보고, 그 원인을 직접 나서서 해결해 주거나 적어도 제안할 수 있어야 합니다. 본인의 문제와 직결된 것이라면 더더욱 해결에 힘써야 합니다. 당면한 문제를 어떻게든 해결해 나갈 수 있어야 합니다. 기본적으로는 회사 내 모든 구성원이 프로덕트 오너쉽을 가져야 합니다. PO에게 요구하는 프로덕트 오너쉽은 각 직무 사람들의 오너쉽 범위의 중간에 있습니다. PO의 오너쉽은 CEO와 구성원의 수직적 오너쉽, 직군과 직군 간 수평적 오너쉽을 링크(연결) 하는 오너쉽입니다. - 문제해결능력 문제를 함께 들여다본다고 달라지는 게 없다면 사람들은 PO에게 아무것도 기대하지 않을 것입니다. 문제해결능력은 크게 문제를 찾는 능력(Definition)과 문제를 해결하는 능력(Resolution)으로 나뉩니다. 문제를 찾는 능력은 Deep dive가 필요합니다. 현상이 어디서 기인했는지를 파악할 수 있어야 합니다. Deep dive는 5whys 기술을 통해 진행합니다. 문제를 짚어냈다면, 그 문제가 진짜 문제인지 뒷받침하는 근거를 수집해야 합니다. 근거는 데이터에 기반해야 하고, 확증 편향에 따라 맞춰서는 안됩니다. 문제를 해결하는 능력은 '어떻게 하면 당면한 문제를 해결할 수 있을까?'의 사고방식에서 나옵니다. 누구도 생각하지 못한 뛰어난 아이디어를 내기는 어렵습니다. 하지만 당면한 문제를 하나씩 해결해나가는 건 대부분 할 수 있고, PO라면 반드시 할 수 있어야 합니다. '어떻게 하면'을 다른 팀에게도 물을 수 있어야 합니다. 나 혼자만의 생각으로 답이 나오지 않는다면 다른 사람들의 리소스를 적극적으로 이용할 수 있어야 합니다. 답을 알 것 같은 사람에게 직접 가서 물어봐야 하고, 문답을 반복하여 도움이 될 만한 답을 이끌어내야 합니다. 여기엔 퍼실리테이팅 기술이 필요합니다. 문제를 찾을 때도, 해결할 때도 다른 사람과 함께 할 경우 경청 능력이 가장 중요합니다. 경청할 때는 상대방이 이야기한 바를 적확하게 이해할 수 있어야 합니다. 여기서 이해란 구조화된 요약본을 뜻합니다. 말에서 섞여 나오는 각종 수사와 추상적인 단어를 걷어내고, 명확한 인과 관계를 도출해 내야 합니다. A→B이고, B→C이니, C→D라는 것을 듣는 즉시 파악하고, 상대방에게 이해한 바가 맞는지 그림을 그려가며 재확인해야 합니다. 아니라고 한다면 어느 인과 관계가 틀렸는지, 어떤 부분을 보완해야 하는지 듣고 구조화된 요약본을 새로 작성해야 합니다. 이해하지 못할 땐 이해하지 못했다고 솔직하게 얘기하고, 다시 설명을 들어야 합니다. 최종적으로 서로가 같은 페이지에 있어야 합니다. - 논리력 협업은 설득의 연속입니다. 모든 구성원은 저마다 다른 논리 체계를 가지고 있고, 자신만의 관점으로 프로덕트를 인식합니다. 그렇기 때문에, 문제를 정의하고 해결책을 고안하는 과정에서 확증 편향이 발생할 수 있습니다. 내 관점에서는 철저히 논리적이더라도 다른 이의 관점에선 논리적이지 않을 수 있습니다. 논리가 빈약하면 설득이 어렵습니다. 일에 관해서만큼은 인간은 논리적 동물입니다. 처음부터 끝까지 논리적으로 얘기가 된다면 협업은 쉬워집니다. 누구나 이해하기 쉽고, 명확하고, 간결하게 생각을 풀어내야 합니다. 생각을 풀어낼 땐 문장화가 필요하고, 문장화를 할 땐 구조화하여 작성해야 합니다. 책을 생각하면 쉽습니다. 책은 제목(말하고자 하는 바, 목적)이 있습니다. 제목을 설명하기 위해 여러 목차로 나눴으니, 이것이 첫 번째 구조화입니다. 목차를 여러 개의 소주제로 구조화하고, 소주제 안에서는 문단으로, 문단 안에서는 문장으로 구조화합니다. 따라서 구조화의 최소 단위는 문장입니다. PO의 논리력은 '한 문장'에서 나옵니다. 구조화 작업이 끝났다면, MECE 기술을 통해 논리적 결함이 없는지 검수해야 합니다. 3가지 현상을 통해 하나의 문제를 도출했다면, 하나의 문제 안에 3가지 현상이 포함되는지, 다른 현상은 없는지를 검토해야 합니다. A→B, B←A를 모두 만족하는지 양쪽 관점을 들여다보고 논리적 결함을 보완해야 합니다. - 커뮤니케이션능력 커뮤니케이션의 핵심은 '정보의 대칭성'입니다. 그러기 위해서는 한쪽에서 발생한 이슈가 다른 쪽에 도달해야 하고, 발생한 측에서는 도달한 측이 내용을 전달받았다는 답을 얻어야 합니다. 쉽게 설명하면 A에게 문제가 발생한 경우 그 문제와 연루된 B가 알아야 하고, A는 B가 그 문제를 공유 받았다는 사실을 공유 받아야 합니다. 커뮤니케이션 코스트를 줄이기 위해 협업 툴을 사용합니다. 협업 툴은 모두에게 오픈되어 있어 투명하고 공유가 쉽습니다. 서로가 무슨 생각을 하고 있는지 오픈 커뮤니케이션을 해야 하고, 하나의 의사결정/제안/진행 상황이 발생할 때마다 공유되어야 합니다. 말하지 않고도 서로가 무슨 일을 어디까지 했는지 알 수 있어야 합니다. 정보의 비대칭이 발생한 경우, 업무는 진행되지 않거나 시간을 허비하게 됩니다. PO는 여러 직군과 커뮤니케이션을 하기 때문에 정보를 독점하고 있습니다. 따라서 정보의 비대칭이 발생할 위험이 가장 큽니다. 자칫 잘못하면 한쪽의 메시지를 다른 쪽에 전달했는지 안 했는지도 모르는 상태가 됩니다. 이는 협업에 큰 위협으로 다가오기 때문에 각별히 신경 써서 메시지를 공유해야 합니다. PO는 공유요정입니다.