팀의 규모가 커질수록 정보를 체계적으로 정리하기란 점점 더 어려워지죠. 그러다 보니 팀원들이 무엇을 빌드해야 하는지, 이것이 왜 중요한지, 여러 부서와 협업하는 지원팀을 어떻게 구성해야 하는지 명확하게 알지 못하는 경우가 많습니다.
Duolingo의 그룹 프로덕트 매니저, Natalia Castillejo는 프로덕트 부서에서 이러한 문제를 직접 목격했습니다. 결재는 그때그때 이루어지고, PRD, 리서치, 전략 문서 등 주요 자료는 찾기 어려웠으며, 회의는 산만하게 진행되었습니다.
그래서 팀은 다시 초심으로 돌아가 한 가지 질문을 던졌죠. 어떻게 하면 모든 사람이 더 나은 프로덕트 의사결정을 내리는 데 필요한 올바른 정보를 얻을 수 있을까?라고 말입니다.
Natalia와 팀은 Notion에서 프로덕트 스펙 문서를 다시 작성했습니다. 사람과 정보 사이의 구심점 역할을 해주는 이 문서는 맥락과 세부 핵심 정보를 결합하여 모두가 가장 영향력 있는 최고의 프로덕트를 출시할 수 있도록 돕습니다.
모든 레벨에서 명확성을 제공하는 가설
프로덕트팀은 업무의 중심에 위치해 회사 전반의 거의 모든 팀과 협업하는 경우가 많죠. 그러나 서로 다른 이해관계자마다 요구하는 세부 사항의 수준이 같을 수는 없습니다.
"저희처럼 프로덕트 부서 전반에 걸쳐 팀이 분산되어 있는 경우에는 일관성과 결속력을 구축하는 것이 훨씬 더 중요해집니다."라고 Natalia는 말합니다. "사람들이 올바른 정보를 얻지 못하면 회사가 원하는 프로덕트를 만드는 데 방해가 될 수 있습니다."라고요.
예를 들어 경영진은 개략적인 업무 요약 자료를 원할 수 있지만, 여러 부서와 협업하는 파트너는 프로덕트 스펙에 대해 더 깊이 있고 상세한 정보를 필요로 할 수 있습니다.
Natalia는 모든 사람이 올바른 정보를 얻을 수 있도록 두 개의 섹션을 만들었습니다.
우선, 가설 섹션에서는 진행하는 실험에 대한 심층 정의를 제공합니다. 팀은 프레임워크를 사용해 각 가설이 영향력이 있는지 확인합니다.
각 가설은 다음 중 하나로 분류됩니다.
잠정적 상태: 하나 이상의 실험 결과를 바탕으로 가설을 구체화할 수 있습니다.
반증 가능: 잘못된 것으로 입증될 수 있습니다.
테스트 가능: 실험을 통해 가설을 뒷받침하거나 반증할 수 있는 증거를 수집할 수 있습니다.
일반화 가능: 한 실험에서 얻은 가설 결과를 향후 실험에 적용할 수 있습니다.
이후, 팀은 문서 상단에 경영전이 실험을 개괄적으로 파악할 수 있도록 한 줄짜리 기본 설명을 작성합니다. 그러나 이 짧은 설명은 단순히 프로덕트 실험을 정의하는 것 이상의 역할을 합니다.
“업무의 핵심을 간결하게 정리하고 경영진을 위한 업무 업데이트를 제공할 수 있는 기회입니다. 동시에 프로덕트팀이 진행하는 업무와 그 업무의 영향력에 대해 진지하게 고민해보도록 장려하는 방법이기도 하죠.”
Natalia Castillejo
Duolingo 그룹 프로덕트 매니저
가설을 다양한 수준으로 제시하면 읽는 사람마다 개략적인 수준과 심층적인 수준 모두에서 무슨 일이 일어나고 있는지 이해할 수 있는 충분한 정보를 얻을 수 있기 때문이죠.
Duolingo의 템플릿 복제
모든 업무를 하나로 연결하여 프로덕트 스펙에 배경 정보 추가
프로젝트가 여러 부서에 걸쳐 진행될수록 동시에 진행되는 모든 업무를 통합하고 업데이트하기가 더 어려워지죠. 이로 인해 중요한 맥락이 되는 배경 정보가 부족해지며 팀의 협업이 난항을 겪기 마련입니다.
Natalia는 몇몇 프로덕트 스펙 검토 회의에서 이러한 문제가 많이 드러났음을 알게 되었습니다. 초점을 잃은 채 비생산적으로 대화가 진행되어 팀원들에게는 돌아온 답변보다 질문이 더 많아졌죠.
“특정 주제나 공개 질문 등, 회의에서 예상되는 사항에 대해 모든 사람에게 더 많은 배경 정보를 제공해야 한다는 것을 깨달았습니다. 더 많은 맥락을 제공할 수록 더 효과적인 팀으로 거듭날 수 있죠.”
Natalia Castillejo
Duolingo 그룹 프로덕트 매니저
그래서 Natalia와 팀은 프로덕트 스펙 전반에 걸쳐 업무를 더 잘 연결하고 테스트 대상에 더 많은 배경 정보를 추가할 수 있는 방법을 마련했습니다.
회의 목표 섹션에서는 모든 프로덕트 스펙 검토 항목을 정의하여 팀이 각 회의에서 구체적인 피드백을 남길 수 있도록 합니다.
배경과 변경 사항 요약 섹션에는 팀이 한 줄 가설을 기반으로 확장하여 이전 실험에서 얻은 교훈을 작성합니다.
관련 업무 섹션에는 프로젝트와 관련된 문서, 리서치, 회의록 또는 작업을 모아둡니다.
디자인과 인터랙션 섹션에서는 팀이 Figma에서 임베드한 디자인 파일과 추가 스크린샷 등을 사용해 프로덕트 내에서 예상되는 변경 사항을 명확하게 보여줍니다.
프로덕트 스펙 문서에 정보를 통합하면 협업팀 멤버들이 여러 툴에서 정보를 확인하거나 최신 정보를 놓칠 염려가 없습니다. Notion에는 프로젝트의 모든 부분을 연결하는 하나의 정보 소스가 있으므로 팀은 올바른 정보를 확보하고 향후에도 쉽게 찾을 수 있게 되었죠.
Duolingo의 템플릿 복제
제대로 된 프로덕트를 만들기 위한 정성적, 정량적 피드백 활용
Natalia에게 피드백 수집이란 실제 사용자 데이터를 기반으로 프로덕트 스펙에 의미 있는 인사이트를 반영하고, 아이디어를 지속적으로 수정하며, 새로운 프로덕트를 기획하기 위한 과정 중 하나입니다.
Natalia의 팀처럼 빠르게 돌아가는 프로덕트팀에게는 이러한 피드백을 모으는 것이 특히 중요합니다. 피드백을 통해 집중 개발할 사항을 파악하고 동시에 프로젝트 범위가 너무 넓어지는 결과를 예방할 수 있기 때문이죠. Natalia와 팀은 정량적 및 정성적 피드백을 모두 고려하여 프로덕트 스펙을 다시 작성했습니다.
정량적 피드백 섹션에서는 프로젝트를 주요 지표와 연결합니다. 이 섹션은 다음 세 가지 영역으로 구성됩니다.
성공 지표: 실험에서 테스트하려는 항목으로, 팀 OKR과 일치하는 경우가 많습니다. '일일 수익' 또는 '일일 활성 사용자' 등이 대표적인 지표이죠.
기능 지표: 테스트 중인 기능의 효과입니다. '해당 기능의 무료 체험판을 시작한 사용자 수' 등이 될 수 있습니다.
가드레일 지표: 이 실험으로 인해 부정적인 영향을 받을 수 있는 부분으로, 모니터링해야 할 중요한 비즈니스 지표입니다. '이 기능은 일일 매출을 증가시킬 수 있지만 일일 활성 사용자 수에 해를 끼칠 수 있음' 등의 리스크가 있다면 유의해야 하겠죠.
정성적 피드백 섹션에는 내부 테스트와 공식적인 사용자 조사에서 얻은 의견을 모두 포함합니다. 수치 외적인 측면을 살펴보고 무엇을 배웠는지, 무엇을 변경해야 하는지, 앞으로 무엇을 개선해야 하는지에 대한 다른 종류의 인사이트를 공유할 수 있는 곳이죠.
집중과 협업을 위한 프로덕트 스펙 문서
팀, 파트너, 경영진 등 모든 사람의 집중력이 하나로 모아질 때 업무 성과는 더욱 강력해집니다. 하지만 배경 정보가 산재되어 있고 영향력이 불분명하다면 효과적으로 일을 완수하는 것은 거의 불가능합니다.
그렇기에 Duolingo는 Notion으로 이 프로덕트 스펙 템플릿을 만들었습니다. 이 템플릿은 프로덕트팀이 모두가 같은 방향으로 나아갈 수 있도록 정보를 연결하고 정리하는 데 도움을 줍니다. 모든 정보와 확인이 필요한 사안들을 한곳에 모아두면 그 어느 때보다 더 효과적이고 업무 집중력도 높아집니다.
Duolingo의 프로덕트 스펙 템플릿을 사용해 보려면 여기에서 템플릿을 복제하여 시작하세요.
