'기술자'
제품 전문가로서 우리는 비즈니스, 영업, 마케팅 이해관계자들에게 '기술자'로 불리곤 한다. 외부 미팅에 참석해 API 통합이 어떻게 작동하는지 자세히 살펴보고 비즈니스 동료에게 특정 기능에 대한 기술적인 제약을 (넓은 인내심과 미소를 장착하고) 설명하려고 한다. 또한 신기술이 제품과 비즈니스에 미치는 영향을 전도한다.
그러나 우리가 문제를 해결할 때 어떤 식으로든 기술적으로 뭔가를 시도한다면 엔지니어들은 여전히 코웃음을 칠 것이다. 이들이 보기에 우리는 엔지니어가 아니라 매니저이다. 당연히, 우리는 엔지니어가 아니므로 그렇게 하려고 해선 안된다. 프로덕트 매니저는 멋진 메모장, 알록달록한 양말, 사용자 측정항목을 선호한다. 엔지니어는 ruby on rails, 펑키한 javascript 프레임워크 그리고 월요일 아침 10시에 먹는 누텔라 샌드위치를 좋아한다. 우린 다르다.
이로 인해 비즈니스 팀에서 우리를 기술자로 보고, 엔지니어링 팀에선 우리가 소프트웨어 개발에 있어 실질적인 기술력이 없는 매니저로 생각하는 까다로운 상황에 놓이게 된다.
만약 당신이 편하게 느끼는 수준보다 더 기술적인 제품을 만들 때 어떤 일이 생길까? 당신이 기술적인 문서에 빠져 그것이 무엇을 의미하는지 전혀 모른다면 어떻게 될까? 아마도, 진정한 프로덕트 매니지먼트 방식에선 당신은 흠뻑 젹셔버리고 일을 배워 계속 할 것으로 예상된다.
기술은 PM 스킬의 삼위 일체(비즈니스, 기술, 디자인) 중 하나이다. 기술력 있는 프로덕트매니저에 대한 찬반이 갈린다. 개인적인 견해로 기술은 특정 조건 하에서 프로덕트 매니저의 자산이다. 그 조건이란 프로덕트 매니저가 '무엇'(고객과 비즈니스에 가치)을 전달하는지와 가치를 고객에게 전달하는 매커니즘으로서 '어떻게'(기술)를 보려고 할 때이다.
만약 프로덕트 매니저가 한 가지 기술만 가지고 살아남아야 한다면 그것은 기술력이 아닐 것이다. 고객 공감, 전략, 비즈니스, 커뮤니케이션과 디자인이 핵심으로 더 중요하지만, 기술력은 강한 의사결정을 하고, 트레이드 오프를 이해하는 데 도움을 주고, 잠재적인 비즈니스 기회를 명확히 할 수 있다. 기술에 너무 깊이 관여하는 것은 'how'에만 집중하면서 제품 관리의 핵심을 놓치게 된다.
모든 웹 기술 중에서 API가 고객 성장과 수익에 새로운 기회를 열어주고 멋진 일들을 하기 때문에 점점 더 프로덕트 매니저에게 중요해 보인다.
내 경험상 API는 비제품/비엔지니어링 이해관계자들이 비즈니스 기회로 언급하는 가장 빈번한 기술적 개념 중 하나이다. 그러므로 API의 기본을 이해하는 것은 매우 유용하다.