by
Sep 03. 2023
#13 제도와 관련된 제품의 한계와 컨텐츠 발행
2023년 35주 차 회고
이전 회고 ☞ https://brunch.co.kr/@327roy/56
다음 회고 ☞ https://brunch.co.kr/@327roy/59
노트
#1 제도와 관련된 제품의 한계와 컨텐츠 발행
#제도 #컨텐츠 #레몬베이스 #SaaS
자사 제품과 관련된 컨텐츠를 알차게 뽑아내는 서비스들이 있다. 예를 들어 배달의민족의 '배민다움'이나 레몬베이스의 '레몬베이스 캠프', 아틀라시안의 '아틀라시안 블로그'를 말할 수 있다.
나는 꽤 많은 뉴스레터를 챙겨보고 있는데, 이번 주에 인상 깊게 본 글이 하나 있었다. 이것은 보편적인 성과관리 솔루션에서 동료들과 서로의 성과 등을 리뷰Review할 수 있는 기능에 대한 것인데, 기업에서 엑셀 혹은 설문지로 진행하던 상향평가, 수평평가 등 360도 평가라고 부르는 것을 시스템으로 만든 것이다.
이렇게 현재는 기업 내부의 제도와 관련된 것을 시스템으로 풀어준 제품들이 많이 등장했는데, 이런 기업 제도와 관련된 제품들의 한계를 생각해 보았다.
가령 기업에서 리뷰를 아무리 편하고 잘 진행할 수 있게 제품으로 도와준다고 하더라도, 1) 기업에서 이 제도에 대한 필요성을 못 느끼거나 혹은 2) 구성원에 대한 배려가 부족하면, 제품의 의미가 없어지거나 퇴색할 수 있다. 리뷰를 작성할 수 있는 시간, 기간을 구성원들에게 공식적으로 마련해 주지 않고 추가 업무로 부여하게 되면 질 좋은 리뷰가 나올 수 없는 것처럼 말이다.
이 관점에서 보면 제품 자체의 고도화에만 집중할 때의 한계를 알 수 있다. 제품을 아무리 잘 만들어도 고객에게 그 제도가 필요한 이유와 가치를 전달하지 못한다면 제품 자체가 소용없기 때문이다. 그래서 컨텐츠 발행을 하는 수많은 이유들 중 하나가 제품의 가치전달 및 제품을 써야 하는 이유를 전염(?)시키기 위한 것이라고도 생각한다.
물론 이런 컨텐츠로 고객에게 얼마나 큰 임팩트를 주었는지 측정하는 것이 쉽지 않아서, 이런 제품을 만드는 기업은 컨텐츠 발행에 쉽사리 투자하지 못한다. 즉, 이 업무에 리소스를 투입할 명분 마련도 어렵다.
그럼에도 불구하고 이런 컨텐츠가 꾸준히 발행되며 사람들을 팬으로 만들고, 신뢰감을 주는 것을 보면 할 이유가 충분하다고 생각하는 편이다(일종의 에펠탑 효과를 기대하는 편). 다만 저 업무를 누가 하느냐가 문제지..
꾸준히 질 좋은 컨텐츠를 발행하고, 커뮤니티를 운영하는 기업들에게 존경과 응원의 박수를 보낸다. (짝짝짝)
에펠탑 효과란 자주 볼수록 호감도가 높아지는 현상을 의미한다.
#2 저 말이 그 말인가 이 말이 저 말인가
#미팅 #의사소통 #딴길
다음에 만들 제품의 형상을 맞추기 위해 많은 이해관계자들이 한자리에 모였다. 미팅의 목적은 1) 담당 파트에 대한 현황 공유와 2) 의사결정이 필요한 것들을 해치우는 것. 어젠다도 명확하고, 누구 하나 빠짐없이 똑똑하며, 이 씬에서 잔뼈가 굵은 사람들이 모였으니 빠르게 의사결정할 것들을 해치워 버렸다.
라고 말하면 좋겠지만 그러지 못했다.
결국 '의사결정을 하고 서로 생각하는 형상에 대한 컨센서스를 맞추기 위해'모인 자리임에도 불구하고, 미팅 도중 몇 번이나 아이디에이션을 위한 자리로 변질될 뻔했다.
나는 이를 1) 모두가 같은 맥락에서 상황을 이해한 상태가 아니고, 2) 각자가 이해한 것을 확인하다 보니 자연스럽게 ‘있었으면 좋겠는 기능’을 말하게 된 것이 원인이라고 생각한다.
[이해한 것이 이게 맞나요? → 이것은 이렇게 푸는 것이 사용자 흐름상 더 자연스럽지 않을까요? → 그러기 위해선 이 기능이 있어야 할 것 같아요.]가 무한 반복되는 불상사
다행히 리더님이 미팅의 성격이 변질될 뻔한 것을 몇 차례 바로잡아 주셔서, 미팅 막바지에는 다음 액션 아이템들을 몇 개 정리할 수 있었다. 그렇다고 회의가 100% 만족스럽지는 않았다.
나는 제품이 전달할 가치와 형상이 명확하지 않은 상태에서 "이런 기능도 있으면 좋겠어요!"와 같은 How to를 미팅에서 얘기하는 것을 좋아하지 않는다.
제품의 형상이 바뀐다면 기껏 낸 아이디어가 물거품이 되는 경우가 많고, 어젠다가 아이디에이션을 위한 미팅이 되는 순간 하루종일 말해도 모자랄 정도로 얘기가 오가기 때문이다. 그래서 아이디어는 따로 전달받거나, 아예 아이디에이션을 위한 미팅을 잡는 편이다.
사람이 많을 때도 질 좋은 미팅을 할 수 있는 방법이 뭐가 있을까? 어젠다가 꽤나 명확하다고 생각하는 미팅임에도 불구하고 미팅이 딴 길로 새는 경우를 방지할 필요를 더 많이 느끼는 요즘.
#3 지식 공유를 위한 아카이빙
#아카이브 #작은도서관
열흘쯤 전부터 정보가 필요한 사람들에게 공유하기 위한 자료를 다시 정리하고 있다. 강의, 아티클, 레퍼런스 정도가 정리의 대상이며, 각 정의는 아래와 같다.
1. 레퍼런스: 실무를 볼 때 참고할 수 있는 자료를 의미한다.
2. 아티클: 당장 실무에 적용하기엔 애매하지만 인사이트를 주는 자료를 의미한다.
3. 강의: 보통 영상 자료를 의미한다. 내가 직접 봤거나 추천받은 강의 위주로 모은다. 그래서 대부분 기획자가 보기 좋은 강의가 많다.
[레퍼런스]의 경우 자료를 접할 때 레슨런, 분석 내용을 함께 남기기 때문에 [아티클]과 따로 관리하려고 한다. 이 자료들은 노션에서 표로 정리해 DB화를 할 생각이다. 관리할 속성(컬럼)은 아래와 같다.
1. 레퍼런스
- 속성: 레퍼런스 이름, 출처, 요약, URL, 작성일자, 카테고리
- 파일이나 분석한 내용이 존재하는 경우 이는 노션 DB 페이지 내의 본문에 작성한다.
2. 아티클
- 속성: 아티클 제목, 출처, 요약, URL, 작성일자, 카테고리(추후)
- 현재는 '출처(소스)'를 기준으로 그룹화를 해놨다. 아티클이 많아지면 '카테고리' 속성을 추가하고 아티클을 세분화한 후 '카테고리'를 기준으로 그룹화할 생각.
3. 강의
- 속성: 숙련도, 추천도, 이름, 개요, 수강시간, 가격
- 리스트업이 쉽지 않다 하하.
레퍼런스의 경우 분석 등 작성한 내용의 특징이 다 다르기 때문에 [카테고리] 속성을 통해 각 레퍼런스의 종류를 먼저 구분해 둘 필요가 있다. 하지만 하나의 카테고리 속성만 사용하기엔 레퍼런스의 종류가 다양하여 세분화된 구분을 하기 위해 [세부 카테고리]이라는 속성을 새로 추가해야 할 듯하다.
가장 어려운 것은 [카테고리, 세부 카테고리] 속성에 어떤 선택값(라벨 이름)을 세팅해 둘 것인가다. 각 분야별 유명한 커뮤니티에 들어가서 그들이 구분해 놓은 카테고리를 벤치마크하는 것이 나을 것 같기도 하다.
신경 쓰이는 점은 [아티클]과 [레퍼런스]에 겹치는 자료가 생길 수도 있을 듯하다. 가령 [밀리의 서재: 회원가입 사용성 개선하기] 같은 것. 가중치를 두고 어떻게든 MECE를 할지, 적당히 눈감고 양쪽에 중복된 자료를 넣든지 선택해야 한다.
우선 한 달 이내에 일종의 작은 도서관을 만드는 것이 목표!
맥비님 자료실과 각종 구독 서비스들을 많이 참고해야겠다.
강의 및 아티클을 모으는 페이지 ⓒ 327roy#4 리프레이밍: 그래서 문제가 뭔데요?
#리프레이밍 #문제정의 #원인 #Why
이번 주에 본 뉴스레터 중 인상 깊었던 내용이다.
서비스 기획에 입문하던 시절, 가설사고를 학습하며 알게 된 '리프레이밍Reframing' 이라는 개념이다.
이 뉴스레터에서 다룬 사례는 그 유명한 '엘리베이터 사례'인데, '엘리베이터가 구식이고 느려서 불편하다.'는 문제가 발제되었을 때, 원인(Why)을 무엇으로 볼 것인지에 따라 솔루션(How to)이 달라진다는 내용이다. 본문을 읽고 난 후, 우리는 How to에 대한 결정은 문제 해결 프로세스의 뒷단에 위치해야 한다는 것을 알 수 있다.
가령 아래와 같은 요구가 있다고 가정해 보자.
'사용자가 서비스에서 어떤 내용을 확인하지 못해 이를 알림 받고 싶어 한다.'
이때 우리는 '버튼 클릭 시 메일을 보낸다.', '사용자가 어떤 액션을 할 경우 시스템 내 알림을 보낸다.'와 같은 해결법들을 먼저 정하곤 한다.
이 경우 우리의 사고는 How to에서 벗어날 가능성이 적어지는데, 이 때문에 비용이 많이 들고 임팩트가 미미한 악수를 선택해야 되는 경우가 발생하기도 한다.
만약 사용자가 알림을 받고 싶어 하는 이유가 '어떤 내용을 진행하는 프로세스가 매끄럽지 못했기 때문'이라면? 근본적인 원인Root cause이 바뀌게 되고, 이를 해결할 경우 메일이든 내부 알림이든 알림 자체를 보낼 필요가 없어질 수도 있다.
아래는 '문제 정의 프레임워크'를 다루는 책에 항상 나오는 내용인 [문제를 제대로 정의하기 위한 7가지 방법]이다.
➊ Establish Clarity - 문제가 무엇인지 명확하게 정의한다.
➋ Seek External Insights - 관성을 벗어나 다른 업계, 다른 방법론을 수용한다.
➌ Write it down - 글로 적어본다. 글쓰기는 문제 해결의 설계도가 되어줄 수 있다..
➍ Uncover Gaps - 지금 문제에 대해 충분히 이해하지 못한 것을 인정한다.
➎ Categorize Complexity - 문제가 다양하게 나타날 수 있다고 인식한다..
➏ Embrace Positive Anomalies - 문제가 발생하지 않았던 일반적인 사례를 살펴본다.
➐ Question Purpose - "왜?"라는 질문을 통해 근본적인 이유를 이해한다.
문제 정의에 대한 내용을 다루는 책으로는 ‘맥킨지의 전략적 사고'를 추천한다.
서울에 막 올라오고 나서 멘토님에게 추천받은 책이다.
아래는 뉴스레터에서 다룬 '엘리베이터 문제'다.
엘리베이터가 너무 느리게 느껴져서 문제가 접수되었다고 해보자.
[엘리베이터 속도가 문제라고 정의할 때의 솔루션]
➊ 속도를 개선하기 위해 모터를 교체한다.
➋ 새 엘리베이터를 설치한다.
[엘리베이터 안에서 보내는 시간이 지루하다고 느끼는 것이 문제라고 정의할 때의 솔루션]
➊ 엘리베이터 안에 거울을 단다.
➋ 엘리베이버 안에 손 소독제를 둔다.
➌ 엘리베이터가 작동하는 동안 음악이 흐르도록 한다.
엘리베이터 '속도'를 문제로 볼 것인가, 엘리베이터를 타고 있는 시간이 '지루하다고 느끼는 것'을 문제로 볼 것인가. 문제를 리프레이밍하면 진짜 솔루션을 찾을 수 있다.
※ 뉴스레터 이름: 레드벅스백맨
#5 35주 차 KPT
#회고 #성찰 #KPT
[KEEP]
1. 회사에서 긍정적인 방향으로 내 이미지가 만들어지고 있다는 느낌이 든다. 그 이미지가 어떤 것인지 문장으로 표현하려면 피드백을 정리해 봐야겠지만, 아직까진 긍정적인 방향이라고 생각한다. 이미지만 좋은 사람이 아닌 정말 실속 있는 사람이 되어야 한다고 리마인드하는 요즘.
저번 달에 타부서 이해관계자에게 받은 코멘트 ⓒ 327roy