Jino
생성형AI 도메인의 Contents Designer를 모십니다.
2024년 정말 치열해지고 있는 생성형AI 분야에서
치열하게 도전하고 성과를 만들 믿을 수 있는 동료를 구하고 있습니다!
2024년 1월 마이타로는 유의미한 성장을 만들었습니다.
이를 기반으로 폭발적인 성장을 하는 마지막 조각을 맞춰 주실
역량있는 동료가 필요합니다.
관심 있으신 분은 디스콰이엇 메시지 주시거나
dev@1zlabs.com 으로 메일 부탁 드리겠습니다!
마이타로
생성형 AI를 활용한 깊이 있는 해석을 제공하는 타로, 사주 콘텐츠 서비스
Jino
생성형AI Contents Designer를 모십니다.
생성형 AI는 이미 문제 해결의 중요한 도구가 되었습니다. 많은 회사들이 AI를 도입하여 업무 생산성을 높이려 하고 있지만, 대부분은 기존 업무의 개선, 효율화에 그치고 있습니다. 하지만 원지랩스는 조금 다릅니다.
저희는 "마이타로" 서비스에 좋은 콘텐츠를 제공하기 위해 생성형 AI 기반의 CMS를 자체 개발하여 기존 대비 50배 이상의 콘텐츠 생산성을 이루어냈습니다. 단 2명의 콘텐츠 기획자가 수십명 규모의 컨텐츠/마케팅 팀이 수행할 업무를 해낼 수 있게 되었습니다. AI CMS를 통해 완전히 초개인화된 컨텐츠 제공과 실시간 소통이 가능한 사용자 경험을 만들어 내고 있습니다.
아무리 훌륭한 콘텐츠를 제작한다 해도,
그것에 공감하는 사용자를 제품으로 유입시키지 못한다면 그 가치는 반감됩니다.
콘텐츠의 성격과 타겟이 공감할 수 있는 배너와 썸네일 디자인이 없다면,
사용자가 콘텐츠를 탐색하는 경험이 좋지 않게 됩니다.
저희는 콘텐츠의 진정한 가치를 사용자에게 전달할 수 있기 위해서
LEAN Cycle : [고객 퍼소나 > 가설 > 실험 기획 > 디자인 > 데이터 분석 > 학습] 능력을 가진
역량있는 인재를 기다리고 있습니다.
이는 단순히 디자인 문제가 아니라, 콘텐츠 전략과 사용자 경험을 통합하는
깊은 이해와 전문성을 요구하는 과제입니다.
저희와 함께 할 Contents Designer는 이런 일들을 하시길 기대 합니다.
기획된 콘텐츠와 타겟에 대한 이해를 바탕으로
Product Manager, Contents Manager와 함께 콘텐츠 이미지 에셋에 대한 가이드라인 수립
탐색, 구매 경험에 임팩트를 줄 수 있는 디자인 업무 : 콘텐츠 배너, 썸네일, 표지 페이지
생성형 AI를 활용하여 콘텐츠에 새로운 경험을 줄 수 있는 다양한 실험
Product Manager, Contents Manager와 함께 마케팅 전략 수립
마케팅 캠페인에 사용될 디자인 업무 : 이미지, 영상광고 소재, 랜딩페이지
SUPER Individual STUDIOS인 원지랩스에서 기다리겠습니다.
Jino
많은 회사들이 AI를 도입하여 업무 생산성을 높이려 하고 있지만,
대부분 기존 업무의 개선, 효율화에 그치고 있습니다.
하지만 원지랩스는 조금 다릅니다.
저희는 "마이타로" 서비스에 좋은 콘텐츠를 제공하기 위해
생성형 AI 기반의 CMS를 자체 개발, 기존 대비 50배 이상의 콘텐츠 생산성을 이루어냈습니다. 단 2명의 콘텐츠 기획자가 수십명 규모의 컨텐츠/마케팅 팀이 수행할 업무를 해낼 수 있게 되었습니다. 그리고 AI CMS를 통해 완전히 초개인화된 컨텐츠 제공과 실시간 소통이 가능한 사용자 경험을 만들어 내고 있습니다.
초개인화된 컨텐츠는 사용자들의 반응도 뜨거웠습니다. 올해 3월 출시 이후 6개월만에 10만명의 가입자에게 50만건 이상의 해석 제공을 제공하며 타로앱 카테고리 기준 Google Play / App Store 매출 1위 달성 했습니다.
그러나 여전히 해결해야 할 과제가 많습니다.
공감을 얻을 수 있는 컨텐츠를 지속적으로 생산하기 위해서는
생성형 AI의 활용만으로는 충분치 않습니다. 좋은 컨텐츠를 만들기 위해서는
시즌과 타겟 퍼소나에 맞는 컨텐츠를 기획하고, 고객 피드백을 통해 점진적으로 개선하는 활동이 꼭 필요합니다.
그리고 저희는 이런 역량있는 컨텐츠 매니저에게 AI CMS라는 강력한 도구를 제공해드릴 준비가 되어있습니다.
생성형 AI의 활용성과 한계에 대해 가장 잘 알고 있는 원지랩스와 좋은 컨텐츠를 함께 만들어 보고싶으신 분은 꼭 연락주세요.
Jino
@송예찬 님과 커피챗이 아닌 3시간동안 진행 한 미팅에 대한 회고
디스콰이엇, 링크드인에 대학교4학년 또는 주니어 PM(PO)분들을 대상으로
커피챗을 통해서 경험을 나눈다는 포스팅을 한 후에 처음으로 연락을 해 주신
감사한 분과 3시간, 2회에 걸친 커피챗이 아닌 그 무엇인가를 진행한 회고 입니다.
성장한 점
[조금 성장 했다고 확실히 느낄 수 있었습니다.]
처음이라 어설프고 경험을 나누는 것이 조심스러웠지만
다른 분들을 본받아 커피챗이 필요한 분들에게 저를 알리고
신청을 받아 1회를 완료하자 자신감이 생겼습니다.
새로운 것을 시도 했을 때 결과와 상관없이 comfort zone을 넘었을때만
느낄 수 있는 감정을 다시 느낄 수 있게 되었습니다.
아쉬운 점
[굿 리스너가 되지 못한 저의 모습을 관찰 할 수 있었습니다.]
당분간은 이 포맷을 유지하면서 진행 해 볼 생각입니다만,
질문 형태의 설문을 먼저 받다보니 사전에 답변을 준비해서
그것을 잘 설명드리는데 집중했던 것 같습니다.
잘 듣고 좋은 질문을 던지는 문답이 아니라
세션 형태, 인터뷰 형태로 진행되는 아쉬움이 있었습니다.
좋았던 점
1. 미리 저와 이야기 하고 싶은 주제, 질문에 대해
제가 충분한 시간을 가지고 답변을 준비해서 깊이 있는 대화가 가능했습니다.
2. 예찬님의 질문에 답변을 하기 위해서 준비하는 과정을 통해서
저의 생각도 정리되고 평소 소홀하게 생각하고
관성으로 일하고 있었던 점을 발견 할 수 있었습니다.
예찬님과 대화
1. 예찬님은 대학교 4학년 마지막 학기를 보내고 계시고 현재 #PARD를 운영하고 계십니다. PARD를 시작하면서 PM(PO) 역할을 수행하시게 되었고 역할, 전문성, 제품, 창업에 대한 깊이 있는 고민을 가지고 계셨습니다.
2. 1차로 10월 18일에 1시간 30분, 2차로 10월 21일 1시간 30분동안 온라인으로
진행 하였습니다. 제가 공유 드린 커피챗 신청 양식에 맞춰 10개 질문을 해 주셨고
그것에 맞춰서 제 생각을 정리한 간단한 문서를 만들어서 예찬님과 커피챗 전에
사전에 공유드리고 시작하였습니다.
3. 예찬님의 질문은 모두 날카로운 질문이여서
제 생각을 전달하기 위해서는 한번씩 제가 어떤 경험을 했는지,
어떻게 생각하고 있었는지를 복기할 필요가 있었습니다.
예찬님은 듣는 태도와 능력이 뛰어나
추가 질문도 적절하게 해 주는 모습을 보여 주셨습니다.
4. 예찬님이 질문해 주신 내용은 아래와 같습니다.
- 성장이란 무엇인가요?
- PM/PO 성장의 노하우
- 학생으로서 그로스해킹을 실제 실행하는데 한계를 어떻게 극복할 수 있는가?
- 제품과 사용자를 바라보는 관점
- 창업 VS 취업
- 힘들었던 문제 해결 과정
- 사용자의 진짜 문제인지 확인하는 방법 (본인의 제품에 매몰되지 않고)
- 신입을 뽑을때 가장 중요하게 보는 역량
- 진로결정 시 도메인을 어떻게 고를 수 있을까?
- PM만 해왔던 사람이 가질 수 있는 맹점
5. 위의 질문들을 보시면 왜 3시간을 예찬님과 진행 했는지
이해가 되실 거라고 생각합니다. 🤣
디스콰이엇, 브런치의 글, 링크드인 프로필만을 보고
솔직한 고민을 기꺼이 알려주시고 경청해 주신
예찬님과 커피챗을 하면서 기분좋은 자극을 많이 받았습니다.
놀라울 정도로 잘하고 있고 더 잘할 것으로 기대되는 예찬님께
저의 첫 커피챗에 신청해 주셔서 너무 감사하다는 말씀 드립니다.
마지막으로
PM/PO 관련해서 커피챗이 필요하신 분들은
아래의 이전 디스콰이엇 포스팅을 확인 부탁 드리겠습니다!
Jino
회사 또는 팀에 데이터분석가가 없다면 PM(PO)가 성과분석을 하게 됩니다.
통계에 대한 지식과 성과분석에 대한 경험이 부족하다면 할 수 있는 성과분석 망하는 노하우(?) 지금 시작합니다!
어제와 오늘 일정한 비율의 사용자 seg가 들어온다는 확실한 보장이 있나요?
이번 기능이 배포되면 100% 적용되는 시점에 일주일 지표와 이전 동일(요일)의 일주일 지표를 비교하고자 합니다. 신규 마케팅 캠페인은 해당 기간에 없는 것으로 확인하였고 일주일 집행 예산 평균도 큰 차이가 없는 것으로 확인하였습니다.
실패할 수밖에 없는 이유.
완벽한 통제 환경을 우린 만들 수 없기 때문에 아무리 같은 요일, 기간 등을 동일하게 조절하려고 해도 이전 데이터와 비교는 신뢰도를 보장하기 어렵습니다.
: 제품 내에서 굉장히 depth가 깊고 명확하게 정의된 사용자를 대상으로 하는 기능이 아니라면 일반적으로 제품의 활성사용자 구성은 어제와 오늘이 차이가 납니다.
성별, 나이, 관심사, 제품에 대한 애정 등 이런 다양한 사용자들의 구성을 우리는 DAU라고 부르는 지표 속에 포함되어 있습니다. 그렇다 보니 같은 기간이라고 하더라도 전체 사용자의 구성비를 동일하게 조절하기는 힘듭니다.
의사결정 할 수 있는 수준의 유의미한 실험을 하려면 실험 대상, 모수를 균등하게 배분할 수 있는 A/B테스트가 가장 신뢰할 수 있는 방법이라고 생각합니다. 자체 개발하기 어렵다면 다양한 솔루션을 연동하여도 되고 구글의 파이어베이스_리모트 컨피그 기능에 실험기능을 제공합니다. 물론 이 A/B테스트의 성과도 실험 대상을 얼마나 균등하게 두 그룹으로 나눌 수 있는가가 관건이라고 할 수 있겠습니다.
중요한 성과분석, 모수가 많을수록 성과분석을 위한 통계적인 오류가 없는지 한번 더 확인이 필요합니다.
이번달에 릴리스한 기능의 전체 이용자는 10만 명입니다. 이 중에서 결제한 사용자는 1만 명으로 10% 수준입니다. 결제한 사용자는 전월 대비 3천 명이 줄었지만 결제 유저당 평균 금액은 1,000원으로 이전달 대비 100원이 증가하였기 때문에 매출의 유의미한 증가가 있었습니다.
실패할 수밖에 없는 이유.
성과가 개선되었는지 비교, 분석을 할 때는 평균의 함정, 상관관계와 인과관계, 퍼센트와 퍼센트 포인트 차이 등 알고 보면 간단하지만 무심코 해석해 버리면 결과가 전혀 달라지는 것들을 주의해야 합니다.
: 통계학 전공 또는 데이터 분석가가 회사, 팀에 없다면 제품의 기능이 출시된 후의 성과를 확인하는 것은 PM(PO)의 역할입니다. (있어도 다른 구성원이 분석한 내용을 검토해야 합니다) 성과분석 경험이 적으면 생길 수 있는 간단한 통계의 함정들에 대해 설명드리겠습니다.
평균의 함정 : 이건 데이터의 분포와 중앙값을 확인해 봐야 한다는 내용입니다. 같은 평균값이라도 데이터의 분포가 상단에 치우쳐 있는지, 하단에 치우쳐 있는지에 따라서 목표로 하는 성과가 났는지 분석할 수 있습니다. 유저당 평균 금액이 증가했다면 헤비유저의 구매 금액이 올라갔을 수도 있고 라이트 유저의 구매 건수가 올라갔을 수도 있습니다. 이것을 "평균"이라는 값으로 정의하게 되면 올바른 분석이 어렵습니다.
https://brunch.co.kr/@edte1020/14
인과관계와 상관관계 : 통계적으로 인과관계인지 상관관계인지를 분석하는 수식이나 방법들이 있습니다만 제가 설명드리고자 하는 것은 개념입니다. 어떤 업데이트를 통해 리뷰를 작성하는 유저 수가 늘었고, 매출이 증가되는 결과를 얻었습니다. 리뷰 작성 유저 수 < > 매출 증가가 원인과 결과의 관계가 명확한 인과관계인지 아니면 원인과 결과는 아니지만 한쪽이 올라가면 같이 놀라가고 내려가면 같이 내려가는 상관관계인지를 따져볼 필요가 있습니다. 특히 예시처럼 구매의사결정에 도움이 되는 정보나 기능들이 실제 매출에 영향을 주었는지를 따져 볼 때는 이런 것들이 잘 분석할 필요가 있습니다.
https://www.beusable.net/blog/?p=1797
퍼센트(%), 퍼센트 포인트(% P) : 얼마 전에 저도 혼용하여 사용해서 코멘트를 받았습니다만 생각보다 많이, 자주 틀리는 내용입니다. 00% 증가하였습니다.라는 설명을 많이 하는데 이때 퍼센트인지 퍼센트포인트 인지에 따라 단위가 달라지는 경우가 많기 때문에 명확하게 정의를 인식하고 사용하는 것이 좋습니다.
근거를 데이터로 삼는 것은 좋지만 데이터 만으로 의사결정을 하려는 고집은 경계해야 합니다.
'실험을 통해 데이터가 나오지 않았는데 어떻게 결정할 수 있죠?'
'실험 환경을 구축하고 기능을 개발하는데 한 달 정도 걸리는데 그동안의 기회비용은..'
'우리는 데이터로만 이야기하고 결정하겠어요. 가설과 가정이 섞인 직관적인 판단은 신뢰할 수 없어요.'
'그 데이터는 얼마나 신뢰할 수 있는 것인가요? 절대적인 믿음을 가질 만큼의 데이터라고 할 수 있나요?'
실패할 수밖에 없는 이유.
데이터 기반 의사결정은 중요합니다. 다만 데이터에 매몰되는 걸 경계할 필요가 있습니다.
: 경계가 필요한 자세는 데이터로 모든 걸 설명할 수 있다거나, 데이터가 없으면 아무것도 결정하지 않는 것입니다. 과제(기능)를 개발할 때 수립한 가설에 가정이 포함되어 있을수록 결과인 데이터에 영향을 미치는 변수가 많다는 것을 뜻하고 그 변수를 통제하기는 사실상 어렵습니다. 결과의 데이터만 보고 중요한 의사결정의 100%를 거기에 의존하는 자세를 경계해야 합니다.
나누지 않으면 보이지 않습니다.
'전환율이 1% P 높아졌는데 왜 1인당 평균 결제 금액이 이 만큼 높아졌을까요?'
'평균이 2% P 높아졌는데 왜 리텐션이 이렇게 많이 떨어졌는지 모르겠어요'
실패할 수밖에 없는 이유.
사용자, 고객, 트래픽을 쪼개어 봐야 합니다.
: 지표, 데이터를 구성하는 사용자의 특성에 따라 여러 segment로 분류할 수 있습니다. 새로운 기능이나 콘텐츠에 반응하는 segment가 어디인지 확인해야 올바른 의사결정을 할 수 있게 됩니다.
제품에서 회원가입 때 회원의 특성을 분류할 수 있는 정보가 있다면 이것을 1차로 분류하기도 하고, 결제가 비결제자, 콘텐츠 생산자와 소비자, 뉴비와 충성 유저 등으로 제품의 특성이나 현재 집중하고 있는 KPI에 따라 중요하게 관찰하고 있는 segment는 달라질 수 있습니다.
분석 전 그 데이터의 신뢰도를 확인하지 않는다면 100,000% 실패할 수밖에 없습니다.
'GA데이터랑 DB데이터가 좀 차이가 있는데 어떤 데이터로 분석하면 될까요?'
'믹스패널, GA, DB에 사용자(USER) 수가 차이가 있는데 어떤 데이터를 기준으로 구매자를 분석하나요? '
실패할 수밖에 없는 이유.
보고 있는 데이터가 어떻게 만들어지는지 분명하게 알아야 합니다.
: 각각의 솔루션이 데이터를 생성하는 기준, 방법이 다르기 때문에 조금 복잡하거나 여정이 긴 데이터를 분석하려면 분석하기 전에 그 데이터에 대한 정합성, 신뢰도, 분석 목적에 부합하는 지를 반드시 따져봐야 합니다. 특히, 여러 솔루션에 데이터와 로그가 흩어져 있고 이것을 하나로 합쳐서 분석하는 경우(ex. 클라이언트 로그는 GA, 결제 데이터는 DB)에는 기준이 되는 값들을 신경 쓰지 않으면 이상한 분석이 되어 버립니다.
Jino
이번에는 팀빌딩에서 예민한 주제일 수 있는 taker, 방출에 관련 된 내용 입니다.
말하기 위한 노하우 이제 시작 합니다!
비율이 너무 높으면 성장하는 팀이 아니라 경쟁하는 팀이 될 가능성이 높습니다.
자기가 성취한 것은 이야기 잘하는데 어떻게 잘할 수 있게 되었는지 노하우 공유가 없다.
회고 때 다른 사람을 평가하는 의견이 많고 자신에게 방어적인 태도를 취하는 사람이 많다.
니일, 내일을 나누고 R&R에 대한 정의를 가능하면 명확하게 하려는 사람이 많다.
https://www.ted.com/talks/adam_grant_are_you_a_giver_or_a_taker
실패할 수밖에 없는 이유.
Team Work가 잘 맞아야 한다는 의미는 팀원들의 MBTI나 혈액형 보다 Giver / Taker 성향의 파악이 더 중요합니다.
: Taker들은 자신을 중심으로 우선순위를 정하는 성향이 있기 때문에 공통의 이익이나 타인을 위해 손해를 감수하려 하지 않습니다. 또한 업무를 조율하지 못하고 자신의 주장을 관철하려고 에너지를 쓰고, 자신의 뜻과는 반대되지만 전체의 의견으로 결정되어 따라야 하는 경우에 납득하지 못하고 비 협조적이 되는 경향이 있습니다. 소수일 때에는 Giver들이 커버를 해 주게 되지만 다수의 비율이 되는 경우에는 업무 진행이 되지 않고 반목이 심해지는 상황이 발생하게 됩니다. 새로운 구성원을 영입할 때 영입의 대상이 되는 팀의 성향 비율이 어떻게 되어 있는지, 새로 합류하는 사람의 성향이 어떤지 미리 따져볼 필요가 있습니다.
새로 구성하는 팀이라도 경험이 적은 사람에게 팀 리딩을 맡기면 절대 안 됩니다.
자기가 무슨 말을 하는지 알고 있는 건가?
이런 것도 일일이 리더에게 물어볼 거면 도대체 역할이 뭐지?
실패할 수밖에 없는 이유.
명시적인 리더로 선임하지 않더라도 제품개발의 중요 의사결정을 하는 비율이 높다면 팀을 리딩하는 포지션이라고 볼 수 있습니다.
: 일하는 문화(방식)에서 PM(PO)가 제품 개발 일정, 범위, 정책, UX/UI 디자인 리뷰 등 넓고 깊은 범위의 의사결정에 관여하는 역할이라면 팀 리더라는 직함이 없어도 실질적으로 그 사람을 중심으로 제품팀이 돌아가게 됩니다. 그런 환경에 경험이 없는 PM(PO)가 stand alone 하게 그 역할을 하길 기대한다면(제품팀의 다른 구성원들이 도와준다는 전제로) 너무 욕심이 크다고 말씀드리고 싶습니다.
클라 1명, 서버 2명, 디자인 1명, 기획자 1명 이렇게 팀 빌딩을 하면 안 됩니다.
이번에 우리가 뭘 한데요?
B2C 제품을 하나 개발한다고 들었어요. 3개월 내에 승부 봐야 한다고 하던데요?
실패할 수밖에 없는 이유.
새로운 팀빌딩은 그 팀이 해야 하는 일이 아니라 미션, 목표를 먼저 정하고 그것을 잘할 수 있는 사람을 모아야 합니다.
: 일을 하기 위한 필요충분조건의 조합으로 팀 빌딩을 하게 되면 팀이 하나가 되기 위한 Why?를 만들어 주지 못합니다. "그걸 왜 나한테 바라는 거지?", "왜 제가 그것까지 해야 하는 거죠?" 이런 생각을 구성원들에게 들게 만들게 됩니다.
어떤 목표를 달성하기 위해 새로운 팀이 필요한지, 그 목표를 달성하면 회사에 팀에 어떤 기여를 하게 되는지를 먼저 정의하고 그것을 잘 수행할 수 있는 구성원을 선정해야 합니다.
예상하셨듯이 새로운 팀에 속하게 되는 구성원들에게는 무엇을 만들어야 한다를 먼저 이야기하는 것이 아니라 목표와 그 목표를 달성하기 위한 미션, 그리고 이 목표를 잘 달성할 수 있는 사람으로 선정된 것이라는 내용을 먼저 이야기해야 합니다. 그래야 하나의 목표의식을 가진 '팀'이라는 정체성을 만들기 용이해집니다.
방출하는 이유를 같은 팀 구성원들에게 잘 공유하는 것이 필요합니다.
'이번에 000님 왜 그만두시는 거예요?'
'몰랐어요? 그만두는 게 아니라 방출이래요.'
'왜요?'
'공유받기로는 역할이나 기대치에 대해서 여러 번 피드백이 있었는데 잘 안되다고 해요.'
'응?! 000 업무 잘해서 이번에 성과 잘 나오지 않았나요?'
'저도 잘 모르겠어요. 짧게만 공유받아서..'
실패할 수밖에 없는 이유.
구성원의 방출은 팀 사기에 큰 영향을 주기 때문에 불필요한 오해를 최소화해야 합니다.
: 방출에는 여러 가지 이유가 있을 수 있습니다. 이런 이유들에 대해서 적어도 같은 팀에는 명확하게 공유되는 것이 필요하다고 저는 생각합니다. 방출되는 사람을 위해서 에둘러서 모호한 표현으로 방출 사유를 이야기하거나 여러 방출 이유 중에서 일부만을 공유하게 되면 남아 있는 구성원들에게 다음과 같은 혼란을 줄 수 있습니다. 1) 고용의 불안정성 : '나도 그냥 잘리는 거 아냐?' 2) 리더십에 대한 불신 : '왜 방출시키는 거지? 어떤 기준이 있는 건가?'
리더십은 방출이라는 의사결정까지 힘들고 고통스러운 일이겠지만 방출이 결정되었다면 남아 있는 팀의 구성원들이 최소한의 영향을 받을 수 있도록 신경 써야 한다고 저는 생각합니다.
누구에게만 방출 이유를 이야기하고 누구는 이야기 안 하는 커뮤니케이션은 더욱 안 좋은 방법이니 투명하게 공개할 수 있는 범위 내에서 커뮤니케이션하시는 선택을 하시길 바랍니다.
방출을 망설일수록 핵심인재가 이탈하거나 팀의 신뢰가 무너질 확률이 커진다고 생각해야 합니다.
'그래도 힘든 창업부터 함께 고생해 온 사이인데..'
'당장 방출하고 나면 그 일을 대체할 사람이 없는데..'
'이건 그래도 잘하는데..'
'방출은 처음이라 뭐라고 말해야 할지 막막한데..'
실패할 수밖에 없는 이유.
개인의 호불호, 감정적 방출이 아니라 명확한 방출의 이유가 있는 것이라면 빠르게 실행해야 합니다.
: 방출해야 하는 구성원이 있다면 그 구성원으로 인해 발생하는 비효율, 리스크가 있다는 것이겠지요. 그것에 영향을 받는 것은 같은 팀의 구성원, 팀의 생산성, 제품의 성과 더 나아가 회사의 성과에 영향을 줄 수 있습니다. 특히 구성원이 작은 규모의 스타트업일 경우 더욱 두드러지게 됩니다.
이런 비효율과 리스트가 시간이 갈수록 누적되고 있는 상황을 인지하고도 빠르게 실행하지 않는다면 물이 새고 있는 걸 알면서 막지 않는 것과 같다고 생각합니다. 양심의 가책, 개인적인 친분, 방출된 동료의 비난 등이 두려워서 결단의 시간이
길어져서는 어려움이 더 커질 수밖에 없다는 걸 생각해 보시길 바라겠습니다.
Jino
피드백은 어렵지만 성장하는 조직, 회사, 개인에게 중요한 문화이자 역량이라고 생각합니다. 오늘은 피드백을 실패하기 위한 ㅋ 노하우를 공유 드립니다.
첫 번째,
관찰한 사실을 기반으로 하지 않은 주관적인 '평가'를 한다.
각자의 기준으로 사람을 평가하는 것이 피드백의 본질이 아닙니다.
'이번 과제를 진행 할 때 000 역량이 부족해 보였어요. 전문성을 키울 수 있도록 노력이 필요합니다.'
'000님이 잘하는 건 000이고, 부족한 건 000입니다.'
실패할 수밖에 없는 이유.
피드백은 관찰한 사실을 기반으로 성장에 도움, 계기가 될 수 있는 제안을 하는 것이라고 생각합니다.
: 주관적인 평가는 피드백 당사자에게 방어적인 태도를 만들게 됩니다. 아무리 도움이 되는 내용이라도 받아들이는 사람을 움추리게 만들어서는 그 효과를 기대하기 어렵습니다. 그리고 주관적이라는 것이 평가 당사자가 평가한 사람을 어떻게 생각하는가에 따라 피드백 내용 그 자체를 생각하지 못하고 왜곡하게 만들기도 합니다. 직속리더가 A라는 피드백을 한 것과 팀의 동료가 A라는 피드백을 한 것이 주관적인 기준으로 작성 되었을 경우에 A라는 내용의 인식과 회고를 하게 되는 것 보다는 누가 나에게 A라는 피드백을 주었는가?를 생각하게 된다는 것입니다.
객관적이고 관찰한 상황과 사실을 간단하게 먼저 적고 그 상황에서 더 좋은 대안, 성장을 위해서 생각해 보면 좋은 제안을 적는다면 피드백 당사자도 그 상황을 떠올리고 그 글을 읽으면서 바로 회고를 하는 효과를 얻기 때문에 스스로 느끼고 깨닫게 되는 자극의 크기가 휠씬 큽니다.
두 번째,
피드백을 요청한 사람의 성장을 돕고자 하는 마음이 없는 사람이 피드백을 한다.
하기 싫은 피드백은 아예 작성하지 않는 것이 좋습니다.
'이번에 같이 일 안했는데 피드백 요청을 받았네 어떻하지?'
'딱히 그 사람에 대해 관심이 없었는데 적당히 써야 하나?'
실패할 수밖에 없는 이유.
피드백은 피드백 대상자의 성장을 위해 평소 많은 관찰을 한 사람이 작성해야 합니다.
: Giver의 마음으로 그 사람의 성장을 위해 평소 그사람의 일하는 방식, 감정의 변화, 성과를 어떻게 만들어 내는지, 다른 구성원과 커뮤니케이션, 성공과 실패에 어떻게 반응하는지 등을 관찰하고 아쉬웠던 점, 잘했던 점, 성장을 위한 제안을 작성해 주시려면 많은 관찰이 필수적 입니다. 당연히 그 사람의 성장을 기꺼이 돕겠다는 마음과 나의 에너지와 시간을 투자 해야 가능한 일입니다.
이런 마음이 없는 피드백은 피드백을 받는 대상에게 혼란을 주거나 의도치 않게 역효과를 줄 수 있습니다. 얼굴을 보고 이야기하는 것이 아닌 글로서 전달되는 경우에는 특히 문장력이나 구성에 따라 불필요한 오해가 발생 할 가능성도 있습니다. 피드백을 요청 받으셨다고 하더라도 충분한 관찰과 마음가짐이 부족하다면 정중하게 아직은 피드백을 위한 준비(관찰)가 부족하니 다음 기회에 더 좋은 피드백을 하겠다는 취지로 정중하게 사양하는 것을 추천 드립니다.
세 번째,
피드백 문화가 전체의 공감없이 일방적으로 (급하게) 시행된다.
피드백은 생각보다 잘 쓰고, 성장에 반영하기 어렵습니다.
'피드백 쓰셨어요?'
'아직 안했는데 그게 다면평가? 뭐 360도 평가? 뭐 그런건가요?'
'비슷한것 같은데 써야 되는 내용이 많아요.'
'솔직하게 쓰는 사람이 몇명이나 되겠어요. 그냥 적당히 빠지지만 않게 하면 되지.'
'그렇겠죠? 이런걸 갑자기 왜 한다고 하는지.. 어디서 또 듣고 왔나봐요.'
실패할 수밖에 없는 이유.
리더쉽 부터 점진적으로 시행해보고 장점과 단점을 충분히 경험한 뒤에 회사와 조직에 맞는 방식으로 정착 시킬 수 있어야 합니다. (심지어 도입을 하지 않는 의사결정까지도 경험을 해본 뒤에 결정해야 합니다.)
: 직접 경험해 보지 않고 원칙과 방법론만으로 '문화'를 만들 수 없습니다. 특히 피드백 문화는 구성원들간의 신뢰에도 영향을 크게 주기 때문에 올바른 방향으로 정착되고 일을 위한 일이나 남 들이 다 하니까 식이 아니라 실제도 성장에 도움이 되는 제도가 될 수 있도록 각별히 신경을 써야 합니다.
그러기 위해서는 리더십들이 직접 서로에게 피드백을 주고 받으며 그걸 성장에 적용 시켜보고 모여서 회고를 하면서 경험하고 '소화'하는 과정이 필수적이라고 생각합니다. 그래야. 우리회사, 팀에 딱 맞는 피드백 문화를 정착 시킬 수 있는 방향성을 찾을 수 있습니다.
네 번째,
피드백 내용(특히 부정적인)을 모두 수용하려고 한다.
피드백은 내 성장을 위한 답안지가 아닙니다.
'A도 부족하고 B도 부족하고 C도 부족하고 도대체 나는 잘하는게 뭐라는 거야?'
'어떤사람은 A가 부족하다고 하고 어떤 사람은 A가 강점이라고 하는데 누구 말을 들어야 하는거야?'
실패할 수밖에 없는 이유.
피드백의 내용을 어떻게 성장에 활용할지는 전적으로 여러분이 결정하는 것입니다.
: 피드백의 본질은 나의 성장을 위해 내가 보지 못한 장점과 단점을 관찰을 통해 알려주는 것이라고 생각합니다. 그것만으로도 스스로 어떤 부분을 잘하는지 부족한지 깨닫기에 충분합니다. 하지만 질 좋은 피드백은 기대 만큼 많이 받기 어렵기 때문에 피드백의 수용 범위와 그것을 내 성장에 어떻게 연결 시킬 지를 취사선택해야 합니다. 맹목적으로 피드백을 수용하려는 태도는 스스로의 인생을 남의 시선과 평가에 맡기는 것과 다름 없다고 생각합니다.
특히 부정적인 피드백에 대해서는 내용이 아니라 피드백에 숨어 있는 나에 대한 기대가 무엇인지를 파악하는데 집중하세요. 그러면 사람마다 나에 대한 기대치가 조금씩 다르다는 것을 알 수 있습니다. 그 기대치와 스스로가 정의하고 있는 역할, 산출물의 퀄리티, 역량이 얼마나 일치되는지를 검토하세요. 그 차이가 많다면 부정적인 피드백의 비율이 높을 것이고 그 차이가 크지 않다면 비율이 낮을 것 입니다.
다섯 번째,
피드백 내용을 성장에 활용하지 않는다. (지나간 과거의 성적표, 점수표라고 생각한다.)
피드백 대로 성장하라는 것이 아니라 성장하는 모습을 피드백 준 사람들에게 보여주세요.
'000님은 피드백 세션이후에 달라지는게 느껴지지 않나요?'
'정말이예요. 변화의 속도는 느리지만 확실히 달라지는게 느껴져요.'
'피드백이 보람있게 느껴져서 좋아요.'
실패할 수밖에 없는 이유.
성장을 위한 최고의 기회를 가볍게 생각하지 마세요.
: 피드백 자체가 성장에 많은 도움이 되는 것은 부정 할 수 없습니다. 몇가지를 나열해 보자면, 1)자기 자신을 메타인지하는데 도움이 됩니다. 특히 주니어인 경우 본인이 인식하는 자신과 타인이 관찰하고 인식하고 있는 모습의 차이가 큰 경우가 많습니다. 메타인지는 주니어 일때 부터 역량을 키워야 빠르게 성장할 수 있는 만큼 적극적으로 피드백을 요청하고 성장하는 것이 좋습니다. 2) 성장을 평가하는데 도움이 됩니다. 특히 소프트 스킬의 경우에 팀 내에서 구성원들과 상호 작용에 영향을 주는 것들이 많습니다. 이 역량이 개발되었는지 좋아졌는지 평가하기 위해서는 함께 일한 사람들의 피드백이 중요한 소스가 됩니다.
피드백을 작성하기 위해 관찰하고, 어떤 내용을 써줄지 고민하고, 이런 사람 또는 역할이 되어 주길 기대하는 마음이 담긴 동료들의 신뢰의 증표인 피드백을 결코 가볍게 생각하지 마시길 바랍니다.
Jino
팀빌딩을 잘못하게 되면 잘 운영되던 제품이 휘청거리게 되기도 하고, 역량이 좋은 핵심 인재가 이탈하게 되는 원인이 되기도 합니다. 팀빌딩에 실패할 수 있는 강력한(?) 노하우를 소개에 드립니다.
성장중독자와 함께 성장, 스타트업, 제품에 대해 이야기하실 분!
첫 번째,
외부의 명성이 있는 "힙"한 사람은 역량이 높을 것이라고 생각하고 많은 비용을 들여 영입한다.
함께 일해보지 않으면 그 명성에 걸맞은 역량이 있는지, 역량이 우리 팀에 필요한지 확인하기 힘듭니다.
'000에 팔로워가 0000명이고 강연도 하고 책도 내신 분이고요. 000에 고문으로 활동하고 있는..'
'0000사, 0000사, 0000사를 거쳐 현재 C00을 하고 있고 네트워킹에 가면 그분 주위에 사람이..'
실패할 수밖에 없는 이유.
명성에 가려 우리에게 필요한 역량이 있는지 따져보는 걸 소홀히 생각하면 안 됩니다.
: '000'하면 알만한 명성이 있는 분들이 있습니다. 그러한 명성이 있는 분들을 영입할 때에는 명성에 걸맞은 역량을 기대하고 좋은 조건에 모시는 경우가 대부분입니다. 이러한 영입에 실패하지 않으려면 '명성'을 걷어 내고 그분이 회사와 팀에 실질적으로 어떤 기여를 할 수 있는지 냉정하게 따져볼 필요가 있습니다. 그리고 그분과도 명확하게 어떤 부분에서 실질적인 업무와 목표를 달성해야 한다는 조건의 합의가 필요합니다.
특정 포지션이 아니라면 '명성'만으로 팀과 회사에 플러스가 되는 일은 거의 찾아보기 어렵습니다. 팀과 회사가 Scale Up 단계에서 외부의 핵심인재를 영입할 때, 이런 부분을 냉정하게 판단하지 못한다면 많은 비용(시간, 돈, 노력)이 지출되게 됩니다.
두 번째,
기대한 역량에 미치지 못하는 사람을 영입한다.
영입의 기본은 현재 팀에 부족하거나 없는 부분을 채워 줄 수 있는 역량이 있어야 합니다.
'이번에 합류하신 000님은 알려진 것만큼은 아닌 것 같지 않아요?'
'그런 것 같기도 하고 아닌 것 같기도 해요.'
실패할 수밖에 없는 이유.
영입 후 빠른 시간 내에 플러스를 만들지 못한다면, 영입의 효과는 마이너스가 됩니다.
: 현재 팀의 수준보다 낮은 수준의 역량을 가진 인재를 높은 비용을 들여서 영입하는 경우, 기존 구성원들의 상대적 박탈감을 주게 되고 팀의 생산력을 떨어트리는 최악의 영입입니다. 온보딩에 시간이 필요할 수 있지만 역량 있는 인재라면 한 달 정도면 스스로의 자리를 찾고 찾고 성과를 내기 시작합니다.
팀 전체 구성원도 새로운 구성원과 함께 일하기 위해서 배려하고 합을 맞추는 시간이 필요하기 때문에 역량 있는 인재가 합류해서 빠른 시간 내 플러스를 만들어 주길 바랍니다. 그렇기 때문에 영입 전 팀 전체에 기대하는 역량 수준과 전문성에 대해 파악을 먼저 하는 것이 필요합니다. 소위 '즉시 전력감'이 되는 인재 영입이 중요한 이유입니다.
세 번째,
현재 제품팀이 일하는 방식에 경험이 없는 사람을 영입한다.
아무리 역량이 뛰어나고 성공의 경험이 있더라도 일하는 문화(방식)가 다르면 성과를 내기 힘듭니다.
'이 회사는 프로세스가 전혀 없는 것 같은데? 누구랑 이야기해야 일이 시작되는 거지?'
'이런 것까지 모두의 동의를 받아야 진행할 수 있는 건가? 내가 결정할 수 있는 건 어디까지지?'
실패할 수밖에 없는 이유.
일하는 문화(방식)는 그 안에서 성과 내본 사람은 당연하지만, 그렇지 않은 사람은 역량의 1/3도 발휘하기 어려울 수 있습니다.
: 많은 스타트업이 애자일(Agile), 린(Lean StartUp) 방법론을 커스터마이징 하고, 수평적인 관계에서 수직적인 의사결정을 기반으로 일하는 것 같습니다. 이런 유사한 일하는 문화(방식) 내에서 성과를 낸 사람과 그렇지 않은 전통적인 수직적인 구조의 일하는 문화에서 성과를 내본 사람과는 일하는 프로세스나 사고의 폭에 차이가 굉장히 큽니다. 예를 들어서 '00 전자'에서 역량 있는 엔지니어가 '00 스타트업'에서 100%의 역량을 발휘할 수 있는가는 불확실성이 클 수 있습니다. '00 민족'에서 역량 있는 엔지니어가 '00사'에서는 온보딩만 잘 거친다면 100%의 역량을 발휘하는데 큰 문제가 되지 않습니다. 그렇기 때문에 직전 회사의 일하는 문화가 지금 제품팀의 일하는 문화와 얼마나 차이가 있는지 고려하는 것이 매우 중요합니다.
네 번째,
영입의 명확한 목적 없이, 일손이 부족해서 사람을 뽑는다.
단순히 일이 너무 많아서 사람을 늘리는 영입은 반드시 피해야 합니다.
'한 달째 야근하고 있는데 왜 사람을 더 안 뽑아주는지 모르겠어요.'
'지금 클라이언트 개발 속도가 너무 느려서 릴리즈 속도가 지연되고 있는데 사람을 뽑아야 되지 않을까?'
실패할 수밖에 없는 이유.
팀의 성장, 없는 역량을 확보하기 위한 인재 영입이 설계되어야 합니다.
: 1차원적으로 일할 사람을 더 확보하는 영입은 생산력은 늘어나게 되지만, 딱 거기까지에 머무르게 됩니다. 갑자기 업무량이 줄어들거나 다른 방향의 업무를 진행해야 하는 경우가 생기면 늘어난 구성원은 성과를 내기 힘들어지는 상황이 오게 됩니다.
50인 이하의 스타트업의 인재 영입은 팀 전체의 성장에 기여할 수 있는 방향의 설계가 필요합니다. 업무량을 소화하는 것이 아니라 상위 차원에서 방향성이나 전략을 수립할 수 있는 역량을 확보하거나 팀이 가지고 있지 않은 역량을 가지고 있는 인재 영입을 통해서 팀이 할 수 있는 일이 확장되는 영입이 좋은 영입이라고 생각합니다. 물론 100명 이상의 큰 규모의 조직을 운영하는 회사에서는 depth를 충분히 확보해서 다양한 경영전략을 기민하게 실행할 수 있는 영입도 중요할 수 있습니다.
다섯 번째,
새로운 구성원을 잘 온보딩하기 위한 담당자 지정이 되지 않는다.
온보딩을 위한 담당자는 선택, 가능하면 이 아니라 필수, 반드시입니다.
'이건 누구한테 물어보면 되는 거지? 인사 담당자에게 물어야 하는 건가 리더에게 물어야 하는 건가?'
'업무 관련 권한을 모두 받지 못했는데 누구 한데 다운로드할 수 있는 거지?'
실패할 수밖에 없는 이유.
아무리 스타를 영입했다고 하더라도 실력을 발휘할 때까지 챙겨줄 사람이 없다면 이탈할 수밖에 없습니다.
: 회사의 규모가 작아 인재 채용 담당자가 없거나 여력이 되지 않는 경우, 또는 이런 역할의 필요성을 간과하는 경우에 새로운 구성원이 첫 출근 한 날. 당황스러운 경험을 할지도 모릅니다.
출근했는데 어디로 가야 하는지도 모르고, 문은 닫혀 있고, 또는 문은 누구를 따라 들어왔는데 빈자리에 앉아 한 시간이 지나도 아무도 나에게 안내가 없는 그런 상황 말입니다.
첫 출근이 이런 상태인데 온보딩이 매끄럽게 될 리가 없습니다. 일하면서 생기는 디테일한 궁금증, 행정이나 복지 관련 처리에 대한 것을 매뉴얼에 있는 것을 찾아 시도해 보지만 매뉴얼이 갱신되지 않았는지 링크가 바뀌어 있거나 신청했더니 담당자가 양식이 변경되었다면서 다른 안내를 해 주는 경험이 이어집니다.
주도적, 적극적인 성향이라면 스스로 잘하겠지 라거나 팀 내에서 누군가는 도와주겠지 와 같은 안일한 생각을 하고 있다면. 어렵게 영입하고도 나가라고 등 떠미는 꼴이나 마찬가지입니다.
성장을 위해 누군가와 커피챗이 필요하신 주니어, 대학생 분들은 아래의 포스트 참고하시고 부담없이 신청해 주세요.
Jino
실패의 경험을 아티클로 공유 드리고 있는 Maker Jino 입니다.
저의 작은 경험과 노하우를 어떻게 많은 분들에게 잘 전달 할 수 있을지
고민하고 있었는데 00드인에서 커피챗을 통해서 상담이나 조언을 해주시는
뛰어난 분들이 많이 있다는 것을 알게 되었습니다.
저도 용기를 내어서 지금 성장에 막연함이 있거나, 정체 되었다고 느끼시거나, 이제 졸업을 앞두고 진로를 고민하고 계시는 분들에게 도움을 드려보고자 합니다.
처음 진행하는 커피챗이다보니 아래 대상분들이면 좋겠습니다.
주니어 (경력 5년 이하의 현재 PM, PO)
대학교 4학년으로 취준생
창업 하시고 모든 걸 혼자하시는 슈퍼맨 대표님
짧은 시간의 커피챗이 최대한 도움이 되어 드리기 위해서
몇가지 설문에 미리 답해 주신다면 일정을 잡기 전에 미리 제가 잘 준비하여
생산적인 미팅이 될 수 있도록 노력 하겠습니다.
아! 제가 누군지, 어떤 경험을 가지고 있는지 궁금하시다면 아래 링크를 참고해 주세요.
>프로필
신청하신 순으로 연락 드리고 일정을 이야기 할 수 있도록 하겠습니다.
Jino
이번 아티클은 저희 모두의 애증의 관계(?) MVP를 실패하는 슈퍼 노하우(?) 입니다.
먼저, @곽근봉님의 아래 아티클을 읽어 보시는 것을 추천 드립니다.
너무 넓고, 깊으면(디테일) 실패하게 됩니다.
'적어도 이 정도 기능은 있어야...'
'이것도 실험하고 싶고, 이 기능은 이걸 쓰는 사람이라면 또 할 것 같기도..'
'경쟁 서비스에서는 이 기능이랑 이 기능이 있던데 없으면..'
실패할 수밖에 없는 이유.
MVP(Minimum Viable Product)라는 단어는 이미 어떤 관념으로서 스타트업에서 일하는 사람들 머릿속에 자리 잡고 있는 것 같습니다. 하지만 '왜 MVP를 만들어야 할까?'에 대해서 큰 고민 없이 'MVP를 만들어서 검증하는 거야'라고 방법론적으로 받아들이고 있지 않은지 경계해 볼 필요가 있습니다.
: 스타트업(LEAN StartUp을 지향한다는 전제)에서 핵심 가설, 비즈니스를 검증하기 위해서는 최소의 비용(실패했을 경우에 들어가게 되는 기회비용을 포함)으로 많은 후보들을 검증하고자 노력합니다.
일반적으로 투자금이 소진되기 전까지라는 시간 제약이 있고 그것을 실행할 수 있는 실행력(인적 자원에 비례)이 한정적이기 때문에 그렇습니다. 그렇기 때문에 MVP에 Minimum(최소한)이라는 단어가 들어가 있다고 저는 생각합니다.
MVP Spec을 가끔 아티클이나 출시되는 제품으로 보면 넓은 범위의 기능이 포함되어 있어서 상당히 놀랐다가도 기능의 완성도나 depth가 없어서 형태만 갖춘 제품을 보기도 하고, 기능의 범위는 좁은데 너무 디테일한 depth까지 개발이 되어 있어서 뾰족하긴 한데 초반에 이렇게까지 쓰는 사람이 얼마나 있을까라는 생각이 드는 제품도 있습니다.
MVP Spec은 깎아내고 덜어내고 욕심을 버리고 이것을 빼면 안 하는 거랑 같다는 범위 + 품질을 위해 포기할 수 없는 기준을 맞추기 위한 구현이 합쳐진 스펙이 좋다고 생각합니다.
추상적이지 않아야 하는 제품개발 방법을 추상적으로 적을 수밖에 없는 건 제품, 가설, 시장, 만드는 제품팀, PM(PO)에 따라 조금씩 달라지기 때문에 어떤 공식이나 법칙으로 일반화하기 어렵기 때문이라고 생각합니다. 아니면 아직 저의 역량이나 경험이 부족하기 때문일 수도 있겠습니다.
심지어 유사 서비스와 큰 차별점이 없는데 유사 제품이 있는지도 모르고 개발하기도 합니다.
'일단 MVP를 개발해서 출시를 해야 검증할 수 있을 것 같아!!'
'이 정도면 MVP를 만들 수 있지 않을까?'
실패할 수밖에 없는 이유.
반드시 AOS, iOS 플랫폼의 애플리케이션으로 제품을 개발해서 출시해야만 MVP인가라고 생각하지는 않지만 잠재고객이 보기에 '제품' 또는 '서비스'로 느껴질 정도의 최소한의 퀄리티를 가진 무엇인가를 만들어야 한다고 생각합니다.
: MVP를 만드는 것에 급급하지 말고 검증하려는 가설이나 가치 제안이 유효한지를 냉철하게 따져볼 필요가 있습니다. 아이디어를 바로 제품화하는 것보다 그 아이디어가 시장이나 사용자(고객)에게 의미가 있는지 한발 물러서서 따져 볼 필요가 있습니다.
프리토타이핑 방법론을 활용해서 그 가설이 PMF 검증이 필요한지를 앞서서 검증해 보는 Pre-PMF Process를 만든다면 성공 확률을 더 높일 수 있습니다.
될 놈을 검증해도 성공보다 실패의 확률이 높은 것이 스타트업, PMF 검증이라고 생각합니다. '될 놈'을 MVP로 개발하세요.
그냥 빨리, 적게 만들어서 출시하고 유저의 반응을 확인하는 제품이 아닙니다.
'최소한 이 정도는 개발해야 MVP 지!'
'이걸 다 개발하는 게 Full Spec이랑 뭐가 다르지? MVP가 아니잖아?'
실패할 수밖에 없는 이유.
PM(PO)와 제품팀이 Minimum Viable Product 두 단어를 얼마나 잘 이해하고 있는지에 따라 의미 있는 MVP를 개발하고 출시할 수 있다고 생각합니다.
: Viable을 Visible로 이해한다면 적은 스펙의 제품을 개발하는 것을 지향하게 되지만 사용자(고객)에게 유의미한 범위의 기능을 구성하지 못할 수 있습니다.
Viable을 Valuable로 정의하게 되면 너무 범위가 넓거나 디테일에 비용이 많이 들어가는 제품이 됩니다.
제품은 PM(PO)를 포함한 제품팀이 함께 만들기 때문에 MVP에 대한 이해, 기대, 방향성을 하나로 일치시키는 것이 중요합니다. 그렇기 때문에 제품팀마다 지향하는 MVP의 스펙, 품질의 수준에 차이가 있을 수밖에 없습니다.
적어도 충분한 모수의 사용자가 제품의 핵심 경험을 경험해 보기 전까지는 Growth Hacking이 필요합니다.
'MVP를 출시하면 모든 걸 확인할 수 있을 거야!'
'1개의 MVP를 출시하고 검증을 하는 동안 다른 MVP를 개발하면 될 거야!'
실패할 수밖에 없는 이유.
MVP를 출시한 후가 MVP를 개발할 때보다 더 많은 자원이 들어갑니다.
: MVP 출시 스펙에는 들어가지 않았지만 유저가 늘어나면서 추가해야 하는 기능을 추가 개발해야 하고, 사용자 여정을 확인해 보니 기대 했던 모습이 관찰되지 않아 UX Flow를 변경해야 하기도 하죠.
퍼포먼스 마케팅이나 바이럴 마케팅을 위해 추가 개발이 필요할 수도 있습니다.
충분한 모수가 제품을 사용해서 PMF를 검증이 끝날 때까지는 Growth Hacking이 필요합니다.
유저의 정성적, 정량적인 반응을 캐치해서 두세 번 정도 핵심경험을 강화해야 실패하더라도 그 원인이 무엇인지 학습하게 되는 유의미한 출시가 됩니다.
MVP 출시는 끝내고 결과를 기다리는 것이 아니라 막 출발선에서 발을 땐 단거리 육상선수와 같습니다.
당신이 보기에도 어설픈 제품을 사용자(고객)가 왜 사용해야 되나요?
'한 달 만에 이 정도면 충분해, 우리는 최선을 다했어'
'개발자 없이 노코드 툴로 이 정도 만들었으니 난 만족해'
실패할 수밖에 없는 이유.
MVP를 실험을 위한 프로토타입으로 생각하면 안 된다고 생각합니다.
: 그렇게 접근하면 가설이 정확하고 잠재고객이 충분하더라도 절대 PMF 검증을 통과할 수 없습니다.
Product가 아니기 때문입니다.
사용자(고객)는 여러분들이 만들고 출시한 제품이 MVP인지 프로토타입인지 대기업이 만들었는지 1인 스타트업이 만들었는지 크게 상관하지 않습니다. 나에게 필요한지 이 제품을 계속 쓸 가치가 있는지 냉정하게 판단합니다.
퀄리티가 구린 애플리케이션은 '설치'조차 하지 않는 것이 현실입니다. 최소의 비용을 들여서 사용자에게 가치를 전달할 수 있는 유지가능한 제품을 개발하는 것이 MVP를 개발하는 것이라고 생각합니다.
제가 경험했던 다양한 실패의 경험을 공유하는 것을 통해서 다른 분들의 학습 비용이 낮아지거나, 현재 어려운 상황에 처한 Product Manager, Product Owner, CEO 분들이 문제를 해결하는데 도움이 되길 바라며 작성합니다.
경험에 의존한 내용으로 검증된 방법론이나 이론이 아닙니다. 편향된 방향으로 기술된 내용이 일부 포함 될 수 있으며, 이로 인해 불편하시거나 이견이 있으신 분들은 편하게 알려 주시면 저의 성장의 기회로 생각하겠습니다.
Jino
제품 개발에 실패하기 위한 두번째 노하우(?)를 공유 드립니다.
이전 글이 PM(PO)의 노하우(?)였다면 이번에는 제품팀 전체에 해당되는 내용입니다.
여섯 번째,
제품팀의 의사결정 할 수 있는 범위가 지나치게 한정적이어서 컨펌이 필요한 상황이 자주 발생한다.
실행의 주체가 되는 제품팀과 PM(PO)가 의사결정 할 수 있는 범위가 한정적이라면 실행에 병목(bottleneck)이 생기게 되고 주도적인 실행이 아니라 수동적인 실행이 되게 됩니다.
'이번 실험 계획은 000 부서 000님과 논의해서 A/B 테스트 비율을 결정할게요.'
'C00 님이랑 싱크를 맞추고 실험 예산이랑 기획 방향을 확정할 수 있어요.'
'이번 기능 디자인에 대해 000님이 이견이 있으신 것 같아요. 일단 어떤 생각이 있는지 제가 확인해 보고 올게요. 그때까지 클라이언트 개발은 홀드 하시죠.'
실패할 수밖에 없는 이유.
제품전략의 목표 달성을 위한 실행을 위한 제품팀이 주체적으로 실행하고 책임질수록 성장하는 조직, 회사가 될 가능성이 높아집니다.
: 보고를 통해 승인을 받는 절차까지는 아니지만 그렇다고 100% 자율적으로 진행하기 어려운 의사결정 범위를 가진 제품팀이 있습니다. 당연히 제품이 규모가 커지면 다양한 조직이 함께 목표를 위해 노력하기 때문에 '독단적'으로 기능을 개발하거나 제품을 변경할 수는 없습니다. 그렇기 때문에 상위제품전략 - 제품전략을 달성하기 위한 주요 과제들과 목표에 대해 다른 조직과 이해를 같이 할 필요가 있습니다. 그리고 사전에 예측 가능한 영향에 대해 검토가 끝난 이후에는 제품팀의 실행은 집중력과 실행력을 잃지 않도록 최대한의 의사결정 범위와 권한을 보장해 주는 것이 좋다고 저는 생각합니다. (회사의 일하는 문화, 조직의 규모, 구성에 따라 차이가 클 수 있다는 점에 대해서 글을 읽으시는 분도 이해하실 거라 생각하면서 제 생각을 말씀드립니다.)
일곱 번째,
사용자 경험, 가치 전달보다는 개발 품질이나 실행 속도를 위주로 개발의 주요 의사결정이 이루어진다.
제품팀이 담당하고 있는 제품이 PMF를 검증하는 단계가 아니라 그 이후 Growth, Scale Up stage인데 개발 품질이나 빠른 실행 속도를 중시하는 의사결정을 자주 한다면 당장은 아니더라도 서서히 빛을 잃어가는 제품이 될 가능성이 높습니다.
'이번 스프린트 내에 구현하기에 마이크로 인터렉션이 많은데 좀 덜어 낼 수 있을까요?'
'지금 개발되어 있는 구조를 많이 변경해야 하는데요... 꼭 필요한 건가요?'
'메인 시나리오 위주로 일단 출시하고 다음 업데이트를 빨리 나가는 방향으로..'
(목표, 사용자에 대한 이야기 보다 각자의 입장에서 시간 내 일을 마치기 위한 이슈 레이징이 많은 경우)
실패할 수밖에 없는 이유.
모든 제품은 사용자(고객)가 잘 사용하는데 그 목적이 있습니다.
: 기본적으로 제품팀이 제품을 개발하는 목적은 사용자에게 가치를 제공하기 위함이라고 생각합니다. (그것이 눈에 보이지 않는 개발 작업이라도) 만들어 내는 사람인 제품팀이 '만들기' 자체에 매몰(埋沒)되거나 회사나 상위 리더가 더 빨리 만들어 내는 것에만 너무 포커스 할 경우에 제품을 사용하는 '사용자'는 없고 허공에 돌을 던지는 것처럼 공허한 기능만 제품에 덕지덕지 쌓이게 됩니다. 사용자가 그 제품을 삭제하지 않고 계속 사용할 이유를 제품팀은 업데이트를 통해 증명해야 한다고 생각합니다.
여덟 번째,
구린 제품, 기능을 출시한다. (속으로 구리다는 걸 알면서도)
스스로 만들고 있는 기능의 아이디어나 품질이 별로라는 것을 알고 있지만 '관성'에 따라 제품을 개발하고 출시하는 일이 반복된다면 제품의 품질은 점점 떨어지게 됩니다.
'디자인이 좀 별로인 것 같은데.. 디자이너한테 이야기해야 되나'
'이 기능은 나 같으면 안쓸 것 같은데.. 왜 만드는 거지?'
'좀 깔끔하게 동작하게 못하는 건가.. 화면에 들어올 때마다 이미지를 로딩하고 턱턱 끊어지는데'
(개발한 제품을 일할 때 외에는 사용하지 않음)
실패할 수밖에 없는 이유.
이유, 설명이 필요하겠습니까? 솔직하게 이런 경험이 최근에 있나요?
: 일정에 쫓기거나 제품팀의 역량이 부족해서 완성도가 떨어지는 기능이나 제품을 출시할 수 있습니다. 하지만 시간도 있고 역량도 있는데 스스로 생각해도 별로인 기능을 만들어 출시한다면 그 기능을 사용자가 사용하길 기대하는 건.. 부끄러운 일이 아니겠습니까? 자신이 사용하는 제품, 잘 나가는 제품, 유행하는 제품들의 기능이나 품질에 대해서는 기준이 높으면서 스스로가 만드는 제품은 품질의 기준을 낮게 두고 있는 것이 아닌지 냉정하게 돌아볼 필요가 있습니다. 더 좋은 퀄리티를 지향하지 않고 적당히 만들면서도 아무런 생각이 없다면, 그 사람은 그냥 실력이 없는 것입니다.
아홉 번째,
사용자(고객)의 피드백을 무시하거나 듣지 않는다.
부정적인 피드백이 빠르게 개선되지 않는다면 어렵게 모은 사용자가 빛의 속도로 이탈하는 걸 경험할 수 있습니다.
'6건 정도면 일단 다음 달까지 같은 내용이 인입되는지 보고..'
'이 내용은 사용자가 제품을 잘 안 써보고 미스커뮤니케이션이 발생..'
실패할 수밖에 없는 이유.
우리들은 이미 알고 있습니다. 사용자의 피드백, VOC가 중요하다는 것을.
: 하지만 실행 우선순위에서 항상 밀려나고 있다면 사용자의 피드백을 무시하고 있는 것과 마찬가지입니다. 특히 규모가 작은 제품팀에서 유저가 많을 경우에 신규기능개발, 사용자 피드백 반영(VOC 대응) 과제 간에 실행 우선순위를 고민하게 되는 상황이 자주 발생하게 됩니다. 이럴 때는 PM(PO)만 사용자의 피드백을 보는 것이 아니라 제팀 전체가 확인하고 가능하다면 운영까지 해보면서 공감할 수 있도록 하는 방법도 도움이 됩니다. 1명이 피드백을 주었다면 적어도 그 10배 이상의 같은 어려움을 느끼는 사용자가 더 있다고 봐야 합니다.
열 번째,
과제 회고를 충실하게 하지 않는다.
'회고'는 다른 회사에서, 옆 팀에서, 에자일 코치가, PM(PO)가 하자고 해서 하는 '이벤트'가 아닙니다.
'바빠 죽겠는데 또 무슨 회고야.'
'회고라고 가봐도 불평만 하고 분위기만 싸해지는데 이걸 왜 하는 거야.'
'회고하면 뭐 해 변하는 게 없는데, 액션아이템만 뽑고 돌아서면 잊어버리는데'
실패할 수밖에 없는 이유.
그렇더라도 회고가 중요하다고 생각합니다.
: 아무리 의미가 없다고 느끼는 회고라도 하지 않는 것보다는 무조건 제품팀에 도움이 된다고 생각합니다. 회고를 통해 서로에 대한 아쉬움과 불평만 늘어놓다가 끝나더라도 하지 않는 것보다 무조건 좋습니다. 특히 평소에 협업 관련 소통이 자연스럽게 잘 되지 않는 제품팀 일 수록 회고를 적극적으로 해야 합니다. 불편하기 때문에 외면하기 시작하면 감정의 골이 깊어지거나 불필요한 오해가 서로의 신뢰 관계를 무너뜨리게 되는 경우를 종종 경험했습니다. 전문적인 회고 기법이 없어도 "어렵고 힘들었던 점 / 좋았던 점 / 성장 한 점"과 같은 간단한 틀로 의견을 나누기만 해도 공통된 감정이나 이슈들이 한두 가지 정도는 나오게 됩니다. 이것에 대해서 함께 10-20분 정도만 의견을 모아보면 되는 것입니다. 먼 미래에 일을 더 잘하기 위해서 회고를 하는 것이 아니라 내일 일을 더 잘하기 위해서 성장하기 위해서 하는 '회고'를 하시길 바랍니다.
제가 경험했던 다양한 실패의 경험을 공유하는 것을 통해서 다른 분들의 학습 비용이 낮아지거나, 현재 어려운 상황에 처한 Product Manager, Product Owner, CEO 분들이 문제를 해결하는데 도움이 되길 바라며 작성합니다.
경험에 의존한 내용으로 검증된 방법론이나 이론이 아닙니다. 편향된 방향으로 기술된 내용이 일부 포함 될 수 있으며, 이로 인해 불편하시거나 이견이 있으신 분들은 편하게 알려 주시면 저의 성장의 기회로 생각하겠습니다.
Jino
PM(PO)로서 다양한 제품의 제품을 다양한 구성원들, 제품팀과 함께 개발하고 출시하면서 실패하거나 결과는 좋았지만 제품 팀이 힘들게 된 경험을 공유합니다.
현재 본인이 여기에 해당하거나 제품팀이 이런 상태에 있다고 관찰되신다면 개선을 위해 빠르게 행동을 취하실 것을 추천드립니다.
공감하지 못하거나, 반대의 의견을 제시하였지만 반영되지 못하였든 실행의 오너십을 가져야 하는 PM(PO)가 상위 제품전략을 자신의 것으로 소화하지 못한다면 당연히 실행도 엉망이 될 수밖에 없습니다.
'이 제품(기능)을 왜 만들어야 되는지 아직도 모르겠는데? 나열된 근거 중에서 공감되는 게 없어..'
'지금 사용자와 제품 stage를 고려했을 때 양적 성장은 무리라고 데이터를 보여 주면서 설득을 했는데 이걸 추진하라니 절대 납득할 수 없어, 날 무시하는 건가?'
실패할 수밖에 없는 이유.
상위 제품전략을 달성하기 위한 구체적인 실행을 기획하는 PM(PO)는 수동적인 상태가 되지 않도록 경계해야 합니다.
: 위의 예시처럼 극단적인 상황이라면 스스로가 납득할 때까지 상위 제품전략을 의사결정한 주체와 토론, 필요하다면 논쟁을 해야 합니다. 그렇게 해서라도 의사결정을 하게 된 배경에 공감하거나, 그 전략의 불확실성을 인정하고 리턴을 극대화하면서 리스크를 최소화할 수 있는 실행 방안을 고민해야 합니다. 수동적인 상태로 실행에 들어가게 되면 제품팀, 협업부서와 킥오프 미팅부터 어려움을 겪게 될 수 있습니다. 스스로가 의심하고 있는 전략을 실행하게 되면 다른 구성원들도 PM(PO)의 말투, 분위기, 표정으로 그 의심을 느끼게 됩니다.
PM(PO)가 과제에 대해 명확하게 정리가 되지 않은 상태에 있다면 결과가 잘 나오기 어렵습니다. (결과가 잘 나오더라도 그것이 왜 잘 나온 것인지 학습하기 어렵습니다.)
(협업 부서 마케팅 담당 구성원의 질문) '이 기능을 출시하게 되면 현재 안정화되고 있는 회원가입전환율에 영향이 있는데요. 어떤 목적으로 개발을 결정하였나요?'
(PM(PO)) '음.. 가입 후 온보딩을 위한 실험을 하는 건데요. 단기 리텐션에 긍정적인 효과가 있는지 확인하기 위한 과제입니다. 그래서 7 day retention을 높여서 구매에 영향이 있다는 가설을 증명하려는 거죠'
실패할 수밖에 없는 이유.
과제(기능)를 시작하기 전 명확한 정의를 해야 합니다.
: '이 기능이 있으면 좋을 것 같은데', '000 전환율을 높이려면 이 기능이 필요한 것 같아, 다른 곳에도 있잖아' 이 정도의 가정과 직감으로 PM(PO)가 과제를 구체화해서 실행하게 될 경우 결과를 떠나 제품에 다양한 악영향을 끼치게 됩니다. 무엇을 왜 실행해야하는 지 결정하는 PM(PO)는 누구에게나 현재 실행되는 과제의 배경, 기대효과를 쉽게 설명 할 수 있을 만큼 스스로가 잘 정의하고 있어야 합니다.
PM(PO)가 정의한 성공의 정의(KPI)가 핵심 지표가 아닌 경우 기대효과가 떨어지는 실행을 하게 됩니다.
콘텐츠의 반응 개수를 늘리면, 신규 콘텐츠 작성 수가 많아질 것이다.
누적 판매 정보를 리스트, 상세 페이에 표시하면, CTA 클릭률이 높아질 것이다.
회원가입 Flow의 UX writing의 Tone을 정리하면, 가입전환율이 높아질 것이다.
실패할 수밖에 없는 이유.
PM(PO)는 지표 간의 관계를 잘 이해하고, KPI를 결정해야 합니다. 그리고 10% 상승이 아니라 200% 상승할 수 있는 가설을 찾기 위해 노력해야 합니다.
: PM(PO)는 과제를 구체화하고, 출시된 기능의 성과를 분석하고, 제품 주요 지표를 모니터링하기 위해 엄청나게 많은 숫자들, 지표들을 보게 됩니다. 숫자들을 많이 보게 되면 경계해야 할 부분은 지표들이 제품, 사용자에게 주는 영향을 간과하게 되는 점입니다. 신규 콘텐츠 작성 수를 높이는 게 목표라면 누가 신규 콘텐츠를 작성하고 있고 누가 작성하지 않는지를 확인하고 작성하지 않는 이유, 가설을 도출해야 문제가 해결이 되고 임팩트가 큰 기대효과를 가진 과제를 정의할 수 있게 됩니다.
PM(PO)가 아주 완벽한 스피치를 한 것이라면 모르겠지만 분위기가 싸하게 흘러간다면 문제가 있습니다.
"이번 과제 설명은 여기까지입니다. 혹시 궁금하신 점이나 같이 이야기하고 싶은 점 있으신가요?"
(정적)
'PM(PO)가 시간을 두고 제품팀을 둘러본다.
(정적)
"그럼 여기서 마치겠습니다.'
실패할 수밖에 없는 이유.
PM(PO)와 제품팀은 일을 시키고 주어진 일을 하는 관계가 아닙니다.
: 물론 PM(PO)가 주요 의사결정을 하는데 많은 비중을 차지 하긴 하지만 BOSS처럼 군림하는 위치는 아니라고 저는 생각합니다. 함께 목표를 달성하고 성장하기 위해 노력하는 하나의 팀이자 공동체 구성원이라고 저는 생각합니다. 그렇기 때문에 PM(PO)는 항상 제품팀과 자신의 관계가 현재 어떤 상태에 있는지 인지하고 있을 필요가 있습니다. 제품의 상황과 제품팀의 상태(퍼포먼스, 사기, 팀워크, 신뢰 관계 등)를 염두에 두고 어떤 관계를 형성하고 발전시켜야 할지 고민하고 적극적으로 소통하는 자세가 필요합니다.
제 경험 상 휴일에 혼자 출근한 것이 아니라면 PM(PO)는 회사에서 한가할 수 없습니다.
(오후 2시부터 6시까지 PM(PO)가 자리에 앉아 아무도 찾아오는 사람 없이 혼자 업무를 진행하고 있다.)
실패할 수밖에 없는 이유.
PM(PO)는 먼저 찾아가서 상태를 확인하고 흐름 관리를 하는 역할입니다.
: 극단적인 예시라 공감이 덜 가실 수도 있지만 위의 주제로 글을 쓰기 위함입니다. PM(PO)는 문제가 있는 상태의 구성원이 찾아와 주길 기다리는 사람이 아니라, 항상 먼저 다가가서 진행 상황을 확인하고, 지금 흐름을 막고 있는 것을 해결하고, 목표달성을 위한 정확한 기능이 개발되고 있는지 점검하고, 제품팀 구성원의 성장을 관찰하는 역할이라고 저는 생각합니다. 이런 역할은 다른 구성원이 할 수도 있지만 제 개인적으로는 PM(PO)가 이 역할을 했을 때 얻는 이익이 더 크다고 생각합니다. 네 번째에 말씀드린 협업 관계와 소통이라는 측면에서도 먼저 찾아가서 소통하고 문제를 함께 해결하려는 자세는 매우 큰 효과가 있습니다. 그리고 제품 개발, 디자인에 대한 이해가 높아지게 되고, 제품팀 구성원들의 지속적인 관찰을 통해 회고, 피드백 시 유용한 내용을 전달할 수 있게 됩니다.
제가 경험했던 다양한 실패의 경험을 공유하는 것을 통해서 다른 분들의 학습 비용이 낮아지거나, 현재 어려운 상황에 처한 Product Manager, Product Owner, CEO 분들이 문제를 해결하는데 도움이 되길 바라며 작성합니다.
경험에 의존한 내용으로 검증된 방법론이나 이론이 아닙니다. 편향된 방향으로 기술된 내용이 일부 포함 될 수 있으며, 이로 인해 불편하시거나 이견이 있으신 분들은 편하게 알려 주시면 저의 성장의 기회로 생각하겠습니다.
Jino
이전 글에 이어서 제품전략을 실패하기 위한 필승(?) 전략 두번째 글입니다.
복잡한 구조의 제품일수록 '숫자' 보다 '가치'를 크게 만들 수 있는 것으로 정의해야 합니다.
A) 콘텐츠 제휴를 늘리기 위해서는 000 어드민과 자동 연동 API기능이 있어야 합니다.
B) 그 기능을 개발하는데 3주는 걸리는데 리텐션을 높이기 위한 제품 과제를 중단하기 어렵습니다.
A) 사용자는 새로운 콘텐츠를 보길 원하지 않나요?
B) 새로운 콘텐츠가 늘어나면 사용자 리텐션이 늘어난다는 근거가 있나요?
실패할 수밖에 없는 이유.
전략은 사용자에게 궁극적으로 제공하고자 하는 '가치'가 정의된 후, 성공의 정의로서 세부적인 목표 지표(숫자)들이 정의되어야 합니다.
: 복잡한 구조의 제품인데 단순하게 지표 증가시키는 제품전략만을 실행하게 되면 한쪽이 달성하게 되더라도 다른 곳은 역성장하거나 성장이 정체되게 됩니다. 예를 들어 광고주 + 콘텐츠 제휴 + 사용자가 사용하는 플랫폼이라고 할 경우 광고주만 확대할 수 있는 위주로 전략이 실행되게 될 경우 나머지 콘텐츠 제휴, 사용자 쪽 과제가 진행이 되지 않으니 비즈니스 파트는 목표를 달성하게 되지만 사용자가 감소하게 된다거나 신규 콘텐츠 확보가 적어서 트래픽이 떨어지게 될 수 있습니다. 예시의 구조의 제품이라면 제품팀도 복수가 되어야 하는 게 이상적이겠지만 막 성장하고 있는 스타트업의 경우 엄밀하게 나누어져 있지 않은 경우가 많습니다. 이럴 때 제품전략이 이해관계자의 목표를 포괄할 수 있으면서도 올해의 경영전략을 달성할 수 있는 방향성을 일치시키는 것이 조직(파트) 간 불만을 줄이면서도 하나의 방향으로 전진할 수 있습니다.
실패를 두려워할 필요는 없습니다. 하지만 같은 구조의 실패를 반복한다면 전략을 기획하는 사람의 자질과 역량을 의심해야 합니다.
1) 사용자가 제품에서 원하는 가치는 A, A를 원하는 사람은 B가치를 원할 것이라는 가설로 전략을 실행하였으나 실패하였습니다.
2) 사용자가 제품에서 원하는 가치는 A, A를 원하는 사람은 C가치를 원할 것이라는 가설로 전략을 실행하였으나 실패하였습니다.
3).. 그렇다면 D가치는 원하지 않을까?
실패할 수밖에 없는 이유.
실패를 통해 학습하지 않는다면 진짜 망합니다.
: '아 이건 안 되는구나. 그럼 다른 걸 찾아볼까?' 이런 나이브한 생각으로 실패를 받아들인다면 전략을 준비하고 실행하는 기간 동안에 들어간 비용(시간, 인력, 기회비용)이 모두 날아가버리게 됩니다. 전략을 기획했을 때 가정했던 부분, 가설, 불확실했던 부분 중에서 무엇이 가장 큰 실패의 원인이 되었는지 찾아내고 그것을 함께 실행한 구성원들에게 공유하고, 실패를 인정하고, 학습하지 않으면 안 됩니다. 제품전략은 그래서 회사에서 가장 뛰어난 구성원이 참여해야 합니다.
전략을 기획하고 리뷰하는 과정에서 합리적인 의심이나 반론을 자유롭게 이야기할 수 없다면 매우 독단적으로 의사결정이 이루어지고 있다고 생각해야 합니다.
000은 어쩔 수 없이 가야 할 수 없다고 제가 설명드렸고요. 그러니까 000 분석을 진행해서 000 단가를 확인하면 되지 않겠습니까.
제가 어제 000을 생각해 보았는데요. 이번에는 이방향으로 000 해서 000을 추진하는 것이 맞을 것 같아요. 일단 000님은 000부터 시작해 주시고 구성원에게도 공유해 주세요.
실패할 수밖에 없는 이유.
독단적으로 의사결정한다고 다 망하는 것은 아닙니다. '반론' 조차 이야기 하지 못하는 분위기, 일하는 문화가 경직된 조직을 만들고 아이디어와 의견이 더해지는 시너지를 떨어지게 할 뿐입니다.
: 강한 카리스마와 추진력으로 한 사람이 조직이나 회사를 끌고 나가면서 성장을 견인할 수 있습니다. 하지만 조직이나 회사의 규모가 커지면 지속 가능한 형태가 되려면 제품전략은 제품책임자가 초안을 잡은 것에 대해 유의미한 의사결정을 할 수 있는 사람들과 함께 리뷰를 하면서 회사 전체의 경영전략의 달성에 부합하는지, 미처 검토되지 못한 리스크가 있는지 점검하는 것이 좋습니다.
실패를 인정하는 일, 실패의 원인이 무엇이었는지 확인하고 실행한 구성원들에게 전하는 일은 전략을 결정하는 일만큼 중요합니다.
이번 분기에 개발한 기능들의 유저 반응이 별로던데 000은 어떻게 된 거예요? 계속 운영하면 되는 건가요?
휴.. 저도 모르겠어요. 주요 지표 중에서 달 성한 개 한 개뿐인데 한 달째 이야기가 없네요.
000 제품 접기로 한 거 이야기 들으셨어요? 공지 팝업 디자인 하고 있더라고요?
진짜요? 2개월을 개발했는데 벌써 내리나요? 전 처음 들었는데. 000님은 누구한테 들었어요?
실패할 수밖에 없는 이유.
실패를 이야기하는 건 어렵습니다. 그렇다고 이야기하지 않는 건 전략을 믿고 실행해 준 구성원들의 신뢰를 저버리는 것입니다.
: 전략의 실패에 대해서 전략을 기획하고 의사결정한 소수의 구성원만 알고 있거나 실행을 주도한 몇몇 구성원만 알고 조직, 회사 전체에 공유되지 않는 경우에는 "전략을 기획", "전략을 실행"하는 역할 사이에 신뢰가 무너지게 됩니다. 특히 추가된 기능이 빠지거나 제품을 내리게 되는 의사결정이 이루어졌는데요. 제품 개발에 참여한 구성원에게 직접적으로 커뮤니케이션되지 않고 다른 사람을 통해 알게 되는 경우에는 최악의 경우 구성원의 이탈까지 발생할 수 있습니다.
조직이 크고 복잡하다면 각 부서별 또는 이해관계자별로 입장이 다르고 중요하게 생각하는 목표에 차이가 있을 수밖에 없습니다.
시즈널 마케팅을 위한 000 기능개발을 통해서 인입단가를 30% 개선하고 싶어요.
구매 전환율 실험을 위해서 000 솔루션을 연동하고 상세페이지 디자인을 변경하고 싶어요.
초기 잔존율이 낮아 유저가 감소하고 있어요. 출석체크 기능을 만들어서 실험하고 싶어요.
콘텐츠 제휴사에게 보내는 일간 리포트가 너무 부실해서 불만이 많아요.
실패할 수밖에 없는 이유.
모든 걸 다할 수 없다면, 선택과 집중이 필요합니다. 올해 달성해야 하는 회사의 경영목표, 현재까지 달성 상황, 이번 분기에 무엇에 집중해야 하는지 큰 목표에서 작은 목표로 방향을 잃지 않는 것이 중요합니다.
: 회사 전체가 달성해야 할 목표가 명확하다면 그것을 위해 모든 조직이 노력할 수 있도록 전략이 수립되어야 합니다. 모든 이해관계자의 의견을 수렴해서 제품전략에 담게 되면 무엇이 중요한지 놓치게 되거나 너무 많은 것을 실행하게 되어서 실행하는 구성원들에게 무리한 목표를 제시할 수밖에 없습니다.
제가 경험했던 다양한 실패의 경험을 공유하는 것을 통해서 다른 분들의 학습 비용이 낮아지거나, 현재 어려운 상황에 처한 Product Manager, Product Owner, CEO 분들이 문제를 해결하는데 도움이 되길 바라며 작성합니다.
경험에 의존한 내용으로 검증된 방법론이나 이론이 아닙니다. 편향된 방향으로 기술된 내용이 일부 포함 될 수 있으며, 이로 인해 불편하시거나 이견이 있으신 분들은 편하게 알려 주시면 저의 성장의 기회로 생각하겠습니다.
Jino
"제품전략"이라는 단어에 대해서 어떤 느낌을 받으시나요?
저는 아직 듣거나 쓰게 될때마다 살짝 긴장되는 걸 스스로 느낍니다. 그만큼 중요하고 부담이 있는 (전략을 정하고 실행하는 것 모두) 것이겠지요.
이렇게 중요한 제품전략을 이번에도 아주 손 쉽게(?) 실패 할 수 있는!!
노하우를 알려 드리겠습니다.
명확한 성공의 기준, 어떤 조건을 만족하면 전략이 성공한 것인지가 이해하기 쉽게 설명 할 수 없다면 그 전략은 실행 전에 이미 실패했다고 보시면 됩니다.
가입전환율이 높아지고, 그러면 유입 단가가 낮아지니까 자연스럽게 매출이 오르는..
매출이 2배 이상 높아지길 기대하고 있..
불확실성이 높은데 어떻게 기대효과를 정확하게 정할 수 있..
실패할 수밖에 없는 이유.
목표가 분명하지 않다면 성공의 정의를 할 수 없습니다.
: 이것도 중요하고 저것도 중요할 수 있습니다. 하지만 주어진 시간에 할 수 있는 실행력이 정해져 있다면 지금, 이번달, 이번 분기에 무엇을 달성해야 하는지 명확하게 한가지를 정해야 합니다. 그래야 그것을 실행하는 제품팀과 PM(PO)가 성공의 정의를 달성하기 위한 다양한 가설과 액션 아이템 중에서 임팩트 있으면서 빠르게 실행할 수 있는 것을 정하고 달릴 수 있게 됩니다. 다 잘해야 된다는 전략은 없는 것보다 못합니다.
일방적으로 실행을 담당하는 제품팀에게 전달만 해서는 결과는 물론 실행 자체도 제대로 되지 않을 가능성이 매우 높습니다.
두 달 안에 신규 제품을 론칭하고, 다음 분기에 미국 시장에 PMF를 검증할 수 있는 일정으로..
(제품전략 리뷰 후) 이상의 내용을 000 PO와 함께 이번 분기에 실행할 수 있도록 진행 부탁..
실패할 수밖에 없는 이유.
도전적인 목표, 일정일수록 Why? 에 대한 충분한 공감이 필요합니다.
: 전략을 실행하는 주체에게 그 전략을 '왜', '지금'해야 하는지 공유하는 것이 특히 중요합니다. 목표를 이야기하기 전에, 해야 할 일을 말하기 전에 그 전략을 실행하게 된 배경과 그 전략을 실행하면 어떤 기대 효과가 있을지를 공유하게 되면 공감대 형성이 쉽고, 주도적으로 이하는 문화를 가진 조직의 경우 세부적인 것들을 지시하지 않아도 맥락에 맞게 스스로 목표를 달성하기 위한 액션아이템을 개별 구성원들이 찾게 됩니다. 달성할 숫자와 해야 할 일 리스트를 알려주게 되면 '누가', '언제까지' 그 일을 해야 하죠?라고 말하는 수동적인 실행이 될 수밖에 없습니다.
실행을 해야 하는 조직이 할 수 있는 일과 (현재) 불가능한 일을 구분하지 못한다면, 실패는 물론 신뢰까지 잃게 될 수도 있습니다.
'왜 이걸 실행하는데 이렇게 오래 걸리는 거지?'
'처음으로 도전하는 도메인(타깃)인데 어디서부터 누가 할 수 있다고 생각하는 거지?
실패할 수밖에 없는 이유.
전략을 구체화할 때 우리(회사)가 (지금)할 수 있는지 냉정하게 판단해야 합니다.
: 특히 '새로운', '잘 모르는' 것을 시도할 때에 핵심이 되는 역량과 기능(조직, 담당자)이 현재 없는데 실행 할 수 있다고 생각하면 오산 입니다. 핵심 역량을 내부에 보유하고 있어도 성공하기 위해서는 여러 불확실성을 돌파해야하는데 전략의 중심이 되는 역량이 없다면 그 가능성을 높다고 할 수 있을까요? 예를들어 커뮤니티가 핵심이 되는 제품인데 내부에 커뮤니티 매니저(MAU5만 이상 규모 운영 경험)가 없다면 규모가 큰 커뮤니티를 만들 수 있을까요? 일단 제품을 개발하면서 채용하면 될까요?
하지만, 현재 실행할 역량이 부족하다고 해서 그 전략을 무조건 포기하고 당장 할 수 있는 것만 해서는 임팩트 있는 기대효과를 만들기 어려울 수 있습니다. 그렇기 때문에 의사결정 프레임에서 "실행 역량", "경험"이라는 요소가 부족한 경우 하이 리스크라고 보고 리턴이 얼마나 되는지 냉정하게 생각해 보시길 바라겠습니다.
본인도 잘 모르겠다는 뉘앙스를 주는 화법으로 제품전략을 공유할 경우, 실행해야 하는 제품팀에게 제대로 전달이 되지 않고 실행력이 떨어지는 결과를 가져옵니다.
일단 이 제품이 시장에 나가고 1분기 동안 성과를 지켜본 후에...
(말꼬리를 흐리거나, 질문에 대한 답변이 명확하지 않은 경우)
실패할 수밖에 없는 이유.
전략을 잘 전달하는 것은 기획하는 것 이상으로 중요합니다.
: 전략=비전을 공유하는 사람의 자신감이 중요합니다. 자신감 넘치는 목소리로 그 전략이 성공 했을 때의 모습(결과)를 귀에 쏙쏙 들어오게 말하는 사람이 있습니다. 까다로운 질문에도 막힘 없이 답하고 고민하지 못한 이견이나 우려를 말하면 인정하고 수용하는 열린 모습을 보이는 사람이 있습니다.
반대로, 평범한 목소리로 준비된 슬라이드를 발표하고 "질문 있으신 분?"이라고 말하는 사람이 있습니다. 까다로운 질문에 답하긴 하지만 근거를 열거하는데 그치고 깊이가 느껴지지는 않습니다.
둘 사람의 비전 중에 어떤 것을 실행하고 싶으신가요?
전략의 실행이 실패하고 있음에도 불구하고 분기 전략, 월간 전략이라는 것 때문에 멈추지 않고 실행된다면 불필요한 실패의 비용이 커지게 됩니다.
'이 그로스 캠페인 언제까지 해야 해요?'
'저도 몰라요. 벌써 마케팅비용이 0000원이나 나갔는데 이대로 괜찮을까요?'
'뭐 일단 그만하라는 말은 없으니까 지켜보시죠. 결제는 좀 늘었나요?'
'큰 차이 없어서 3주 전에 중간 공유 했는데 다른 결정 사항이 없는 것 같아요.'
실패할 수밖에 없는 이유.
전략이 실행되면 중간점검을 하고 필요하다면 멈추는 결정을 적시에 할 수 있어야 합니다.
: 큰 규모의 회사나 조직이라면 어려울 수 있지만, 작은 스타트업의 경우 전략의 실행 주기를 짧게 정해서 실패하더라도 최소의 비용으로 만드는 것이 필요합니다. 어렵게 정한 전략이 초반에 성과가 나오는 것 같지 않다고 쉽게 없었던 것으로 하는 것이 쉬운 의사결정은 아니겠지만, 적절한 타이밍에 실패를 인정하고 다른 전략으로 방향을 돌리지 않으면 더 큰 비용이 조직, 회사에 돌아오게 됩니다. 가능하다면 실행이 되고 성과에 대해서 정기적으로 리뷰하고 미세하게 방향을 조정하면서 목표에 근접한 지 점검하는 것이 중요합니다.
Jino
제목이 도발적(?)인가요? 이번 글은 개발문화에 대한 내용입니다.
퇴사율이 올라가는 개발문화를 만드는 노하우를 알려드립니다.
첫 번째,
스탠업, 업무 관련 커뮤니케이션, 티타임을 하면서 이런 이야기를 하는 구성원이 한 명이 있다면 말하지 않은 10명이 같은 생각을 하고 있을 가능성이 높습니다.
실패할 수밖에 없는 이유.
제품은 혼자 만들 수 없습니다. (제품뿐만 아니라 모든 일이 거의 그렇다는 생각을 합니다만)
: 본인이 하는 일이 무엇을 달성하기 위해서 하는지, 나의 업무 앞뒤로 어떤 일이 진행되는지, 함께 결정해야 하는 구성원은 누군지, 내가 담당한 일이 잘못되면 어떤 영향이 있는지 관심이 없는 구성원이 한 명이 있다면 그 한 명의 리스크를 보완하기 때문에 다른 구성원이 더 일하거나, 불필요한 감정적 소모를 감내해야만 합니다.
두 번째,
회사와 조직에 따라 수평적 일하는 문화의 정의에 차이가 있을 수 있지만, 누구나 결정에 참여할 수 있고 나의 동의가 없으면 불합리한 의사결정이라고 생각하는 사람은 주변에 부정적인 에너지를 빠르게 퍼트릴 가능성이 매우 높습니다.
실패할 수밖에 없는 이유.
완전히 공평하게 수평적인 조직이 아닌 이상 '결정'을 하고 '책임'을 지는 역할이 존재합니다.
: 직급의 구분 없이 수평적인 조직이라도 Ownership을 가진 역할을 가진 구성원이 있기도 하고, 프로젝트에 따라서는 담당자가 그런 역할을 하게 됩니다. 모두가 자신의 의견을 편하게 이야기할 수 있고 자유롭게 더 좋은 방향에 대해 건설적이고 치열한 논쟁을 할 수 있지만 모든 결정을 함께하기는 현실적으로 어렵다고 생각합니다. 비즈니스에 대한 의사결정에 운영담당, 디자인담당이 의견을 낼 수 있지만 결정에 참여할 경우에 그 결정의 퀄리티나 빠른 의사결정에 많은 비용이 들어가기 때문입니다. "000(팀 또는 개인)을 설득하지 않으면 작은 일 하나도 실행되기 어려워"라고 푸념하시는 분들은 이러한 '수평적 일하는 문화'가 역효과를 내고 있는 것이 아닌지 고민해 볼 필요가 있습니다.
세 번째,
옆자리의 동료가 왜 늦게까지 일하는지 관심이 없다면 전체 프로젝트에 관심이 없을 가능성이 매우 높습니다.
실패할 수밖에 없는 이유.
인간적인 관심 이전에 함께 일하는 동료들을 '관찰' 할 필요가 있습니다.
: 첫 번째 시그널과 비슷한 맥락이면서 살짝 다른 내용입니다. 긴밀하게 협업하는 구성원들 간에 서로 컨디션 변화, 감정 상태의 변화, 퍼포먼스의 변화, 성장의 변화를 '관찰'하는 것이 필요합니다. 특히나 관계성을 중요하게 생각하는 구성원들의 비율이 높다면 서로에게 관심과 '관찰'을 하는 것이 더욱 중요합니다. 이 '관찰'을 통해 이상 징후가 발생하기 전에 Red Flag를 들 수도 있고, 회고 때 유의미한 피드백을 할 수 있기 때문입니다.
네 번째,
구성원이 회사를 떠날 때 이유가 투명하게 공유되지 않는다.
어설프게 공유하거나 공유하지 않으면 불필요한 소문, 억측으로 분위기가 어수선하게 됩니다.
실패할 수밖에 없는 이유.
남아있는 구성원들의 고용 안정성을 흔들지 않기 위해 노력해야 합니다.
: 자발적 퇴사, 권고사직, 해고 여러 가지 이별의 이유가 있습니다. 그리고 개인적이고 공개하기 예민한 이야기들이 연관될 수 있습니다. 특히 구성원이 많은 조직의 경우 굳이 잘 알지 못하는 사람의 퇴사 사유까지 알고 싶지 않은데?라고 생각하는 비율이 높을 수 있습니다. 만약 그렇다면 그 구성원이 몸을 담았던 팀, 조직 내에서만이라도 명확한 퇴사 이유를 공유하는 것이 이후 불필요한 소문으로 뒤숭숭하게 분위기가 나빠지는 것을 방지할 수 있다고 생각합니다. 공개해도 불안하고 안 해도 불안하다면 굳이 안 하는 게 좋지 않을까?라고 생각 하실 수도 있지만 그 둘의 차이는 나빠지는 분위기가 신뢰를 잃게 만드는 더욱 안 좋은 상황으로 번지지 않기 위해서 저는 하는 편이 더 나은 선택이라고 생각합니다.
다섯 번째,
반대와 우려를 말하기 어려운 분위기이다.
리더십, 의사결정자, 제품담당자의 결정과 의견에 편하게 자기 생각을 이야기할 수 없다면 구성원들은 수동적이고, 방어적으로 점점 변하게 됩니다.
실패할 수밖에 없는 이유.
거의 모든 스타트업에서 중요하게 생각하는 자기 주도적으로 일하기 위해서는 자신에게 주어 진 목표를 자신의 것으로 만드는 과정이 필요합니다.
: 당연히 반대의 의견이 있을 수 있고, 제품, 사용자, 비즈니스적인 우려가 생길 수 있습니다. 그런 의견에 대해 자유롭게 이야기하고 목표를 제시한 사람은 어떻게 생각하는지 소통을 통해 자신의 목표로, 자신의 일로 만들게 된다고 저는 생각합니다. (비록 스스로 마음에 들지 않고 실패하는 길이라도 그것을 뒤집을 만한 명확한 반론, 대안이 없다면 쿨하게 따라서 일하고 그 과정을 통해 조직 전체가 학습을 하게 되는 성장 모델을 저는 지향합니다.)
Jino
성장중독자의 단상(斷想) #2
사전적 의미까지는 모르겠지만, 리더(리더십을 가진 사람)는 비전(Vision)을 제시할 수 있어야 한다고 이야기한다. 여기서 비전은 '방향성' 또는 '목표'에 가까운 의미라고 생각하는데. 이것이 쉽지 않다.
첫 번째로 비전을 찾는 일이 어렵다.
어떤 가능성이 비전이 될 수 있을까? 회사, 조직, 개인의 비전을 어디서부터 어떻게 찾아야 할까? 아무도 알려주지 않는다면 하늘이라도 쳐다봐야 하는 걸까? 조직의 크고 작음을 떠나서 소수의 누군가가 비전을 찾는 어려운 일을 해야 한다.
두 번째로 비전의 결과에 책임지는 일이 두렵다.
결국 비전을 달성할 수 있을지, 성공할지 실패할지에 대한 불확실성, 결과에 대한 책임을 제시하는 사람이 지게 된다. 그러한 상황 속에서 결단력을 발휘하는 것이 비전을 제시하는 사람의 위대함이라고 생각한다.
(물론 실패해도 공유하지 않고 다른 비전을 제시하는 사람도 있겠지만)
마지막으로 비전을 전달하는 일은 굉장히 중요하다.
비전을 전달하는 방법 내지는 노하우는 개인마다 다르고 시기나 조직의 크기에 따라 달라져야 한다. 특히 이 부분을 잘하는 것에 대해 개인적으로 어려움을 느끼는데 어렵다고 피하지 말고 작은 방향성이라도 자주 공유하고 의견을 수렴하는 경험을 쌓는 것이 중요하겠다.
"이 길로 가야 합니다!"라고 이야기했을 때 어색한 침묵이 흐르는 경험, 맹렬한 도전, 이견, 우려를 직설적으로 이야기 하는 구성원들과 공개적으로 이야기하는 경험을 해 본 사람들이라면 크고, 작은 비전을 제시하는 일이 얼마나 어렵고, 중요한 일인지 공감할 거라고 생각한다.
어떻게 하면, 회사나 조직의 비전이 구성원의 업무에서의 목표와 성과로 일치시킬 수 있을까?
Jino
(성장중독자의 단상(斷想) #1)
성장에 대한 글을 쓰기 시작한 후 경험을 공유하는 어려움을 크게 느끼게 된다.
서사적인 시점으로 경험을 전달하는 것이 아니라 그 경험 중에서 글을 읽는 사람에게도 도움이 될 수 있는 '배움' 또는 '간접 경험'이 될 수 있는 것이 무엇인지 생각하면서 주제를 선정하고 글을 쓰기 때문이다.
대부분의 성장은 시행착오, 실패를 통해 크게 돌아왔다. 성공은 온전히 혼자의 힘으로 만들기 어려운 일을 하고 있기도 하다. 그래서 성장하는 경험을 공유하는 것이 더욱 어렵다.
무엇이 성장하였다. 어떻게 했더니 성장했다고 간단하게 한 단락을 적기 위해서는 그 성장을 위한 시행착오의 전과 후를 다시 떠올려야 하고, 시행착오(실패) 후의 고통을 떠올린 후, 그 후에야 한 단락으로 된 경험(Insight)을 적을 수 있게 된다.
이런 글쓰기를 하는 최초의 목적이 "남들에게 도움이 되는 글"이었기 때문에 생생한 시행착오, 실패의 경험을 전달하려고 용을 쓰고 있다. 새삼스러운 감정이 스쳐 지나가기도 하고 다시 벅차오르는 감정이 떠오르기도 하기 때문에 제법 감정 소모가 큰 작업이라 하루 한 편의 초안을 겨우 마무리하는 것 같다.
그래서,
단상(斷想)이라는 주제로 어깨의 힘을 빼고 자유롭게 의식의 흐름을 옮길 수 있는 곳으로 쉬러 오게 되었다.
단상의 번호가 100번이 되었을 때 나는 목표로 했던 성장의 경험을 모두 전달했을까?
내 글들이 정말 다른 사람들의 성장에 도움이 되었을까?
보람찬 웃음을 지을 수 있었으면 한다.
Jino
제품을 고민하고 만들어가는 일을 하면서 실패의 경험과 '개인의 성장'
을 공유하면서 또다른 성장 엔진을 만들기 위해 조금씩 전진하고 있습니다.
이번에 공유 드릴 내용은 첫 사회생활 부터 지금까지 약 14년동안의 '성장 여정' 인데요. 경력증명서에 적는 나의 경력, 역량에 대한 이야기가 아니라 무엇을 하고 싶고, 어떤 (계기로) 성장을 했는지를 꽤 오랜 시간을 들여 정리해 보았습니다.
눈 앞에 삭적한 일들, 숫자들을 해결하는데 몰두하다 보면 가끔 내가 뭘하고 있지라는 생각에 순간 멈짓 할 때가 있는데요. 만약 그런 느낌이 드신다면 저 처럼 본인의 '성장 여정'을 한번 회고-정리 해 보시는 걸 추천 드립니다.
첫 번째 챕터,
제 주변 사람들의 삶이 근본적으로 달라지고, 지금 보다 편하게 살 수 있도록 만드는 일을 하고 싶었습니다.
저는 시각디자인 전공이었지만 디자인보다는 애니메이션이나 게임처럼 많은 사람들에게 '울림'을 줄 수 있는 것을 동경했습니다. UX/UI라는 개념이 생소했었던 2007년, 4학년 전공 수업으로 UX/UI 수업을 들으면서 사람들이 사용하는 무엇인가를 만드는 것이 재미있는 일이라는 강한 느낌을 받게 되었고 졸업 후 UX/UI 에이전시에 합류하게 됩니다. UX/UI 기획자라는 업무를 수행하면서 사용자 경험이 얼마나 큰 힘을 가지고 있는지 현업에서 체감하게 되었고 제 커리어의 비전은 이때 완성 되었습니다.
내 주변 사람들의 삶이 근본적으로 달라지고, 더 편하게 살 수 있는 무엇인가를 만들고 싶다.
두 번째 챕터,
일을 누구보다 열심히 하면 자연스럽게 성장했습니다.
첫 번째 회사는 UX/UI 에이전시에서 다양한 디바이스의 UI를 기획하고 프로젝트 매니징을 하는 역할을 6년 조금 넘게 했습니다. 이 시기에는 일을 잘하는 것 = 성장이라고 생각했습니다. 사실 '성장'해야겠다는 생각은 한 번도 해본 적이 없습니다. 그보다는 일을 잘하는 전문가가 되어서 인정받고 싶다는 목표를 가지고 있었습니다.
하지만 마음속의 답답함, 힘듦이 쌓이고 쌓였고 "주어진 요구사항 안에서 최선의 결과물을 제안하는 업무의 한계(왜 요구사항이 나왔는지 출시 후 성과를 알 수 없다는 것을 포함)", "UX/UI기획자라는 포지션이 사라질 것이라는 예감"에 더해 개인적인 사정으로 퇴사하게 되었습니다.
첫 번째 회사, 두 번째 회사를 통해 경력을 위로 끌어올려보았고, 낮은 곳으로 내려와 다시 올라가는 경험을 하면서 '주도적'으로 일하는 곳에서 제가 무엇인가를 결정하고 싶었고, 전문성을 갖춘 회사에서 일하면서 발전하고 싶다고 생각하게 되었습니다.
세 번째 챕터,
이전에 제가 가진 역량, 경험을 버리고 변해야만 성장할 수 있었습니다.
스타트업, 린, 에자일, 칸반, 수평적인 문화를 가진 세 번째 회사에서 "성장"이라는 단어가 이론이나 개념이 아니라 실제로 행동을 통해 증명해야 하는 환경이었습니다. 3개월 트라이아웃(수습기간)도 겨우겨우 통과하고 이후 1년 넘게 부딪치고, 넘어지고, 다투고, 내보내질 뻔하면서 그야말로 하루하루 살아남기 위해 스스로를 증명하기 위해 몸부림쳤습니다.
모르는 것이 있다면 빠르게 학습, 실행을 위한 주도성, 적극적 커뮤니케이션, 역할과 도메인에 대한 전문지식의 체득, 신뢰할 수 있는 동료가 되기, 1000% 거짓 없이 떳떳하게 일하기
iOS 플랫폼으로 출시하는 제품담당을 시작으로 독립적인 제품팀과 가설을 검증하는 역할, 몇백만 단위의 월간 사용자가 사용하는 큰 규모의 B2C서비스의 Product Manager, 제품전략을 고민하는 Product Owner 역할까지 할 수 있도록 성장한 것은 위에 열거한 성장 엔진들을 새롭게 장착할 수 있었기 때문입니다.
네번째 챕터,
남의 기대를 충족시키기 위한 성장이 아니라 나를 위한 성장이 필요했습니다.
정기건강검진을 통해 갑상선암 진단을 받고 '암환자'가 되었습니다.
수술과 회복을 하는 시기에 저의 인생을 많이 돌아보게 되었고 스스로를 원망하는 힘든 시간을 거쳐 인생관을 살짝 바꾸게 됩니다.
회사, 가족이 바라는 내가 아니라, 내가 하고 싶은 것을 하기 위해 성장하고 싶다.
다섯 번째 챕터,
성장중독자로 불리게 되었습니다.
Early Stage의 스타트업인 지금 회사에서 저의 성장은 하드스킬, 소프트스킬, 직무의 전문성의 확보를 넘어 더 큰 변화가 필요하다는 것을 느끼게 됩니다. 작은 규모의 회사에서는 구성원 한 명의 성장, 변화가 더 큰 임팩트를 가진다는 것을 체감하게 되었습니다.
스스로의 컴포트 존을 깨고, 남들이 생각하는 편견에 도전하는 더 큰 성장을 하자.
지금 회사의 구성원에게 '성장중독자'라는 별명(?)을 얻게 되었습니다. 처음에는 적극적으로 부정하였습니다만, 개인 회고를 하면서 곰곰이 생각해 보니 '성장의 고통을 포함한, 긴장, 기대, 성취에 빠져있다.'라는 점에서 실소할 만큼 잘 어울린다고 생각하게 되었고. 그렇게 저의 애칭(필명)으로 삼게 되었습니다.
원문 전체가 보고 싶으시다면,
Jino
첫 번째 글에 이어 나머지 5개 실패 확률을 높이는 꿀팁(?)을 공유해 드립니다.
현재 이런 상태에 있거나 미처 고려하지 못하신 항목이 있다면 진지하게 검토해 보시는 걸 추천드립니다.
새로 팀 빌딩을 한 제품팀, 경험이 많지 않은 PM(PO) 이 제품팀에 합류하여 리딩하거나, 창업한 지 얼마 되지 않은 회사의 경우 서로의 역할이나 역량을 확인할 기회나 시간이 촉박한 상태에서 신규 제품의 PMF의 검증을 담당하게 될 경우 실패할 확률이 매우 높았습니다.
이걸 왜 못한다는 거지? 이 정도를 이 기간에 개발하지 못하는 제품팀인가?
도대체 무엇을 개발한다는 거지? 그 제품이 정말 유의미한 성과를 만들 수 있는 건가?
실패할 수밖에 없는 이유.
신뢰의 강도가 낮은 상태에서는 PMF 검증을 하는 동안 제품팀이 겪게 되는 매우 불확실성이 높은 상태, 실패의 연속인 실험과 학습의 사이클을 견디기 어렵습니다.
: 제품팀 안에 PM(PO)가 깊숙하게 들어가 있는 구조라면 시행착오를 거치고 회고를 하는 등의 활동으로 서로의 신뢰와 working agreement를 잡아갈 수 있지만, PM(PO)와 제품팀이 독립적인 관계일 경우에는 이러한 긴밀한 커뮤니케이션을 하는데 많은 코스트가 들어갔던 것으로 기억합니다. 만약 현재 신뢰의 강도가 낮다고 생각하신다면 일주일이내에 실행, 성과분석, 회고까지 진행할 수 있는 작은 실험을 제품팀과 함께 여러 번 진행하면서 팀빌딩(사람만 모으는 것이 아니라)을 다시는 것을 추천드립니다.
B2C 제품에 한정적이긴 하지만, 제품 출시에 1개월 이상 걸리면 중간에 출시를 못하게 되거나 출시하더라도 좋은 결과를 얻지 못했습니다.
경쟁사 리서치, 사용자 퍼소나를 정의하고, MVP에 포함이 되는 핵심사용자 경험을 설계하고, 최종 출시 제품의 SPEC의 논의하는데 꼬박 2주, 그 후 UX디자인, 브랜딩 디자인을 하는데 2주.
자 이제 드디어 제품을 개발합시다!라고 해서 UX 디자인 리뷰를 하는데, 웬걸 개발을 2개 월해야 할 분량의 디자인이 완성되어 있는 상황. 그때서야 출시 스펙을 다시 잘라서 논의해 봅시다!라고 미팅을 해보지만 이미 시간은 5주나 지나가 있는 상황. 엇! 우리가 만들려고 했던 제품이 000 스타트업에서 출시해서 좋은 반응 이라는데?
실패할 수밖에 없는 이유.
PMF stage의 제품의 MVP는 정말 정의하기 어렵습니다. 지금 당장 1위 하고 있는 제품과 경쟁하는 제품을 개발하는 것이 목적이 아니라 타깃 사용자에게 핵심 가설을 검증할 수 있는 최소한의 기능을 개발하는데 목표를 두어야 합니다.
: 1개월이라는 기간은 주관적인 의견과 개인적인 경험으로 각 회사의 조직, 일하는 문화, 구성원의 역량에 따라 달라질 수 있다고 생각합니다. 최대한 도전적인 일정으로 제품을 개발하여 출시 후 다음 1개월 동안 성과를 분석하고 Growth 하는 사이클을 하나의 가설을 검증을 완료하는데 필요한 기간으로 한정하고, 그 기간 내 어떤 것들 실행해야 하는지 우선순위를 결정하는 방법을 추천드립니다. (출시 후 한 달의 실행을 통해 출시 스펙에 포함되지 않았던 많은 일들을 빠르게 실행해야 하기 때문에 사실 출시 후가 더 정신없고 짜릿한 기간입니다.)
타깃 유저를 잘 모객 해서 제품을 사용하게 하는 것은 제품을 개발해서 출시하는 것만큼이나 중요합니다. 이때 첫 일주일간의 CPI, CPA 단가가 예상치의 200% 이상 높게 나온다면 실패한 가설일 가능성이 매우 높습니다.
현재 1등 하고 있는 제품의 등록정보를 벤치마킹해서 기본적인 ASO 셋업을 했고, 관여도 높은 타깃 유저 모객을 위해 메타채널에 이미지 소재와 동영상 소재를 2개 이상 그룹으로 분리해서 세팅해 두었다. 다음날 아침 CPI단가가 6,000원. 3일째에 조금 낮아져서 5,500원인 상황. B2C앱 설치단가가 5,500원이라고?
실패할 수밖에 없는 이유.
타깃 유저와 제품 핵심 가설이 어느 정도 들어맞는 경우, 기대하는 수준의 CPI, CPA 단가를 보여 줍니다.
: 퍼포먼스 마케팅 셋업이 잘못된 것이 아니라면 앱 설치, 회원가입(또는 첫 번째 전환) 단가는 여러분들의 제품의 핵심 가설에 대한 1차 검증 데이터를 제공하게 될 것입니다. 이때 광고 클릭(CPC) 단가는 괜찮은데 설치(CPI) 단가가 너무 높아진다면 ASO를 점검해 볼 수 있습니다. ASO를 최적화하고도 설치 단가가 떨어지지 않는다면 그 제품의 타깃 사용자에게 '설치할 만한 가치'가 없다고 보면 됩니다.
리뷰 작성을 요청하는 기능이 있는데, 평점이 3.5 아래로 떨어진다면 제품의 퀄리티가 사용자들의 기대에 미치지 못하거나 제품의 핵심 가설이 동작하지 않았을 경우입니다.
핵심 사용자 경험 끝에 만족스러웠다면 평가를 요청하는 팝업을 표시하고 동의 한 유저를 스토어로 보내는 간단한 기능이 제공되고 있는데 10% 미만이 작성하기를 클릭하고 그나마 평점은 3.0인데 시간이 갈수록 떨어지는 추세를 보이고 있다. 간혹 달리는 리뷰는 경쟁 제품과 비교하거나 의미 없는 내용뿐.
실패할 수밖에 없는 이유.
타깃 유저와 시장에 FIT 한 제품이라면 좋은 평가를 받지 못할 수가 없습니다. 출시 후 한 달간 업데이트를 하는 동안 실제 사용자들의 긍정적인 평가를 확인하지 못한다면 실패라고 생각해야 합니다.
: 특히 리뷰의 경우 점점 더 고관여 사용자들만 작성하는 추세이기 때문에 한 명의 의견이나 불편은 30-40명의 동일한 사용자가 있다고 생각해도 됩니다. 문의하기(메일 쓰기) 기능을 간단하게 만들고 출시 후 인입되는 사용자들의 의견에 집중하고 높은 우선순위로 개선하거나 수정할 필요가 있습니다.
B2C 제품에 한정적이지만 PMF의 단계의 제품을 개발하고 출시한 후, 제품팀이 일할 때만 제품을 사용하는 경우에 실패할 확률이 매우 높습니다.
회원 가입부터 핵심 사용자 경험의 끝까지 어떤 화면들이 있는지 한 번도 써보지 않은 마케터, 현재 어떤 오류가 있는지 어떤 사용성에 불편함이 있는지 계속 제품을 사용하면서 리스트업 하지 않는 UX 디자이너, 일단 출시를 했으니 다음 과제가 구체화될 때까지 코드 품질을 높이기 위해 시간을 보내는 엔지니어, 쌓이는 데이터와 정성적인 피드백에 압도되어 지금, 내일 제품에 필요한 과제가 무엇인지 정의하지 못하는 PM(PO)로 구성되어 있다면 제품이 성공하는데 필요한 아이디어를 낼 수 있을까요?
실패할 수밖에 없는 이유.
스스로가 만든 제품을 잘 사용하지 않는다면 남들이 어떻게 사용하는지, 어떤 부분을 개선해야 하는지, 어떤 기능이 필요한지 누가 정의해 줄 수 있을까요?
: 한 달을 꼬박 매달려 치열하게 만든 제품에 애착과 성공에 대한 기대와 흥분이 없는 제품팀이라면 PMF 검증을 통과하더라도 유의미한 수준의 Growth를 만들기 어려울 수 있습니다. 그 원인이 어디에 있는지 반드시 찾고 개선을 위한 노력을 하는 것을 추천드립니다.
'반드시 실패한다' 첫 주제에 대한 글을 이렇게 마칩니다.
앞으로도 실패 경험을 공유하는 글로 찾아 뵙겠습니다.
Jino
PM(PO)로서 다양한 제품을 탐색(Discovery), 검증하면서 PMF stage에서 실패 확률을 엄청나게 높이는 꿀팁(?)을 공유해 드립니다. 현재 이런 상태에 있거나 미처 고려하지 못하신 항목이 있다면 진지하게 검토해 보시는 걸 추천드립니다.
첫 번째,
'될 놈'인지 확인하지 않고 실행했다.
: 통찰이나 경험으로 해성 같이 시장이나 사용자의 문제를 해결하는 제품을 만들 수 있을까요? 제품을 개발하는 것은 형태가 어떻게 되었든 많은 비용(시간, 인력 등)이 투입됩니다. 최소한의 검증은 하고 들어가야 출시 후 실패 하더라도 유의미한 학습, 성장이 가능합니다.
시장 규모, 경쟁 서비스, 주요 사용자들을 충분히 파악하지 않았다.
: 여러 제품들을 출시하면서 느꼈던 것 중에 하나인데 올바른 문제를 해결하는 제품, 가치를 더해주는 제품이더라도 결국 비즈니스 모델이 동작할 수 있어야 한다는 것입니다. 이런 측면에서 바라보면 "문제"에만 집중할 경우 그 문제 해결에 기꺼이 돈을 지불할 사용자의 볼륨이 지나치게 적을 수 있습니다. 혹은 트렌드가 다소 이른 시기라면 때가 올 때까지 제품을 유지하고 알리는 비용이 기하급수적으로 늘어날 수 있습니다.
두 번째,
우리 제품을 설치할 이유, 삭제하지 않고 내일 다시 쓸 이유가 부족한 핵심 가설을 제품 출시 전 정의하지 못했다.
: 다음의 질문을 반드시 치열하게 생각해봐야 합니다. "그 문제가 얼마나 자주 발생합니까?", "그 문제를 해결하지 않으면 얼마나 불편합니까?", "현재 그 문제를 어떻게 해결하고 있습니까?", "그 문제를 해결하기 위해 돈을 지불할 용의가 있습니까?" 제품을 사용하는 사용자(고객)가 다른 제품을 사용하지 않고 여러분의 제품을 사용해야 하는 단 하나의 이유가 있어야 핵심 가설이라고 할 수 있겠습니다.
세 번째,
PMF stage의 제품에서 핵심 가설의 검증과 사용자 외에 중요한 것은 없다.
: 특히 초기 스타트업에서 PMF stage에 제품, 사용자, 비즈니스모델 이외에 다른 것들이 제품전략에 중요한 의사결정에 영향을 주는 경우가 있었습니다. 다행히 제품이 PMF를 통과한다면 괜찮지만 그렇지 않은 경우에 회사의 체력을 더 크게 떨어트리게 되는 것 같다는 생각입니다.
네 번째,
제품의 핵심 가설, 사용자 경험이 되는 콘텐츠, 전문성이 확보되지 않은 상태라면 제품 가설의 검증뿐만 아니라 성공할 수 없다.
: 제품의 핵심이 되는 역량이 외부에 있는 경우가 있습니다. 그렇다면 제품을 개발하기 전에 이 불확실성을 낮출 수 있어야 합니다. 제품을 개발하면서 제휴, 아웃소싱으로 동시에 해결하면 되겠지라고 생각하고 계신다면 다시 한번 그것이 실현가능한지, 그걸 할 수 있는 사람이 있는지 생각해 보시길 바라겠습니다.
다섯 번째,
퀄리티가 떨어지는 제품을 당신은 다운로드합니까? 그런데 왜 당신이 만드는 제품이 구린데 남들이 다운로드할 거라고 생각합니까?
: 린 스타트업을 포함한 다양한 Growth 방법론에서 '실험'을 이야기합니다. 실험의 대상이 되는 건 사용자(고객)이지요. PMF stage에 있는 제품이기 때문에 봐주는 사용자는 제품팀의 가족이나 친구를 제외하면 없다고 생각합니다. 1등 제품의 퀄리티까지는 어렵겠지만 보편적으로 "이 정도는 괜찮네"라는 수준이 아니라면 여러분의 제품은 기대하는 PMF를 검증하기 어려울 것이라고 생각합니다.
조만간 #2로 찾아 뵙겠습니다.
제가 경험했던 다양한 실패의 경험을 공유하는 것을 통해서 다른 분들의 학습 비용이 낮아지거나, 현재 어려운 상황에 처한 Product Manager, Product Owner, CEO 분들이 문제를 해결하는데 도움이 되길 바라며 작성합니다.
경험에 의존한 내용으로 검증된 방법론이나 이론이 아닙니다. 편향된 방향으로 기술된 내용이 일부 포함 될 수 있으며, 이로 인해 불편하시거나 이견이 있으신 분들은 편하게 알려 주시면 저의 성장의 기회로 생각하겠습니다.
