toss2026년 5월 22일

Cross Functional 기술 문제 풀기 위한 역량 성장 Tip (새 탭에서 열림)

조직이 커질수록 각 팀이 맡은 일은 잘 수행해도 팀과 팀 사이의 공백이 커지며, Cross Functional 기술 문제가 발생합니다. 이런 문제는 회의·보고·리스크 관리 같은 조율만으로 해결되지 않으며, 문제를 재정의하고 구조화해 실제 실행으로 전환해야 합니다. 토스의 TPM은 공식 권한보다 문제 정의력, 구조화 능력, 영향력과 실행력을 바탕으로 복합적인 문제를 끝까지 해결하는 역할을 합니다. ## 조직 성장과 함께 커지는 경계의 문제 - 팀별 책임과 전문성이 높아질수록 팀의 경계 밖 문제가 늘어납니다. - 인프라, 제품, 데이터, 보안, 운영 이슈가 서로 얽혀 한 조직만으로 해결하기 어렵습니다. - 단기 대응과 장기 구조 개선이 충돌합니다. - 중요하지만 공식 Owner가 없는 회색지대가 생깁니다. - 각 팀이 최선을 다해도 전체 최적화가 이뤄지지 않을 수 있습니다. ## 조율만으로 해결되지 않는 이유 - 회의를 더 자주 열고 진행 상황을 공유해도 문제의 본질은 남을 수 있습니다. - 리스크 목록이나 일정표에는 결정 구조의 공백, 모호한 책임, 충돌하는 우선순위가 잘 드러나지 않습니다. - 핵심은 관리의 밀도를 높이는 것이 아니라, 문제를 해결 가능한 구조로 바꾸는 것입니다. - 먼저 “진짜 병목은 무엇인가”, “누가 빠져 있는가”, “어떤 결정이 비어 있는가”를 물어야 합니다. ## TPM에게 필요한 핵심 역량 ### 문제를 다시 정의하는 힘 - 일정 지연이나 협업 속도 저하 같은 표면적 현상에 머물지 않습니다. - 지연의 원인, 비어 있는 의사결정, 불명확한 Owner, 반복되는 조직 구조의 문제를 찾아냅니다. - 증상을 관리하는 대신 해결해야 할 문제 자체를 다시 설정합니다. ### 모호함을 구조로 바꾸는 힘 - 무엇을 결정해야 하는지 명확히 합니다. - 가능한 선택지와 책임자를 정리합니다. - 문제를 실행 가능한 단위로 쪼개고 우선순위와 순서를 만듭니다. - 복잡한 문제를 여러 사람이 함께 다룰 수 있는 단순한 구조로 바꿉니다. ### 전략적 판단력 - 일시적인 이슈인지 반복될 구조적 문제인지 구분합니다. - 팀 내부 해결이 가능한지, 조직 차원의 개입이 필요한지 판단합니다. - 지금 개입해야 하는 문제와 관찰해도 되는 문제를 나눕니다. - 해결했을 때 조직의 실행 수준 자체를 높일 수 있는 문제에 집중합니다. ### 실행으로 전환하는 힘 - 실제로 움직여야 할 사람을 명확히 합니다. - 선행 결정과 Blocker를 정리합니다. - 모호한 논의를 결정 포인트로 바꾸고 담당자가 결론을 내리게 합니다. - 합의된 액션 플랜을 실제 행동으로 연결합니다. ### 공식 권한 없이 영향력을 만드는 힘 - 직함이나 지시가 아니라 신뢰와 판단력으로 참여를 이끌어냅니다. - 각 팀의 맥락과 제약을 이해하고 서로 다른 언어를 번역합니다. - 필요한 경우 불편한 대화를 열어 우선순위와 책임 문제를 드러냅니다. ### 사람과 구조를 함께 보는 시각 - 기술 문제가 역할 정의, 팀 구조, 운영 방식에서 비롯될 수 있음을 고려합니다. - 프로세스 개선만으로 충분한지, 역할 재설계나 리더십 개입이 필요한지 판단합니다. - 사람과 시스템을 분리하지 않고 함께 바라봅니다. ## 자율성이 낮은 조직에서의 단계적 접근 - **작은 문제부터 해결하기:** 분명한 병목 하나를 구조적으로 해결해 신뢰를 쌓습니다. - **조율에 구조화를 더하기:** 회의를 진행하면서 결정 사항, 의존성, 병목을 함께 드러냅니다. - **작은 범위에서 Owner 명확히 하기:** 담당자, 의사결정권자, 완료 기준을 구체화합니다. - **사례로 역할 증명하기:** 역할을 설명하기보다 Owner 없는 문제를 해결하고 반복 병목을 줄인 실적을 만듭니다. ## 주의할 점 - 조율은 중요하지만 목적이 아니라 문제 해결을 위한 수단이어야 합니다. - 공식 권한이 없어도 신뢰와 구조화 능력으로 영향력을 만들 수 있습니다. - 조직에 이상적인 역할 모델을 한 번에 강요하기보다 현재 환경에서 작동하는 작은 성공 사례부터 만들어야 합니다. 결국 Cross Functional 기술 문제를 풀기 위해서는 일정과 회의부터 관리하기보다 문제를 다시 정의해야 합니다. 진짜 병목, 누락된 사람과 책임, 실행을 가로막는 구조를 찾아 작은 범위에서부터 바꾸는 것이 실용적인 출발점입니다.

cross-functional-collaborationproblem-solvingorganizational-designtechnical-program-management+2

toss2026년 5월 14일

AI 시대, 성과 내는 조직일수록 토스식 TPM이 필요한 이유 (새 탭에서 열림)

토스가 정의하는 TPM(Technical Program Manager)은 일정과 리스크를 관리하는 전통적 조율자를 넘어, 여러 팀 사이에 방치된 구조적 문제를 발견하고 해결하는 **전략 실행자**다. 특히 AI 도입으로 기술·조직·운영의 의존성이 복잡해질수록, 공식 Owner가 없는 회색지대를 구조화하고 실행 가능한 상태로 만드는 역할이 중요해진다. TPM의 성과는 문서나 상태 보고가 아니라 병목 제거와 현실의 변화로 증명된다. ## 기존 TPM 정의의 한계 - 일반적인 TPM은 이미 정의된 기술 프로그램의 일정, 리스크, 의존성, 커뮤니케이션을 관리해 안정적인 전달을 돕는다. - 그러나 조직이 커질수록 어려운 문제는 정식 프로그램이나 명확한 과제의 형태로 등장하지 않는다. - 대표적인 문제는 다음과 같다. - 여러 팀이 관련되어 있지만 최종 책임자가 없는 문제 - 전략은 존재하지만 실행 구조가 없는 문제 - 상태 공유는 계속되지만 실제 상황은 바뀌지 않는 문제 - 제품·기술 전략·조직 설계·운영 방식이 복합적으로 얽힌 문제 - 이런 상황에서는 일정 관리나 이해관계자 조율만으로 문제를 해결하기 어렵다. ## PO·EM·전통적 TPM과의 차이 - **PO(Product Owner)**는 사용자와 비즈니스 관점에서 무엇을 만들고 어떤 우선순위를 둘지 정의한다. - **EM/SDM**은 사람, 기술 품질, 팀 운영과 조직 건강을 관리해 특정 팀이 꾸준히 실행할 기반을 만든다. - **전통적 TPM 또는 Technical Project Manager**는 정해진 목표를 일정 안에 전달하도록 계획과 리스크를 관리한다. - **토스식 TPM**은 이 역할들을 대체하지 않고, 역할 사이와 조직 경계 밖에 남은 문제를 담당한다. - 제품 방향은 있지만 여러 조직을 움직일 실행 구조가 없을 때 - 각 팀은 제 역할을 하지만 전체 관점의 Owner가 없을 때 - 리더십이 중요성을 인식해도 기존 구조에서는 우선순위를 만들기 어려울 때 - 따라서 이미 정의된 업무를 관리하기보다, 정의되지 않은 중요한 문제를 해결 가능한 형태로 바꾸는 데 초점을 둔다. ## 성숙한 조직에서 커지는 회색지대 - 조직이 성숙하면 각 팀의 책임과 목표가 선명해지고 실행 속도도 빨라진다. - 반면 명확한 조직 경계 때문에 어느 팀에도 완전히 속하지 않는 문제가 방치될 수 있다. - 이러한 문제는 여러 조직에 조금씩 걸쳐 있거나, 당장은 긴급하지 않지만 미래를 위해 해결해야 하거나, 개별 팀의 로컬 최적화로는 풀리지 않는 경우가 많다. - AI 시대에는 모델 도입, 데이터 거버넌스, 품질 기준, 보안, 개발 생산성, 업무 방식이 동시에 얽히면서 이런 현상이 심화된다. - 높은 자율성과 실행력을 가진 조직일수록 팀 간 경계를 전담해 다룰 역할이 필요하다. ## 토스식 TPM이 다루는 문제 - 중요한데 공식 Owner가 없다. - 여러 팀과 직무가 동시에 연관되어 있다. - 전략·기술·운영·사람 문제가 섞여 있다. - 진행 상황은 자주 공유되지만 실질적인 전환은 일어나지 않는다. - 기존 역할 하나의 권한과 책임만으로는 끝까지 해결하기 어렵다. - TPM은 표면적인 현상만 추적하지 않고 다음을 수행한다. - 진짜 문제와 단순 증상을 구분한다. - 빠진 이해관계자와 필요한 의사결정을 드러낸다. - 권한과 책임 구조를 설계한다. - 결과가 만들어질 때까지 실행에 개입한다. ## 문제 발견부터 현실 변화까지의 역할 - **문제를 선제적으로 발견한다** - 누군가 정리한 업무를 기다리지 않고 반복되는 병목, 책임의 공백, 이름 붙지 않은 중요 문제를 찾는다. - **전략을 실행 구조로 전환한다** - 어떤 팀이 어떤 순서로 움직일지, 무엇을 포기할지, 누가 DRI(최종 책임자)가 될지 구체화한다. - **팀 사이에서 실행을 설계한다** - 서로 다른 조직의 목적·속도·제약을 연결하고 공동 문제를 풀 수 있는 협업 구조를 만든다. - **블로커를 보고하는 데서 그치지 않는다** - 필요하면 의사결정 구조, 우선순위, 참여자 구성과 협업 방식을 바꿔 실제 장애물을 제거한다. - **사람과 조직 구조를 함께 본다** - 필요한 리더십, 팀 구성, 권한 배치와 반복 가능한 운영 메커니즘을 함께 설계한다. - **현실의 변화로 성과를 판단한다** - 막힌 실행이 다시 움직이고 반복 병목이 줄어들며, 다음에는 같은 문제를 더 쉽게 해결할 수 있어야 한다. - 문서와 회의, 조율은 수단이며 TPM의 정체성은 문제 해결에 있다. ## 강한 TPM에게 필요한 역량 - **문제 구조화** - 모호한 현상에서 본질과 증상을 구분하고, 관계자와 의사결정 병목을 빠르게 파악한다. - 회의 후 내용을 정리하는 수준을 넘어 회의 전부터 문제의 프레임을 제시한다. - **전략의 실행 전환** - 필요한 작업 흐름, 개입 순서, 시점별 책임자를 설계해 방향성을 실제 행동으로 연결한다. - **영향력과 동원 능력** - 공식 권한에 의존하지 않고 신뢰와 판단력으로 여러 팀을 움직인다. - 조직마다 다른 언어를 번역하고, 불편한 대화를 열며, 합의가 느린 상황에서도 실행 기반을 만든다. - **시스템 사고** - 문제가 반복되면 개인의 노력보다 조직 구조와 운영 메커니즘을 점검한다. - 영웅적인 개인의 희생 없이도 기본적으로 잘 작동하는 시스템을 만든다. - **완결성** - 문제 발견, 구조 설계, 관계자 동원, 실행, 결과 도출, 재발 방지까지 끝까지 책임진다. - 업무량보다 어렵고 넓은 회색지대의 문제를 완결할 수 있는지가 중요하다. ## AI 시대의 TPM - AI 도입이 확대될수록 기술 변화는 빨라지고 팀 간 의존성과 책임 경계는 복잡해진다. - 조직에 필요한 것은 회의와 상태 보고를 늘리는 사람이 아니라, 비어 있는 구조를 찾아 실행이 다시 움직이도록 만드는 사람이다. - 모두가 중요하다고 하지만 아무도 끝까지 책임지지 않는 문제가 반복된다면 새로운 형태의 TPM이 필요하다는 신호다. - 정식 직책이 없더라도 이런 문제를 발견하고 구조화해 해결까지 이끄는 비공식 TPM 역할부터 시도해볼 수 있다.

cross-functional-collaborationaidata-governanceorganizational-design+3

figma2025년 7월 14일

개발 리더들이 디자인 (새 탭에서 열림)

최근 개발 리더들 사이에서 디자인은 단순한 시각적 요소를 넘어 제품의 성공과 비즈니스 성과를 결정짓는 핵심 전략으로 자리 잡고 있습니다. IDC의 연구에 따르면 디자인을 매우 중요하게 여기는 리더는 프로젝트 목표를 초과 달성할 확률이 5배나 높으며, 디자인과 개발의 긴밀한 협업이 시장 출시 속도를 높이는 결정적인 요인으로 작용하고 있습니다. 특히 AI 기술이 발전함에 따라 AI가 생성한 결과물을 사용자 중심의 완성도 높은 제품으로 다듬기 위한 디자인 전문성의 가치는 더욱 커지고 있습니다. ## 디자인의 비즈니스 가치와 전략적 중요성 현대 소프트웨어 개발 환경에서 디자인은 고객 유치와 유지를 위한 핵심적인 차별화 요소로 인식되고 있습니다. * 조사 대상 개발 리더의 75%가 디자인을 소프트웨어 개발에서 "매우 중요"하거나 "극도로 중요"한 요소로 꼽았습니다. * 디자인에 집중했을 때 얻을 수 있는 주요 비즈니스 이점으로는 고객 유지율 향상, 고객 참여도 증가, 제품 혁신 가속화가 언급되었습니다. * 디자인을 우선순위에 둔 조직은 그렇지 않은 조직보다 프로젝트 기대치를 훨씬 상회하는 성과를 낼 확률이 500% 더 높게 나타났습니다. ## 개발자와 디자이너의 협업을 통한 제품 품질 향상 기존의 분리된 작업 방식에서 벗어나 프로젝트 초기 단계부터 디자인과 개발이 협력하는 구조가 제품의 출시 속도와 품질을 동시에 개선하고 있습니다. * 개발 리더의 54%는 디자인 협업 강화가 혁신 증가로 이어졌다고 답했으며, 43%는 시장 출시 기간(Time to Market)이 단축되었다고 보고했습니다. * 초기 단계부터 범위를 조율하고 실시간으로 피드백을 주고받는 과정은 재작업을 줄이고 팀의 사기를 높이는 효과를 가져옵니다. * 성공적인 협업은 단순한 업무 전달이 아닌 '동기화된 조화'나 '기초부터 탄탄히 쌓아 올리는 구조물'과 같이 긴밀한 파트너십의 형태로 진화하고 있습니다. ## AI 제품의 완성도를 결정짓는 디자인 전문성 AI가 개발 생산성을 높여주는 도구로 부상하면서, 역설적으로 AI의 결과물을 정교하게 다듬는 디자인 기술의 중요성이 더욱 강조되고 있습니다. * 개발 리더의 80%는 2년 전보다 AI 기반 제품의 성공에 디자인이 더 중요한 역할을 하게 되었다고 평가했습니다. * AI가 생성한 초안은 사용성, 브랜드 일관성, 품질 관리 측면에서 인간 디자이너의 세밀한 검토와 조정이 필수적입니다. * AI를 최종 결과물이 아닌 '시작점'으로 활용할 때 최고의 성과가 나오며, 디자인 전문 지식은 AI의 잠재력을 사용자 가치로 변환하는 핵심 매개체가 됩니다. ## 성공적인 제품 개발을 위한 제언 경쟁이 치열한 시장에서 앞서나가기 위해 개발 조직은 디자인을 전략적 우선순위로 삼고 다음과 같은 실천 방향을 고려해야 합니다. * **디자인의 전략적 자산화:** 디자인을 단순한 미적 단계가 아닌 고객 만족과 비즈니스 지표를 견인하는 전략적 투자처로 인식해야 합니다. * **교차 기능적 협업 문화 구축:** 디자이너와 개발자가 사일로(Silo)를 허물고 초기 기획 단계부터 함께 의사결정을 내릴 수 있는 환경을 조성해야 합니다. * **AI 프로세스 내 인간의 개입:** AI 도구를 도입하되, 최종적인 사용자 경험과 품질 보증을 위해 디자인 전문가의 통찰력을 적극적으로 활용해야 합니다.

cross-functional-collaborationaiuxproduct-development+3

figma2023년 10월 24일

Figma의 데이터 사이언스 및 (새 탭에서 열림)

Figma의 데이터 과학팀과 사용자 조사팀은 알림 문제를 정량 데이터와 정성적 사용자 의견으로 함께 분석했다. 그 결과 알림 클릭률보다 앞선 단계인 “알림을 아예 받지 못하는 문제”가 가장 큰 개선 기회임을 발견했다. Figma는 이를 해결하기 위해 새로운 알림 유형을 추가하고, 누가 언제 알림을 받아야 하는지 재검토하는 실험을 시작했다. ## 정량 데이터와 정성 조사의 결합 - 데이터 과학은 대규모 사용자 행동을 통해 **무슨 일이 일어나는지(What)** 보여준다. - 사용자 조사는 사용자가 왜 그렇게 행동하는지 **이유(Why)** 를 파악하는 데 도움을 준다. - 수치만으로는 사용자의 동기와 맥락을 알기 어렵고, 인터뷰만으로는 전체 사용자에게 나타나는 패턴을 확인하기 어렵다. - 두 방법을 함께 사용하면 각 분석의 한계를 보완해 더 완전한 제품 이해가 가능하다. - 두 팀은 이를 날실과 씨실을 엮어 천을 만드는 과정에 비유했다. ## Figma 알림 퍼널과 문제 정의 - Figma 알림은 이메일, Slack, 모바일, 파일 브라우저·시스템 트레이·데스크톱 알림 등 여러 경로로 전달된다. - 알림 유형에는 댓글, 댓글 답글, 댓글 반응, 파일·팀·프로젝트 초대, 편집 초대, 멘션 등이 있다. - 사용자가 알림과 상호작용하려면 다음 단계를 통과해야 한다. - 알림 대상이 될 수 있음 - 알림을 받음 - 알림을 확인함 - 알림과 상호작용함 - 활동 팀은 어느 단계에서 사용자가 가장 많이 이탈하는지, 어떤 단계에 투자해야 하는지 알지 못했다. - 분석 결과 가장 큰 문제는 많은 사용자가 알림을 열지 않는 것이 아니라 **알림 자체를 받지 못하고 있다는 점**이었다. ## 협업형 분석 프로세스 구축 - Caitlin Hudon과 Jennifer Sanders는 FigJam에서 팀 전체 브레인스토밍을 진행했다. - 팀은 알림을 받은 사용자, 열어본 사용자, 클릭한 사용자의 비율과 현재 상태를 공유했다. - 이후 다음과 같은 질문을 함께 정리했다. - 분기별로 어떤 지표를 개선할 것인가? - 새로운 알림 유형이 필요한가? - 현재 데이터만으로 알 수 없는 것은 무엇인가? - 질문을 데이터 과학으로 답할지, 사용자 조사로 답할지 각자의 전문 영역에 따라 나누었다. - 두 연구자는 각자 프로젝트를 진행하면서도 지속적으로 소통하고, 공통된 질문과 발견을 맞춰 갔다. - 이런 지속적인 동기화와 결과 종합에 충분히 투자하는 것이 단순히 두 연구 결과를 나열하는 것보다 중요했다. ## 행동 데이터가 보여준 것과 사용자 조사가 밝혀야 한 것 - 데이터 분석은 알림 퍼널의 각 단계에서 사용자가 얼마나 줄어드는지 파악하는 데 적합했다. - 특히 알림 수신 여부와 실제 상호작용 사이의 차이를 수치로 확인할 수 있었다. - 사용자 조사는 사용자가 알림을 받지 못하거나 활용하지 않는 상황의 맥락과 기대를 이해하는 데 사용됐다. - 사용자는 자신의 행동 이유를 항상 정확히 설명하지 못할 수 있으므로, 인터뷰 결과를 행동 데이터와 함께 검증해야 했다. - 정량 결과와 정성적 설명을 결합해 팀은 단순한 클릭률 개선이 아닌 알림 전달 구조 자체를 개선해야 한다고 판단했다. ## 발견을 제품 개선으로 연결 - 활동 팀은 알림을 통해 팀원 간 연결과 협업을 강화하는 것을 목표로 했다. - 가장 큰 개선 영역은 기존 알림의 클릭을 유도하는 것보다 다음 문제를 해결하는 데 있었다. - 적절한 사용자가 알림을 받지 못하는 문제 - 필요한 상황을 포괄하지 못하는 알림 유형 - 알림을 받을 시점과 대상이 적절하지 않은 문제 - 이후 팀은 여러 알림 실험을 시작했다. - 사용자의 주요 불편을 해결하기 위한 새로운 알림 유형도 출시됐다. ## 실용적인 결론 제품 문제를 분석할 때 퍼널의 마지막 행동만 보지 말고, 사용자가 그 단계에 도달하기 전 어디에서 이탈하는지 확인해야 한다. 대규모 행동 데이터로 문제의 범위를 파악한 뒤, 사용자 조사로 원인과 맥락을 보완하고, 두 결과를 공동으로 종합하는 방식이 효과적이다.

cross-functional-collaborationfigjamslackuser-research+2

figma2021년 7월 21일

Figma PM 팀이 (새 탭에서 열림)

Figma의 PM 팀은 신뢰·투명성·성찰·포용을 바탕으로 제품 개발 과정을 여러 직군과 공유한다. 아이디어를 우선순위로 구체화하고, 정기 회의에서는 단순한 진행 상황을 넘어 개인적인 고민과 어려운 문제까지 나누며 협업의 질을 높인다. 핵심은 PM의 업무를 폐쇄적인 의사결정이 아니라 다양한 구성원이 참여하는 공동 창작 과정으로 만드는 것이다. ## 투명성과 신뢰를 중심으로 한 PM 문화 - PM은 제품 개발의 중심에서 디자인, 엔지니어링, 마케팅 등 여러 팀과 지속적으로 협업한다. - 회사마다 PM의 역할과 프로세스는 다르지만, 여러 직군과 효과적으로 소통하는 능력은 공통적으로 중요하다. - Figma는 다음 네 가지 가치를 PM 업무의 기반으로 삼는다. - 신뢰 - 성찰 - 포용 - 투명성 - FigJam을 활용해 아이디어 발상부터 회고까지 업무 과정을 공개하고 협업자들의 참여를 유도한다. ## 아이디어를 넓게 모으는 크로스펑셔널 브레인스토밍 - 좋은 아이디어는 한 팀에서만 나오는 것이 아니라 여러 팀과 구성원의 의견을 거치며 발전한다. - 브레인스토밍은 아이디어를 많이 내는 것만으로 끝나서는 안 된다. - 명확한 의사결정 - 실행 항목 - 담당자와 후속 조치 가 뒤따라야 실제 제품 방향으로 연결된다. - Figma PM 팀은 다양한 참여자의 의견을 정렬하고 우선순위를 정하기 위해 여러 협업 기법을 사용한다. ## `Buy a Feature`로 투자 우선순위 정하기 - 구성원에게 일정량의 가상 화폐를 나누어 주고, 제품 아이디어나 집중 영역에 투자하게 하는 우선순위 결정 방식이다. - PM은 각 아이디어에 투자할 수 있는 시간과 자원의 규모를 정한다. - 단순한 순위 투표와 달리, 사람들이 어떤 영역에 **얼마나 투자할 의향이 있는지**를 파악할 수 있다. - 사용자와 사내 여러 팀에서 들어오는 수많은 요청 중 무엇을 실행하고 무엇을 보류할지 논의하는 데 유용하다. - 아이디어의 선호도뿐 아니라 시간과 자원에 대한 인식까지 함께 드러난다. ## 얼라인먼트 스케일로 의견과 확신의 정도 확인하기 - 팀이 제품 방향이나 작업을 이끌어 갈 주장과 신념을 먼저 정한다. - 각 구성원은 FigJam의 프로필 스탬프를 척도 위에 배치해 자신의 동의 정도나 확신을 표시한다. - 구성원은 댓글로 배경과 우려를 설명하고, 의견 차이를 토론한다. - 이를 통해 찬반 여부만 확인하는 것이 아니라 다음을 파악할 수 있다. - 어떤 결정에 팀의 확신이 높은지 - 의견이 갈리는 지점은 무엇인지 - 추가 조사나 논의가 필요한 부분은 어디인지 ## 상태 보고를 넘어서는 주간 스탠드업 - PM 팀의 주간 스탠드업은 업무 진행 상황만 공유하는 자리가 아니다. - 임원진 업데이트와 PM들의 업무 공유 외에도 개인적인 상황과 심리적 상태를 나눈다. - 각 PM은 FigJam에서 다음 질문에 답한다. 1. 개인적으로 최근 어떤 생각을 하고 있는가? 2. 업무 또는 개인적으로 걱정되거나 기대되는 것은 무엇인가? 3. 고민 중인 어렵거나 흥미로운 문제는 무엇인가? - 이러한 방식은 단순한 태스크 추적을 넘어 팀원 간 공감과 신뢰를 만든다. - 동시에 다른 PM이 해결책을 제안하거나 도움을 줄 수 있는 문제를 조기에 발견하게 한다. ## 실무에 적용할 때의 시사점 - 브레인스토밍 후에는 반드시 결정 사항과 실행 항목을 문서화한다. - 우선순위 논의에서는 단순 투표 대신 제한된 예산이나 시간을 배분하게 하면 실제 투자 의향을 확인할 수 있다. - 의견 차이를 숨기지 말고 척도나 댓글로 시각화해 추가 논의가 필요한 부분을 찾는다. - 정기 회의에 업무 외 고민과 해결이 필요한 문제를 공유하는 시간을 포함하면 협업과 팀 신뢰를 함께 강화할 수 있다.

cross-functional-collaborationfigmafigjamuser-research+3