Change aversion : “내가 맨날 쓰는 거 그냥 좀 놔둬!”

사람은 대개 변화를 두려워하죠. 익숙한 것을 좋아하고 편안해하구요. 어느날 아침 출근하니 매일 사용하던 업무용 툴의 디자인이 하루 아침에 확 바뀌어 있다고 상상해 보세요. “와 엄청 예뻐졌네. 엄청 사용하기 편해졌겠어!”라는 생각보다는 “아 이제서야 좀 익숙해졌는데 또 바뀌었어? 아 그 XX메뉴는 어딨는거야? 바빠죽겠는데 하나씩 다 눌러봐야 하나?”와 같은 반응일 거에요.

얼마 전에 저도 업무 중에 같은 경험을 했습니다. 이번엔 제가 ‘사용자’가 아닌 그 변화를 주도한 ‘제품팀’이었다는 점이 다르지만요. 모든 맥락을 설명하자면 엄청 길기에 간단히 요약하자면 : “사용자들의 불편한 점을 개선하고자 새로 디자인한 제품을 프로토타입 테스트, 알파테스트, 베타테스트를 거치며 신중하게 테스트했고 마지막에는 78%의 만족도(기준선은 65%였음)를 확인하였기에 ‘성공’을 확신했던 제품 업데이트였습니다. 하지만 큰 규모의 사용자에게 릴리즈를 하기 시작하면서 이 만족도는 급감하였습니다. 처음엔 25% 수준까지 떨어졌죠. PM으로서 실망이 컸습니다. 하지만 이 만족도를 매일 측정하다보니 조금씩 높아지는 게 보였습니다. 2주가 지난 지금은 50% 이상까지 올라왔죠. 사용자들의 피드백을 확인해보면 ‘이전께 더 좋다’, ‘왜 바꿨냐’, ‘불편하다’ 와 같은 피드백이 다수였습니다. 구체적으로 무엇이 불편하다 라는 내용보다는 그냥 불편하다, 이전 것이 더 편하다 라는 의견들이 많았죠.”

사용자들은 갑작스런 변화를 불편하게 느낍니다. 익숙한 것이 편하고 안전하다고 느끼죠. 사실 이번엔 고객 만족도가 초기에 떨어질 것이라는 것은 예상하던 일이었습니다. 이전에 어느 정도 유사한 경험을 한 적이 있었고, 첨부한 링크와 같은 자료를 읽으면서 이것이 자연스러운 일임을 미리 알고 있었기 때문입니다. 첨부된 링크에서는 이러한 현상을 ‘change aversion(변화를 싫어하는 것)’이라는 용어로 사용하고 있습니다.

작은 변화를 적용하는 A/B 테스트라면 굳이 이런 걱정은 하지 않아도 될 것입니다. 하지만 어느 정도 큰 규모의 변화를 적용하는 케이스이고, 정량적인 데이터 뿐 아니라 정성적인 데이터(사용성, 만족도 등)의 중요성도 큰 변화/실험을 계획하고 있다면 첨부한 링크를 한 번쯤 꼭 읽어보시길 바랍니다. 변화의 레벨에는 어떤 것이 있고, 어떤 경우에 큰 change aversion을 예상할 수 있고, 패턴(사용자의 반응)에 따라 어떻게 대응을 해야 할지도 알려줍니다. Change aversion을 줄이기 위한 여러가지 방법도 설명해주고 있구요.

Change aversion은 인간으로서 자연스러운 일입니다. 그렇기에 완전히 피할 순 없어도 최소화 할 수는 있습니다. 첨부된 링크 한 번 읽어보세요. 나중에 피가 되고 살이 될 내용이라 생각합니다. 저만해도 당장 ‘지금’ 경험하고 있는 것이니까요.

* 궁금해 하실까봐 첨언하자면, 베타 테스트 시 change aversion을 확인하지 못했던 이유는 사용자들이 이미변화가 올 것을 알고 있었기 때문이죠. 테스트를 자발적으로 신청한 것이니까요. 그리고 일단 새 디자인의 제품을 사용해보고 원하지 않으면 베타 테스트에서 나갈(opt-out) 수 있도록 구성을 해놓았었습니다. 지금 진행하고 있는 ‘릴리즈’는 opt-out이 불가능한 일괄 변경이기 때문에 저항이 더 큰 것이라고 보구요.

** 이 글은 Publy News에 올린 글입니다.

RICE – 일에 우선순위를 매기는 방법

퍼블리 뉴스에 큐레이션해서 올린 글입니다.

원문 : RICE, simple prioritization for product managers


<RICE – Simple prioritization for PMs>

Product Manager의 중요한 역할 중 하나가 바로 어떤 프로젝트나 태스크의 우선순위를 결정하는 일이라 볼 수 있습니다. 이게 쉬운 일은 아니죠. 같은 프로젝트라도 상황에 따라(예, 코로나 전/후), 회사의 전략 방향에 따라, 조직의 목표에 따라, 주요 고객이 누구냐에 따라, 개발팀의 리소스나 디펜던시(다른 팀과 일이 엮여있는 정도) 등에 따라 그 중요성이 달라질 수 있습니다.

그렇기에 ‘이것만 따르면 돼’라고 할 수 있는 방법은 없습니다만 그래도 일반적으로 사용될 수 있는 프레임워크가 여러 가지 있습니다. 이번에 소개할 글은 그 중 RICE framework에 대한 설명입니다. 우선순위를 매기는데 있어 중요한 4개의 단어의 앞글자를 따서 RICE라고 이름 붙였으며 각 단어의 의미는 아래와 같습니다.

  • Reach : 얼마나 많은 수의 사용자에게 영향이 미치는지
  • Impact : 그 임팩트의 크기는 어떠할지
  • Effort : 이를 수행하는데 있어 드는 노력이 얼마나 클지 (시간, 인력)
  • Confidence : 내가 측정한 위 R, I, E의 값에 얼마나 자신이 있는지(예, 구체적인 증거가 있다면 자신감이 높음)

그리고 최종적으로 RICE 점수는 = R * I * C / E 로 계산을 합니다. 이 결과가 큰 순서대로 더 중요한 일이라고 보는 거죠.

사실 모든 일을 이렇게 계산할 수 있다면 좋겠지만 각자의 상황에 따라 이런 프레임워크가 유용할 수도 있고 아닐 수도 있습니다. 저의 경우는 우선순위를 계산할 때 위와 같이 점수를 매기는 방식을 활용하는 경우도 있지만 아닌 경우가 더 많습니다. 여러분들도 일단 이와 같이 우선순위를 계산할 수 있는 프레임워크가 있다는 것만 알아두고 본인의 상황에 맞게 적절히 활용하셨으면 좋겠습니다.

  • 저의 경우는 위의 값과 데이터를 쭉 늘어놓고 디펜던시, 리소스 상황, 현재 회사의 방향, 앞으로 몇 개월 동안 예상할 수 있는 장애물/난관 등 여러가지를 고려해서 우선순위를 결정합니다. 그리고 이렇게 결정한 로직을 제 매니저 그리고 제 개발팀, 디자이너, 마케팅 담당자에게 잘 설명하여 이해를 얻어내려 합니다. (물론 더 복잡한 경우도 많지만 지면상 생략합니다)

Product manager에서 Product leader로 성장하기 위한 길 (Publy News 큐레이션 글)

지난 6월 중순부터 Publy News 라는 서비스에 주 2~3회 씩 짧은 기사를 큐레이션해서 올리기 시작했다. Google Play에서 퍼블리 뉴스를 검색 후 다운받으면 무료로 사용할 수 있는 앱으로 각 분야에서 일하는 전문가들이 각자 관심분야의 글을 큐레이션하여 올려줍니다. 제가 올리는 글/기사 중에서도 제 블로그의 성격과 맞다고 생각하는 글들을 이곳에도 올리려고 합니다.


원문 : Crossing the Canyon: Product Manager to Product Leader

<Product manager에서 Product leader로 성장하기 위한 팁>

제가 다니는 Booking.com이나 본 사례에 나오는 회사들(Airbnb, LinkedIn, Dropbox, Uber, Amazon)은 Product 조직의 규모가 크죠. 이에 Product manager들도 PM —> SPM(Senior PM) —> GPM(Group PM) —> Product director 등 직급 체계가 짜여져 있습니다.

본 글에서는 PM/SPM와 같은 실무자급에서 GPM(보통 3~5명의 PM을 매니징하는 단계라고 보시면 됩니다)과 같은 관리자/Producer leader로 성장하기 위해선 기존의 능력과는 성격이 다른 능력을 길러야 한다고 합니다. PM에서 PL(Product Leader)로 성장하기 위해서는 아래와 같은 능력의 transition이 필요합니다.

(왼쪽 : PM/SPM에게 필요한 능력 —> Product leader에게 필요한 능력)

  • Depth in one type of product work → Breadth across multiple types of product work
  • Being good at your job → training others to be good at theirs
  • Solving with the resources you have → Solving by allocating resources and influencing others
  • Gaining more personal scope → Creating more scope for the organization

단순히 SPM 에서 GPM으로 승진하기 위한 팁은 아닙니다. Product manager에서 leader로 성장하기 위한 조언이라 생각하고 한 번쯤 읽어보시길 권합니다.

Product manager와 Product owner (2편)

내 블로그의 첫 글 <그래서 Product owner는 뭐하는 사람이에요?>이 브런치에서만 조회수가 6천이 넘었다. 그리고  <Product owner? Product manager?>라는 글도 꾸준히 읽히고 있다. 한국에서 Product owner에 대한 관심이 높아지고 있긴 한가보다.

<Product owner? Product manager?>의 주요 내용 중 하나는 Product manager(이하 PM)과 Product owner(이하 PO)는 하는 일이 기본적으로 같다는 것이다. 하지만 어느 날 독자 분이 브런치 댓글을 아래와 같이 남겨주었다. 엄밀히 말하면 완전히 같은 건 아니라고 한다. 이론적으로 말이다.

<내 글에 달린 댓글 중 발췌. 참고로 SAFe는 Scaled Agile Framework로 나도 자세한 내용은 모른다. 공식 웹사이트 검색해보시길>

다시 한 번 말하지만 실제 내가 다녔던 회사(쿠팡, Booking.com)나, 면접 봤던 회사들이나, 지인들이 일하는 회사 등에서 PM과 PO가 따로 구분되어 있는 경우는 본 적이 없었다. 대부분 PM or PO 였고 그 둘이 하는 일은비슷했다.

하지만 최근에 내 주위의 한 회사에서 PO와 PM이 함께 있는 사례를 발견했다. 바로 암스테르담에 본사를 두고 있는 Tomtom이라는 디지털 지도 관련 회사(tomtom.com)이다. 나름 유명한 네덜란드의 IT 회사로 이 분야에선 유명한 회사다. 위의 사실을 알게 된 계기는 아래와 같다.

이 회사의 Senior PO 직무가 Linkedin이 떴었고, 제품이 재밌어 보여서 내 주위의 Tomtom 출신 동료에게 회사는 어떤지, 그 팀은 어떤지 그리고 PO라는 직무가 어떤 권한을 갖고 있는지 물어볼 기회가 있었다. 그때 이 친구가 이렇게 얘기했다.

  • 동료 : “Tomtom은 PM과 PO가 나뉘어져 있어. 난 Tomtom 외엔 IT 회사 경험이 없어서 모든 회사가 그런 줄 알았어. 그래서 오히려 Booking.com에 처음 왔을 때 Product owner가 하는 일의 범위가 넓어서 놀랐어.(이 당시 우리 회사에서는 Product owner로 부르고 있었고, 2019년부터 Product manager라고 이름이 공식적으로 바뀌었다. 나는 당시 Product owner였고 지금은 Product manager가 공식 직무이다) Tomtom에서는 PM은 고객과 만나고 데이터 분석을 하고 장기 계획과 로드맵을 짜는 일을 주로 했고, PO는 개발팀(제품팀)이 효과적으로 일할 수 있도록 일의 우선순위를 결정하고 개발 요구사항을 명확히 하고 백로그를 관리하는 일을 주로 했었거든. Booking.com의 PO는 그 둘을 다 하고 있잖아.”
  • 나 : “어? 나는 모든 회사의 PO나 PM이 이름만 다르고 똑같은 일을 하는 줄 알았어. 내 경험상 그랬고 주위에서도 Tomtom과 같은 사례는 들어본 적이 없었으니까.”
  • 동료 : “어, 그래서, 내가 아는 너는 Tomtom 기준에서의 PM일은 즐겨할 것 같은데, PO일은 안 맞을 수도 있을 것 같아. 그래서 얘기해주는 거야. 한 번 그쪽과 확인해봐.”

위의 대화를 통해 얻은 인사이트를 확인하기 위해 온라인상으로만 알고 있던(LinkedIn connection) Tomtom의 PM에게 직접 물어봤다.

  • 나 : “I heard from ex-TomTom employee that there is also a Product Manager role in TomTom who’s mostly in change of the vision/roadmap/user research and so on, while POs are mostly in charge executing the roadmap in agile method. If so, I am not interested in PO role. I wanted to clarify this and I thought about you.”
  • 그녀의 대답은 ‘그렇다’ 였다.

그렇다. 내 글에 댓글 달아주신 분 덕분에 알게된 사실을 실제 내 주위에서 사례로 검증을 했다.

더 궁금해져서 이것 저것 자료를 찾아보다가 아래와 같은 Atlassian의 동영상을 찾게 되었다. 참고로 Atlassian은 개발 협업 툴 Jira와 Trello(인수함)로 유명한 호주의 소프트웨어 업체이다.

위 동영상의 2:40 정도를 보면 PM과 PO에 대해 설명하는 부분이 나온다. 요약하자면 아래와 같이 역할과 책임을 구분한다.  (위 동영상과 같은 내용으로 Atlassian blog 글도 있다)

  • Product manager : Mission, vision, high level problems, what success looks like
  • Product owner : break down and translate the vision to day-to-day activities

즉, PM은 장기적이고 큰 그림을 그리고 비즈니스 목표를 정의하는 직무이며, PO는 그 큰 그림을 실제 디자이너와 개발자들이 구현할 수 있도록 작은 태스크로 나누고, 요구사항을 명확히 정의하며, 태스크의 우선순위를 정하여 제품팀이 최대한 효과적이고 효율적으로 일할 수 있게 이끄는 직무이다.

이 글에선 위와 같이 PM과 PO를 구분하는 사례가 있다는 것을 보여주고 싶었다. 조금 부끄럽기도 하다. 몇 천명이 읽은 내 예전 글에서는 PM과 PO가 하는 일이 거의 동일하다고 했기 때문이다. 하지만 여전히 누군가 내게 PM과 PO가 뭐가 달라요? 라고 물어보면 ‘대부분의 회사에선 비슷하다. 그러나 회사마다 역할과 책임을 다르게 정의하기 때문에 정답은 없다‘ 라고 대답할 것이다. 물론 ‘일부 회사에선 그 둘을 나누기는 한다’라는 것을 덧붙이며 말이다.

이런 리서치와 검증 과정을 거치면서 내가 배운 점은 딱 하나다. 독자분들께도 이 한 마디 마지막으로 하고 싶다. 모든 회사마다 PM과 PO의 역할과 책임의 범위가 다 다르다. 그러니 이직할 때, 입사 지원할 때 그 자리가 어떤 자리인지, 회사에서(위에서)는 어떤 기대를 하는 자리인지, 개발팀과는 어떻게 일하는지, 의사결정의 권한은 얼마나 있는지 등을 꼼꼼히 확인하고 지원하라는 것이다. 인터넷 검색으로 잘 모르겠으면 면접 과정에서 리쿠트링 담당자나 면접관에서 물어보면 된다. 나도 면접할 때 면접관에게 늘 하는 질문이 “그 회사, 그 자리에서 내가 의사 결정할 수 있는 권한이 얼마나 있는가?”이다. 물론 어떤 조건이 좋을지는 사람마다 다르니 무엇이 좋다 나쁘다 라고 얘기할 순 없지만 말이다. 

나는 오늘도 옆방으로 출근한다.

오늘 아침에도 안방에서 일어나 옆방으로 출근했다. 물론 출근 전에 세수도 하고 아침도 먹고 커피 한 잔 내리는 것도 잊지 않았다.

지금은 CoVID-19(코로나바이러스) 여파로 인해 한국에서도 많은 사람들이 재택 근무를 하고 있지만 나는 재택근무가 처음은 아니다. 네덜란드 오기 전 쿠팡에서 일하면서 가끔씩 재택근무를 했었고 Booking.com에서도 한달에 두 세 차례 정도는 재택근무를 하며 혼자 집중하면서 일하곤 했다.

그래서 이번 사태 때도 재택근무가 익숙할 줄 알았다.

하지만 일주일에 하루가 아닌 매일 재택근무를 하는 것은 또 다른 경험이었다. 거기다 코로나바이러스 때문에 아이도 학교를 못가게 되어 아이도 함께 집에 있는 상황이었다. (네덜란드는 지난 주부터 모든 학교를 닫았다) “아빠가 방문을 닫아 놓으면 일하고 있는 거니까 들어오면 안돼”라는 말은 소용이 없었고, ‘퇴근’이라는 물리적인 행위가 없다보니 5시 반(퇴근시간)이 지났음에도 계속 일을 붙잡게 있게 되고, 사무실에서 일할 때보다 오히려 더 쉬지 못하며 일하고 있는 나를 발견하였다.

이에 일주일 간 일하면서 느끼고 생각한 ‘효율적으로 재택근무하는 법’을 내 나름대로 정리해 보았다. 다른 블로그나 기사를 참고해서 내가 실험해보고 있는 것도 있고 일하면서 느낀 것들도 있다.

1. 일하는 공간을 정하자. 그리고 사무실같이 꾸며놓자.
출근해서 일할 장소가 뚜렷이 있어야 한다. 그리고 일은 그곳에서만 해야 한다. 먹고 쉬는 것은 다른 곳에서 해야 업무와 쉼의 구분이, 출근과 퇴근의 구분이 뚜렷해진다.

2. 업무 시간을 정해 놓아야 한다.
사실 내가 잘 못 하고 있는 것이다. 오전 9시에 일을 시작해서 12시에 점심을 먹고 1시에 업무를 다시 시작하고 5시에 끝낸다와 같은 룰을 정해야 한다. 그렇지 않으면 나처럼 쉼없이 일하게 된다.

3. 옷은 갈아입고 출근하자.
침대에서 입던 옷 그대로 입고 일하진 말자. 업무에 집중하기도 힘들 뿐더러 어차피 화상 회의를 할 때 잠옷 입고 미팅할 것은 아니잖는가?

4. 중간 중간 휴식은 꼭 취하자. 업무 공간 밖에서.
내가 워커홀릭 타입인 건지, 이상하게 집에서 조용히 일하면 쉬지 않고 계속 일하게 된다. 회사에 있을 땐 종종 동료랑 잡담도 하고 화장실 다녀오면서 바람도 쐬곤 했었는데, 재택근무 중에는 계속 업무 효율을 높여야 한다고 생각을 해서 그런지 쉬질 않게 된다. 장기적으로 봤을 때, 그리고 건강을 생각했을 때, 틈날 때마다 휴식을 취하는 게 좋다.

5. 건강을 위한 매일의 ‘루틴’을 만들어라.
재택근무 중에는 모든 생활이 ‘집’을 중심으로 이루어진다. 특히 코로나바이러스 때문에 모든 식당과 카페, 바(bar), 체육관(gym) 등이 닫은 상황이다보니 갈 곳도 없다. 날씨도 좋지 않으면 더 고역이다. 집에 붙어 있어야 하는데 지겹고 지친다. 그래서 난 이번 주부터 저녁에 조깅을 하고 있다. 시원한 공기를 마시며 조용한 밤에 뛰다 보면(코로나 덕분에 거리에 사람도 없다) 스트레스도 풀리고 건강에도 좋다.

6. 아이와 룰을 정하자
처음에 얘기했지만 나는 아이에게 “아빠가 방문을 닫아 놓으면 일하고 있는 거니까 들어오면 안돼”와 같이 말하며 룰을 지키도록 했다. 하지만 이것은 내가 온전히 콘트롤 할 수 없는 것이기에 항상 성공하는 것은 아니었다. 그럼에도 계속 반복을 해서 얘기했고 지금은 일주일 전보다 많이 좋아진 상황이다.
한 가지 더 추가하자면 ‘5시 퇴근 후에는 아이와 꼭 놀아주기’와 같은 룰도 정해서 아이와 시간을 보내보자. 내가 잘 하고 있지는 못하고 있는 부분이지만 이것도 ‘루틴’에 추가해서 반복한다면 아이도 놀 수 있는 시간과 없는 시간을 구분할 수 있게 될 것이다.

7. 미팅(화상회의)을 효율적으로 운영하자.
재택근무를 한다고 미팅이 없는 게 아니다. 나 혼자 재택근무를 했을 때에는 미팅을 피하고 중요한 일에 집중하려고 했었지만, 모두가 재택근무를 하고 있는 상황에서는 어쩔 수 없이 화상으로 미팅을 진행해야 한다. 허나 화상회의 경험이 많지 않은 상태라면 회의를 효율적으로 이끌기 힘들다. 기술적인 이유로 인해 회의가 자주 끊기기도 하고, 여러 사람이 한꺼번에 발언을 하다보면 이해도 안되고 정리도 안되기 일쑤다. 이를 몇 번 경험하고 난 후 내가 사용해 본 방법은 다음과 같다.

  • 인사는 짧게, 본론으로 바로 들어가기
  • 발언을 할 사람은 손을 들게 하기 (발언할 사람은 음소거를 끄고 손을 들고 있게 한다. 보통 조그만 화면으로 참석자들이 손을 들고 있는게 보이게 된다). 필요한 경우 미팅을 운영하는 이가 발언할 사람을 지목하여 발언하게 한다.
  • 안건마다 시간을 정하여 놓고(time boxing) 최대한 시간 안에 결론을 낸다. 꼭 화상회의만의 팁은 아니지만 미팅이 비효율적으로 흐를 가능성이 높은 만큼 시간 내에 결론을 이끌어 내야 한다.

8. 시간을 정해서 메신저와 메일을 확인하자.
팀원들과 떨어져 원격으로 일하다 보니 사무실에 있을 때보다 메신저 알림을 더 자주 확인하게 된다. 나 때문에 의사 결정이 늦어지진 않을 지, 놓치는 게 없을 지 등의 생각 때문인 것 같다. 물론 직무와 직급에 따라 그 사람의 부재가 팀의 의사 결정을 막을 순 있겠지만 그런 상황이 항상 발생하는 것은 아니다.
2시간 자리에 없다고 큰 일이 일어나진 않을 것이다. 시간을 정해놓고 메신저 알림과 메일을 확인한다면 계속되는 컨텍스트 스위칭(context switching)으로 인한 생산성 하락을 막을 수 있을 것이다.

9. 미팅 내용을 실시간으로 문서화하자.
모두 회의실에 있을 때는 화이트 보드를 사용하여 브레인스토밍도 하고 결정사항 등을 적곤 했었다. 하지만 원격 화이트보드 솔루션을 사용하지 않는한 화상회의에서 같은 경험을 하기엔 쉽지 않다.
보통 화상회의 솔루션에는 ‘화면 공유’ 기능이 있다. 이 기능을 사용하여 미리 준비한 문서나 빈 문서를 띄운 후 결정사항을 적어나가면서 회의를 진행해보자. 모든 참석자들의 이해와 동의도 실시간으로 구하고 나중에 회의록 작성할 시간도 아낄 수 있다.