사이드프로젝트로 임팩트를 내는 법

[TTT실험실] - 1

[임팩트를 내기 위한 1년의 시도]

졸업 후 1년동안 6번의 사이드 프로젝트, 3번의 서비스 출시와 2번의 실패, 1번의 창업을 겪으면서 문득, 세상에 더 큰 임팩트를 내기 위해서 나를 갈아서 넣는 것은 분명한 한계가 있다는 토스의 강수영 디자이너님의 인터뷰 내용에 크게 공감할 수 있었습니다.

“어떤 방법을 통해서든 제곱으로 가는 임팩트를 내려면 나를 갈아서 할 게 아니라 시스템을 만들어서 그걸 통해 내 꿈을 이뤄야겠다는 생각이에요. “ - EO 인터뷰 중-

시스템, 그 놈의 시스템. 도대체 어떻게 혼자서 이 시스템을 만들어야 할지 막막함을 느끼던 중, 우연한 기회로 토스에서 커리어를 쌓아오신 영화님의 강의를 듣게 되었고 정말 아낌없이 공개해주신 영화님의 실험 방식과 일상에서 실험을 녹이는 사례들을 보며 현재 시스템의 청사진을 그리게 되었습니다. (유난한 감사를 전합니다ㅎㅎ)

TTT의 구조

[지속성과 확장성]

concept 자체는 굉장히 단순한 구조로, 성공과 실패 여부 상관없이 각 스쿼드의 결과물들은 한 콘텐츠 플랫폼인 X라는 프로덕트의 콘텐츠로 귀결되는 구조입니다.

특히 프로덕트와 프로젝트를 구분하여 '프로덕트 스쿼드'에선 6달간 리스트업한 아이템들의 PMF를 검증하는 과정을, '프로젝트 스쿼드'에서 디자이너로서 해소하고 싶은 실험을 진행하며 다양한 목적을 가진 구성원들의 니즈를 최대한 포용할 수 있는 커뮤니티로써의 기틀을 마련하고자 했습니다.

[한계점]

자유롭게 프로덕트와 프로젝트를 진행하고 성공 혹은 실패로 정의되기까지의 과정들을 다시 프로덕트 X의 콘텐츠로 활용하는 순환을 그리는 것이 이 모델의 최종적인 청사진이 될 예정입니다.

사실 도식화로 봤을 땐, 너무 이상적인 그림이라는 생각이 드실 수도 있을 것 같은데요, 맞습니다. 제가 생각해도 너무 이상적이고, 리소스 운용이나 우선순위, 병목같은 요소들이 전혀 고려되지 않았습니다.

[그럼 이제 무엇을 해야할까?]

사실.. 이미 진행하고 있습니다. 결국 이 시스템에서 가장 중요한 것은

[사이드 프로젝트’라는 느슨한 관계에서 규모가 커지더라도 이 모델이 지속성을 가질 수 있는가?] 이기 때문에,

문제를 지속성 관점으로 더욱 쪼개서 가장 최소한의 가설을 기반으로 해당 모델에 대한 실험을 진행하고 있습니다.

앞으로 천천히 더 공개하겠지만, 현재 1개의 프로덕트 스쿼드와 2개의 프로젝트 스쿼드를 병행하며 콘텐츠 플랫폼으로 귀결시키는 최소한의 사이클을 돌리고 있고, 해당 사이클이 성공으로 판단되면, 사이클을 지수적으로 늘릴 수 있는 방안을 마련할 계획입니다.

[첫 글을 마치며]

예비군에 왔는데 심심해서 긴 글을 쓰긴 했다만, 이미 비슷한 경험이 있으신 누군가에게는 제가 정말 어설픈 얘기를 하고 있다고 느끼실 수도 있을 것 같습니다.

그래서 꼭 부탁드리고 싶습니다. 제 생각이 부족한 점, 왜 안 될 것 같은지, 혹은 어떤 걸 주의해야 하며, 현재 고민하고 있는 병목은 어떻게 해소할 수 있을지 더욱 많은 분들의 의견이 궁금합니다.

긴 글 읽어주셔서 감사드리며, 또 소식을 전하러 오겠습니다!