PM은 프로덕트에 대해 기획, 개발 과정, 디자인, 등 모든 요소들에 대해 알고 이해하고 있어야한다. "자신이 이해하지 못하는 것을 관리하려는 시도는 어리석음의 극치다." 결과적으로 좋은 제품을 만들려면 모든 것을 알아야한다. 기업이 제품을 생산하여 사고자하는 고객들이 구매를 통해 기업의 이익이 남는 전체적인 구성을 필두로 고객이 이 제품을 왜 사는지 어떨때 제품을 사는지 무엇을 사는지 고객에게 어떤 가치인지에 대해 끊임없이 물음표를 던지며 연구해야한다. 제품의 심리를 알아야 좋은 제품을 만들 수 있다.
제품의 심리는 무엇인가? 이는 마케팅으로 작용된다. PM은 제품의 가치를 알아보면서 고객들이 왜 제품을 사야하는지 제품이 고객들에게 어떤 가치로, 어떤 심적 또는 사회적 작용이 어떻게 작용되길래 고객이 제품을 사는지에 대해 분석해야하고 이를 정성적 분석과 정량적 분석으로 알아볼 수 있는데
정성적 분석은 사람을 통계의 대상으로만 분석이 하는 것이 아닌 고객이 특정 행동을 하는 이유에 대한 물음이며, 어떤 데이터로도 인간의 본연 행동을 담아낼수 없다는 분석이다. 고객에 대한 또는 제품에 대한 가치의 깊은 고찰을 통해 분석을 할 수 있다.
정량적 분석은 다양한 분석 도구들을 통해 고객의 행동 양상들을 숫자로 정리하여 분석하는 방식이다. 고객이 실제로 '무엇'을 하는 그 행동에 초점이 맞춰져있고 그 행동에 대한 데이터를 수집해 정리하고 분석한다고 보면된다.
옳고 그름은 없다. 각 분석은 장단점이 있는데, 정량적 분석은 고객의 행동을 순수하게 데이터로만 추출하여 분석하여 보기 쉽고 가용하기 편하다는 장점이 있지만 그 포괄적인 분석을 하려면 그 만큼 많은 데이터들이 필요하다는 단점이 있다. 정성적 분석은 궁극적으로 고객이 생각하는 제품의 가치에 대한 분석이라 제품의 성공을 직접적으로 영향을 주는 분석일수있다.
하지만 정성적 분석은 고객이 사는 이유에 대한, 제품에 대한 본질적인 분석이다. 그렇기에 데이터와 분석 툴만 있으면 가능한 정량적 분석보다 어렵고 risk가 생길수도 있다. 제품의 가치에 대해 분석을 끊임없이 해야하기에 시도와 실패를 두려워하는 기업들은 정량적 분석을 요하는 경향이 있다.
단 한가지 중요한 점 제품이 성공하려면 여탸 다른 경쟁사 기업보다 '압도'적이어야 한다.
자 그럼 제품의 성공 오너십을 갖고 있는 PM은 무슨 분석을 해야할까? 데이터 수집과 분석이 용이한 정량적 분석? 제품이 성공하려면 정량적 분석도 좋지만, 정성적 분석을 통해 시장 분석과, 마케팅, 고객의 제품가치 트렌드 등 심리적 분석이 더 큰 정성적 분석을 통해 고객의 심리를 정확히 파고든 제품이 더 이상적이고 성공률이 높다고 본다.
또 제품의 가치와 성공을 연결짓는 전문성은 마케팅이다. 고객이 제품을 구매하게 만드는 행위 즉 마케팅은 제품의 기획, 개발부터 프로세스 출시 이후 운영 등 모든 과정과 깊게 연관되어 있다. 제품을 이해하고 시장 트렌드와 산업에 대한 이해를 바탕으로 도메인 지식을 쌓일 필요가 있고 어느 정도 전문성을 갖춰 전문가들과 얘기는 할 수 있어야 제품 관리자로서 충분한 역량이 될수있고, 스스로 제품에 오너십을 갖출수 있다고 본다.
PM에게 좋은 제품보단 성공, 또는 성장하는 제품이 더 와닿는다. 제품을 성장시키며 PM또한 성장할수 있기 때문이다. 성공, 또는 성장하는 제품을 만들려면 철저한 시장 트렌드 이해와 분석, 적어도 모든 것에 대해 일반인들보다 얕은 지식은 더 알고있어야 유리하다고 생각한다. 제품에 대한 지식과, 디자인, 또는 개발은 어떻게 진행되고 있는지, 프로젝트는 어떻게 관리할것인지에 대해 스스로 물음에 답할 수 있어야 한다.
PM에게 가장 중요한 것은 더 좋은 제품,결과물을 내기 위해 필요한 끊임없은 도전과 집착이다.
물론 PM이 개발자 영역과 디자인 영역 외 기업 경영, 법무 등 전문적인 지식을 더불어 모든 것을 알고 있을 필요는 없지만 내외부 자원, 기타 여건들을 모두 엮을 수있는 역량이 되어야한다. PM은 전문가들과 협업하는 직업이다. 그럼 각 구성원들의 전문가들과 어떻게 협업 할 것인가?
적어도 협업을 하기 위해서는 언급했던것처럼 각 분야에 어떻게 흐르는지에 대한 뒷배경 지식이 필요하다. 그래야 각 영역들의 여건들을 맞춰 각 분야 전문가들과 효과적인 의사소통을 할 수 있기 때문이다.
PM은 고객을 이해하는 것에 오너십을 갖는다. 그것이 PM의 역량중 하나의 전문성이고 자신감 마인드셋이기 때문이지 않을까 싶다. 이상적인 팀 미션팀을 만들기 위해서는 각 구성원들에게 오너십을 갖도록 해야한다. 제품에 대해 오너십을 주되, 인간은 책임감을 느끼면 자율성이 뺏기게 되기에 자율을 먼저 주어 책임감을 유발시켜야한다.
디자인의 첫번째 요건은 뭘까? 디자이너가 디자인하는 것에 대해 초점이 아닌 사용자 즉 고객에 초점이 맞춰져있어야한다. 디자인의 본질은 제품의 쓰임 그대로 한눈에 보여야한다는 것이다. 고객들이 본질을 파악하고 바로 사용할 수있게 디자인해야한다.
제품에 대한 가치를 같이 분석하고 디자이너에게 맥락을 설명해주어, 그 맥락이 고객에게 어떤 가치인지 알려주고, 디자인에 있어서 문제를 발견하고 해소하기위해 점진적으로 하나씩 여러개의 문제를 해결해나가야한다.
디자이너에게 제품에 대한 오너십을 알려주어 스스로 책임감을 가질수있도록 해야한다. 어떤 디자인이 사용자에게 친숙한지, 당신이 하는 일이 제품과 고객에게 어떤 가치를 의미하는지 설명해주어야한다.
디자이너가 바라보는 UX경험은 PM보다 더 전문적이다. 단순히 디자인이 맘에 안든다는 이유로 결과물에 터치해서는 안되고, 소통과 문제 개선을 통해 점점 더 나은 제품을 만들어 나가는 게 이상적이다.
PM은 알고있어야한다. 개발자들은 단순히 우리가 제품을 만들기 위해 요청하는 단순 제품 구현자가 아닌 제품을 현실화 하는 전문가이다. 각 필요한 프로세스 일정에 맞게 스스로 개발자들의 의견을 충분히 듣고 수용할 필요가 있다. 일정이 촉박하거나 기술적 한계에 도달하면 스스로 개발자들이 해결책을 찾을 수 있도록 해야한다.
제품의 문제 해결 방안에서도 PM이 먼저 찾고 해결책을 제시하는 것보단 개발자들이 스스로 문제를 분석하고 최적의 방법을 제안할 수 있도록 해야한다. 효율적인 개발 프로세스를 위해 개발자들에게 개발 우선순위를 정해주어야 하고, 기술적 의사결정은 기술의 전문가들이 해야한다.
모든 개발 검토를 '구현 가능성'을 높히는 방향으로 고려하되 된다/안된다가 아닌 최적의 방법과 현실적인 대안을 고려하는 역할을 개발자들이 맡아야한다. 그리고 단순히 주어진 제품 기능에 대한 기능 구현만 신경쓰는 것이 아닌 새로운 기술을 탐색하고 적용함으로 성장하는 제품이 될 수 있도록 해야한다.
제품에 있어 버그는 당연한 문제다. 해소되지않은 문제들은 고객들에게 있어 치명적이면서도 좋지못한 경험을 선사한다. 단순 기능만 구현하는 것이 아닌, PM이 강요를 하는것이 아닌, 개발자들이 자율적으로 버그를 찾고 관리하며 고객 경험에 있어 최적의 방법으로 항상 운영될 수 있도록 해결할 책임 있다.
제품의 기술적 리소스, 복잡한 시스템의 코드 등 이러한 전문적인 지식과 테크닉을 요하는 작업은 개발자만 접근할 수있기 성장하는 제품을 위해서라면 때문에 책임을 지고 지속적으로 개선할 수있도록 해야한다.
따라서 PM은 함께하는 각 구성원들에게 오너십을 주어 각 역할군에 맞춰 자신감과 팀 효능감, 자율과 책임을 주기 위해서는 PM이 스스로 이해할 수 있을 만큼 기술과 디자인에 대해 기초 지식을 갖춰야한다. 가장 효과적인 방벙을 통해 신뢰관계를 형성할 수 있는데 바로 '질문을 통한 학습'이다.
예를 들면 "이 기능을 구현하려면 어떤 기술적 접근을 해야할까요?", "이 디자인은 고객에게 어떤 영향을 미칠까요?" 으로 볼 수 있다.
용병팀과 같이 이런 말은 "왜 이렇게 하나요?" "버그가 발생했으니 롤백해주세요" , 이 태도는 팀원을 파트너가 아닌 지시에 따라 움직이는 사람으로 밖에 인식을 하는 것이다.
팀원들이 PM을 단순 "방해 요소"가 아닌 믿고 신뢰할 수 있는 "협업 파트너"로 인식할 수 있도록 해야하고 그렇게 만들어야한다.
