내가 디자이너와 PO를 거쳐 배운 것들
시간이 많이 지나서야 하는 회고
총 10년간 프로덕트 디자이너를 거쳐 PO로 일했습니다. 그리고 크고 작은 성공 실패를 겪었습니다. PO와 디자이너는 명백히 다른 관점과 입장차가 존재하는 것을 실감했습니다. PO는 문제정의를 통해 일을 만드는 사람이고 디자이너는 그에 적합한 솔루션을 찾아 일을 처리하는 사람에 가까웠습니다. 머릿속에서 두 입장을 오가다 보니 용기가 안나 덮어버린 과거와도 마주하게 됐습니다. 이 글은 제 커리어에 대한 까만색 회고이기도 합니다.
모든 상황에 PO가 필요한 건 아니었다.
제가 겪은 스타트업에서 모두 PO가 필요했던 것은 아닙니다. PO는 0to1 단계의 회사에서 뚜렷한 방향성과 정답을 갖지 못할 때, 그리고 대표가 너무 많은 것들을 하고 있어 스쿼드에 권한을 위임해야 할 때 적절합니다. 과거 재직한 스타트업 'J'의 경우 입사할 때부터 뚜렷한 방향성이 존재했습니다. 당시 디자인 리더였던 저는 “신선한 식재료를 최대한 빠르게 고객 식탁 위에 올린다”를 목표로 모든 디자인 방향성을 맞췄습니다. 이는 거창한 구호나 비전 같은 것이 아니었습니다. 실제로 이 가치를 통해 회사가 돈을 벌고 확실하게 성장하고 있었기 때문입니다. 이 경우 권한을 위임받은 PO는 필요치 않았습니다.
J에서는 경영진이 내놓는 서비스의 큰 방향성과 전략이 납득됐기 때문에 솔루션, 실행, 그리고 결과 해석에만 집중하면 됐습니다. 누군가 새롭게 서비스의 문제 정의를 할 필요는 없었습니다. 반면 제가 PO로 재직한 'A'의 경우 회사 내 많은 비즈니스 모델과 스쿼드가 존재했습니다. 시작하는 단계였기 때문에 대부분 명확한 방향성을 찾아야만 하는 단계였고 각 스쿼드마다 대표가 권한을 위임한 리더나 PO가 있었습니다. 아직 뚜렷한 답이 없었기 때문에 스쿼드마다 명확한 문제 정의가 솔루션보다 훨씬 중요했던 기억이 납니다.
모든 상황에 필요하지는 않았던 PO @unsplash따라서 PO가 있거나 없거나, top-down 방식이거나 아닌 것은 좋고 나쁨의 문제가 아니라 회사의 상황에 따라 달라집니다. 그리고 대개는 회사가 내고 있는 매출과 관련이 깊습니다. 대표의 경영 방식이 다소 올드하더라도 회사가 매출을 확실히 내며 향후 몇 년간 방향이 명확하면 저는 그게 정답이라고 생각합니다. 이때는 PO가 아닌 솔루션을 공고히 할 기획 포지션이 필요합니다. 꼭 스프린트나 스쿼드가 필요하지도 않습니다. 모든 상황에 권한 위임이 필요한 것은 아니기 때문입니다. 경영 방식에 동의하지 않는다면 본인이 떠나면 됩니다.
0to1의 디자이너 역시 어떤 상황에 놓이느냐에 따라 일하는 방식이 크게 달라집니다. 그리고 대부분 이 두 가지 구조(PO가 필요한 회사와 명확한 방향성이 정해진 회사) 중 하나에 놓이게 됩니다. 따라서 이 두 가지 환경을 이해하면 낭비되지 않는 디자인을 할 수 있습니다. 두 구조 모두 PO 입장에서 보면 다음과 같은 공통된 흐름을 가집니다.
문제 정의 > 솔루션 > 실행 > 결과 해석
아직 확실한 방향성이 픽스되지 않은 경우, 스쿼드 내 문제 정의가 별로면 디자이너는 PO에게 질문할 수 있습니다. 더 나은 디자인 솔루션을 만들기 위한 책임감 때문입니다. 저 역시 PO 시절 정의한 문제와 가설에 대한 무수히 많은 질문과 공격을 받았습니다. 모든 질문에 답을 잘해야 한다는 중압감 때문에 매주 열리는 스프린트 위클리가 공포스러웠습니다. 하지만 시간이 지나 보니 당시 제가 함께한 디자이너, 개발자, 마케터, QA 분들은 자신들이 만들어야 할 솔루션에 대한 큰 책임감과 이행할 논리를 갖고 싶었던 것뿐입니다. 이 점을 너무 늦게서야 깨닫게 됐습니다.
저는 부족한 PO였습니다.
PO로 일하며 잘못된 문제 정의로 불필요한 기능들을 만든 적이 있습니다. 그리고 그 판단은 짧게는 몇 주, 길게는 몇 달이라는 팀의 귀중한 리소스 낭비로 이어졌습니다. 당시에는 프로덕트의 몇 배 성장을 앞당기기 위한 도전이었다고 스스로 합리화했습니다. 하지만 그 가설들은 유저에게 전혀 쓸모가 없었습니다. 그리고 팀의 리소스는 곧, 멤버들의 귀중한 삶의 기회라는 것도 시간이 한참 지나고 나서야 뼈저리게 알게 됐습니다. PO로 성급히 성과를 증명하고 싶었던 제 에고가 아니라 더 성실하게 시장에서 문제를 발견하고, 사려 깊게 제안해야만 했습니다. 이 사실을 너무 늦게 깨닫게 된 것을 후회하고, 당시 동료였던 분들께 여전히 죄송한 마음입니다.
디자이너로 성공에 기여하기
지금부터는 실패를 통해 얻은 것들을 털어놓으려고 합니다. 제가 생각하는 0to1 스타트업의 절대 가치는 ‘생존’입니다. 그리고 스타트업의 생존율을 높이는 가장 확실한 방법은 성공 확률이 높은 솔루션을 최대한 많이 실행하는 것입니다. 여기서 0to1 스타트업의 PO와 디자이너는 솔루션에서 창의적일 필요가 없습니다. 시장에 없는 것을 ‘발명’ 하기보다는 영리하게 ‘모방’하는 것이 많은 부분 더 낫기 때문입니다. 그런데 다시 디자이너 입장으로 이야기하는 상황에서 ‘모방’이라는 단어를 쓰기가 무척이나 조심스럽습니다.
프로덕트 디자이너와 모방 @unsplash미디어에서 만들어낸 디자이너 이미지와 창의성은 떼려야 뗄 수 없습니다. 하지만 0to1 스타트업에서 일하는 디자이너의 가치는 이 세상에 없는 솔루션을 만들어내는 창의성과는 크게 관련이 없습니다. 우리 스쿼드에서 정의한 문제는 이미 전 세계 많은 사람들이 겪었을 문제이고, 그것을 풀어낸 솔루션들은 이미 존재할 것이기 때문입니다. 제 생각에 디자이너가 팀의 성공률에 조금이라도 보탬이 되기 위한 가장 좋은 방법은 ‘우리와 비슷한 스테이지’에서 ‘유사한 문제’를 해결한 ‘솔루션’을 최대한 많이 찾고 우리 상황에 맞게 적용해 보는 것입니다.
여기서 중요한 것은 ‘우리와 비슷한 스테이지’입니다.
저는 디자이너로 처음 벤치마킹을 배울 때 대성한 서비스의 현재 모습을 기준으로 삼았습니다. 선배들과 사수 모두 그렇게 하고 있었기 때문입니다. 그런데 여기에 큰 함정이 존재합니다. 바로 생존자 편향입니다. 현재 멋져 보이는 서비스도 초창기에는 지금과 엄청나게 다른 모습과 상황일 확률이 높습니다. 따라서 벤치마킹에는 시점에 대한 명확한 기준이 필요합니다. 그리고 외형과 함께 숨겨진 의도를 해석할 능력이 필요합니다.
조금 더 명확하게 말해보겠습니다. 우리와 비슷한 스테이지에 있고 유사한 문제를 납득이 가는 솔루션으로 풀지만, 동일 선상의 경쟁자들보다 티가 나게 앞선 존재를 찾아야 합니다. 0to1이라면 MAU 1,000만 명의 이미 검증된 서비스가 아닌 10만 명의 빠르게 성장하는 숨은 서비스들이 여기 해당합니다. 편의상 글에서는 이 존재를 '레드울프'라고 부르겠습니다. 만약 운이 좋게 레드울프를 찾았다면, 목적(UX, 마케팅, 브랜딩..)에 맞게 낱낱이 분해하는 훈련을 하면 좋습니다.
왜 온보딩의 첫 화면이 일러스트일까?
왜 소셜 로그인에 애플과 트위터만 있을까?
왜 콜투액션이 녹색일까?
왜 팝업이 떠야 할 순간에 새 페이지로 이동시켰을까?
왜 친근한 퍼소나인데도 ’ 해요체’를 UX 라이팅에 녹이지 않았을까?
그런데 생각보다 국내와 해외, 그리고 오래된 UX 아카이브를 뒤져도 이 레드울프를 찾는 것이 저는 정말 어려웠습니다. 신규 서비스에 적합한 레드울프를 찾기 위해 한동안 눈이 돌아있던 적도 있습니다. 유사한 성장 스테이지와 풀고 있는 문제, 납득 가는 솔루션이 일직선에 놓인 희귀한 사례이기 때문입니다.
저는 성공적인 솔루션을 팀에 제안하고 싶다면 레드울프를 찾기 위해 70% 가까운 시간을 쓰라고 감히 말씀드리고 싶습니다. 이 고민이 디자인을 조금 더 아름답게 만들고, 디자인 시스템을 정교하게 만드는데 0to1의 부족한 리소스를 투자하는 것보다 생존에 더 이롭다고 생각합니다.
정말 찾기 힘들었던 레드울프 @midjourney스퀘어 창립자가 쓴 [언카피어블]이라는 책에는 ‘할 수만 있다면 모방하라, 해야만 할 때는 발명하라’라는 말이 나옵니다. 10년 간의 커리어에서 수많은 기능을 디자인하고 기획했지만 ‘발명’을 해야 하는 경우는 극히
일부였습니다. 그리고 대부분 잘못된 판단은 제가 발명을 하려고 할 때 발생했습니다. 아마도 0to1에 우리가 직면할 많은 문제는 레드울프를 찾고 분해해 솔루션으로 적용하는 것으로 대응이 가능할 것입니다. 그리고 우리가 성장한 만큼 또 그 수준에 맞는 레드울프를 찾아 나서야 할 것입니다.
PO가 있는 조직이라면 디자이너는 문제 정의보다 적합한 솔루션을 찾는 것이 더 중요하다고 말했습니다. 하지만 잘 납득 가지 않는 문제 정의를 그냥 넘어가선 안됩니다. 만약 수준 높은 PO, 혹은 리더와 일한다면 문제 정의는 다음 예시처럼 날카롭게 다가올 것입니다.
PO와 디자이너의 대화 예시
배경) 새로운 기능을 도입하여 사용자 유지율을 높이기 위한 회의.
PO : 안녕하세요, 디자이너님. 이번 주에 우리가 초점을 맞출 기능에 대해 논의하고 싶습니다. 가설은 앱의 1개월 후 사용자 유지율을 높이는 것입니다. 현재 사용자 유지율이 20% 수준인데, 경쟁사들은 50%로 차이가 크게 나는 상황입니다. 경쟁사 수준으로 사용자 유지율을 높이면 장기적으로 활성 사용자 수를 3배 이상 증가시킬 수 있습니다.
디자이너 : 안녕하세요, PO님. 사용자 유지율을 높이는 것은 매우 중요한 목표네요. 이를 위해 어떤 접근 방식을 생각하고 계신가요?
PO: 저희가 생각한 첫 번째 접근 방식은 사용자 맞춤형 알림 기능입니다. 사용자에게 개인화된 알림을 보내어 앱에 다시 방문하도록 유도하려고 합니다. 예를 들어, 사용자가 관심을 가질 만한 새로운 콘텐츠나 프로모션 정보를 제공하는 것입니다.
디자이너: 좋은 아이디어네요. 개인화된 알림 기능은 사용자 참여를 높이는 데 효과적일 수 있습니다. 알림 메시지 내용도 중요할 것 같습니다. 사용자에게 유용하고 관련성 있는 정보를 제공해야 하니까요. 알림을 어느 시점에 보낼지에 대한 전략도 필요합니다.
PO: 맞아요. 알림의 타이밍도 중요합니다. 사용자의 앱 사용 패턴을 분석하여 적절한 시점에 알림을 보내도록 설정할 필요가 있습니다. 또 다른 접근 방식으로는 사용자 리워드 시스템을 도입하는 것도 고려하고 있습니다. 사용자가 앱에 지속적으로 참여하도록 인센티브를 제공하는 것이죠.
디자이너: 리워드 시스템도 좋은 접근 방식입니다. 사용자가 특정 행동을 할 때마다 포인트를 적립하거나, 일정 기간 동안 활동을 유지하면 보상을 주는 방식이 효과적일 것 같습니다. 이를 매력적으로 디자인하여 사용자에게 동기부여를 줄 수 있을 것 같아요.
PO: 네, 리워드 시스템과 개인화된 알림을 함께 도입하면 시너지 효과를 낼 수 있을 것 같습니다. 그럼, 우선 알림 기능의 디자인과 프로토타입을 먼저 진행해 주실 수 있나요?
디자이너: 물론입니다. 알림의 시각적 디자인과 사용자 경험을 고려한 프로토타입을 준비하겠습니다. 또한, 리워드 시스템에 대한 초기 구상도 함께 진행하겠습니다. 다음 주에 초안을 공유드릴 수 있도록 하겠습니다.
나가며
스타트업의 디자인은 가설 검증을 위한 수단일 뿐이라는 것을 인식하는 것이 매우 중요합니다. 저는 이 말이 처음에는 디자이너의 에고를 줄이라는 가혹한 말처럼 들렸습니다. 하지만 디자인뿐 아니라 개발, 데이터 관련, 마케팅 모두가 빛나고 싶은 욕망이 있고 이것은 인간의 본성에 가깝습니다. 최선은 모두가 수단임을 인지하고, 빈도 높은 실행과 어떻게든 가설을 검증하려는 합의된 의지가 아닐까요? 끝으로 제가 디자이너 - PO를 거쳐 배운 것을 요약하면 다음과 같습니다.
내 에고가 아닌 유저와 시장에서 진짜 문제를 발견하고, 레드울프가 가진 것들을 우리에 맞게 효율적이고 빈도 높게 실행한다.
이 글을 읽는 분들은 되도록 많은 실패 없이 건강한 커리어를 이어가면 좋겠습니다. 긴 글 읽어주셔서 진심으로 감사합니다.
'내가 디자이너와 PO를 거쳐 배운 것'(끝)
