product-management

20 개의 포스트

figma3분 읽기큐레이션 요약

팀을 최대한 활용하는 방법 |

팀의 잠재력을 끌어내려면 관리자가 목표, 회의, 역할, 성장 기회를 설계해 구성원이 주도적으로 일할 수 있는 환경을 만들어야 한다. 핵심은 목표를 소수의 우선순위로 좁히고, 회의를 꼭 필요한 경우에만 운영하며, 직책보다 좋은 아이디어와 실험을 중시하는 것이다. 팀의 성공은 구성원이 몰입하고 성장할 수 있는 업무 환경을 만드는 관리자의 성공과도 연결된다. ## 목표는 세 가지 우선순위로 좁힌다 - 구성원에게 분기나 반기 초에 자신이 이루고 싶은 목표를 먼저 작성하게 한다. - 처음에는 10~15개의 목표가 나올 수 있지만, 최종적으로는 **세 가지 핵심 우선순위**만 남긴다. - 목표를 줄이는 과정에서 실제 기간 안에 달성할 수 있고, 높은 완성도로 수행할 수 있는 일에 집중하게 한다. - 목표는 회사의 가장 중요한 전략적 과제와 연결해야 한다. - “무엇을 할 것인가”뿐 아니라 목표가 만들어낼 **영향을 구체적·정량적으로 표현**하도록 돕는다. - 확정된 목표를 다른 리더들과 공유해 조직 전체의 정렬과 책임감을 높인다. ## 회의는 반드시 필요한 순간에만 연다 - Work & Co.는 하루에 한 번 아침 체크인만 진행한다. - 전날 완료한 일 - 당일의 다음 단계 - 필요한 협업 사항 - 나머지 시간은 방해 없이 개인 작업이나 공유 파일 기반 협업에 사용한다. - 회의가 많아질수록 집중해서 결과물을 만들 시간이 줄어들기 때문에, Slack이나 FigJam으로 해결할 수 있는 사안은 회의로 만들지 않는다. - 회의를 줄이기 어렵다면 회의 목적과 진행 방식을 더 명확하게 설계해야 한다. ## 발언이 적은 사람도 참여할 수 있는 회의 구조를 만든다 - Twitch는 Amazon식 6쪽 문서 회의 형식을 하이브리드 업무에 맞게 적용했다. - 참석자는 회의 전에 공유 문서를 읽고, 10~15분 동안 질문과 의견을 문서에 주석으로 남긴다. - 이후 회의에서는 문서에 달린 의견을 중심으로 논의한다. - 즉흥적으로 말하는 데 익숙한 사람만 유리한 ‘자유 발언식 회의’의 문제를 줄인다. - 문서, FigJam 스탠드업 등 구성원이 편한 방식으로 생각을 표현하게 하면 참여의 형평성과 회의의 효율이 높아진다. ## 직책보다 좋은 아이디어를 가치 있게 만든다 - 역할이 모호하면 업무 충돌과 영역 다툼이 생길 수 있다. - 반대로 직무를 지나치게 상세하게 규정하면 새로운 업무나 혁신적인 아이디어가 등장할 여지가 줄어든다. - Oura Ring은 모든 캠페인과 프로젝트를 실험으로 간주한다. - 좋은 아이디어는 강한 가설에서 시작하고, 결과를 측정한 뒤 다음을 결정한다. - 확대할지 - 반복 적용할지 - 중단할지 - 새로운 아이디어를 내는 일을 특정 직무의 책임으로 제한하지 않고 모두의 책임으로 본다. - 구성원이 새로운 일을 시도하거나 기존 역할의 경계를 잠시 넘는 것을 허용하면 아직 존재하지 않는 중요한 역할과 기회도 발견할 수 있다. - 영향력을 만들려는 시도를 조직이 과도하게 막지 않는 것이 중요하다. ## 경력 대화를 시각화하고 함께 설계한다 - 경력은 직선적인 승진 경로가 아니라 다양한 방향으로 움직일 수 있다. - 관리자는 구성원이 가능한 경로와 미래의 선택지를 상상하도록 도와야 한다. - 특히 원격 근무 환경에서는 우연한 만남이나 비공식 네트워킹이 줄어들기 때문에 의도적인 경력 대화가 더 중요하다. - 글에서는 이를 “경력 대화를 스토리보드로 구성하기”라는 방식으로 제시하지만, 제공된 내용에는 구체적인 실행 방법까지 이어지지 않는다. 구성원에게 많은 일을 맡기는 것보다 중요한 것은 무엇을 하지 않을지 결정하도록 돕는 일이다. 목표를 소수로 제한하고, 회의를 정교하게 운영하며, 누구나 아이디어를 실험할 수 있게 만들면 팀의 자율성·집중력·성장 가능성을 함께 높일 수 있다.

원문 읽기(새 탭에서 열림)
figma3분 읽기큐레이션 요약

FigJam과 함께한 시간: 베타

FigJam은 원격 근무 확산으로 커진 협업·소통 수요에 대응해 탄생했으며, Figma는 완벽한 제품을 한 번에 만들기보다 베타 출시 후 사용자 피드백을 바탕으로 발전시키는 방식을 택했다. 제품의 방향과 우선순위는 내부 여러 팀과 실제 사용자들의 지속적인 의견을 통해 결정됐다. 그 결과 FigJam은 장기 비전을 유지하면서도 빠르게 개선되는 협업 제품으로 정식 출시 단계(GA)에 도달했다. ## 원격 근무가 만든 온라인 화이트보드의 필요성 - Figma는 원격 근무를 시작하며 사람들이 온라인 공간에서 더 많은 시간을 보내는 상황을 경험했다. - 사용자들은 Figma를 디자인 작업뿐 아니라 사람들과 연결되고 소통하는 공간으로도 활용했다. - 브레인스토밍, 팀 아이스브레이커, 사교 활동 등 비업무적 협업 수요도 커졌다. - Figma 내부에서도 함께 모일 수 있는 디지털 공간이 필요했기 때문에 FigJam 개발에 전사적인 추진력이 붙었다. ## 협업을 촉진하는 제품 관리 방식 - Figma에서는 좋은 아이디어와 결정이 특정 직책의 사람에게서만 나온다고 보지 않는다. - 제품 관리자의 역할을 최종 결정자라기보다, 여러 직군이 더 나은 결정을 내리도록 돕는 촉진자로 정의한다. - PM, 디자이너, 엔지니어뿐 아니라 지원, 영업, 마케팅 팀도 제품 아이디어와 우선순위 결정에 참여한다. - “혼자서는 위대한 제품을 만들 수 없다”는 원칙에 따라 제품 개발 자체를 협업 과정으로 운영했다. ## 베타 출시로 완벽주의를 극복하다 - FigJam은 Figma의 두 번째 제품이었기 때문에 기존 제품과 같은 수준의 완성도와 유지보수성을 확보해야 한다는 부담이 있었다. - 모든 것을 완벽하게 결정하려다 출시가 늦어질 위험이 있었다. - 이를 해결하기 위해 베타로 먼저 출시하고, 실제 사용자 반응을 바탕으로 제품을 반복 개선했다. - 베타는 단순한 시험판이 아니라 장기적인 제품 비전을 유지하면서도 변화하는 요구에 빠르게 대응하는 방법으로 활용됐다. ## 결정적인 문제부터 해결한 우선순위 설정 - 모든 세부 사항을 오래 논의하기보다, 다음 단계의 결정을 막는 핵심 문제를 먼저 해결했다. - 초기에는 Figma와 FigJam의 관계, 두 제품을 통합할지 별도 애플리케이션으로 만들지 등이 중요한 쟁점이었다. - 결정이 필요한 사안은 우선 판단한 뒤 이해관계자와 사용자에게 피드백을 받아 조정했다. - 알파 테스트에서 수집한 요청은 다음과 같이 분류했다. - 최초 출시 전에 반드시 해결해야 할 문제 - 초기 출시 이후 빠르게 추가할 기능 - 예를 들어 스티키 노트 작성자 표시 기능은 출시 필수 항목으로 분류했고, 타이머 기능은 후속 개선 항목으로 미뤘다. ## 알파 테스터와 지속적인 사용자 피드백 - 개발팀은 수백 명의 알파 테스터가 참여한 공동 Slack 공간을 운영했다. - 테스터들은 사용 중 발견한 문제와 개선 아이디어를 지속적으로 공유했다. - 출시 후에도 신규 기능을 먼저 사용하는 사용자 패널을 두고 적극적으로 의견을 수집했다. - 사용자 피드백은 Slack, 고객 지원 채널, Twitter 등 다양한 경로에서 얻었다. - 제품 결정의 기준은 기능 자체가 아니라 실제 FigJam 사용자가 필요로 하는 문제를 해결하는지 여부였다. ## FigJam 개발에서 얻은 방식 - 회사 차원의 명확한 목표가 있으면 새로운 제품도 짧은 기간 안에 여러 팀의 역량을 결집해 개발할 수 있다. - 초기부터 모든 답을 확정하기보다, 중요한 구조적 문제를 먼저 결정하고 나머지는 사용자의 반응을 보며 조정하는 것이 효과적이다. - 베타 출시는 불완전함을 감수하는 전략이 아니라, 실제 사용 환경에서 제품을 학습시키는 개발 과정이 될 수 있다. - 다양한 직군과 사용자로부터 아이디어를 얻고, 이를 출시 필수 기능과 후속 기능으로 구분하면 속도와 품질을 함께 관리할 수 있다. 실무적으로는 제품의 장기 방향은 분명히 유지하되, 초기에는 핵심 가설을 검증할 수 있는 수준으로 출시하고 실제 사용자 피드백을 우선순위 결정에 직접 반영하는 접근이 유용하다.

원문 읽기(새 탭에서 열림)
figma4분 읽기큐레이션 요약

Figma 제품 부사장과의

Figma의 VP of Product Yuhki Yamashita는 FigJam이 팬데믹 시기 사용자들이 Figma를 브레인스토밍과 소셜 활동에 활용하던 방식에서 출발했다고 설명한다. FigJam은 아이디어가 아직 구체화되지 않은 단계에서 협업을 돕고, Figma는 이를 인터페이스 설계와 개발로 발전시키는 도구다. 두 제품은 디자이너뿐 아니라 엔지니어와 PM까지 함께 참여하는 비선형적이고 개방적인 제품 개발 문화를 지원한다. ## 사용자 행동에서 출발한 FigJam - Figma 팀은 제품의 방향을 정할 때 사용자와 Figma Community가 제품을 예상 밖으로 활용하는 방식을 관찰했다. - 팬데믹 초기 사용자들은 Figma를 다음과 같은 용도로 확장해 사용했다. - 브레인스토밍 - 팀 워밍업 활동 - 아이디어 구체화 - 구성원 간 친목을 위한 온라인 이벤트 - Figma 역시 원격 근무로 전환하면서 오프라인 협업 과정을 온라인으로 옮길 필요를 경험했다. - 여러 사람이 하나의 가상 공간에 함께 있다는 경험이 협업과 소속감에 대한 중요한 요구를 충족한다고 판단해 온라인 화이트보드인 FigJam을 만들었다. ## 디자인과 개발의 경계가 흐려지는 현상 - 디자인은 더 이상 디자인팀만의 활동이 아니라 조직 전체가 함께 참여하는 과정으로 확장되고 있다. - 디자인팀 내부에서는 서로의 아이디어를 빠르게 변형하고 발전시키는 협업이 늘었다. - 디자인팀 외부에서도 다음과 같은 참여가 초기 단계부터 이루어진다. - 카피 문구 수정 - 제품 아이디어 검토 - 근본적인 문제 정의와 방향 변경 - Figma와 FigJam 링크가 개발 과정 초기에 조직 전체에 공유되면서 엔지니어, 디자이너, PM이 함께 문제를 해결하는 방식이 강화됐다. - 직무와 책임이 협업의 경계를 결정하던 기존 모델에서 벗어나, 여러 직군이 팀의 경계를 넘어 공동으로 문제를 해결하는 방향으로 변화하고 있다. ## PM 역할의 변화와 공동 소유 - PM과 디자이너의 역할은 원래도 일부 겹쳤지만, 과거에는 두 직군이 함께 탐색하고 편집할 수 있는 도구가 부족했다. - 과거에는 디자인 파일을 디자이너의 소유물로 보는 인식이 강해 PM의 수정이나 개입이 침해처럼 받아들여지기도 했다. - 이제는 누가 파일을 소유하는지보다 문제를 어떻게 함께 해결하는지가 중요해졌다. - 디자인과 제품 관리는 더욱 긴밀하게 연결됐으며, 이러한 역할의 결합은 더 나은 협업을 가능하게 한다. ## 비선형적인 디자인 프로세스와 ‘혼란의 수용’ - 디자인은 처음부터 끝까지 직선적으로 진행되지 않는다. - 아이디어를 만든 뒤에도 반복적인 탐색과 수정, 평가가 필요하다. - 브레인스토밍 직후 아이디어를 폐기할 수도 있고, 상당히 발전한 개념에 새로운 관점이 필요할 수도 있다. - Figma가 말하는 “혼란을 받아들이기”는 디자인 과정의 복잡성과 불확실성을 제거하기보다 적극적으로 활용한다는 뜻이다. - 협업 공간은 작업을 가까이서 살펴보는 동시에 전체 맥락을 내려다볼 수 있어야 한다. - FigJam은 아이디어 발상과 구조화에, Figma는 인터페이스 설계와 구현에 적합하며 두 단계가 자연스럽게 이어지도록 한다. ## FigJam과 Figma의 사용 구분 - **FigJam** - 아이디어가 아직 모호하고 구체화되지 않은 단계 - 자유로운 브레인스토밍 - 사용자 여정이나 문제 구조 매핑 - 팀의 의견과 분위기 확인 - 워크숍 및 다양한 협업 활동 - **Figma** - 아이디어를 실제 인터페이스로 발전시키는 단계 - 화면 설계와 프로토타이핑 - 구체적인 디자인 결과물 제작 - 두 제품은 서로 대체 관계라기보다, 아이디어 발상부터 설계·개발까지 이어지는 전체 과정의 서로 다른 부분을 담당한다. ## 회의의 표현 방식과 인간적인 상호작용 - 기존의 공유 문서 기반 회의는 의제, 진행 상황, 마일스톤 중심으로 흐르기 쉬웠다. - FigJam은 회의 기록을 남기는 것보다 구성원들이 같은 공간에서 함께 문제를 해결하는 경험에 초점을 둔다. - 화상회의에서는 음소거를 해제하고 발언해야 한다는 부담이 생기지만, FigJam에서는 다음과 같은 방식으로 자연스럽게 반응할 수 있다. - 커서 채팅 - 이모지 - 스티커 - 이러한 표현은 웃음이나 동의처럼 가벼운 반응을 영구적인 기록으로 남기지 않고 전달할 수 있다는 장점이 있다. - 결과적으로 FigJam은 회의의 분위기와 팀이 함께 일하는 방식을 더 편안하고 인간적으로 바꿀 수 있다. ## 앞으로의 발전 방향 - 사용자들은 FigJam을 다양한 워크숍과 협업 활동에 활용하고 있다. - Figma는 사람들이 이러한 활동을 더 쉽게 진행하고 운영할 수 있도록 지원 기능을 확장하려 한다. - 사례로 타이머 기능이 언급되며, 향후에도 진행 관리와 퍼실리테이션을 돕는 기능이 중요해질 것으로 보인다. FigJam은 단순한 온라인 화이트보드라기보다, 아직 정리되지 않은 생각을 여러 직군이 함께 탐색하는 협업 공간이다. 따라서 아이디어 발상과 의견 수렴에는 FigJam을, 구체적인 화면 설계와 프로토타이핑에는 Figma를 사용하면 제품 개발 과정 전체를 더욱 유연하게 연결할 수 있다.

원문 읽기(새 탭에서 열림)
figma3분 읽기큐레이션 요약

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이 해결책을 제안하거나 도움을 줄 수 있는 문제를 조기에 발견하게 한다. ## 실무에 적용할 때의 시사점 - 브레인스토밍 후에는 반드시 결정 사항과 실행 항목을 문서화한다. - 우선순위 논의에서는 단순 투표 대신 제한된 예산이나 시간을 배분하게 하면 실제 투자 의향을 확인할 수 있다. - 의견 차이를 숨기지 말고 척도나 댓글로 시각화해 추가 논의가 필요한 부분을 찾는다. - 정기 회의에 업무 외 고민과 해결이 필요한 문제를 공유하는 시간을 포함하면 협업과 팀 신뢰를 함께 강화할 수 있다.

원문 읽기(새 탭에서 열림)
figma3분 읽기큐레이션 요약

Figma 내부 이야기: PM 팀

Figma의 PM 팀은 FigJam을 단순한 아이디어 발상 도구가 아니라 제품 개발 전 과정의 협업 공간으로 활용한다. 제품 비전 수립부터 브레인스토밍, 로드맵 계획, 회고, 주간 회의까지 동일한 시각적·실시간 협업 환경에서 진행하며, 템플릿으로 팀의 업무 방식을 표준화한다. FigJam의 핵심 가치는 자유로운 아이디어 공유와 구조화된 실행 프로세스를 하나의 공간에서 연결하는 데 있다. ## 제품 비전 수립 - 제품 비전 보드를 사용해 단기·장기 우선순위를 정리한다. - 사용자 니즈, 기능, 비즈니스 목표를 시각화해 제품 전략을 검증한다. - 구체적인 문구를 다듬는 데 시간을 쓰기보다 아이디어를 빠르게 기록하고, 각각의 계획이 큰 목표와 어떻게 연결되는지 확인한다. - H2 계획과 같은 반기 단위 전략 수립에 활용한다. ## 제한 시간 브레인스토밍 - ‘Crazy 8’s’ 프레임워크를 사용해 8분 동안 8개의 해결 아이디어를 만든다. - 참여자는 각 아이디어의 완성도보다 빠른 발산에 집중한다. - 시간이 끝난 뒤 아이디어를 공유하고, 실제로 해결할 가치가 있는 주제를 함께 논의한다. - FigJam의 자유로운 캔버스는 여러 사람이 동시에 아이디어를 추가하고 발전시키는 데 적합하다. ## 로드맵과 리소스 계획 - 간트 차트 템플릿을 사용해 제품 로드맵을 시각화한다. - 프로젝트별 기간과 범위를 한눈에 파악할 수 있다. - 여러 업무 흐름에 필요한 인력과 리소스를 판단하는 데 도움을 준다. - 일정과 프로젝트 규모를 비교하면서 우선순위를 다시 조정해야 하는 시점도 쉽게 확인할 수 있다. - FigJam 자체의 로드맵을 만드는 과정에도 이 방식을 사용했다. ## 제품 및 팀 회고 - 제품·엔지니어링·디자인 팀은 제품 실행과 출시 과정을 함께 회고한다. - 마케팅·고객지원·제품 교육 팀은 출시와 시장 진입 활동을 검토한다. - 잘된 점과 개선할 점을 공유해 다음 작업의 품질을 높인다. - 다른 팀의 업무를 이해하고 협업 과정의 가시성을 확보할 수 있다. - 제품 출시뿐 아니라 팀의 업무 프로세스 자체도 회고해, 조직이 성장하면서 기존 방식이 여전히 적절한지 점검한다. - 반복 가능한 템플릿을 사용해 참가자들이 회의의 진행 방식과 기대 결과를 미리 알 수 있도록 한다. ## 주간 팀 회의와 원격 협업 - Figma PM 팀은 매주 하나의 FigJam 파일에 모여 업무 상황을 공유한다. - 현재 해결하기 어려운 문제, 기대되거나 우려되는 일, 업무 외 근황 등을 정해진 프롬프트에 따라 기록한다. - 커서로 대화하거나 스티커와 이모트를 사용하는 방식으로 원격 회의를 더 상호작용적으로 만든다. - 정기적인 시각적 회의 공간이 원격 근무 환경에서 팀 간 연결을 유지하는 접점 역할을 한다. - 이 프로세스 역시 다른 팀이 재사용할 수 있는 템플릿으로 공개했다. ## 템플릿을 통한 업무 방식 표준화 - FigJam은 아이디어를 자유롭게 탐색하는 동시에 로드맵이나 회고처럼 구조가 필요한 업무도 지원한다. - 템플릿은 회의 준비 시간을 줄이고, 참여자 모두가 동일한 방식으로 업무에 참여하게 한다. - 비전 수립, Crazy 8’s, 간트 차트, 회고, 주간 스탠드업 템플릿을 상황에 맞게 선택할 수 있다. - 팀의 필요에 따라 템플릿을 수정하고 반복 사용하면서 조직의 업무 의식을 발전시킬 수 있다. 팀 협업을 FigJam에 도입할 때는 모든 활동을 한꺼번에 옮기기보다, 브레인스토밍이나 주간 회의처럼 참여 효과가 분명한 활동부터 시작하는 것이 좋다. 이후 비전 보드, 로드맵, 회고 템플릿으로 확장하면 자유로운 논의와 체계적인 실행을 자연스럽게 연결할 수 있다.

원문 읽기(새 탭에서 열림)