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