[경영] 개발 함정을 탈출하라 -5부 프로덕트 중심 조직

 

 

이전 글

2023.03.23 - [IT 말고/책 리뷰] - [경영] 개발 함정을 탈출하라 - 4부 프로덕트 매니지먼트의 4단계

[경영] 개발 함정을 탈출하라 - 4부 프로덕트 매니지먼트의 4단계

 

5부 프로덕트 중심 조직

앞부분에 저자가 코닥에서 일할 때의 경험이 나옵니다. 아이폰 출시가 코닥에게 위협임을 깨달은 코닥연구소는 코넬대학 혁신팀과 협력해 20대 초반 소비자가 좋아할 만한 신제품을 개발 중이었습니다. 저자가 속한 팀은 시장의 니즈와  코닥이 가진 기술의 교차점에서 혁신방안을 만들었고, 경영진에 보고 했습니다.
 
보고 내용은 휴대폰에서의 사진보정 기능과 즉시 SNS에 공유하는 기능, 사진에 장소를 태그 하고, 보기 좋게 정리하고, 사진을 볼 수 있는 사람을 통제할 수 있어야 한다는  것이었습니다. 그리고, 자체 휴대폰을 개발해 애플과 경쟁하거나, 휴대폰 제조사에 기술을 제공하는 두 가지 방향을 제시했으며, 시급한 상황이라고 알려주었다고 합니다.
 
하지만, 모두 알다시피 코닥은 그 제안을 실행하지 못했고, 그 제안은 인스타그램에 의해 현실이 되었습니다.
 
프로덕트 매니지먼트를 올바르게 수행해 맞는 방향과 전략을 수립했지만, 조직이 이것을 따라오지 못한 것입니다. 혁신을 추구한 조직은 사일로에 갇혀있었고,  다른 조직들은 수동적으로 반응했습니다. 연도예산의 한계 때문에 예산도 확보하지 못했습니다.  
 
이런 사례를 볼 때, 프로덕트 매니지먼트를 올바르게 수행하려면 조직 전체가 프로덕트 중심 조직이 되어야 합니다.
 

1. 성과지향적 의사소통

1년 전 마케틀리는 개발 함정에 빠진 기업의 전형적인 사례였다. 프로젝트를 중심에 두고 무엇이든 CEO가 우선시하는 일부터 처리하도록 팀들을 굴렸다. 프로덕트 매니저는 없었다. 고객과 대화도 나누지 않고 소프트웨어를 완성해 내보내야 보상을 받았다. 

5부까지 오면서 살짝 흐려진 개발 함정에 빠진 기업의 모습을 다시 한번 상기해 봅니다. 사실 아주 권위적인 CEO가 아니라면, 시키는 대로만 하는 직원을 좋아할까? 싶은데요. 그럼에도 불구하고, 직원들은 높은 사람이 하는 말이 아무리 말이 안 되거나, 중요하지 않다고 해도, 그 말에 따를 수밖에 없기는 합니다. 그러려면 CEO가 탈권위적이라는 것을 직원들에게 인지시킬 필요가 있을 것 같습니다. 그래야만 상향식으로 의사소통이 되지 않을까요? 

내가 보아온 기업들이 변화에 실패한 주요 원인을 하나 꼽자면 경영진이 성과지향적 기업으로의 전환을 받아들이지 않은 것이었다. 경영자들은 결과를 내고 싶다고 말하지만 결국 기능 출시 여부를 성공 기준으로 삼곤 한다...(중략)... 그러므로 다양한 수준에서 진척 상황을 알려주고 그것을 소통하도록 도와주는 다른 방법들이 필요하다.

검토회의를 안 하면 크리스(마케틀리CEO)는 안달이 났다. 무슨 일이 진행 중인지 자신에게 의미 있는 방식으로 깊이 이해할 수 없었기 때문이다. 대부분의 경영진이 크리스와 같으므로 조직의 모든 수준에게, 각 수준의 청자에게 맞는 방식으로 진척 상황을 보여주는 의사소통 리듬을 갖추어야 한다. 

일을 다 했다고, 성과가 난 것으로 보는 것은 끈기 있게 성과를 기다리지 못하기 때문이라고 합니다. 여기에서 진척상황을 점검하는 회의에서 진척사항이라는 것이 무엇인지 명확히 나오지 않는데, 앞서 4부에서 보았던 지표를 통해 진척을 관리한다고 보아야 할 것 같습니다. 개발함정에 빠지는 이유와 마찬가지로 진척 관리도 목표한 기능의 개발 완료 수준으로는 확인이 어렵고, 원하는 성과를 달성하기 위해 필요한 지표를 설정하는 것이 중요하겠습니다.

리듬과 의사소통

우리에겐 전략적 프레임워크에 맞는 의사소통 전략 리듬이 필요하다. 4단계 전략은 비전, 전략적 의도, 프로덕트 계획, 옵션이었다. 각 단계의 시간 지평은 다르며 각각을 향한 진척 상황을 그에 맞게 전달해야 한다...(중략)

- 분기 사업 검토
- 프로덕트 계획 검토
- 출시 검토

...(중략) 지금까지 소개한 회의들에서 모든 사항이 결정되는 것은 아니다. 이 회의는 진척 상황을 보여주고 조사가 필요한 부분에 이의를 제기하는 시간으로 보아야 한다. 의사결정은 주로 회의가 끝난 후 조치가 필요한 뭔가가 튀어나왔을 때 이루어진다. 

각 검토 회의는 위에서부터 경영진에 가깝고, 아래로 갈수록 실무진에 가깝습니다. 이런 회의를 통해 진척 상황을 공유하고 대처할 수 있는 시간을 벌 수 있습니다.

로드맵과 영업팀

기업들은 로드맵을 두고 허우적거리니다. 그들은 과거에 간트 차트를 만들어놓았고 그 차트들은 기본적으로 '1월 18일까지 이 기능을 공개하고, 3월 20일까지 이 기능을 공개한다.'라는 식이기 때문이다...(중략)

로드맵을 간트 차트라고 생각하지 말고 전략과 프로덕트의 현재 단계를 설명하는 수단으로 바라보자. 그러면 전략적 목표가 업무 주체, 그로부터 새로 생기는 프로덕트 상품과 결합된다. 그러려면 특히 팀 수준에서 프로덕트 로드맵을 꾸준히 업데이터 해야 한다...(중략)

로드맵을 구성하는 핵심 요소는 주로 다음과 같다.
- 주제
- 가설
- 목표와 성공지표
- 중요한 이정표

이때 각 개발 단계를 설명하는 용어들을 전사적으로 통일시키면 현재 어떤 활동을 진행 중인지 전 직원이 이해할 수 있다. 

회사에서는 흔히 로드맵이라는 이름으로 간트차트를 사용하는데요. Task기준으로 진척도를 보는 것과 성과를 중심으로 진척도를 보는 것은 다르게 보는 것이 맞겠다는 생각이 들긴 합니다.
이런 용어 통일은 경영진과 타 부서와의 소통을 수월하게 합니다. 비단 이런 용어뿐 아니라, 회사에서 쓰는 전반적인 용어는 통일이 필요하고, 새로운 용어를 만들어 내는 것에는 신중할 필요가 있습니다.

변수가 많은 소프트웨어 개발 업계의 특성을 고려하면 현재 상황을 알려주는 것이 두려울 수도 있다. 그래도 필요한 일이다. 프로덕트 매니지먼트가 있어야 영업전략도 나온다...(중략)
업무 협약을 맺고 리듬과 로드맵을 충족하는 형태의 바람직한 의사소통이 있으면 사내 정렬 문제는 상당수 해소된다. 

여기서 말하는 "리듬"이라는 것을 책에서 친절하게 설명을 해놓지 않았습니다만, 본문 내용 전반적으로 이해해 보면, 음악의 리듬처럼 조직 내의 전략에 대한 의사소통이 주기와 패턴을 가지고  반복되는 것을 의미하는 것으로 보입니다. 이런 의사소통이 되어야 사내 각 조직 간 전략이 정렬이 됩니다.

프로덕트 운영
프로덕트 팀이 늘수록 진척 상황, 목표, 진행 과정을 추적하기 힘들어진다...(중략)

업무 분장을 돕기 위해 우리는 상급직원이 이끌면서 CPO에게 보고하는 프로덕트 운영팀을 만들었다...(중략)
그들은 전략 리듬을 감독하고 진척 상황 추적을 위해 협력할 분석업체를 물색하고 목표 달성 현황을 취합, 정리해 경영진이 볼 보고서를 작성했다. 그 덕분에 개발 담당자들은 자신의 주 특기에 집중하고 운영 담당자들의 보고서를 바탕으로 정보에 근거한 판단을 내릴 수 있었다. 

프로젝트로 치면 PMO에 해당합니다. 확실히 프로덕트 팀이 많으면, 프로덕트 매니징의 체계를 잡아주는 팀이 있어야 효율적으로 업무가 가능합니다.
 

2. 보상과 성과급

보상과 성과급은 이 세상 모든 직장인을 움직이는 동기요인이다. 프로덕트 중심 기업으로 탈바꿈하려는 기업들에서 발견되는 가장 큰 문제는 현재의 보상체계로 올바른 행동을 장려할 수 있는지를 평가하지 않는다는 것이다.

꼭 돈이 중심이 아니라도, 어떤 일을 했을 때, 좋은 평가를 받는지를 보았을 때, 많은 기업들이 산출물 중심의 평가를 합니다. 앞서 수차례 보았듯이 진짜 성과를 측정하는 것은 어려우니까요.
하지만, 이런 식의 평가가 지속되면, 본인 업무에 대한 자부심이 점점 사라지고, 결국에는 현실에 타협해서, 평가는 잘 받을 수 있지만, 회사를 망치는 방향의 일을 하게 됩니다. 
"나중에 분명 문제 될 텐데요."라는 말에 "내가 그때까지 있을지도 모르는데, 나중에 생각하자"는 말도 참 많이 들었고, 실제로 개발이 완료된 그 해에는 상도 받고 승진도 했는데, 나중에 아무도 안 쓰거나 애물단지가 되어버리는 경우도 너무 많았습니다.

 훌륭한 프로덕트를 개발하고 싶지만 현재의 환경에서 그럴 수 있다고 믿지 못하는 것이다. 그게 잘못된 방식인 걸 알면서도 회사 정책 때문에 개발 함정으로 끌려가는 것이다.
고객을 돕기 위해 필요한 지식을 얻거나 문제를 해결하는 대신 제품부터 출시하고 봐야 생계유지가 된다면 직원들은 개발 함정에 빠질 수밖에 없다. 이런 환경에서는 새로운 것을 시도하기도 두렵다. 이런 정신은 혁신을 억누른다. 
기업의 대대적인 변신을 위해 담당자들에게 새로운 업무 방식을 요구하면서, 그들의 성과를 판단할 땐 왜 낡은 잣대를 들이댈까?

결국 우리가 회사를 다니는 주된 이유는 생계유지이므로, 회사의 정책을 따를 수밖에 없는 한계가 있습니다. 

상급자가 아니라면 정책의 많은 부분을 바꾸는 것이 어렵지만 그런 메시지를 전달할 수 있는 사람들이 사고방식을 바꾸도록 노력해 볼 수는 있다. 그렇게 할 때 올바른 방향의 대화가 시작될 수 있다. 상사에게 성공의 진정한 의미에 대해 이야기하자. 완료 여부를 판단하는 기준을 정의하자. 이 프레임워크를 활용해 검토 과정에서 대화를 유도하고 데이터를 항상 지참하자. 

자신이 책임자 위치에 있다면 직원 장려금 지급 방식을 재검토해보자. 성과를 내고 사용자에 대해 배우고 적절한 사업 기회를 찾아내 사업을 진전시키는 사람에게 보상이 주어져야 한다. 나머지는 결국 허영 지표일 뿐이다. 

피플웨어에서도 기존 체계에 순응하지 말고 변화를 일으키라고 했는데요. 여기서도 그러네요ㅎㅎ 다 맞는 말입니다. 용기가 나지 않지만요. 한편으로 성과를 내는 직원에게 보상을 주는 것이 바람직하지만, 그것을 측정하기 어렵다면, 산출물이나 기능의 개수 같은 의미 없는 지표를 사용하는 것보다, 차라리 주관적인 것이 낫다는 생각도 듭니다. 
의미 없는 지표는 현상유지가 아니라 오히려 매몰비용을 만들어 낼 뿐이니까요. 

3. 안전과 학습

마케틀리가 성공한 비결은 직원들이 실험하는 동안 CEO와 임원들이 뒤로 물러나 있었던 것이다. 프로덕트 매니저는 조직의 신임을 받을 때 비로소 다양한 선택지를 탐구할 수 있다...(중략)

현재 상태는 안전하다. 현재 상태는 혁신을 가로막는다. 그렇다고 장렬히 실패해야 한다는 뜻은 아니다...(중략)

실패하면서 배운 게 없다면 성공이 아니다...(중략)

학습은 모든 프로덕트 중심 조직의 핵심이다. 학습이 조직을 이끄는 원동력이 돼야 한다...(중략)

직원들에게서 혁신을 바라고 기막히게 좋은 신제품을 원하는 기업이 많다. 하지만 혁신을 원한다면 실패하더라도 안전하다는 합의가 있어야 한다...(중략)

좋은 말이 많네요. 학습이 핵심이라는 말이 와닿습니다. 과거에는 BA(Business Analyst)라고 불렸고, 지금은 PM으로 불리면서 자주 했던 생각이 늘 모르는 것이 많다는 것이었습니다. 얇고 넓게만 알다 보니, 전문성이 없다고 느껴지기도 했고, 늘 누군가에게 자세한 내용을 물어봐야 했었는데요. 프로덕트 중심 조직의 핵심이 학습이라고 하니, 좀 위안이 됩니다. 
실패하더라도 안전하다는 합의는 참 중요한 것 같네요. 우리나라는 실패하는 프로젝트가 거의 없다고 하죠. 실제로 실패했어도 오픈해 놓고 고치면서 쓰기도 하고, 프로젝트 후의 성과측정은 소홀한 경우가 많습니다.

수많은 기업이 서서히 실패한다. 프로덕트를 출시해 놓고 반응을 전혀 측정하지 않는다. 자리에 가만히 앉아서 가치가 창출되는지는 신경도 안 쓰고 끝없는 '기능의 바다'에서 제품이 먼지나 뒤집어쓰게 한다. 그것은 더 위험하고 비용도 많이 드는 실패의 길이다. 개발 과정에서 자잘한 실패를 허용하는 것보다 갈 일을 잃은 채 천천히 현금을 태워가며 10년에 걸쳐 실패하는 것이 더 큰 문제다.

이 구절은 정말 무서운데요. 지금 우리 회사도 이런 게 아닌가? 두렵습니다. 좁게 봐서 저도 그렇고, 더 넓게 보면 우리나라도 그렇고요. 
그래서 천천히 크게 실패하지 않고, 작게 자주 실패해서 만회할 수 있어야 한다는 것이 프로덕트 중심조직의 특성입니다.
실험을 해서 실패하면, 더 큰 실패를 막은 것이 되고, 그것 자체가 그 직원의 성과가 되고, 인정받는 방법이 되어야겠습니다. 

4. 예산 책정

"그게 무슨 뜻인지 아세요? 개발 비용을 줄이거나 아예 제품 개발을 접어도 된다는 사실이 드러나도 일단 개발하고 본다는 말이죠. 예산을 다 쓰지 않으면 불리해지니까요."

이런 건 미국이나 우리나라나 똑같네요. 흔히 보도블록 깐다고 하죠. 매년 말이 되면, 각 지자체는 남는 예산을 태우기 위해 멀쩡한 보도블록을 새로 깝니다. 한해 예산을 다 쓰지 않으면, 내년에는 예산이 삭감되니까요. 
저는 어릴 때 공군 비행장 옆에 살았는데, 월말이 되면 전투기들이 쉴 새 없이 날아다닙니다. 나중에 알고 보니, 비행기 연료를 다 써야 하는데, 남아서 다 태워버리는 거라고 하더군요. 공무원 조직이야 유명하고, 회사에서도 연말이 되면, 남은 예산을 쓰려고 갑자기 프로젝트가 승인되기도 합니다. 연초에는 그렇게 갈구해도 얻지 못했는데, 연말에는 안 해도 되는 것까지 하죠. 

미쳤다. 그 예산을 연간 단위로 집행하므로 팀들은 1년 동안 방향을 바꿀 힘을 박탈당한다. 

맞습니다. 미친 짓이 확실합니다. 비용도 비용이고, 잘못된 것을 알아도 계속 나아가야 한다는 것이요. 
언제쯤이면, 연도 예산의 함정에서 벗어날 수 있을까요?

5. 고객 중심

고객중심적 태도의 핵심은 스스로 고객의 입장이 되어 '우리 고객을 만족시키고 우리 사업을 발전시키는 것은 무엇일까?' 생각해 보는 것이다. 이 책을 시작하면서 우리는 프로덕트 매니지먼트가 가치 교환이라고 말했다. 고객을 중심에 두면 어떤 프로덕트와 서비스가 고객 측면에서 가치를 전달할 것인지 알아낼 수 있다. 

...(중략) 고객에 대한 깊은 이해야말로 훌륭한 프로덕트 개발의 가장 중요한 요소라는 것을 아는 것이다. 이 말은 '프로덕트 중심'이라는 말의 핵심이기도 하다. 

맞습니다. 모든 것은 고객이 중심이 되어야 합니다. 이것은 누구나 하는 뻔한 말이지만, 분명히 맞는 말입니다. 그리고 한 가지 잊지 말아야 하는 것은 프로덕트 매니지먼트는 고객에게 모든 것을 퍼주는 것이 아니라 고객에게 가치를 주고, 우리는 그에 상응하는 가치를 얻어야 한다는 것입니다. 그것은 당장에 이익이 안되더라도 고객을 위하는 행동이 쌓여 기업의 평판을 올리기도 하고, 당장에 이익이나, 손해를 피하려고 막장 고객의 비위를 맞춰주는 것이 향후 기업에 악영향을 줄수도 있다는 것입니다. 
 

6. 마케틀리, 프로덕트 중심 기업으로 거듭니다

마케틀리의 CEO 크리스는 조직 책임자로부터 변화가 시작된다는 사실을 스스로 이해했다.
자신이 성과물지향적, 고객중심적 사고방식을 취하고 불확실성을 기꺼이 받아들이지 않으면 아무 직원도 그렇게 안 할 거라는 걸 알고 있었다. 

...(중략) 기업들이 저지르는 가장 큰 실수 중 하나는 경영진이 변화를 자신들이 아닌 다른 직원들의 몫으로 여기는 것이다.

우리 조직에서 저는 PM이라고 불리고 있지만, 아쉬운 점이 참 많습니다. 성과물 지향적으로 일하고 싶고, 마케팅 부서가 가져오는 산출물 중심적인 요구사항을 거절하고 싶지만, 거절할 수 있는 권한이 없습니다. 다들 좋은 게 좋은 거라고 합니다. 저도 아니라고는 말을 못 하겠네요. 그래도 언젠가는 조금씩 마케틀리 같은 기업으로 나아가면 좋겠습니다.
 

후기. 개발 함정에서 벗어나 프로덕트 중심 기업으로 거듭나기

프로덕트 매니저로 첫걸음을 내디뎠을 때는 겸손을 배워야 했다. 내 역할은 거창한 아이디어를 내는 게 아니라 나쁜 아이디어를 끝장내는 것이었다.

팀원들과 실험하면서 데이터의 힘을 배웠다. 어떤 의견이 나오든 데이터가 백전백승이다.

고위직으로 올라가면서 훌륭한 전략 틀이 회사의 성패를 좌우한다는 것을 배웠다. 

컨설턴트가 된 후에는 조직 내 인물들의 힘을 배웠다...(중략)... 위험을 줄이려면 사람의 마음을 무엇이 움직이는지 깊이 이해하고 그들을 설득할 정보와 데이터를 제시해 동기를 자극해주어야 한다.

훌륭한 직원을 도저히 성공할 수 없는 환경에 밀어 넣는 것이야말로 그들의 사기를 꺾는 지름길이라는 사실도 컨설팅을 통해 알게 됐다.

아마존, 넷플릭스, 구글 등 오늘날 최고의 자리를 지키는 기업치고 고객의 요청이라면 무엇이든 수용하고 개발해 주는 곳은 없다. 애자일 프로세스를 무작정 따르면서 만들 수 있는 기능을 빨리빨리 개발하고 보지 않는다. 그 대신 고객에게 가치를 전달한다는 의도 아래 프로덕트를 개발한다. 

이 책을 참 재미있게 읽어서 마무리 멘트를 쓰려고 했는데, 작가의 후기가 곧 제 후기가 되겠네요. 제가 경험한 것도, 경험하지 못한 것도 많지만, 제가 10년이 넘게 BA/PM으로 일하면서 느끼고 생각했던 것들을 잘 정리해 준 책입니다.
설명이 친절하지 않아서, 다소 읽기 힘든 부분도 있었지만, 전반적인 흐름을 생각한다면 PM이 되고자 하거나, 이미 PM으로 일하면서 어려움을 겪으시는 분들이 읽어보면 좋겠다는 생각을 했습니다. 특히 프로덕트 중심 조직을 만들기 위해 경영진이 읽어보면 좋은 책이라는 생각이 들었습니다.

부록. 프로덕트 중심 기업 여부를 판단하기 위한 6개 질문

질문	좋은 기업	나쁜 기업	비고
1. 최근 개발한 기능이나 프로덕트 관련 아이디어는 누가 냈는가?	프로덕트팀이 아이디어를 낸다.	경영진이 아이디어를 낸다.	실무진이 개발 중인 제품을 왜 개발하는지 모른다면 심각한 상황이다.
2. 최근 무산시킨 프로덕트는 무엇이었는가?	회사의 목표 달성에 기여하지 못하는 프로덕트와 아이디어는 무산시킨다.	모든 프로덕트와 아이디어를 개발한다.	고객과의 약속, 연도예산, 경영진에 대한 두려움이 원인이다.
3. 마지막으로 고객과 대화한 것은 언제였는가?	고객과 대화하는 것을 장려한다.	고객을 귀찮게 한다고 생각한다.	고객과의 대화는 문제를 찾기 위한 활동으로 PM업무에서 큰 비중을 차지해야 한다.
4. 무엇이 목표인가?	목표를 명확히 표현한다.	목표를 명확히 표현하지 못한다.	회사의 목표를 모르고 목표를 어떻게 달성할까?
5. 현재 무슨 일을 하고 있는가?	문제 자체에 열정을 쏟는다.	해결 방안에 열정을 보인다.	문제 해결에 집중해야지, 문제를 해결하기 위한 방안에 집중하면 자칫 주객이 전도될 수 있다.
6. 사내 프로덕트 매니저들은 어떤가?	프로덕트 매니저를 존중한다.	프로덕트 매니저를 무시한다.	프로덕트 매니저를 존중하지 않는 조직은 답이 없다.