?또 한 권의 흥미로운 책을 접했다. "트랜스폼드"라는 제목의 책인데, 실리콘밸리 프로덕트 그룹(SVPG)이라는 업체를 창업한 마티 케이건이 쓴 책이다. 사실 이 책을 접하기 전까지 SVPG라는 회사에 대해 잘 몰랐는데, 나름 업계에서 유명한 회사로서 초창기 실리콘밸리의 IT업체들에서 중역으로 일했던 사람들이 모여서 만든 일종의 컨설팅 펌이다. 많은 기업들에게 교육과 컨설팅을 제공하면서 혁신적인 제품을 만들 수 있도록 도움을 주는 것을 목적으로 활동하고 있는 듯 하다. (구글링을 조금 해보니, 컨설팅 비용도 어마 무시한 듯.. ^^)  본 도서는 혁신의 정의, 프로덕트 오퍼레이션 모델과 이를 위한 핵심 역량, 혁신의 기술 등과 관련된 내용을 담고 있는 총 6개의 파트로 구성되어 있는데, 세부적으로는 약 4~6페이지 정도의 분량으로 된 짤막짤막한 chapter가 무려 49개나 있다. 모두가 다 저자가 제안하고 있는 프로덕트 오퍼레이션 모델로 기업 형태를 "전환"하는 것과 관련된 내용을 담고 있다고 보아도 과언이 아니다. (그래서 책 제목도 "트랜스폼드"이다.) SVPG는 그 동안 훌륭한 디지털 제품 기업들을 관찰하고 그 내용들 중에 공통 주제로 묶을 수 있거나 가장 중요한 원칙이라고 여겨지는 것을 중점으로 다루고 내용을 추려 이 책에 담았다. 다만, 이 책 뿐만 아니라 Inspired, Loved 등 그 동안 SVPG가 집필한 몇 권의 책을 비롯하여 본 서도 마찬 가지로, 제품(프로덕트)을 구축하는데 정답은 없기 때문에, 도서 내용이 항상 옳지 않은 경우도 있다고 첨언하고 있다.  파트2에서는 프로덕트 오퍼레이션 모델로의 변화에 대해 3가지 관점에서 이야기하고 있는데, "제품 구현 방식의 변화", "문제 해결 방식의 변화", "우선 순위 결정 방식의 변화"가 바로 그것이다. 많은 내용을 담고 있지만, 다소 함축적이더라도 핵심만 요약한다면 개발 프로세스의 대상을 "프로젝트에서부터 프로덕트로 초점을 변화"해야 한다는 부분과 "조직 내 이해관계자가 아닌 고객을 위해 개발을 진행"해야 한다는 부분, 그리고 "기능 중심의 로드맵을 성과 중심의 로드맵으로 변화"시켜야 한다는 내용으로 각각 정리할 수 있을 것 같다. 또한, 파트3에서는 이러한 프로덕트 모델을 실천하기 위해 결국 제품 단위의 크로스펑셔널(cross-functional)한 조직 구성 방식이 필요하고, 각 이해관계자들의 필요 직무와 각기 담당하는 업무에 대해서도 설명하고 있다. 책임 범위에 따라, 크게 프로덕트 매니저, 프로덕트 디자이너, 테크 리드..로 구분하는데, 프로덕트 매니저는 제품의 가치와 실현 가능성에 대한 리스크를 관리하고 제품의 성과 전반에 대한 책임을 지는 실질적 리더의 역할을 가지며, 프로덕트 디자이너는 사용성에 대한 리스크를 관리하고 제품 전반의 경험, 즉 제품과 고객이 상호작용하는 모든 순간을 책임지는 역할을 띠며, 테크 리드는 구현 가능성에 대한 리스크를 관리하고 제품의 출시와 배포에 대한 책임을 진다.  파트4에서는 앞서 소개한 제품팀 조직이 고객을 위한 제품을 기획하고 구현을 하는 과정에 대해 다루고 있는데, 이 중에서도 특히 제품팀의 문화를 다루고 있는 chapter15와 chapter19가 인상적이었다. 저자는 제품팀을 구성하고 제품을 개발할 때 필요한 문화로서 아래와 같은 원칙을 언급하고 있다. 일종의 그라운드 룰 정도로 보면 될 것 같다.
파트5부터는 프로덕트 모델로의 변화를 통해 혁신을 이끌어낸 실제 사례에 대해 간략히 소개하고 있으며, 조직 구성을 변화시킨다는 것이 참 쉽지는 않겠지만 변화를 통해 성과를 얻은 사례를 통해 그러한 변화가 의미있는 시도였다는 것을 본 서에서 입증하고 있다. 그리고 그러한 성공적인 혁신을 위해서는 적절한 조직 구성과 CEO를 비롯한 각 담당자의 뛰어난 역량, 엔지니어들에 대한 능력 배가 및 사기 고취, 고객의 관점에서의 통찰력 있는 제품 전략 수립, 그 외 지원조직 등 이해관계자와의 유기적인 협업 등이 필요하며, 무엇보다 이러한 프로덕트 모델로의 전환을 하고자 시도하는 기업 단위의 용기가 가장 중요하다고 저자는 이야기하고 있다.  결론적으로, 본 서는 아래와 같은 분들이 읽으면 좋을 것 같다.
|
|
거인의 어깨 뉴턴은 각 세대의 발전적인 성과가 쌓여서 혁신이 이뤄어짐을, " 나는 거인의 어깨 위에 올라섰기 때문에 좀 더 멀리 볼 수 있었습니다. "라는 말로 표현했습니다. 앞 세대 혁신은 다음 세대에게 "거인의 어깨"가 되어 또 다른 혁신의 단초를 제공하는 것이죠. 소프트웨어 분야도 눈에 띄게 뚜렷한 '거인의 어깨'가 여럿 있었습니다. 50, 60년대엔 아주 소수의 사람들만 사용하던 컴퓨터가 80년대 그래픽 유저 인터페이스(GUI)의 발명으로 크게 혁신을 이루고, 대중이 쉽게 사용하는 컴퓨터가 되었고, 90년대 인터넷 확산은 컴퓨터 자체뿐만 아니라 컴퓨터 밖에 있는 산업들도 컴퓨터 안으로 빨려 들어가기 시작한 계기가 되었습니다. 이른바 '디지털 트랜스포메이션'의 시작이죠. 이는 먼저 소프트웨어 분야에 극단적인 변화를 불러왔습니다. 소프트웨어를 패키징 해서 파는 제품이 아니라 인터넷을 통해 서비스하는 서비스가 되게 만들었거든요. 이를 감지한 통찰력 있는 개발자들은 2001년에 "애자일 선언"을 합니다. 디지털 대전환의 시발점이 되는 소프트웨어 개발은 가장 먼저 변화를 겪게 될 것이고, 그 변화는 이런 식으로 대응해야 한다는 것이었습니다. 이런 변화는 다분히 애자일 선언을 했던 개발자들만 느끼고 있었던 것이 아니었습니다. 프레드릭 브룩스는 ＜맨 먼스 미신＞ 40주년 기념판에 1986년에 본인이 썼던 논문을 추가해서 출간했는데요. 그 논문의 제목은 ＜은 총알은 없다＞였습니다. 소프트웨어 개발 작업은 본질적 작업(essential taks)와 부차적 작업(accidental task) 부분이 있는데, 소프트웨어 작업의 복잡도를 증가시키는 본질적 작업을 개선할 방법보다는 부차적 작업을 개선하는 방법에 치중하기 때문에 소프트웨어 복잡도를 감소시킬 "은 총알"이 없다는 내용이었습니다. 이에 대한 해결 방식으로 제시한 첫 번째가 소프트웨어를 build(건축) 하지 말고 grow(성장) 시키라는 것이었죠. 제품을 만들지 말고 지속적인 성장이 가능하게 하라는 주문이었습니다. 이렇게 하면 본질적 작업을 개선할 수 있고 은총 알은 아니더라도 소프트웨어 복잡도를 줄일 수 있게 될 겁니다. 브룩스에게 직접 영향을 받았는지는 모르지만 애자일 선언을 했던 개발자들은 정확하게 소프트웨어를 성장시키려면 뭘 해야 하는지 선언하고 있습니다. 브룩스와 애자일 개발자들은 공통적으로 "폭포수 개발"방식을 혐오합니다. 브룩스는 ＜맨 먼스 미신＞과 ＜디자인 오브 디자인＞이라는 저서에서 "폭포수 모델은 틀렸으며 해롭기까지 하다."라고 말했습니다. 애자일 진영의 개발자들도 동일한 태도를 취하고 있고요. 저는 애자일에 대해서 알아가기 시작하면서, 실무에도 적용시켜보고 싶어서 다양한 시도를 했습니다. 자처해서 팀 내 세미나도 하고 동조하는 동료를 찾아서 함께 팀 업무에 적용해 보기도 했습니다. 하지만 그때마다 다양한 방식으로 좌절했었는데요. 개발자 동료들조차 애자일에 대해서 비판적이었고, 관리자와 조직장 레벨에서도 공감하지 못하는 경우가 많았기 때문입니다. 그뿐만 아니라 애자일을 접목하려면 개발 조직에서만 노력해서는 안 된다는 걸 뼈저리게 느낀 다음 부터는 애자일을 회사에 적용하는 것보다 개인적인 작업을 애자일 방식으로 하는 걸 연습하곤 했습니다. ＜트랜스폼드＞ 이 책은 제가 좌절했던 부분에 대해 거의 정확하게 해결책을 제시해 주는 책입니다. 개발자가 아니라 회사 자체를 요즘 트랜드에 맞는 서비스형 소프트웨어를 개발하기 위해서 어떻게 바꾸어야 혁신할 수 있는지를 설명하고 있기 때문입니다. ＜트랜스폼드＞를 읽으면서 지난 20년간의 한을 해소하는 것 같은 느낌을 얻을 수 있었습니다. 먼저, 저자는 혁신의 엔진이 기술 조직에 있음을 선언 합니다. "사업을 성장시킬 동력이 기술이라는 것을 의미한다" (본문 3쪽) 이는 ＜디지털 트랜스포메이션 엔진＞이라는 책에서 영감을 받은 것으로 보이는데요. 책 곳곳에서 이 책을 언급하고 있습니다. 다행히 저는 2022년말에 ＜디지털 트랜스포메이션 엔진＞을 읽었습니다. ＜디지털 트랜스포메이션 엔진＞의 저자들은 DevOps 분야에서 선구자적인 업적을 가지고 있는 분들인데요. 고성과 조직이 되기 위해서 기술조직이 어떻게 변화해야 하는지를 설명합니다. 기술조직이 "엔진"이 되어야 고성과를 내는 회사로 혁신할 수 있음을 실험 데이터와 혁신적 기업의 예를 가지고 설명하고 있습니다. 성장 동력이 기술임을 못박는 건, 에서 엘리 골드렛이 말한 "제약이론"과 맥을 같이하는 것으로 보입니다. 제약이론은 병목구간 이외 구간의 개선은 환상일 뿐이라는 걸 말하는 이론입니다. 즉, 프로세스 개선을 하려면 병목을 찾아야 한다는 말이고 병목을 찾는 다는 건, "흐름"을 주도하는게 무엇인지 기준을 정해야 한다는 말이되거든요. 소프트웨어 개발에서 제품 개발의 흐름을 주도하는 건, 개발 조직입니다. 우리 회사가 제공하는 서비스가 사용자들의 필요에 빠르게 반응해야 회사가 돈을 벌 수 있기 때문에 개발 조직이 개발 흐름을 빠르게 해야 하는 거죠. 다시 말해 '리드타임'을 극적으로 줄이기 위해서 개발조직이 병목을 찾아 대응하는 것이 가장 합리적인 혁신 방법이고, 이를 기준으로 회사는 사업을 성장 시키게 되는 것이죠. ＜트랜스폼드＞에서는 이런 모델을 "프로덕트 모델"이라고 명명합니다. 그리고 "프로덕트 모델"이 되기 위해 회사에 있는 모든 구성원들과 어떻게 협력해야 하고, 조직이 어떻게 바뀌어야 하는지 설명합니다. 마음 같아서는 ＜트랜스폼드＞의 내용을 그대로 발표자료로 만들어서 회사에 들고가서 떠들고 다니고 싶더군요. 그러나 ＜트랜스폼드＞는 변화의 세세한 방법들을 설명하는 책이라서, 전체 그림을 모두 볼 수는 없었습니다. 저자들은 전작인 ＜인스파이어드＞, ＜임파워드＞ 그리고 ＜러브드＞에서 나머지 디테일을 설명하고 있는 것 같은데, 제가 아직 이 책들은 읽지 못했거든요. 외주 작업 책을 읽으면서 중간 중간 눈에 띄었던 것 하나가 외주 작업에 대한 관점이었습니다. "외주로 일하는 경우, 혁신을 이뤄내기 위한 기회에 너무 늦게 투입되거나 제품이나 고객에 대해 무지한 상태일 수 있다" (본문 66 쪽) "외주 인력이 점하고 있었다. 그렇다 보니 ... 기업의 미래에 대한 관심은 별로 없었다" (본문 130 쪽) "엔지니어를 왼주화하는 것이 아니라 내재화하고 그 역량을 강화해야 했다"(본문 188 쪽) "엔지니어를 외주화하는 것은 무척 비효율적이다" (본문 311 쪽) 1960년대 피터드러커가 ＜단절의 시대＞에서 예견한 것처럼, 현재 우리는 지식산업사회에 살고 있습니다. 그리고 디지털 트랜스포메이션 흐름은 지식 산업 상황을 더 심화 시킬 것이 자명하지요. 따라서, 현재와 미래에 경쟁력있는 회사는 지식을 축적하는 회사입니다. 그럼 어떻게 지식을 축적해야 할까요? 개발조직이 엔진이 되어야 한다고 했는데요. 그 이유가 여기서도 나옵니다. 회사내에 지식이 축적되려면, 학습해야 하고, 학습이 이루어지려면 경험 해야 합니다. 리드 타임을 빠르게 해서 작은 서비스를 빠르게 지속적으로 시장에 적용시켜보고, 이에 따라 돌아오는 피드백 데이터를 정보화하고 정제해서 지식으로 축정하는 과정을 거쳐야 합니다. 이렇게 그림을 그려서 조망하다보면, "외주"는 그 흐름을 끈는 방법이 되죠. 소프트웨어 개발 결과가 패키징 제품이 아니라 서비스라고 생각한다면, 그리고 그 서비스는 점차적으로 고도화해서 사용자의 필요를 가장 제대로 충족하는 서비스로 혁신되어져야 한다고 본다면, 일부분을 떼어서 외주주는 행위는 장기적으로 회사의 발전 흐름을 막는 것이 되고 말기 때문에 신중에 신중을 기울여야 합니다. 혁신 "프로덕트 모델에서는 예측 가능성이 아니라 혁신에 집중한다" (본문 322 쪽) 기업은 "예측 가능성"에 목말라 합니다. 연말이 되면 내년에 뭘할지 계획하고 그 로드맵대로 서비스가 출시되는 것이 회사가 생존하는 방법이라고 여기곤 하죠. 하지만 여기엔 많은 부분이 틀렸습니다. 그렇게 이루어지려면 서비스 사용자들은 우리 서비스 출시에 목매고 있는 광신도들이어야 합니다. 뭘 던져주던지 아무런 불평없이 그 서비스를 사용하는 사람들이어야 하죠. 하지만 현실은 그렇지 못하거든요. 시장도 트랜드도 '일주일이 멀다'하며 바뀌니까요. 그럼 예측 가능성이 아니라 혁신에 집중해야 한다는 저자의 주문이 맞는 말이 됩니다. ＜보랏빛 소가 온다＞에서 세스 고딘은 "광고는 집어치우고 혁신을 시작하라"라고 했습니다. 그 이유는 우리의 서비스에서 우리가 전달하고자 하는 메시지를 전달하는 사람들은 보편적으로 우리 서비스를 사용하는 사람들이 아니라 "얼리 어댑터"들이기 때문입니다. 얼리 어댑터들이 포지션을 바꾸고 우리 서비스를 들고가서 주변 사람들을 설득하지 않으면 우리의 서비스는 확산될 수 없습니다. 우리 서비스가 "예측 가능성"에 치중해서 그저 그런 서비스로 조금씩 변화해 나간다면 "얼리 어댑터"들은 우리 서비스에 대한 에반젤리스트가 되어주지 않을 것입니다. 그럼 우리의 회사 형편도 월등히 나아질 방법은 없는 셈이 되죠. 얼리 어댑터들의 눈이 번쩍 뜨일만큼 혁신적인 서비스를 만들어 내면서도 그들이 자처해서 에반젤리스트가 되어 주변사람들에게 보여줄 만큼 충분히 쉬운 서비스를 만들기 위해서 순간마다 혁신하는 조직을 만들어야 합니다. 결론 2024년 말에 ＜트랜스폼드＞라는 책을 읽게 된건 일종에 행운이었던 것 같습니다. 힘들게 일하고 무언가 꽉막혔던 느낌을 가진 한해였는데 한줄기 빛을 선사해주는 느낌을 주었습니다. ＜트랜스폼드＞의 다른 부분들을 말하고 있는 나머지 3권의 책들도 빨리 구해서 읽고, 2025년을 새롭게 시작해야 겠습니다. |
|
IT업계의 흐름 및 선두적인 경험을 미리 책으로 알아볼수 있는 기회는 매우 흥미롭게 다가옵니다. 특히 SVPG (실리콘밸리 프로덕트 그룹)에서 5명이 공동저자로 업계의 흐름중에 프로덕트에 대한 직.간접적인 경험 및 사례를 통한 내용은 실제 조직을 운영하고, 회사의 제품을 지속적으로 발전시키는데 필수적인 부분입니다. 한분의 저자나 한 업체의 내용보다, SVPG에서 공통된 관심사를 도출해서 책으로 출간된 내용이라고 더욱 현실적이고 공감대가 많은 내용으로 구성되어 있을 것이라고 독서를 하기전에 생각이 들었습니다.
■ 내용 살펴보기 실리콘밸리의 혁신을 이끄는 프로덕트 운영 전략과 사례의 부 제목을 가지고 있습니다. 책의 제목으로된 "트랜스폼드" 라는 용어가 조금은 어색하게 다가옵니다.
이 책에서 전하는 총 3개의 주요 목표는 아래와 같습니다. 1. 프로덕트 오퍼레이팅 모델이 의미하는 바와 그 방식으로 일하는 것이 어떤 의미인지를 인지시키는것 2. 프로덕트 모델로 전환하는 것이 어렵긴 해도 구체적인 성공 사례를 통해 우리의 조직도 설득하고자 하는 것 3. 조직의 혁신을 완수한 뒤 무엇이 달라지는지 사례를 들어 영감을 주는 것
· 프로덕트 오퍼레이팅 모델이란? 이 책에 제일 중요하게 이해를 해야 하는 내용입니다. 몇몇 기업은 축약 표현인 "프로덕트 모델" 이라는 용어를 사용하기도 한다. 업무를 진행하는 구체적인 절차 또는 특정한 방식을 지칭하는 것이 아닙니다. 오히려 관념적인 모델에 가까우며 뛰어나 디지털 제품 기업이 따르는 주요 원칙의 합이다. 기본적으로 프로덕트 오퍼레이팅 모델은 고객이 만족하면서도 사업의 성장에 기여할수 있는 기술 기반의 접근 방식을 의미한다.
· 프로덕트란? 우리는 프로젝트와 프로덕트에 대해서 조금은 개념적으로 다른 의미를 가지고 접근하실수 있습니다. 이 책은 꼭 IT의 프로덕트를 개발하기 위한 책은 아닙니다. 조금 더 큰 상위 개념으로 접근을 합니다. CIO, CTO 및 각 직급에 맞는 상황에 따리서 회사의 이익 및 영속성을 위해서 신규 프로덕트에 대한 접근하는 방법 및 기존에 잘 안되고 있는 사항들에 대해서 명확한 가이드를 받을수 있는 책이라고 생각이 듭니다.
신규로 혁신을 이루려면 어떻게 해야할까요? 기존에 잘 진행되는 프로세스가 있다면 그대로 유지하고 적용하면 되지만, 기존에 프로세스가 없는 조직 및 조금 더 보완하고 싶은 부분이 있을때 우리는 다양한 혁신 사례를 찾게 됩니다. -＞ 그러한 고민 거리나 관심사가 있다면, "프로젝트 오퍼레이팅 모델"을 통해서 전환하는 것을 제시합니다. 1) 제품 구현 방식의 변화 2) 문제 해결 방식의 변화 3) 우선순위 결정 방식의 변화 이러한 변화되는 부분에 대해서 어떻게 접근할수 있을까? 회사에서 어떻게 하면 기존의 자원, 리소스로 원하는 결과물을 얻을수 있을까? 기존에 제품 구현 방식에도 많은 변화가 있었습니다. 조직에서 혁신은 제품을 어떻게 구현하느냐 에서 시작을 합니다. 프로젝트에서부터 프로덕트로 초점이 바뀌고 있습니다. 예전에는 빅뱅 방식으로 제품 출시를 하는 경향이였지만, 이제는 작은 단위로 변화를 주는 방식으로 개편되고 있습니다.
문제 우선순위의 가장 큰 문제는 고객을 위해서가 아니라, 조직 내 이해 관계자를 위해서 일하는 탓이다. (책에서 언급한 사항이지만, 많은 공감을 가질수 있는 멘트 입니다.)
우선순위 결정은 매사 어떠한 업무를 진행하려고 해도 가장 중요한 부분이고, 가장 어려운 부분입니다. - 제품 중장기 계획을 폐기하자 - 파괴당하기 전에 스스로 파괴하자 - 고객 중심의 제품 비전을 세우자 - 인사이트에 따라 제품 전략을 세우자 - 제품팀 조직장의 역활을 구체화 해야 한다. ＜세부적인 구체적인 내용이 별도 구성되어 있는 부분도 도움이 되고, 책이 최근에 출간되어서 사용되는 예시도 최신 기술기반으로 구성되어 있습니다.＞ 
■ 프로덕트 모델의 실천 이제 조금씩 다양한 협업 케이스에 대해서 다룹니다. · 고객과의 협업 · 영업팀과의 협업 · 프로젝트 마케팅팀과의 협업 · 재무팀과의 협업 · 이해관계자와의 협업 · 경영진과의 협업 유관부서가 몇개 안될수도 있고, 난이도 및 규모가 큰 프로덕트인 경우 정말 다양한 담당자들과 협업이 필요합니다. 이런 경우에 우리는 성공적으로 일정을 준수하면서 프로덕트를 진행해야 할지 잘 정리 되어 있습니다.
· 다양한 사례에 대한 내용도 실제 이론적인 부분을 조금 더 구체적으로 접할수 있습니다. - 짐패스 : 펜데믹이라는 상황에서, 사업을 확장하는 성과를 얻은 프로덕트 모델 전환 사례 - 데이터 사이트 : 크리스천 이디오디 영입을 통한 사양산업, 기술혁신이 부족한 제품, 레거시 모델, 높은 부채 등에 대해서 변화하고 혁신하는 과정 : 프로덕트 모델로 전환 / 제품 구현 방식의 변환 / 문제 해결 방안의 변화 / 문제 정의 방식의 변화 릍 통해서 이러한 접근을 진행할수 있습니다. - 어도어 : 레아 히크먼를 통해서, 기존에도 유명한 기업이였지만, 프로덕트 모델을 바탕으로 신규 새로운 다음 먹거리를 준비하고 대비하는 과정 - 카이저 퍼머넌트 : 이해관계자가 많아서, 효과적인 혁신을 할 수 없다고 생각하는 사람들을 위한 리더십 및 동기가 있다면 혁신이 가능하다는 사례
■ 혁신에 대해서 단순히 신기술을 적용했다고, 혁신이라고 말할수 있을까? 새롭게 서비스하려고 하는 프로덕트에 대해서 우리는 측정하고, 전파하는 다양한 역활 및 과정에 대해서 인지하고 있어야 합니다. · 혁신의 성과, 평가, 기술, 전파, 도움에 대해서 part8장에서 다룹니다. 평가에 대해서는 개인/조직에 대한 평가는 수행과장에서 필수입니다. 이러한 부분은 모두 공감이 되어 있는 상태에서 진행되어야 합니다. 이러한 과정에 대화/자료증거등을 기본으로 미리 인지하고 있어야 합니다. 
· 혁신을 수행하는데 다양한 반론과 재반론의 과정은 필수입니다. - 반대의 종류는 너무 다양합니다. : 고객, 영업팀, CEO와 이사회, 사업팀, 고객지원팀, 마케팅팀, 재무팀, HR/인사팀, CIO, PMO, 제품팀내 반대등 정말 다양한 반대요소가 있습니다. 모두 일반적으로 부서가 다르고 담당하는 업무가 모두 차이가 있다보니, 접근하고 풀어가야 하는 방법들이 모두 다를수 밖에 없습니다.
이 책은 평소 답답한 상황을 거의 대부분 담고 있다고 생각합니다. 각자의 위치가 다르고 풀이법도 다르고, 조직의 상황이 다른데 어떻게 하면 프로덕트를 우리가 잘 진행될수 있고, 성과를 얻을수 있게 접근하고 풀어가고 준비를 해야 하는지 잘 구성되고 있고, 내용 및 혁신사례등은 바로 필요한 부분을 적용해보고, 생각의 변화를 가지고 올수 있는 내용들로 구성되어 있습니다. |
|
이 책은 단순한 이론서가 아니라 실무에 바로 적용할 수 있는 가이드를 제공한다는 점에서 큰 장점이 있어요. 특히 혁신 과정에서 팀원들이나 이해관계자들의 반발을 어떻게 설득할지, 리더로서 어떤 자세를 가져야 할지에 대한 팁들이 정말 좋습니다. |
|
아마 이 책을 처음보는 분이라면 잘 이해하지 못할 수 도 있을 것 같다. ＜인스파이어드＞와 ＜임파워드＞라는 책을 먼저 읽는다면 보다 이해하기 수월할 수 있다. 하지만 앞의 두 책을 읽지 않았어도 프로덕트 오퍼레이팅에 대한 내용은 결국 알게될 것이다. 먼저 챕터2를 자세히 읽고 이해하는게 먼저일 것이다. 프로덕트 오퍼레이팅이라는 내용에 대해 자세히 설명하고 있다. 이 책을 끝까지 읽어나가기 위해서는 제대로 알고 시작해야 한다. 제시된 사례를 읽으면 경영자가 기업을 이끌어가는 과정이 고스란히 드러난다. 성공과 실패사례를 보면서 혁신이라는 추상적인 단어에 대한 구체적인 모습을 알게될 수 있다. 기업이라는 것이 최고경영자의 의지대로만 운영되는 것이 절대 아님을 알게 되었다. 생각했던 것보다 신경써야할 것들이 정말 많았고, 여러 반대를 무릅쓰고 추진해야할 일도 많았다. 실리콘밸리의 성공사례를 보면 수많은 위기를 가까스로 이겨내고 만든 결과라는 것도 알게 되었다. 책의 이해를 돕기 위해 내용 중간에 참고가 될만한 내용이 있어서 충분히 독서를 이어나갈 수 있다. 그리고 현직에 있는 제품코치와 프로덕트 코치에 대한 설명도 있어서 어떤식으로 프로덕트에 대한 혁신을 이루어낼 수 있는지도 실감하게 되었다. 스타트업 규모의 사업을 하는 기업가라면 반드시 읽어야할 책이라고 생각한다. 혁신 이전에 지속적인 기업의 생존을 위해서라도 프로덕트 오퍼레이팅에 대한 개념이 없다면 큰일 날 것이다. 이 책을 다 읽고 나면 앞에서 언급한 두 책도 반드시 읽어보기 바란다. 그렇게 해야 이 책을 더 확실히 체득함은 물론, 기업을 이끌어가는 경영자가 어떤 목표를 가져야 할지 명확해질 것이다. -제이펍 출판사에서 제공받은 도서를 읽고 작성한 서평입니다- |
|
- 본 서평은 출판사로부터 책을 제공받아 읽고, 주관적으로 작성한 서평입니다. 오랜기간 회사에서 직장인으로 일을 하다보니 맡은 업무 외에도 전략, 조직 운영, 기획 등에도 관심이 간다. 사측에서도 생산성 향상을 위해 그간 매트릭스 구조나 애자일 문화처럼 조직문화, 혹은 데이터/AI 중심 전환 등 일하는 방식을 변화시키고자 많은 노력들을 시도해왔다. 여러 방식마다 각각 장, 단점이 있겠지만 개인적으로 R&D라는 업무 특성상 제일 아쉬웠던 부분은 현실과 다소 동떨어진 부분에 중점을 두고 있는게 아닐까? 하는 생각이었다. 대체로 기술 구현에만 중심을 두고 있다보니 실제 제품으로 채택되기까지는 비용, 편의, 스펙 등에서 이슈가 생겨 중단되는 경우가 종종 있었다. 이번에 읽은 책은 '트랜스폼드'라는 책이다. 평소 프로젝트 중심으로 돌아가던 실제 업무와 달리 프로덕트 운영 전략을 표방한 점도 궁금했고, 실리콘밸리의 일하는 방식이라는 점에서 무언가 우리네와 다른 새로움이 있을 것 같아 기대가 되었다. 저자는 SVPG라는 제품 중심 마케팅, 컨설팅 기업 설립자이자 기존에 '인스파이어드'와 '임파워드' 두 책을 통해 혁신을 이끄는 제품에 대해 오랜기간 연구해 온 작가로, 이번 책에서는 프로덕트 중심으로 일하는 방식에 대해 독자에게 전달하고 있다. 이번 책은 몇가지 점에서 흥미로운 생각거리를 던져준다. 먼저 프로젝트 관리에서 프로덕트 오퍼레이팅 모델이라는 개념을 도입한다는 점이다. 사내 부서별로 부바부겠지만 개인적으로 프로젝트 중심으로 일해왔던 경험 측면에선 제품구현 가능성을 중시하는 관점은 굉장히 참신한 접근이었다. 나아가 프로덕트 매니저, 프로덕트 디자이너, 테크 리드가 제품의 가치, 실현 가능성, 사용성, 구현 가능성 등에 대해 소통하고 완성해가는 방식은 기존 제품의 실제 구현보다 KPI만을 중시해오던 문화와 달라 굉장히 매력적이라 느껴졌다. 한편 기존 업무수행시 PQC만을 중시하여 이는 충족했으나 결과물은 엉망인 경우가 많았는데, 첵에서처럼 프로덕트 성과 중심으로 전환된다면 이러한 문제의 해결책이 될 듯 싶었다. 또한 이를 수행하는 각 단계에서의 세부 원칙과 함께 제품팀 이외의 팀과 협업을 위한 세부 실천 방안을 제시해 준 점도 실적용에 많은 도움이 될 것 같다. 프로덕트 중심 모델의 장점과 일하는 방식 전환에 관심이 있다면, 개념 정의부터 각 단계, 세부 전략과 팀별 실천 방안 등 구체적인 것이 망라된 이번 책이 많은 도움이 될 것 같다. #트랜스폼드 #마티케이건 #옥지혜 #제이펍 #프로덕트운영 #프로덕트오퍼레이팅모델 #조직문화 #전략 #혁신 #제품 #구현 #성과 |