[요약]
조직 / 협업 방식
일하는 방식은 고정되지 않음 (분기마다 변화)
팀 구조
→ 블루(BM) / 레드(프로덕트) / 그린(B2B)
- 역할 기반 분리 intentionally 회피
- 사일로 방지 (“내 일만 한다” 방지)
팀 이름을 컬러로 설정
- 역할 고착 제거
- 문제 중심 협업 유지
구조 = 목적 조직 + 기능 조직 하이브리드
핵심 원칙
One Team
문제에 따라 유연하게 팀 재편
조직 변화는 불안 요소가 아니라 성장 단계에 맞는 필수 과정
일하는 방식 (Process)
문제 해결 흐름
문제 정의 → 가설 설정 → 데이터/리서치 → 설계 → 검증 → 반복
하나의 강한 가설에 집중
→ 여러 시도보다 “한 방향 깊게”
빠른 실행 → 디자인 → 다음날 배포 가능 수준
협업 방식
- PM / 디자이너 / 개발자 / 데이터 분석가 공동 문제 해결
- 직무 중심이 아니라 문제 중심 협업
문제 정의 방식
출발점 = 항상 질문
“이게 진짜 문제인가?”
문제는 감이 아니라 데이터 + 사용자 행동 패턴 기반
관찰 대상
- 이탈 지점
- 반복 행동
- 사용 흐름
단순 UI 문제로 보는 것이 아니라 구조 / 흐름 단위로 재해석
제품 관점 (UX / 설계)
기능 단위가 아니라 사용자 여정 단위로 설계
중요 구간
탐색 → 행동 전환
목표
“자연스럽게 행동하게 만드는 경험”
디테일이 중요하다
버튼 / 문구 / 위치 / 흐름
성과 접근 방식
작은 변화 → 큰 지표 변화 가능을 기억하기
KPI는 기능 추가보다 기존 흐름 최적화로 개선
성과 기준
실제 사용자 행동 변화
속도와 환경
- 제품 성장 속도 매우 빠름
- 의사결정 / 실행 / 배포 모두 빠름
- 조직도 속도에 맞춰 계속 변경
팀원 인식 또한 변화 = 당연한 과정
지원자 평가 기준
결과물보다 중요하게 보는 것
- 왜 이 문제를 선택했는가
- 어떤 가설을 세웠는가
- 어떻게 검증했는가
핵심 역량
- 문제 정의 능력
- 사고 과정
[인사이트]
서비스 기획 입문을 수강하면서 실무 엿보기를 통해 잠깐 언급됐던 아티클이었는데, 유의미한 정보가 많을 것 같아 스크랩해두고 오늘의 아티클로 선정했다. 아니나 다를까 당근 내부정보라고 불러도 될 정도로 당근의 조직문화, 인사이트가 가득한 글이었음
당근은 여러 아이디어를 동시에 시도하기보다 하나의 강한 가설에 집중하고 이를 데이터로 검증하며 빠르게 반복하는 방식으로 일한다. 많이 시도하는 것이 아니라 명확하게 가설을 세우고 실행해나가는 통찰력과 추진력이 중요.
기능이 많은 것보다 서비스의 변화가 실제 사용자의 행동을 바꾸었는지를 목표로 두고 달려나가는 조직임 !!!
팀이 유연하게 재편된다는 것도, 구성원들이 편하게 받아들이는 것도 아주 좋은 문화라는 생각이 든다. 하나의 문제를 각자 따로 풀어서 합치는 게 아니라, 함께 모여서 푼다는 진정한 협업식 운영. 안에서 많이 성장할 수 있을 것 같다.
