안녕하세요, 레몬베이스 웨이브 스쿼드에서 Product Owner로 일하고 있는 Dennis입니다. 🙂
금융업, 제조업, 이커머스 PM을 거쳐 재작년 초에 레몬베이스 팀에 합류했어요.

웨이브 스쿼드는 구조화된 질문 및 분석을 통해 HR & 조직문화팀이 구성원의 조직 내 라이프사이클 안에서 몰입을 체계적으로 개선하고 궁극적으로 구성원의 리텐션을 개선할 수 있는 ‘서베이’ 제품을 만들고 있어요. 출시된 지 아직 1년도 채 되지 않은, 레몬베이스 내 신규 제품이죠.

레몬베이스에서 일하는 것의 장점 중 하나는 좋은 성장 방법을 습관화할 수 있는 것 인데요. 특히 많은 동료 크루들이 자체적으로 개인목표를 세우고 회고하고 성장해 나가는 모습을 보면서 좋은 자극을 받고 있습니다.

저도 23년 한 해를 복기해보니 저와 스쿼드가 어떤 성장을 이뤘는지 몇 가지 생각나는 사례들이 있었어요. 스쿼드 내에서 이뤄진 피드백을 중심으로 각각의 문제 상황과 원인 / 개선점 도출 / 변화까지 정리해보았습니다.

이 내용은 레몬베이스 전사 셰어링을 통해 먼저 공유를 했었는데요. 우리만 알기 아깝다는 반응이 많았습니다 😅 그래서 외부에 계신 인재분들께도 레몬베이스 제품 조직이 어떤 문화를 갖고 어떻게 발전해나가고 있는지, 또 현재 모습까지도 최대한 생생히 느끼실 수 있기를 기대하며 공유해보고자 합니다.

레몬베이스로 이직하고 스쿼드를 빌딩한 후 처음 담당했던 영역은 플랫폼 개선이었어요. 가장 우선순위 높은 고객 문제에 대해, 이전 조직에서 진행하던 것 처럼 진행배경을 정리하고 그동안 쌓여있던 고객의 VOC와 타 글로벌 제품을 분석, 문제 해결을 위한 로드맵, 그리고 MVP 스콥에 대해 상세한 스펙을 정리해서 스쿼드에 공유했는데 생각보다 크루들의 반응이 좋지 않았습니다.

레몬베이스로 이직하고 스쿼드를 빌딩한 후 처음 담당했던 영역은 플랫폼 개선이었어요. 가장 우선순위 높은 고객 문제에 대해, 이전 조직에서 진행하던 것 처럼 진행배경을 정리하고 그동안 쌓여있던 고객의 VOC와 타 글로벌 제품을 분석, 문제 해결을 위한 로드맵, 그리고 MVP 스콥에 대해 상세한 스펙을 정리해서 스쿼드에 공유를 했는데 생각보다 크루들의 반응이 좋지 않았습니다.

[크루들이 느꼈던 문제]

스쿼드 크루들은 처음부터 너무 상세하게 스펙을 잡아온 것 같다는 피드백을 주었고, 그 외에도 다양한 보이스들이 나왔습니다.

💬 스펙 공유까지 시간이 오래 걸렸던 것 같다.

💬 왜 해야되는지 완전히 이해되지 않았다.

💬 스펙 중 일부는 필수인지 잘 모르겠다.

[원인 파악]

위와 같은 피드백을 받았을때 처음에는 당황스러웠습니다. 이전 조직에서는 오히려 팀원들에게 더 상세한 스펙을 요구 받았던터라 의아했어요. 저 자신의 일하는 방식은 그대로였으니 저를 둘러싼 환경이 어떻게 변했는지 생각해보면 그 안에 답이 있을 것이라 생각하고 상황을 돌이켜 봤는데요 🤔

[이전 조직의 상황]

• 매우 상세한 스펙까지도 PO가 작성했었는데, 대부분은 데이터 분석가 및 UX 리서처와 B2C 고객의 문제에 대해 깊숙이 들여다보고 디테일까지 모두 확정하는 경우가 많았습니다.
• PO와 다른 스쿼드 크루간 정보의 비대칭성이 컸기 때문에 PO의 의견이 스쿼드 내부적으로는 잘 챌린지되지 않는 문화였습니다.
• AB test로 PO의 의사결정에 대한 결과가 명확히 나오기 때문에 지속적으로 성과를 내는 PO는 신뢰를 받는 환경이었습니다.
• 엄청난 트래픽이 발생하는 B2C 비즈니스로 의사결정에 사용할 수 있는 수 많은 데이터가 상시적으로 확보되는 환경이었습니다.

[현재 조직의 상황]

• SaaS의 특성상 사용자의 퍼소나가 다양하고 퍼소나 간에 상황과 니즈가 매우 달랐습니다.
• 기업 고객분들이 제품을 검토하는 특정 시기가 있었기에 가치를 구현했을 때 비즈니스 지표 개선으로 이어지는 속도가 느렸습니다.
• B2C 대비 트래픽이 낮고, 고객과 다양한 조건 조율 후 계약을 통해 거래가 성사되었기 때문에 AB test의 효용이 높지 않았습니다.
• 다만 PO 외에도 디자이너와 엔지니어가 고객의 진짜 문제를 찾고 해결하는 데 진심이었고, 동기부여되어 있었습니다.

[개선점 도출]

변화된 환경을 인지하고 나서 받았던 피드백에 대해 다시 고민해보니 아래와 같은 개선점을 발견할 수 있었습니다.

• B2B SaaS에 맞는 스펙 처음 작성했던 스펙에는 정확히 어떤 특성을 갖는 회사에서 어떤 역할을 하고 있는 퍼소나가 어떤 목적의 업무를 할때 겪는 문제를 해결하려고 하는 것인지 잘 드러나지 않는 문제가 있었습니다.
• 우선순위 싱크 B2B의 경우 고객의 업무를 직관적으로 이해하기 어렵기 때문에 우리가 해결하려는 문제가 고객의 목적 달성에 어떻게 중요한지, 그리고 타겟 퍼소나의 전체 워크플로 안에서 해당 영역이 왜 중요한지를 싱크하는 것이 중요했습니다.
• 집단 지성 활용 데이터가 부족하고 리소스가 부족한 환경에서 차선책으로는 집단 지성의 활용이 효과적이라고 생각했는데요. 그 이유는 부족한 근거 안에서 PO가 독자적으로 의사결정한다면 많은 편향이 생길 수 있기 때문에, 의욕적인 크루들과 함께 다양한 관점으로 해결책을 도출해야 겠다고 생각했습니다. 이를 위해서는 최대한 투명하게 피드백 할 수 있는 환경을 지속적으로 조성할 필요가 있었습니다.

스펙 작성 / 싱크 방식 퍼소나와 해결하려는 문제가 잘 드러나는 유저 스토리 기반으로 스펙 작성 방식을 변경했고, 이후에 지속적인 피드백을 받아서 개선하는 과정을 거쳤습니다. 배경정보에 대해서는 크루들이 이해하기 쉽게 전사차원에서의 임팩트와 고객 차원에서의 임팩트를 Top-down 뷰로 시각화해서 공유했습니다.

• 투명한 소통의 원칙 ‘투명한 소통과 피드백’을 스쿼드의 중요한 원칙으로 두는 것에 대해 진솔한 얘기를 나눴습니다. 이렇게 하기 위해서는 높은 심리적 안전감이 필요한데, 이를 올리기 위해서 어떤 부분이 필요할지 다 함께 얘기를 나눴고 친밀감이 중요하다는 결론을 얻어 주기적인 점심 회식 시간을 갖기로 했습니다. 이렇게 스쿼드의 문화가 생기기 시작했습니다.
• 스펙 고도화 프로세스 PO가 핵심이라고 생각하는 유저 스토리와 필수적인 인수기준(AC) 2~3개 만으로 초기 스펙을 간소화하여 공유한 이후 디자이너, 엔지니어와 핑퐁을 해서 스펙을 완성시키는 방식으로 프로세스를 변경했습니다.

스펙/솔루션 퀄리티 상승 핵심 스펙을 빠르게 공유하면서, 자연스럽게 앞단에 디자이너 및 엔지니어와 함께 논의하는 시간이 많아졌어요. 그로 인해 미처 생각하지 못했던 부분들도 꼼꼼하게 채워지면서 스펙의 퀄리티가 전반적으로 상승했고, 출시 후에 사용성이나 성능 문제가 적은 탄탄한 솔루션이 도출되는 발판이 되었습다.

• 몰입도/속도 상승 왜 지금 시점에 이 가치를 전달 해야하는지 크루들의 이해도가 높아져 자연스럽게 업무 몰입도가 개선되었고 결과적으로 실행 속도가 빨라졌습니다.

첫번째 피드백을 받고 한 분기가 지난 이후였습니다. 당시에는 수천 명 규모의 리드 고객이 필요로했던 보안 및 연동 관련 플랫폼 기능들을 빠르게 확보해나가고 있던 상황이었는데요.

[크루들이 느꼈던 문제]

스프린트를 마치고 진행한 회고에서는 크루들은 목표했던 기간 안에 굵직한 가치를 지속적으로 전달하고 있는 점은 잘하고 있지만, 그 outcome인 성과가 잘 측정되고 있지 않다는 목소리를 냈습니다.

💬 과연 우리가 확보한 기능들이 많은 시간을 들인것 만큼 큰 가치를 전달하고 있는지 모르겠다.

💬 성과가 잘 측정이 안되고 있는 것 같다.

💬 어디서 성과를 봐야하는지 모르겠다. 페이저에 일일이 들어가서 확인하기 어렵다.

[원인 파악]

크루들과 더 깊이있게 얘기를 나누다보니 보다 근본적인 문제를 파악할 수 있었습니다. 모두 크루의 몰입도 저하로 연결될 수 있는 문제라고 생각이 들었고 개선방안을 찾아보기로 했습니다.

• 고객의 반응 확인 부족 비즈니스 임팩트를 당장 확인하기 어렵더라도 타겟했던 고객이 의도대로 사용하는지, 어떤 부분에서 개선이 필요한지 구체적으로 알고 싶어했습니다. 특히 프로덕트 디자이너는 성장하기 위해서 해당 정보를 필요로했습니다.
• 셀프리뷰 작성 시 찾기 어려움 크루들이 매번 셀프리뷰를 작성하는 과정에서 스쿼드의 성과가 각 페이저 깊숙이 들어 있어서 참고하기 어려웠고 성과 내용이 업데이트 되었는지도 알기 어려웠습니다.

• 선행지표 시각화 크루들이 납득할만한 선행지표 (언제든지 대시보드로 볼 수 있는) 를 세우고 관리한다면 그래도 우리가 잘했는지 못했는지를 판단 할 수 있고 몰입이 개선될 수 있다고 생각해서 모두가 동의 할 수 있는 성공지표를 세우고 대시보드를 확보하는데 집중했습니다.
• 성과 SSOT 확보 그동안 릴리즈했던 모든 피쳐들의 상태, 성과, 개선방안, 레슨런드를 볼 수 있는 SSOT 페이지를 만들었습니다.
• 정기적 리뷰 및 회고 진행 주기적으로 성과를 리뷰하고 회고하기 위해 월단위로 일정을 잡았습니다.

• 몰입 개선 내부적으로 계속 도돌이표처럼 나왔던 성과에 대한 질문들이 사라졌고 크루들의 몰입도가 전반적으로 개선되었습니다.
• 데이터드리븐 역량 개선 데이터팀의 리소스 사용 없이도 SaaS 제품팀에게 적합한 데이터 로깅 프로세스, 성과 측정 시각화, 데이터 기반의 의사결정 프로세스를 나름 갖추게 되었습니다.
• 고객 만족을 위한 문화 기능을 배포한 것으로 끝나는 것이 아니라 타겟했던 고객이 의도대로 잘 사용되고 있는지 확인하고 개선점은 끝까지 파악해서 개선해내는 정기적인 프로세스와 이를 축하하는 문화가 구축되었습니다.

두 번째 피드백 이후 스쿼드는 어느덧 구성원의 몰입 개선을 위한 신규 제품을 출시하고 빠르게 고도화 중인 상황이었습니다. 엔터프라이즈 고객이 당사 제품으로 전사 조직문화 서베이를 진행하기로 하면서 고객 요구사항 확인 및 조율 과정에서 핑퐁이 많았던 시기가 있었는데요.

[크루들이 느꼈던 문제]

• 조율 과정에서 PO가 많이 인볼브하다 보니 다음 기획 문서가 (페이저) 계속 늦어지는 현상이 있었고 스쿼드가 일부 멈추는 상황이 두 스프린트 동안 반복되었습니다.
• 이때 디자이너 크루가 PO의 리소스가 부족하다면 페이저 작성의 일부를 위임해달라는 피드백과 제안을 했습니다.
• 문제점과 원인은 명확했고 개선이 필요하다는 점에서도 동의했습니다.

제안을 받았을때 즉각적인 반응은 ‘우려’였습니다. 반면에 ‘기회’는 어떤 것이 있을지도 생각해봤습니다.

• 우려 페이저의 작성을 위임해도 괜찮을까? 위임했을때 정말 잘 작성 할 수 있을까? 오히려 일이 늘어나지 않을까?
• 기회 위임이 가능하다면 제품이 더욱 빨리 고도화될 수 있겠는데? 예전에 Associate PO 온보딩 과정을 위해 만들었던 페이저 온보딩 문서를 활용해서 교육을 진행해볼까? 이왕 하는김에 좀 더 청자를 확장해서 PO가 아닌 크루들도 더 체계적인 방식으로 문제해결을 할 수 있도록 기여해볼까?

제안을 기회로 만들 수 있겠다는 확신이 들었을 때 아래와 같은 개인 목표를 수립해서 레몬베이스 목표 제품 내에 등록하고 지속적으로 트랙킹 했습니다.

[개인 목표 수립]

• 더 빠르게 고품질의 제품을 만드는 스쿼드를 빌딩한다.

[타깃 지표 (기대 결과물)]

• 위임한 페이저로 성공적인 제품 개발을 완료한다.
• 페이저 미비로 인한 병목현상을 0으로 만든다.

[이니셔티브]

• 페이저 교육 및 크리틱 세션 진행을 통해 페이저 작성 방법의 확산
• 위임한 페이저를 통해 킥오프 및 피처 릴리즈

• 전체에 대한 기여 계획했던 페이저 교육 세션에는 비즈니스, 엔지니어링, 디자이너팀에서 총 6명이 참여했고 교육 이후에 크루들은 각 팀에서 문제해결에 대한 체계적인 접근 방법에 대해 전파하는 역할을 하게 되었습니다.
• 제안했던 크루의 성장 스쿼드 내 디자이너 크루가 작성한 페이저를 가지고 성공적으로 제품 개발을 진행했습니다. 제품 구조에 영향을 많이 미치는 부분이었는데, 페이저로 배경에 대해 잘 정리한 후에 미리 많은 고민을 하고 또 크루들과도 깊이 있는 논의를 진행하는 역할도 진행해주었어요. 회고 과정에서 이를 통해 시야가 확장될 수 있었고 PO가 고민하는 부분들도 더 잘 이해하게 되었다는 들었다고 얘기해주었습니다.
• 실행 속도의 급성장 해당 분기에는 총 9개의 가치를 고객에게 전달하면서 역대급의 속도와 퀄리티로 제품이 고도화되었습니다. 스스로도 페이저 작성 지연으로 딜레이 되었던 시간은 0에 가까웠다고 회고할 정도였고 분기 말 회고에서도 많은 셀러브레이션이 있었습니다.

• 우리가 만들고 있는 제품으로 몰입도를 관리하면서 적시에 개선점을 확인 및 개선하고 있습니다.
• 협업 과정에서 높은 심리적 안전감을 갖고 투명하게 자신의 상태를 공유하고 피드백을 받고 있습니다.
• 구성원 개개인이 발견한 문제는 직접 오너십을 갖고 해결하는 문화로 발전해나가고 있습니다.
• 정기적으로 성과를 회고 하고 실패에서 배우면서 더 나은 의사결정을 하는 조직으로 성장하고 있습니다.

• 다양한 조직의 고객을 PO, PD, 엔지니어가 상시적으로 만나 진짜 문제를 찾고 감탄할만한 솔루션으로 해결합니다.
• 진짜 문제를 해결하는 과정에서 스쿼드가 하나의 시드 단계의 스타트업처럼 개개인이 더 많은 권한과 역할을 갖고 일합니다.

만약 피드백을 수용하지 않고 변화하지 않았더라면, 아마도 지금 조직의 모습은 매우 달랐을 것 같습니다. 투명한 소통과 주도성이 사라지고 몰입도가 떨어져 속도가 느려지고 제품의 퀄리티도 떨어졌을 것이라고 생각합니다.

고객의 문제를 귀기울여 듣고 잘 해결해나가는 제품이 시장에서 성공하듯이, 구성원의 목소리를 수용하고 변화하는 리더와 조직은 빠르게 성장하고 성공할 가능성이 높다고 생각합니다. 여기서 구성원의 목소리는 공동의 목표를 달성하기 위한 협업 과정에서의 목소리를 뜻합니다.

구글의 아리스토텔레스 프로젝트에 따르면 일 잘하는 팀의 비결 1순위는 높은 심리적 안전감이었습니다. 심리적 안전감이란, 어떤 의견을 말하더라도 리더와 동료들이 ‘이상한’ 혹은 ‘잘못된’ 의견이라고 생각하지 않을 것이라는 믿음을 가리키는데요. 이러한 환경은 리더가 구성원의 목소리를 적극적으로 수용할 때 형성됩니다.

기발한 아이디어로 피드백을 반영하고 개선할 필요는 없다고 생각합니다. 워크포스인스티튜트가 11개국 4,000명의 구성원 대상으로 설문한 결과에서 ‘나의 의견을 조직이 듣는다고 느낄 때 업무 효율성이 올라간다’고 답변한 비중은 74% 였다고 합니다. 이와 같이 ‘조직이 내 말을 듣는다'는 구성원의 인식과 신뢰만 형성이 되어도 구성원의 몰입도는 상승할 가능성이 높습니다.

낯설고 불편한 피드백을 받았을 때 회피했다면 오히려 빠르게 성장할 수 있는 기회를 놓쳤을 것입니다. 애덤 그랜트 저자의 싱크 어게인 책에서 높은 성과 집단은 업무 갈등이 많고 관계 갈등이 낮은 반면, 낮은 성과 집단은 그 반대가 목격된다고 하는데요. 특히 지도자들이 업무 갈등으로부터 자신을 보호하는 행동의 종착지는 ‘실패'라고 강조합니다. 업무 갈등과 관계 갈등을 잘 구분하고 생산적인 갈등을 잘 활용하는 마인드셋을 갖추는 것이 중요합니다.

개인 차원에서, 더 나아가 팀 차원에서 큰 성장을 할 수 있도록 견인한 스쿼드 크루들의 3가지 솔직한 피드백을 중심으로, 사례와 그 과정에서 배운점을 정리해봤습니다 🙂

레몬베이스의 스쿼드 조직처럼 각기 다른 전문성을 가진 사람들이 팀을 이뤄 하나의 목표를 달성하는 방식으로 일 하는 다른 많은 조직들이 있을텐데요. 저희 팀의 경험과 그 과정에서의 레슨런드를 통해, 지금 계신 조직에서도 적용해볼만한 것들을 찾으실 수 있다면 좋겠습니다!

레몬베이스 팀은 조직과 사람의 성장에 관심이 많고, 고정관념에 갇히지 않고 빠르게 성장하며 임팩트를 내고 싶은 분들을 찾고 있습니다. 레몬베이스 팀에 관심이 있으시다면 채용페이지를 둘러보세요 😊