[일간 애자일#691](5/3) 캐나다 정부의 프로덕트 매니지먼트 정책 도입의 의미 등

  • 매일 애자일, 린, 조직문화, 협업, 리더십, 자기계발 등과 관련된 새로운 소식을 공유드립니다.
  • 소감, 동의, 반론 등을 댓글로 남겨주세요. 활발한 소통을 기대합니다.
  • 지난 기사는 [여기]에서 보실 수 있습니다

캐나다 정부의 프로덕트 매니지먼트 정책 도입의 의미

  1. 피닉스 프로젝트 실패의 뼈아픈 교훈에서 출발

많은 나라의 정부가 추진하는 정보기술 정책에는 유사성이 있다. 기술에 대한 만성적인 과소 투자, 품질 기반 성능 평가시스템보다는 비용 중심적 평가, 사회 변화에 따른 데이터 및 디지털 역할의 확산 요구는 많으나 종종 디지털 리더십이 부족하고, 임기 내 위험 부담을 회피하는 환경을 갖고 있다. 많은 정부에서 정부 CIO 조직을 마련하고 컨트롤타워로의 역할을 추진하려 하고 있지만 CIO의 비전과 목표만으로는 기존의 업무 관행을 바꾸는 것은 거의 불가능하다.

캐나다 정부는 2009년 연방 공무원을 위한 새로운 급여시스템을 완전히 갱신하는 프로젝트 를 야심 차게 시작한다. ‘피닉스 급여 시스템’ 이라 이름 붙여진 이 거대한 프로젝트는 2년 동안 기술 파트너를 찾는데 시간을 보내고 2011년 IBM과 3천만 달러 계약을 맺는다. 그 후에 수많은 잡음과 충돌이 나고, 예산은 한정 없이 늘어나고, 2016년에 1월에 30만 명의 직원 신상정보가 유출이 된다. 그 후 2월에서야 첫 번째 출시가 된다. 품질 문제가 곧 나타나기 시작했고, 2017년 6월 말까지 누적 급여 오류가 5억 달러를 넘게 되었다. 엄청난 실패를 가져다준 프로젝트였다. 프로젝트가 실패한 원인은 다음과 같이 정리된다.

엔드 투 엔드 프로세스 변환에 대한 전반적인 관리가 제대로 이루어지지 않았다.
비즈니스 프로세스, 인력/기술, 조직 문화, 서비스 및 기능, 인사 데이터 및 관련 인사 시스템의 품질 및 적시 제공에 대한 포괄적인 계획이 개발되거나 구현되지 않았다.
정부 전체의 일관성을 위한 공통 비즈니스 프로세스가 충분히 상세한 수준으로 구현되지 않았다.
역할과 책임에 관해 설계, 문서화 또는 전체적인 프레임워크의 일부로 구현되지 않았다.
전반적인 거버넌스 기구는 없었다.
위험에 대해 오픈하는 문화가 없었고, 진실에 대해 말하는 것을 허락하지도 않았다.
충분히 테스트되지 않았다. 테스트 볼륨과 적용 범위는 시간 및 예산 압박으로 인해 최종 단계에서 축소되었다.

이렇게 어마어마한 예산을 들여 추진했던 프로젝트가 완전한 실패로 끝난 뼈아픈 경험을 가진 캐나다 정부가 최근 정보기술 부분에서 꽤 인상적인 변화를 만들고 있다. 소위 소프트웨어 기업에서 활용하고 있는 프로덕트 매니지먼트 관리기법을 사용하고 디자인 씽킹(Design Thinking), 린스타트업(Lean Startup), 애자일(Agile), 데브옵스(DevOps)까지 도입하며 빠르게 변화를 시도하고 있다.

그림 2는 캐나다 정부의 공공 디지털 서비스를 제공하는 캐나다 디지털 서비스(CDS)가 프로덕트 매니지먼트 그룹장을 채용 하는 공고이다. 정부가 사용하는 프로덕트/서비스를 기획하는 프로덕트 매니저를 관리하고, 정부와의 파트너 관계를 유지하면서 요청하는 디지털 서비스에 대한 비전과 솔루션을 제공하는 역할이다. 공고 내용을 살펴보면 실리콘 밸리에서 채용하는 프로덕트 매니지먼트 그룹장의 기준, 경험이나 역할과 다르지 않다. 단지 업무 파트너로서 정부 부서를 상대할 뿐이다.

매우 놀라운 변화가 아닐 수 없다. 많은 나라의 정부가 디지털 트랜스포메이션을 표방하고 변화를 시도했지만, 실제 프로덕트 매니지먼트를 도입하여 실행하고 있다는 것은 생각보다 훨씬 더 많은 변화를 의미하기 때문이다. 그중에서도 가장 큰 변화는 정부 디지털 서비스의 기준이 ‘프로젝트’에서 ‘프로덕트’로 패러다임이 넘어왔다는 것을 의미한다.

원문:https://bit.ly/3uc5bje


10배 빠르게 업무 성과를 내는 마인드셋

IT 기업을 중심으로 빠르게 사업을 실행을 하는 것이 사업의 중요한 경쟁력이 된다는 것은 이미 공감대가 만들어져 있다. 그리고 서바이벌을 고민해야 하는 스타트업에서는 그 중요성은 더욱더 크게 받아들여진다. 하지만, 빠르게 실행하는 것에 대한 우리가 가진 선입견 때문에 실제로 빠르게 실행하는 조직은 많은 것 같지 않다.

왜 많지 않다고 확신할 수 있냐면, 빠르게 실행하는 것은 실행의 속도의 문제가 아니기 때문이다. 일주일에 100시간 가까이 일하면서 빠르게 성장하는 스타트업을 본 적도 있지만, 그렇게 일하면서도 성장이 더딘 스타트업도 있다. 빠른 실행은 구성원들이 “실행”하는데 시간을 많이 쓴다고 그냥 얻어지는 것은 아니라는 것을 많은 사례로 보아왔다. 하지만 지금도 “우리는 빠르게 실행해야 해”라고 할 때 가장 먼저 얘기가 나오는 것은 근무 시간일 것이다.

시험 준비를 벼락치기하는 예를 들어 보자. 나도 중고등학교, 대학교, 대학원까지 길고 긴 학교 생활에서 벼락 치기를 하지 않았던 시험이 없는 것 같다. 벼락치기의 핵심은 내가 시험을 보기 전에 많은 시간을 투자해서 시험을 준비하는 것에 있지 않다. 시간이 얼마 남지 않은 제약이 생기고 나서야 나는 교과서 100페이지 시험 범위 중에서 어떤 것이 시험에 나올만 한지, 어떤 것은 그렇지 않은 지에 대해 매시간 고민하고 선택 취사해서 공부하게 되었다. 즉, 벼락치기의 핵심은 마감을 앞에 두고 고도의 집중도로 짧은 시간에 많은 일을 하는 것이 아니라, 짧은 시간 내에 내가 꼭 해야 하는 것을 발견(Discovery)해 나가는 것이 핵심이었다.

즉, 빠르게 실행하는 것은 정해진 결과물을 한정된 시간 내에 빠르게 만들어 내는 것이 아니다. 이건 불가능하다 (혹은 계속 그런 방식을 유지할 수 없다). 빠르게 실행한다는 것은 한정된 시간 내에서 만들 수 있는 목표와 가장 가까울 수 있는 결과물로 업무를 한정하고 이를 받아들이는 것이다. 빠른 실행에서 제한 요소는 결과물의 요구 사항이 아니라 시간인 것이다. 시간을 아무리 효과적으로 써도 24시간을 240시간처럼 쓸 수는 없다. 하지만 한정된 시간 때문에 우리가 정말 중요한 것만 보려고 한다면, 만드는데 240시간이 걸릴 만큼 결과물이 결국 어떤 가치를 전달하는 것인가에 더 집중하게 된다. 최종 목표로 생각한 결과물이 사실은 그 가치를 전달하기 위한 도구인 셈이다.

원문:https://bit.ly/3uceuzS


1편 일을 제대로 리딩하는 법 / 3화 일을 만드는 구조

Why는 일의 이유다. 안타깝게도 왜 그 일을 해야 하는지 알고 수행하는 사람은 많지 않다. 설명해주거나 설득하는 사람이 별로 없기 때문이다. 물론 Why만 유독 강조하는 관리자들이 있다. 이들은 괜찮은 사람처럼 보인다. Why를 강조하는 것은 업무에 뛰어들 분위기를 만드는 데 분명 도움이 된다. 하지만 이것만 늘어놓는 것은 허무함을 가져온다. ‘그래, 해야 한다는 건 알겠는데, 다음은 뭔 데?’라는 반응이 뒤따르기에 십상이다. 집은 당위성만 가지고 지을 순 없다. 이런 관리자는 실무에는 약하고 마음씨만 좋은 ‘몽상가’ 타입이다.

그 다음은 일의 주제(WHAT)다. 일을 잘 분류해서 단계별, 분야별 주요 사항을 발라내야 한다. 마치 집을 지을 때 집 전체를 받쳐주는 주춧돌과 기둥을 잘 아는 것과 비슷하다. 하지만 여기서 멈춘다면 실무자는 우왕좌왕할 수 있다. 구체적인 방도까지 함께 꿔내야 한다. 잘 모르겠다면 함께 찾아보자고 해야 한다. 본인도 모르면서 두루뭉술한 지시만 하고, 결과를 가져오라 독촉만 하는 관리자는 (나쁜) 권위주의자 타입이다.

실행(HOW) 단계에선 실무진의 의견을 들어야 한다. 단순히 의견을 수렴하는 것뿐만 아니라 일부 사안은 과감하게 위임하는 것이 필요하다. 특히나 요즘 젊은 세대는 본인의 의견이 일에 직접 반영되는 것을 선호한다. 전반적으로 그들의 자발적인 반응을 끌어낼 수 있다면, 작은 부분이 망가지는 것까지 감수할 수 있는 것이다.

마지막으로 교훈(Lesson learned)을 얻을 차례다. 일은 복기를 통해 완전히 종료되며 교훈을 남긴다. 그 교훈은 후일을 위한 기본 토양이 된다. 우리는 교훈을 얻기를 꺼리는 경향이 있다. 잘된 경우에는 뭘 그런 거까지 하나 싶은 생각이 들고, 못된 경우에는 안 좋은 기억과 다시 대면하기 싫기 때문이다. 그래도 맞닥뜨려야 한다. 그래야 일을 다시 시작할 수 있다.

원문:https://bit.ly/338fgSv


우리는 성장을 위해 올바른 노력을 하고 있는가

우리는 선택적 노력을 하지만,
그 선택은 전략적이지 못할 때가 많다

우리는 각자의 방식으로 성장을 위한 노력을 한다.

오래전부터 해왔던 여러 루틴을 꾸준히 가져가기 위해 하는 여러 종류와 힘이 필요한 다양한 노력부터, 어떤 일을 새롭게 시작할 때 하는 사전적 활동도, 새롭게 추진하여 실행한 일들을 잘 마무리 짓는 것도 모두 각자가 가진 방식대로 진행한다. 유지, 반복하는 것이 곧 성장할 수 있다는 믿음 아래, 새롭게 시작하게 되는 모든 일을 다할 수 없어 선택적으로 노력한다. 그것도 일종의 능력의 일종이다.

하지만, 우리는 이를 전략적으로 활용하지 못한다.

무언가를 새롭게 시작하여 이를 추진하는 것에만 초점을 맞추지, 그다음에 이어질 여러 활동들과의 인과 및 상관관계, 내가 현재 하고 있는 새로운 활동과 기존 활동 간의 ‘부딪힘’에 따른 긍정/부정적 효과 등 각종 시너지 등에 대하여 생각하지 않는 경우가 많다. 새로운 활동은 기존의 활동을 대체하거나, 가치를 더하는 쪽으로 해야 하지만, 이러한 관련성을 갖지 못한 경우가 많다. 그저 누군가를 따라 하거나, 좇거나, 막연하게 되고 싶다는 생각으로 하는 시도(try)에 가까운 것이 대부분이다.

예를 들어, 가장 일상적인 ‘독서’도 마찬가지다.

어떤 기준과 목적으로 책을 선택해야 하고, 그걸 어떻게 활용해야만 잘 읽고 활용한다고 볼 수 있고, 단순히 읽는 것에 그치지 않고, 함께 읽거나, 읽고 토의 또는 독후감과 같은 것을 쓰는 것도 마찬가지다. 기왕이면, 자신의 일과 삶에 적극적으로 도움을 줄 수 있는 요소를 갖춘 책을 고르는 것도, 이를 내 일과 삶에 전략적으로 활용하기 위한 읽고 활용하는 방법을 책과 그 주제에 맞도록 사용할 수 있는 것도 역량, 실력일 수 있기 때문이다.

**조금 더 기획적/전략적 요소를 더해보면, 되고자 하는 나를 위한 다양한 활동들이 널려있다. 처음에는 막연하게 누군가를 닮고 싶다는 생각을 갖고 시작할 수 있지만, 변화하는 자신의 모습으로부터 새로운 기획이 나타날 수 있고, 그에 대한 디테일을 부분적 전략과 전술로 검증하고 완성하는 과정에서 나만의 원리와 원칙(Principle & Rule)이 만들어질 수 있다. 물론 이 부분도 자연스럽게 변화한다. 이 과정에서 내가 가진 정체성(Identity)도 그 정체성에 어울리는 생각과 태도 등도 비로소 자연스럽게 나타날 수 있는 것(Routine)이다.

원문:https://bit.ly/3ea7xJO


중고신입 전성시대..멘토링만 바꿔도 탈출 막는다는데..

지금 회사 그냥 다니기 VS 경력 포기하고 ‘쌩’ 신입되기
당신의 선택은?

취업포털 사람인이 올해 성인남녀 3833명을 대상으로 한 설문에 따르면 2명 중 1명은 경력을 포기하고 신입으로 지원한 경험이 있었다. 중고신입으로 지원해도 무리가 없을 저연차 사원들이 직장에 마음을 두지 못하는 것으로 보인다. 기껏 뽑았는데 1-2년 후면 나가버리는 현실 앞에서 조직의 고민도 깊다.

그런데 의외로 답은 가까운 곳에서 찾을 수 있다. 바로 멘토링이다. 대부분 회사는 입사 초 신입사원에게 선배 사원을 멘토로 붙여준다. 멘토가 어떻게 이끌어가느냐에 신입사원의 열정과 몰입을 끌어낼 수 있다고 한다. DBR 206호에 실린 기사는 심리학자 클레이튼 앨더퍼(Clayton Alderfer)의 ERG이론을 활용한 멘토링 기법을 소개한다.

원문:https://bit.ly/3uc5ESw

[일간 애자일#645](2/8) 덜컥 리더가 된 이가 비즈니스에 고전하는 9가지 이유 등

  • 매일 애자일, 린, 조직문화, 협업, 리더십, 자기계발 등과 관련된 새로운 소식을 공유드립니다.
  • 소감, 동의, 반론 등을 댓글로 남겨주세요. 활발한 소통을 기대합니다.
  • 지난 기사는 [여기]에서 보실 수 있습니다

덜컥 리더가 된 이가 비즈니스에 고전하는 9가지 이유

직장인은 조직의 비즈니스에 ‘참여자’로, 리더와 책임을 나눠 갖는다. 지분은 없다. 그럼 직장인은 어디까지 비즈니스를 알아야 할까. 어려운 부분이다. 책에 씌여있는 경영 경제 관련 지식만으로는 어렵고, 그렇다고 모두 경험할 수 없다. 그렇다고 포기도 안된다. 꾸역꾸역 Business Friendly 하는 방법밖에 없다. 그런데, “그게 뭔가?!” 말이다. 급하게 리더급으로 올라선 대다수가 이런 혼란 속에 맴돌고 있다.

비즈니스는 어렵다. 그럼에도, 불구하고 우리는 비즈니스를 위한 노력은 좀처럼 하지 않는다

우리네 직장인은 조직에서 여러 이유로 다툰다.

더 많이 일을 하기 위해, 또는 덜 하기 위해.

하지만, 늘 마음대로 되지 않는다. 왜? 비즈니스를 잘 모르기 때문이다. 비즈니스가 무엇으로 구성되어 있고, 그중에 내가 맡고 있는 책임 영역이 무엇이며, 이것이 누구의 어떤 영역과 연결 및 중첩되어 있으며, 이런 복잡한 상황에서도 주어진 책임을 적절히 수행하고 있다는 증거(KPI)를 무엇으로 제시해야 하는지 말이다.

‘직장인’ 만큼의 근시안적 접근이 한계다.

결국, 우리 조직의 비즈니스가 무엇이고, 그중에 맡고 있는 영역 속에서 자의 반 타의 반으로 발생시켜야 할 가치와 최적화된 방법론에 대한 개발 및 적용은 꿈도 꾸지 못한다. 하루하루 해야 할 일(Works) 때문에 퇴근하기도 벅차다. 대다수가 오늘의 할 일을 어떻게 하면 슬기롭게(?) 내일로 미룰 것인가에 대하여 고민할 뿐이다.

당연히 비즈니스는 안중에도 없다.

회사가 잘 되는 것(성장하는 것)과 자신의 일이 잘 되는 것 사이에 미묘하고 복잡한 상관관계를 따지고 싶지 않다. 머리 아프기 때문이다. 그래서 열심히 머리 박고 주어진 일(Tasks)을 제 때(Due-date)에 처리하는 것만으로 목표를 하향 조정한다. 그리고, 이를 달성했을 때, 일에 대한 만족감을 느낀다. 그런데, 그것도 오래가지 못한다. 금세 익숙해지기 때문이다.

비즈니스를 위한 노력은 커리어를 위한 노력과 맥을 같이 한다.

그 익숙함에 대해 스스로 백기를 들고 환영하면 큰 일이다. 어느덧 경험과 연차가 쌓이며, 좀 더 무겁고 큰 책임을 짊어져야 할 자리에 갈 것이기 때문이다. 나도 모르게 ‘비즈니스에 가까워져’ 버렸다. 아뿔싸, 미리부터 비즈니스를 공부할 것…이라는 후회가 밀려온다.

그렇게 우리는 준비도 없이 리더 혹은 리더에 가까운 위치가 된다

<비즈니스에 고전하는 9가지 이유>

첫째, 시장 경험이 거의 없거나, 다소 생소하고 생경한 ‘비즈니스’에 겁 없이 뛰어들어 일을 해야 한다.
“나는 할 수 있다 또는 해야 한다”라고 무작정 믿는다.

둘째, 비즈니스를 비즈니스로 보는 것에 그친다.
비즈니스 속 여러 요소가 있음에도 ‘돈’만 집중해서 본다.

셋째, 사업에 정해진 길이 있다고 착각한다.
결국, 과거의 경험 또는 몇몇의 타인을 의존하여 의사결정을 한다.

넷째, 자신의 리더십에 대해 과소 또는 과신하고 있다.
자신이 어떤 리더십 스타일을 지향하는지 잘 모른다

다섯째, 함께 하는 동료들을 믿지 않는다.
그저 이용만 하려고 한다. 그걸로 충분하다고 믿는다

여섯째, 목적과 목표를 명확히 공식화하지 않는다.
발생한 문제만 우선적으로 대응 및 대처합니다.

일곱째, 한 단계 높은 성장 및 확장을 위한 복안(腹案) 등을 생각하지 않는다.
다양한 시나리오를 갖고 움직이지 않는다. (Pivoting = Spin off vs Split off)

여덟째, 비즈니스에 대하여 학습하지 않는다.
주어진 상황 안에서 판단만 내리려고 한다.

아홉째, 비즈니스와 자신의 인생 방향을 동일시하려는 노력을 하지 않는다.
비즈니스와 삶을 별도로 두고, 두 가지 페르소나를 갖추려고 한다.

원문: http://bit.ly/3nfYQzn


프로덕트 매니저가 제품 아이디어를 관리하는 방법

프로덕트 매니저로 일하다보면, 여러 경로로 제품에 대한 다양한 제안과 피드백을 받게 됩니다. 새로운 아이디어가 나타날 때마다 ‘앗.. 이거 해야 하나..?!’ 라며 흔들리지 않으려면 분명한 목표와 탄탄한 로드맵이 있어야 합니다. 그리고 그 로드맵 안에서 제안된 여러 아이디어를 잘 조합하고 훌륭한 액션 아이템으로 발전시켜 프로덕트의 개선을 만드는 것이 바로 프로덕트 매니저의 일입니다.

아이디어를 잘 모으고 관리한다는 것이 생각처럼 쉽지 않을 때가 많은데요. 번역/편집해 소개하는 아래 글에서는 아이디어 관리 방법을 단계별로 쪼개어 구체화해두었습니다. 여기저기 흩어진 아이디어는 많은데 어떻게 활용해야할지 고민된다면 참고해보시기 바랍니다.

원문: https://bit.ly/2O7KAMQ


PM에게 유용한 ‘인수 기준’ 작성법

How to Craft Strong Acceptance Criteria for a User Story 원문을 요약했습니다.

제가 일하는 팀은 인수 기준(Acceptance criteria)을 작성하지는 않고, 테스트 케이스를 프로젝트 초반에 작성하여 유사한 역할을 담당하는데요.

개인적으로 PM이 인수 기준(Acceptance criteria)의 범위와 pass/fail 기준을 신중하게 검토하는 것이 중요하다는 점에 공감이 되어서, 주요한 혹은 유저 스토리 대상으로 사례를 만들어볼까 생각해봤습니다.

인수 기준(Acceptance criteria)은 우리가 마치 장보기 할 때, 사야 할 물건을 정리한 리스트와 유사함. 프로덕트의 기능을 성공적으로 개발하기 위한 체크리스트, 일종의 완료조건.

에자일에서 유저 스토리(user story)는 ‘사용자’ 관점에서 기능이 무엇인지 정의하는 것을 의미함. 좋은 유저 스토리 정의는 필수적으로 좋은 인수 기준((Acceptance criteria)의 작성을 필요로 함. 인수 기준은 팀이 유저 스토리의 범위에 무엇이 포함되고, 무엇이 제외되는지 제품 개발 범위를 이해하는데 도움이 됨.

Best practices for writing acceptance criteria

# 1. Who, When and How?
# 2. Shared understanding and consensus
# 3. Clarity comes first
# 4. Make it testable, measurable and achievable
# 5. The format

원문: https://bit.ly/3pUM4YS


생존을 위한 ‘피벗’…대기업도 별도의 괴짜 조직 만들어야

시장이 급변함에 따라 가설과 검증을 통해 비즈니스 모델을 빠르게 수정하는 피벗 전략의 중요성이 커지고 있다. 변화에 대한 유연한 대처가 핵심인 피벗을 실천하려면 린스타트업 방식을 이해해야 한다. 특히 대기업은 기존과는 다른 방식으로 팀을 디자인하며 혁신 조직을 만들어야 한다. 혁신의 종류에 따라 규정집의 부록 같은 별도 절차를 만들거나 아예 별도 건물에 독립적인 조직을 구축할 수 있다. 린스타트업의 선구자인 ‘스티브 블랭크’ 스탠퍼드대 교수는 기업의 규모와 상관없이 피벗 전략이 중요해진 만큼 구체적인 실행 방안이 필요하다고 강조했다. 그와의 인터뷰를 소개한 DBR 313호의 내용을 통해 알아보도록 하자.

원문: https://bit.ly/3tBhxBG


How Programmers and Testers (and Others) Should Collaborate on User Stories

Have the testers on your team ever struggled with what they should do early in a sprint before the programmers have finished coding a user story?

And have the programmers ever wondered what they should do near the end of the sprint while the testers are verifying the implemented code? Are they tempted, perhaps, to start on the next user story even though it can’t be finished in the sprint?

When a team discovers the right way to collaborate on user stories, these questions vanish. Plus, the team is able to deliver more value more regularly to its stakeholders.

원문: https://bit.ly/3cLjjKw


[일간 애자일#632](1/20) 나는 어떤 프로덕트 매니저 유형일까? 등

  • 매일 애자일, 린, 조직문화, 협업, 리더십, 자기계발 등과 관련된 새로운 소식을 공유드립니다.
  • 소감, 동의, 반론 등을 댓글로 남겨주세요. 활발한 소통을 기대합니다.
  • 지난 기사는 [여기]에서 보실 수 있습니다

나는 어떤 프로덕트 매니저 유형일까?

맥킨지에서 2017년에 실리콘밸리의 Product Manager들의 유형과 역량을 조사한 글인데, 지금 읽어봐도 고개가 끄덕여 지는 부분이 있다.
https://www.mckinsey.com/industries/technology-media-and-telecommunications/our-insights/product-managers-for-the-digital-world

이 글의 내용에서 유형에 대한 부분만 발췌해서 요약해보려고 한다. 원문 번역이 아니라 내 이해를 바탕으로 쓴 것이므로, 더 자세히 궁금하다면 원문을 읽어보길 추천한다.

1) Product Manager의 역할
개발, 디자인, 고객 만족, 세일, 마케팅, 운영, 재정, 법, 등등의 프로덕트의 기능들의 전문가들이다. 무엇을 하겠다고 의사결정을 할 뿐만 아니라 무엇을 어떻게 만들고 런칭할 지 영향을 줄 수 있다.

2) Product Manager의 종류
단, 데일리로 개발자의 실행을 챙기는 역할은 엔지니어링 매니저, 프로그램 매니저, 스크럼 매니저가 대행한다. 이렇기 때문에 PM은 12명 이상의 개발자와 한번에 일할 수 있다.
technologist, Generalist, Business-Oriented 3가지 종류의 PM이 나타나면서 기존의 Project Manager 들은 사라져 가는 추세. (Project Manager 는 요청을 받아서 프로젝트만 리드하는 업무)

A. technologist

  • 매우 시스템과 기술적인 부분에 중심적
    • 기술적인 해결책을 중요시함
  • 백엔드 플랫폼 또는 굉장히 복잡한 B2B 프로덕트를 운영한다. 가끔 목표 메트릭에 연결되지 않은 “쿨한 아이디어”에 대한 기술적 리스크를 감수하기도 한다.

B. Generalist
– 기술적 깊이와 더불어서 비즈니스에 대한 실전적 지식 중심

  • 사용자 만족이 제일 중요
  • 최종 엔드유저에 대한 메트릭을 성장시킬 수 있는 가능성을 측정하여 실행한다.
  • B2C 서비스 또는 B2B의 프론트엔드 서비스

C. Business- Oriented

  • 비즈니스 배경 지식 중심
  • 특정한 비즈니스 메트릭을 극대화 시키는 것에 집중
  • B2C 서비스가 가진 자산을 이용해서 창의적인 새로운 비즈니스를 생각해낼 수 있는 프로덕트에 필요

원문: https://bit.ly/2LRbMP7


새로 기능 추가할 때 생각해야 할 질문 3가지

재화와 서비스에 어떤 기능적 요소(feature)를 포함시킬지 정하는 일은 기업에게 매우 중요하다. 기능을 추가하면 비용이 상승하지만 신규 고객을 유인하거나 기존 고객을 유지하는 데 도움이 되므로 수익이 증가할 수 있다. 기업이 ‘추가할 기능’을 결정할 때는 고객 유인에 효과적인 기능과 고객 유지에 도움이 되는 기능이 다를 수 있음을 이해하고 각기 다른 조사 방법을 활용해야 한다. 리베카 W.해밀턴 외 2명의 학자는 이에 대한 연구 결과를 발표했다. DBR 220호에 소개된 내용을 통해 알아보도록 하자.


신규 고객을 유인하기 때문에 필요한 기능이 있는 반면에, 기존 고객을 유지하기 때문에 가치가 있는 기능도 존재한다. 예컨대 강력한 사용자 커뮤니티는 게이머들을 유지하는데 큰 역할을 한다. 하지만 신규 사용자들에게 기존의 강력한 커뮤니티는 부담스럽게 느껴질 수 있다. 동일한 기능이 소비자에 따라 다르게 작용하는 것이다. 따라서 기능적 요소를 더하는 것이 제품에 대한 매력도를 높인다고 보장할 수도 없다. 흔히 기업이 기능을 추가하면 고객이 그 기업의 재화와 서비스를 선택할 가능성이 높아진다고 생각할 수 있다. 호텔, 놀이공원을 선택할 때 위치와 가격 같은 중요 속성뿐만 아니라 편의시설이나 인기 시설에 영향을 받는 것처럼 말이다. 그래서 기업은 최초 선택을 극대화하기 위해 대개 더 많은 기능을 제공하려 한다. 하지만 과도한 기능은 사용 후 제품에 대한 고객 만족도를 감소시킬 수 있다는 결과가 이번 조사에서 나타났다.

고객 유인을 위해 다양한 기능을 제공하는 것과 고객이 다시 찾아오게 만드는 기능을 제공하는 것 사이에 차이점이 있다. 더 많은 기능을 원했던 고객이 제품 사용 후 기능이 적은 제품이 낫다고 답하는 경우가 비일비재하다. 이렇다 보니 기업은 고객이 제품 사용 전에 자신이 원한다고 생각하는 기능과 추후 재구매하게 만드는 기능을 구별해야 한다.

원문: https://bit.ly/2KtucEY


관련부서 담당자에게 전투적으로 대하는 직원을 어찌하리요?

구글에서 ‘Project Aristotle’이라는 프로젝트를 실시한 적이 있다. ‘도대체 완벽한 팀은 어떤 특성을 가지고 있는 걸까?’ ‘무엇이 완벽한 팀을 만들게 하는 걸까?’에 대한 답을 찾기 위해, 2년간 180개의 팀을 대상으로, 3만 7000여 명의 직원을 조사하고 분석했다. 심리학자, 사회학자, 통계학자가 참여해 완벽한 팀을 만드는 원칙 5가지를 발견했다.

1, psychological safety(심리적 안전감)

: Team members feel safe to take risks and be vulnerable in front of each other

2, Dependability(믿음, 신뢰)

: Team members get things done on time and meet Google’s high bar for excellence

3, Structure & Clarity(구조와 명확성)

: Team members have clear roles, plans, and goals

4, Meaning(의미)

: Work is personally important to team members

5, Impact(영향력)

: Team members think their work matters and creates change

눈 여겨 봐야 할 것은 1번이 ‘심리적 안전감’이다. 나머지 원칙이 가능하려면, 심리적 안전감이 전제되어야 한다는 것이 핵심이다. 심리적으로 안전감을 느끼지 못하면, 신뢰할 수도 없고, 구조와 명확성도 불가능하고, 의미도 없게 되고, 영향력도 미치지 못하게 된다는 말이다.

하버드 대학교 leadership professor인 ‘Amy Edmondson’은 ‘심리적 안전감’을 ‘대인관계의 위험으로부터 근무환경이 안전하다고 믿는 마음’이라 정의한다. 같이 일하는 동료로부터 안전하다고 느껴지는 마음, 업무와 관련해서 상사에게 그 어떤 벌을 받거나 보복을 당하지 않을 거라고 믿는 마음이 ‘심리적 안전감’인 것이다.

그렇다면 어떤 말들이 심리적 안전감을 해칠까. “그걸 아이디어라고 내?” “이걸 보고서라고 써왔어?” “그거 이미 2년 전에 시도해 본 거야!” “우리 회사는 예산이 없어서” “우리 팀은 인원이 부족해서…” 등이 모두 해당된다. 흔히 쓰는 “좋아, 그런데 내 생각에는” 여기에도 문제가 있다. ‘좋아’라는 말의 진정성을 해치기 때문이다. 듣는 사람은 ‘좋다는 건 어쩔 수 없이 쓰는 말이고, 결국 네 얘기를 하겠다는 거잖아’라고 받아들이게 된다. 두 가지 중 어떤 말이 더 와닿는가.

“넥타이 멋지다. 근데 셔츠 색깔이랑 잘 안 어울린다”

Vs.

“넥타이 멋지다. 그리고 셔츠를 노란색으로 하면 더 어울릴 것 같아”

구글에서는 새로운 구글 입사자들(newglers라고 부른다)에게 ‘yes, and~’를 꼭 교육시킨다고 한다. ‘좋은 의견입니다. 그리고~’ 이른바 plussing 기법. 상대의 의견에 부정적인 의견이 있다하더라도, 일단 ‘좋은 의견입니다. 그리고~’라고 이야기를 하면서, 아이디어를 덧붙여주는 방법이다. “주 4일제 근무를 해 보면 어떨까요?”라고 팀원이 이야기하면, “그걸 말이라고 해? 지금 바쁜 거 안 보여? 생각이 있는 거냐? 없는 거냐?”가 아니라 “좋은 의견입니다. 일단 주 4일 출근, 1일 재택근무를 6개월 정도 해 본 다음에 실시하면 좋을 것 같습니다!” “좋은 의견입니다. 수요일을 쉬는 날로 하면 좋을 것 같습니다” 등과 같이 대답하는 것이다.

원문: https://bit.ly/3p0n95O