Product(제품)이란

Product Manager은 말 그대로 Product(제품)을 관리하는 사람을 의미한다.

그러면 여기에서 Product란 무엇인지 한번 짚어보고자 한다.

 

마티 케이건(Marty Cagan)의 저서 인스파이어드(Inspired)에서는 제품에 대한 정의를 아래와 같이 한다.

 

제품은 당연히 기능(Functionality)을 포함한다.

그리고 이 기능을 가능하게 하는 기술 또한 포함된다.

이 기능을 표현하는 사용자 경험 디자인도 포함된다.

그리고 이 기능을 통해 우리가 어떻게 돈을 벌지도 포함된다.

제품은 사용자와 고객의 마음을 사로잡고 획득하는 방안도 포함된다.

그리고 제품의 가치를 전달하기 위해 필요한 오프라인 경험도 포함한다.

(예를 들어, 당신의 제품이 전자상거래 사이트인 경우 상품의 주문과 반송을 처리하는 경험을 모두 포함한다. 일반적으로 전자상거래 비즈니스에서 제품이란, 판매되는 물품을 제외한 모든 경험이 포함된다.)

 

마찬가지로 미디어 회사는 콘텐츠 자체를 제외한 모든 경험을 제품이라고 한다. 요점은 매우 폭넓고 총체적인 제품의 정의를 사용하라는 것이다. 당신이 할 일은 그저 기능들을 구현하는 것이 아니다.

 

*추가/나의생각/

이 문장을 보고 목표를 기능에만 매몰되어 챙기지 않았었는지 나를 반성하게 되었다.

매 프로젝트를 진행할 때 조금 더 효율적이거나 최신 기술을 적용해보는것을 선호하는데, 지난 프로젝트를 진행하면서 기존의 워터폴 방식이 아닌 애자일 방식에 대해 의견을 꺼냈다. 많은 사람들이 수직하강방식인 워터폴보다는 MVP부터 시작하여 계속해서 발전해나가는 시스템이라는 것에 호감을 표했고, 그 방식을 채택하여 스프린트 형식으로 일정을 짜고, 스크럼을 매일 짧게 진행하며 프로젝트를 진행해갔다. 하지만 이 방식이 유효하지 않다는건 프로젝트의 중반쯤 왔을때였다.

 

애자일 방식을 채택해보았으나 조직 전체가 애자일에 대한 구체적 연구없이 착수했으며 그보다 고객과 애자일 초보인 우리들은 기존의 방식에서 쉽게 벗어나지 못해 이러한 프로젝트는 워터폴 방식이 옳다는 결론을 도출하고야 말았다. 워터폴 프로세스를 적용하고 있었음에도 스스로 애자일 프로세스를 적용하고 있다고 착각했던 것이다.

 

개발자들은 기존의 고객과 기획자들이 정의하는 문서가 나올때까지 To-be에는 관심이 없었으며, 오로지 As-is를 분석하는데에만 몰두하는 현상이 계속되었다. 그러다보니 오픈이 다가오는 막바지에 도달하여도 계속해서 기획자의 문서를 이해하지못해 다른 프로젝트를 수행하고 있는 기획자에게 문서를 다시 물어보는 상황이 반복된 것이다.

문제를 이해하고 해결하는것이 아니라 기능을 이해하고 구현하는 것에만 매몰되었던 것이다.

 

애자일이나 린 방식이 나쁘다고 생각하지는 않는다. 구체적으로 고객과 맞닿아있는 프로젝트에서는 가능할 것으로 생각한다. 하지만 고객이 운영을 하는 이해관계자이며, 이해관계자가 원하는 것이 명확한 상태에서는 애자일은 좀 어렵다는게 본인 생각이다.

 

제품 얘기를 하다가 방법론으로 빠져버렸는데, 앞으로 계속해서 애자일과 린 방법에 대해 연구하고 수행할 수 있는 날이 올거라고 믿는다.