본문 바로가기
업무 관련 생각들

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

by 우공80 2023. 3. 20.
728x90

개발 함정을 탈출하라

"개발 함정을 탈출하라" 라니 제목부터 너무 끌리지 않나요? 저는 프로덕트 매니저로 일하고 있습니다만, 프로덕트 매니저의 역할이 무엇인지 사실 잘 모르고 있었습니다. 그래서 프로덕트 매니저가 무엇인지, 좋은 프로덕트 매니저가 되기 위해서는 어떻게 해야 하는지 알아보고자 이 책을 선택했습니다. 

1부 개발 함정

 
1부에서는 이 책의 제목인 개발함정이 무엇인지 정의하고, 진정한 프로덕트 매니지먼트는 어떤 것인지 이야기합니다.

성과물이 아닌 산출물을 성공 기준으로 삼다가 옴짝달싹 못하게 됐을 때, 소프트웨어에 들어가는 기능의 실제 가치는 확인하지 않고 기능을 개발해서 출시하기에만 급급할 때 기업은 개발 함정이라는 덫에 빠진다. 사용자에게 효용가치를 전달하지 못하는 조직은 시장 점유율을 잃으면서 무너지기 시작한다. 이 개발 함정에서 빠져나오려면 탄탄하고 계획적인 프로덕트 매니지먼트 관행을 발전시켜야 한다. 그럴 때 프로덕트 매니저는 비로소 사업가치와 고객가치를 극대화할 기회를 찾게 된다. 

 시작하자마자 제 속을 시원하게 긁어주는 말이 나왔는데요. 실제로 큰 효용이 없다거나, 심지어 원복 해서, 효용이 마이너스(-)인 기능을 개발하는 경우가 너무나도 많기 때문입니다. 절대 이런 것이 바람직하지 않다고 생각하는데도 이런 개발을 할 수밖에 없다는 것에 자괴감도 느끼죠. 이 책에서 이런 괴로움에 대한 해답을 얻었으면 합니다.

- "그쪽 시장에서 서비스를 제공해 본 적도 없는데 처음부터 전부 새로 만들어야 할 판이에요. "

- "로드맵이 있어야 하는데 고객에게 설득할 거리를 주는 사람이 아무도 없어요. 저는 그냐야 나가서 고객사들에게 공수표나 날리며 실적을 올리고 있어요."

- 이 회사에는 지시를 내리는 사람이 너무 많았다. 

- 내가 정말 어떤 기능을 개발해야 할지 재고해 보자고 말할 때마다 프로덕트 매니저들의 반발은 엄청났다. "경영진이 시킨 거예요. 이 기능을 출시하지 않으면 제 상여금이 날아가요." 그들은 형편없는 계획과 전략 때문에 고생 중이었다.

- 몇 주 후 수강생들이 새 기능을 얼마나 쓰는지 확인해 보았다. 새 기능을 쓰는 사람은 아무도 없었다. 공들여 그 많은 기능을 만들었는데도 마케틀리는 제자리만 맴돌 뿐이었다.

- "이 회사는 그런 의견을 낼 수 있는 구조가 아닙니다. 직원들은 CEO나 상사와 대화하길 두려워해요. 문제 해결 여부가 아니라 기능 출시 여부에 따라 상여금을 지급하시잖아요. 그래서 직원들은 출시를 안 하면 돈을 못 받는다고 생각합니다."

마케틀리는 개발 함정에 빠진 회사의 전형적인 예다. 훌륭한 아이디어나 프로덕트가 없는 게 아니라 회사 자체가 그 프로덕트를 계속 성공시킬 준비가 되어있지 않은 것이 문제였다. 진정한 가치 창출을 장려하고 지속하는 데 필요한 직무, 전략, 절차, 정책이 갖춰져 있지 않았다. 

무엇이 중요한지 보지 못하고 가치가 무엇을 의미하는지 기억하지 못하는 상태에서 만들어낸 프로덕트는 망한다. 

개발함정은 소프트웨어 출시 과정에만 도사리지는 않는다. 개발 함정에서 탈출하기 위해 항상 해오던 방식을 바꿀 필요성을 깨닫고 산출물 중심의 업무 평가를 진정한 가치 평가와 혼동할 때 함정이 나타난다. 개발 함정에서 탈출하려면 개발팀뿐만 아니라 회사 전체도 살펴보아야 한다. 지속적으로 가치를 창출할 수 있도록 최적화하는 조직, 기업 차원에서 프로덕트를 성장, 지속시킬 준비를 하는 조직이 프로덕트 중심 조직이다. 

마케틀리는 책에서 예시로 들은 가상의 회사입니다. 그런데, 나오는 내용마다 우리 회사 같네요. 아마 누가 읽어도 본인 회사 같다고 생각이 들 거 같기는 합니다만, 문제는 "우리 회사는 안 그런데?"라고 말하는 회사가 우리 경쟁사일 수도 있다는 것이겠죠.

가치 교환 체계

가치를 잘못 이해하면 개발 함정에 빠진다. 회사가 소비자에게 안겨주고 싶은 성과가 아니라 생산물 개수를 기준으로 가치를 매기는 것이다.

소비자와 사용자에게는 문제, 바람, 필요가 있다. 다른 쪽에는 그 문제를 해결하고 바람과 필요를 채워주는 제품이나 서비스를 만드는 기업이 존재한다. 소비자는 문제가 해결되고 바람과 필요가 채워질 때 가치를 깨닫고 그다음에야 기업에게 가치를 돌려준다.

마케틀리는 영업과정에서 고객사들과 계약을 맺기 위해 약속을 남발했다. 그 결과, 특정 고객사 한 곳만을 위한 단발성 기능이 잔뜩 쌓였다. 많은 고객에게 유용한 프로덕트를 개발하는 방향으로 전략적 선택을 하지 않았다. 그들은 각 기능이 고객사들에게 어떤 고유한 가치를 제공했는지를 분석해 기업전략을 발전시키는 대신 고객사의 요구에 부응하는 데만 급급했다.

프로덕트와 서비스가 고객의 문제해결, 욕구나 필요를 충족시킬 수 있고, 이것이 반복되어야 기업이 성공할 수 있다. 이런 것은 직원들이 고객에게 더 가까이 다가가 배워야 하며, 직원 개개인이 아니라 조직차원에서 그에 맞는 정책이 있어야 한다.

산출은 우리가 제작해 쉽게 정량화할 수 있는 것들이다. 프로덕트나 기능의 개수, 출시 횟수, 개발부서의 속도 등이 그 예다. 그 기능을 출시해 소비자의 문제가 해결되도록 하는 것이 성과다. 

가치 교환 체계
가치 교환 체계

이 글에서 말하는 가치교환체계를 의심하거나 부정하는 사람은 없을 것 같습니다. 그럼에도 불구하고, 이런 가치실현체계를 무시하는 경우를 자주 보게 됩니다. 그래서 기능의 개수, 코드의 양, 백로그의 양 같은 것으로 성과를 평가하는 것이죠. 회사에서도 "가치"를 생각하지 않는 것은 아니라고 생각합니다. 다만, 소비자의 문제, 바람, 필요를 계량화하기 어렵기 때문에 쉬운 길을 가는 것이 아닐까 싶습니다. 그리고 아주 심각하게 생각하지는 않기도 하고요.

예전에 회사 내의 어느 부서는 담당 임원이 직원들 상품 출시 개수 순서대로 고과를 주겠다고 했다는 말을 들었습니다. 그것이 일개 직원도 아니고, 임원의 사고방식이라는 것이 더 충격적이기도 했습니다.
그리고, 고객의 요구에 부합한다는 것마저도 고객에게 제공한 “가치”를 기준으로 다시 평가해야 합니다. 실제로 특정 고객의 요구에 따라 기능을 개선을 했지만, 다른 고객은 불편을 겪거나, 기능을 요구했던 특정 고객마저도 사용 빈도가 낮은 기능을 개발하는 경우도 많습니다. 
하지만 처음에 나온 것처럼 "고객의 요구", 라던지 "성과 평가"는 개인의 노력으로 극복이 불가능합니다. 조직 전체가 프로덕트 중심이 되어야 합니다.

프로젝트 대 프로덕트 대 서비스

프로젝트 매니지먼트 식의 사고방식을 이끌어주는 모범 실무 프레임워크와 자격증은 많다. PRINCE2, PMI, PMBOK 등을 예로 들 수 있다. 개발 함정에 빠진 기업은 이런 프레임워크를 프로덕트 매니지먼트 프레임워크와 혼동하곤 한다.


프로덕트, 즉 제품이란 앞에서 말했듯이 가치를 전달하는 매개체이다. 매번 기업이 신제품을 선보이지 않아도 소비자와 사용자에게 반복적으로 가치를 전달해 주는 것이 프로덕트다. 하드웨어, 소프트웨어, 소비재 등 인간의 개입 없이 사용자에게 가치를 전달할 수 있는 모든 것이 프로덕트다. 마이크로소프트 엑셀, 이유식, 틴더, 휴대폰이 모두 제품, 프로덕트다. 

서비스는 프로덕트와 달리 인간이 주요 역할을 수행해 사용자에게 가치를 전달하는 것이다. 로고나 브랜드를 만드는 디자인 회사, 세무를 대행하는 세부법인 등이 서비스 기반 조직이다. 

많은 기업은 프로덕트와 서비스를 결합해서 가치를 전달하므로 서비스와 프로덕트가 어우러져 하나의 체계를 이루도록 최적화해야 사용자를 위한 가치 흐름을 키워 성공할 수 있다. 
이 지점에서 프로젝트가 등장한다. 

프로젝트는 특정 목표 달성을 위해 개별적으로 지정하는 업무 범위다. 프로젝트에는 마감일, 이정표, 완성해야 할 산출물이 정해져 있다. 프로젝트는 프로덕트 개발에서 빠질 수 없는 부분이지만, 프로젝트 안에만 갇힌 사고방식은 위험하다.

프로덕트는 잘 보살피고 성숙하게 키워야 할 대상이다. 그러려면 시간이 오래 걸린다. 기능을 출시해 프로덕트를 개선하면 프로덕트 전체가 더 큰 성공을 거둘 수 있다. 이 기능 개선활동이 프로젝트이지만 프로젝트가 끝나더라도 일은 계속된다. 새 프로젝트에서 기회를 계속 물색하면서 반복적인 개선활동으로 전체적인 결과를 개선하고 프로덕트를 성공시켜야 한다. 

우리는 프로젝트가 일의 끝이라고 생각하는 경향이 많은데, 그 뒤에도 프로덕트는 지속적으로 키워야 할 대상이라고 본다면 프로젝트를 대하는 마음부터 달라질 것 같습니다. 

프로덕트 중심 조직

프로덕트 중심 기업은 프로덕트의 성공의 회사의 성장과 가치 창출의 주요 동력임을 안다. 프로덕트 성공을 중심으로 우선순위를 매기고 조직을 구성하고 전략을 짠다. 

프로덕트를 중심에 두지 않는 기업의 중심에는 무엇이 있을까?

영업중심: 계약서에 따라 프로덕트 전략을 정의한다. 전략을 전체적으로 정렬하지 않고 고객사에 해준 약속에 따라 프로덕트 로드맵과 방향성을 결정한다.

비전 중심: 애플. 단, 올바른 비전이 있다면 엄청난 위력을 발하지만, 스티브 잡스 같은 인물은 흔치 않다. 게다가 그 비전이 사라지면 프로덕트는 방향을 잃고 무너지기 십상이다. 애플도 팀 쿡이 CEO로 부임하면서 그런 난관과 싸워야 했다. 

기술 중심: 가장 근사한 최신기술을 중심으로 회사가 움직이며 주로 시장을 직시하고 가치를 중심에 두는 전략이 없어 어려움을 겪는다. 기술은 소프트웨어 기업 성공의 중요한 열쇠이지만 프로덕트 전략까지 기술에 좌우되게 놔둘 수는 없다. 주도권은 반드시 프로덕트 전략에 있어야 한다. 기술에 주도권을 맡기는 기업은 무척 멋있지만 정작 아무도 안 사는 프로덕트를 열심히 생산한다. 

우리 회사는 어떤 것을 중심에 두고 있는 걸까요?? 넷 중에 무엇에 해당하는지 모르겠어서 당황스럽네요. 회사가 커서 그렇겠지만, 굳이 따지자면  조직별로 네 가지가 적당히 섞였다고 할까요?

우리는 무엇을 알고 무엇을 모를까?

아는 줄 아는 것: 데이터나 고객사들이 보내온 핵심요구사항에 들어있는 사실 정보다. 정부 규제 때문에 반드시 지켜야 할 사항, 업무 수행에 기본적으로 필요한 요건 등

모르는 줄 아는 것: 아는 줄 아는 것의 항목 중 불확실한 것. 어떤 질문을 해야 할지 알 정도로 명확히 정리된 것이다. 시험해보고 싶은 가설, 조사할 수 있는 데이터 포인트. 탐구와 실험으로 답을 확인하고 그 답을 사실 정보로 변환하고 그 사실 정보에 부합하는 프로덕트를 개발한다.

아는 줄 모르는 것: '왠지 이게 맞을 것 같은' 것으로 이런 직감은 수년간의 경험에서 나온다. 직감에 귀 기울이되 그것을 통해 편견을 쌓지 않도록 주의하자. 직감이 맞았는지 점검과 실험으로 확인해야 한다.

모르는 줄 모르는 것: 모르고 있다는 사실조차 모르는 것이다. 알맞은 질문을 할 수도, 지식 격차를 파악할 수조차 없을 만큼 아는 것이 없는 상태다. 고객과 대화를 나누거나 무관해 보이는 데이터를 분석하는 과정에서 이런 정보가 발견되곤 한다. 

프로덕트 매니지먼트는 모르는 줄 아는 것을 알아보고 조사하며 모르는 줄 모르는 것을 줄여나가는 것이다.

영업, 마케팅, 기술, 디자인 등 회사의 다양한 직무를 생각해 보자. 이 직무의 상당수가 기술 영역과 사업 영역 둘 중 하나에만 머물러 있다. 반면, 프로덕트 매니저는 그 두 영역의 징검다리가 되어 고객들의 필요를 제품이라는 언어로 해석하고 고객을 만족시키는 동시에 사업의 성장과 지속 가능성을 도모하는 존재다. 

아는 것과 모르는 것
아는 것과 모르는 것

책에는 아는 줄 모르는 것과 모르는 줄 아는 것이 바뀌어있는데, 문맥상 모르는 줄 아는 것이 맞는 것 같아서 본문과 그림을 수정하였습니다. 아는 것과 모르는 것을 정의하는 것만으로도 제가 해야 하는 역할이 무엇인지 명확해지는 것 같습니다. 프로덕트 매니저로 일을 하다 보면 정말 아는 게 없는 사람처럼 계속 질문을 하게 됩니다. 업무에 대한 전문성이 없기 때문에 계속 질문만 하게 되는 것이라는 생각을 한 적도 있는데요. 지금은 계속 질문하는 것이 프로덕트 매니저의 역할이 아닌가 생각합니다. 답은 프로덕트 매니저가 내지 않아도 됩니다. 중요한 질문을 던지는 것이 가장 중요한 역량이 아닐까요? 그리고 한편으로는 시간 남을 때마다 이런 데이터 저런 데이터 뒤지다가 새로운 것을 발견하여 개선한 적도 있는데요. 그런 측면에서 제가 잘못하지 않았다는 위로가 되는 내용이었습니다.
 

2부에 계속..

2023.03.21 - [IT 말고/책] - [경영] 개발 함정을 탈출하라 - 2부 프로덕트 매니저의 역할과 커리어

 

[경영] 개발 함정을 탈출하라 - 2부 프로덕트 매니저의 역할과 커리어

2부 프로덕트 매니저의 역할 2부에서는 프로덕트 매니저가 구체적으로 어떤 일을 하고, 프로덕트 매니저의 커리어를 어떻게 구성해야 하는지에 대해 정리하고 있습니다. 프로덕트 매니지먼트는

woogong80.tistory.com

"이 포스팅은 쿠팡 파트너스 활동의 일환으로, 이에 따른 일정액의 수수료를 제공받습니다."

728x90

댓글