파운더(Founder)가 되고 나서 보이는 것들
이런 내적 혼란이 반가운 나는 혹시 마조히스트인가.
어찌어찌 굴러가다 보니, '아니, 지금 이건 내가 파운더인 거잖아?'까지 오게 되었다. 내가 아끼는 이들에게 진짜 도움이 되는 일을 해주고 싶어 시작한 일인데, 실천하고자 하는 가치를 잃지 않기 위해 비영리 프로젝트로 운영하기 시작했다.
아무튼 그러다 보니 파운더의 포지션에서, 내가 그냥 팀원일 때는 체험할 수 없었던, 또는 완전히 이해하고 공감하지 못했던 것들을 많이 접하는 중인데, 어쩌면 이런 경험과 인사이트가 다른 사람들에게도 도움이 될지 모른다고 생각해 글을 써보고자 한다.
이번 글에서는, 파운더가 되고 나서 뼈저리게 느끼고 배운(-우는) 것들에 대해 공유할 계획이다.
물론 그 인사이트들이 딱히 몰랐던 건 아니지만, 그것을 오롯이 내 것으로 느꼈을 때와 인지적으로 이해만 했을 때와는 그 감각의 깊이와 크기가 달랐고, 또 파운더가 되고 나서야 알게 된 것들도 있기 때문이다. 결과적으로, 나는 이 경험이 내 내면을 한층 깊고 넓게 확장시켰다고 믿으며, 지금도 계속 그렇게 작용하고 있다고 생각한다.
이제 각설하고 들어가 보자.
목차
1. 팀원으로서
2. 파운더로서
3. 프로덕트 운영의 주체로서
제1장 - 팀원으로서
한 조직 내 피라미드의 아래에 속하면서 동시에 무언가 성장과 진보를 이룬다는 건 동시에 성취하기 굉장히 어려운 일이다. 그래서 많은 사람들이 사이드 프로젝트를 하기도 하고, 이직도 하는 것이리라. 나 또한 영국에서 사는 동안 다음 디딤돌을 밟기 위해 무던히도 고민하고, 애썼다. 그리고 감사하게도 나를 비주얼메이커로만 쓰지는 않으려는 좋은 상사를 만나, 프로덕트 디자이너로서 더 많은 것에 대한 접근권한을 갖고, 다양한 사람들과 협업해 보면서 시야를 확장할 수 있었다. 하나의 프로덕트를 운영하는 비즈니스더라도, 여러 부서의 이해관계는 무엇을 언제, 어떻게 할지 등 거시적인 것부터 디테일까지, 서로 불가피하게 얽히고설켜있다. 어떤 기능하나를 개선하고 나서 그것을 위해 어느 부서가 어떻게 노력해줘야 할지도 중요했고, 협업한 업무에 대한 KPI의 기준도 각 팀/부서의 분야에 따라 조금씩 달랐다. (특히 마케팅 부서와 긴밀히 협업해야 하는 작업들은 더 그랬다.)
하지만 솔직히 말해, 그냥 '그렇구나~' 정도였지, 사실 그다지 새로울 것도 없는 일들이었다. 물론 어떤 디자인 결정을 내리든 더 많은 요소들 사이에서 균형을 잡고, 많은 것을 배려한 결정을 내리려 노력했지만 여전히 나는 나의 역할에 더 집중했고, 가끔은 논리적인 상식을 뒤집거나 삐딱선을 탄, 의사결정들이 정말 이해되지 않았고 맞지 않다고 생각했다.
하지만 UXer로서의 내 역할에는 '비즈니스 이해관계자'를 협업에 초대하여, 그들이 한 팀으로 원활히 나와 협업할 수 있도록 돕는 것도 포함된다. 따라서 늘 각자의 주장이나 요구사항에 대한 Why를 이해하기 위해 수없이 진심을 담아 접근했다. 하지만 늘 어딘가 석연찮은 구석들이 잔재했다.
제2장 - 파운더로서
그런데 직접 프로덕트를 개발해 POC를 검증하고, 파운더라는 또 하나의 퍼소나가 생기고 나서는 그야말로 빅뱅이 터졌다. 다만, 모든 의문들이 한 번에 날아가는 그 상황은 날 겁주기 충분했다. 1인 파운더가 되고 나서는 영업, 마케팅, 프로덕트 개선 및 로드맵 수립, 펀딩 전략에 대한 고민 등 프로덕트 하나를 유지·성장시켜 가기 위해 필요한 모든 것을 혼자 도맡아야 하니, 프로덕트 오너(말 그대로, owner)로서 작든 크든, 어떤 결정을 내리는데 꽤 큰 관점의 변화를 겪게 되었다. 그중 가장 큰 깨달음은 아래 2가지였다.
1. 돈은 사업의 주춧돌이다.
혼자서 많은 것들을 고민하고 해오다 보니, 비즈니스 이해관계자들이 왜 '사용자 중심'이라는 관점에 쉽게 공감할 수 없었는지 이해가 되기 시작했다. 비록 그것이 회사를 성장시키고, 제품의 규모와 이용자층을 확장시키는 길이라고 해도 말이다. 사업이란 기본적으로 자본 없이는 존속할 수 없으며(사실상 금전적 투입이 없이는 거의 정체 수준에 가까울 수밖에 없다) 우리가 Product person으로서 이루고자 하는 것들은 대개 돈이 필요하다. 그게 설령 개발인력 투입용이 아니라 해도 말이다. 따라서, 제품개발의 우선순위는 때때로 '사용자를 위해 더 나은 UX를 만들자!'가 아닐 수도 있다. 비즈니스를 위한 자금조달의 목적으로, 때로는 UX개선이 아니라 그 외 전혀 접점이 없어 보이는 다른 개발 우선순위가 상위를 차지하게 될 수도 있다는 말이다.
파트너십 고려에 따른 제품개발 의사결정 변동 등이 아주 좋은 예가 될 것 같다.
실제로 내 마일스톤 중 최대한 빨리 성취하고 싶은 것이기도 하다. 브랜드 인지도를 높여 전반적으로 사업을 조금 더 안정적으로 궤도에 안착시키기 위해선, 다른 사업체/단체들과 좋은 파트너십을 맺는 것도 좋은데, 이는 광고 비용을 절감하는 데 큰 도움이 되기 때문이다. 아마 인스타크램 마케팅 도구나 광고를 띄워본 경험이 있다면, 그 지출이 결코 작지 않다는 것, 그리고 따라서 지속가능하지 않다는 데 어느 정도 공감할 것이다. 이런 고민을 해소하기 위해 떠올려 볼 수 있는 사업전략 중 하나가 바로 파트너십이며, 원만한 파트너십을 맺기 위해서는 요구되는 여러 물밑 작업들도 있겠지만, 때론 우리 제품을 비즈니스 파트너의 다른 비즈니스와 어떻게 연결할지 고민하는 것을 우선순위에 두어야 할 수도 있다. 그럴 경우, 프로덕트 팀의 우선순위는 그에 직접적 관련이 있는 쪽으로 언제든 바뀔 수 있으며, 실질적인 사용자의 목소리 반영이나 사용자에 대한 애정과 고민은 후순위로 약간 밀려날 수밖에 없다.
경력을 위해 경력이 필요하고, 사업유지를 위해 돈을 불러오는 결정을 하게됨...결과적으로, 파는 것이 무엇이든, 사업 존속을 위해 필요한 기능이거나 개선/변경 작업이라면, 실제 사용자의 우선순위와 1도 맞지 않더라도, 어떤 면에선 논리적으로 말이 되는 우선순위일 수 있다.
이쯤 되니 최근 카카오의 동향에 대해 더 이해하고 싶어졌다. 자승자박의 이유는 대체 뭐였을까? 물론, 언론을 통해 비친, 리더로서 방어적이었던 모습은 여전히 아마추어스럽다고 생각하지만, 궁금하다. 정말 이해해보고 싶다.
2. 아무리 MVP여도, 좋은 UX를 제공하려는 노력은 계속되어야 한다.
Pre-seed, 또는 Bootstrapped 단계에서 이제 막 POC를 검증하는 제품이라 해도, 정기적이고 꾸준한 경험 개선 세션은 중요하다. 왜냐하면 초기 검증 중인 제품은 시장에서 가장 나약하며, 특히나 B2C 시장에서 개인 소비자들은 언제든지 그것을 다른 것으로 갈아치울 수 있기 때문이다.
한번 어떤 것에 안착해 나의 오랜 역사와 그에 상응하는 데이터가 프로덕트에 누적되면, 보통은 A에서 B로 완전히 갈아타는 것이 심리적/물리적으로 점점 더 어려워지곤 한다. 욕을 먹을지언정 사용자는 그 제품을 계속 사용하게 되는 것이다. 하지만 이제 막 짜잔! 하고 시장에 등장한 새삥은, 고객과의 관계가 깊지 않기 때문에 싫거나 마음에 들지 않으면 금세 떠나버릴 수 있다. 사람들은 자기가 익숙한 것을 가장 편하게 느끼며, 원래 해오던 방식이 실제로는 더 불편하더라도 새 제품이 기존의 것을 잘 대체해내지 못하면, 얼마든지 다시 돌아갈 가능성이 높다.
신상이셔서 여러모로 공 많이 들여야 하는 장그래씨많은 아티클에서 초기 검증단계에서 MVP는 정말 최소한으로 가져가라고 조언한다. 운영자의 입장에서, 틀린 말은 아니다.
하지만 나는 약간 다른 관점을 제시하고 싶다. 아무리 MVP여도, 비주얼이 너무 구리거나 UX에 결함/불만족이 자꾸 생기면 우리는 언제 이별통보를 당할지 모르기에, 여러 측면에서 꾸준한 경험관리는 정말정말 중요하다. 더 많은 사용자를 유치하기 위한 규모적 성장도 필요하나, 초기 프로덕트일수록 질적인 부분 개선/유지에 집중하는 시간들도 반드시 가져야 한다고 생각한다.
제3장 - 프로덕트 운영의 주체로서
이런 여러 경험과 A-ha 모먼트를 겪고 보니, 2가지에 대한 의문을 짚고 가지 않을 수 없다 - 왜 고작 3-5명 밖에 안 되는 작은 스타트업부터 큰 조직까지 이해관계자 충돌이 생기며, 우리는 어떻게 이런 피곤한 문제들을 완화시켜 가야 할까?
내 생각은 이렇다.
일단 가장 주된 원인으로는 팀원 간 여전히 불투명한 의사소통 방식에 있을 가능성이 높다고 생각한다. 만약 내 글을 보고 '아, 저런! 그런 이유가 있었구나....' 하며 무릎을 탁! 쳤다면, 이는 어떤 면에서 그 팀/회사가 굉장히 제한된 내용만 공유해 왔다는 방증일 수 있다. 인력을 AI 에이전트 식으로만 보고 부려온 것이다. 우리가 AI 에이전트를 사용할 때는 계획과 목적만 명료하다면 굳이 맥락까지 이해시킬 필요가 없다. 그냥 명쾌한 지시사항을 던져주면 된다. 하지만 인간은 다르다. 내가 보기에 굉장히 뻔해 보이는 것이라도 상대방은 비동의할 수도 있고, 다른 생각을 가질 수도 있다. 그렇기 때문에 쓸데없는 정신적 에너지를 쓰지 않고자 할수록, 충분한 맥락 공유를 통해 서로 '동기화'되는 것이 중요한데, 큰 그림과 그 맥락이 투명하게 보이지 않는다면 우리는 자연스레 보이는 것에만 의존해 판단하게 된다.
그래서, 통치가 아닌 피력의 접근법이 필요하다고 생각한다.
왜 우리가 그런 선택을 할 수밖에 없는지, 더 많은 정보에 접근권한이 있는 사람일수록 더 투명하게 그 맥락을 공개하고 팀원들을 설득하는 것이다. 요구사항이 아니라, 상황설명이 곁들여져야 한다.
회사가 도산에 이르는 것은 조직에 소속된 그 누구도 원치 않을 것이다. 도리어 대부분은 내가 하루 중 절반의 에너지를 쏟는 이 일/제품이 좋은 명성을 거두고 많은 사랑을 받아서, 나 또한 그에 일조한 사람으로 남길 원할 것이다. 물론 그것이 곧, 고대 신라의 화백회의 같은, 듣기만 해도 벌써 피곤한 만장일치제여야 한다는 뜻은 아니다.
하지만 적어도, 한 팀으로 같은 목표를 향해 진척을 내려면 일정 수준의 사고력을 지닌 객체들이 모인 그룹에선, 그만큼의 상호이해를 하는 단계가 요구된다. 어느 정도 공감이 되면 적어도 감정으로 점철된 자기주장들은 어느새 차분히 가라앉게 되고, '대체 저 a;qt4!o@8vZ~는 왜 저러는 거야!'에서 '흠...'으로 바뀌게 되며, 모두에게 생각의 여지를 주기 때문이다. 여기엔 경험상 투명한 맥락공유만큼 효과적인 것이 없다.
그리고 이걸 잘 수행하기 위해서는, 자기 Ego를 조금 많이 내려놓고, 타인에 대한 불신도 조금 줄일 필요가 있다. 우리는 믿지 못하는 사람과는 그 어떤 일도 잘 해낼 수 없으며, 세상에 안전하고 확실한 것은 거의 없다. 불안함이 남아있더라도 때론 그걸 해소할 때까지 물고 늘어지는 게 아니라, 있는 그대로 포용하고 움직임은 과감하게 할 필요가 있다. 아울러 또 하나의 팁은, 바로
나와 다른 소속의 사람들과의 꾸준하고 잦은 소통이다.
개발자, 디자이너 등 나랑 직결된 이들하고만 어울릴게 아니라, 여러 팀들/이해관계자들의 고민과 현주소를 훑어봄으로써 더 큰 그림이 어떠하고, 어디로 흘러가고 있는지를 미리 파악해보면, 1번에서 쏟아야 하는 인지적 노력의 양을 조금 더 줄여볼 수 있다. '음... 난 여전히 동의하긴 힘든데..'는 될지언정 '저 ㅁㅊ놈은 왜 또... 어휴..'는 어느 정도 회피할 수 있었다.
보통 후자의 생각이 들면 감정적 동요도 함께 커지기 때문에 우리의 마음은 더 힘들어진다.
시간이 흐르면서, 적어도 내가 어떤 것을 내려놓지만 않는다면 그건 어떤 방식으로든 변화하고, 발전한다고 생각한다. 모르는 것은 찾아보고 고찰하면서 깨치게 되고, 서툴렀던 것들은 시간이 지나면 무르익는다.
삶에서 여러 가지 경험을 해보게 되면서, 많은 것들이 변화하는 걸 느끼지만 점점 더 강화되어 가는 믿음을 한 가지 꼽으라면, 그건 바로 '팀원을 뽑을 때는 능력보다 사람과 사람 간 매칭도, 그리고 인간상을 봐야 한다'는 것이다. AI 툴도 많이 나오고, 어차피 교육에 대한 접근성도 꽤나 넓어진 마당에 Hard skill 같은 건 그냥 놔둬도 웬만하면 선인장처럼 알아서 무럭무럭 자라고 숙성된다. 하지만 인간상은 그 사람이 살아온 것을 바탕으로 굳게 다져진 '신념'이며 그 사람의 정신적 버팀목이기에 거의 변하지 않으며, 잘못된 사람을 들이면 목표를 달성하는데 팀에 문제가 생겼을 때, 여러 가지 변화를 시도하는데 방해가 된다. 그래서 나는 AI로 민요 시리즈도 나올 것 같은 세상에, 말만 들어도 정말 고루하게 들리는 '사람 됨됨이를 보자'라는 믿음을 갖고 살아가려고 한다.
물론 그게, 현실적으로는 내 미래의 구직/구인활동에 가장 큰 걸림돌이 되겠지만 말이다.
