제품 로드맵 프레젠테이션은 개발자와 제품 매니저 모두에게 초조한 일이 될 수 있습니다. 한 당사자는 비전을 제시하려고 열심히 작업했고 다른 당사자는 작업에 영향을 미칠 미지의 결과를 보려고 기다립니다.
개발자로 일하면서 같은 긴장을 느꼈고 완성된 제품 관리 로드맵에 만족하지 못하는 경우가 많았습니다. 저는 결정을 완전히 받아들이지 않았고, 계획 미팅을 떠나면서 "글쎄, 난 이해가 안 가지만 남들이 그렇게 생각한다면야..."라고 생각할 때가 많았고, 더 심한 경우는 "우리 스스로 파악한 다음에 우리 작업이 이 로드맵에 들어맞는 것처럼 보이게 만드는 수밖에 없겠다"라고 생각한 적도 있습니다.
제가 NIH(Not Invented Here syndrome) 문제로 고통받았을 것이라고 주장하신다면 물론 정답일 수도 있습니다. 개발자로서 저는 옳은 일이 무엇인지에 대해 매우 강한 의견을 가지고 있었습니다. 하지만 이제 제품 매니저로서 단절의 원인을 이해하며, 제품 매니저가 로드맵 프레젠테이션을 통해 성공하기 위해 단절에서 얻을 수 있는 일반적인 지식도 알고 있습니다. 결국 기술 팀이 큰 그림에 동의하고 이해한다면 일상적인 디자인 및 구현 결정이 올바른 컨텍스트를 통해 이뤄지고 구상했던 제품도 얻을 수 있습니다.
다음은 제품 로드맵 프레젠테이션을 통해 팀을 사로잡는 10가지 주요 방법입니다.
1. 유행어보다 본질 선택
“빅데이터 분석", "머신러닝" 또는 “사물 인터넷 이니셔티브(IoT)" 같은 유행어는 비즈니스 이해 관계자에게 높은 수준의 고정점으로 공감을 끌어낼 수 있지만 기술 팀에는 유용하고 실행 가능한 항목이 아닙니다. 엔지니어링 팀은 무엇을 구축하고 있는지, 현재 제품과 어떤 관련이 있는지, 어떻게 제공되어야 하는지, 결국 누가 어떤 목적으로 사용할 것인지 정확히 알아야 합니다.
높은 수준의 테마를 설정하면 로드맵과 컨텍스트를 구성하는 데 유용하지만, 여기서 멈추지 말고 각 상위 수준 항목 이면의 내용에 대해 좋은 답을 얻어야 합니다. 예를 들어 테마 "지능형 서비스"를 호출한 경우 이 테마를 제공하는 데 필요한 주요 이니셔티브 및 에픽으로 분할해야 합니다.
2. 적합한 컨텍스트 설정
기술 팀에는 로드맵에 무언가를 구축하는 이유에 대한 컨텍스트가 필요합니다. "원하는 것을 알려주시면 제가 구축할게요"라고 말하는 기술 팀은 절대 없습니다. 반대로 엔지니어는 기능을 요구하는 이유에 대한 증거를 확인해야 합니다. 데이터가 스스로 말할 수 있게 하고, 사용자의 관점에서 강력한 스토리를 전달하게 하세요. 페르소나를 사용하고 여러분이 제외한 몇 가지 대안과 그 이유에 대해 이야기하세요. 팀 전체가 로드맵을 이해하도록 도우려면 "이유"가 "대상"만큼이나 중요합니다.
3. 이행 약속 신중하게 고려
기능이 잘 고려되지 않았거나 현실적으로 보이지 않지만 여전히 로드맵에 있다면 위험 신호를 눈치채야 합니다. 기술 팀이 누군가에게 약속했다는 이유만으로 무언가 만들어야 한다는 인상을 받아서는 안 됩니다. 여기서 이유란 고객에 대한 이행 약속일 수도 있고 "경영진이 원해서"일 수도 있습니다. 그러니 이행을 약속할 때는 현명해지세요. 특정 변경을 요구하며 밀어붙이는 부서가 있더라도 반드시 여러분이 이론적 근거를 이해하고 팀에 전달하며 변경 사항을 스스로 지지해야 합니다.
4. 현실적인 계획 세우기
비전은 좋지만 모두가 비전을 달성할 수 있다고 확신하면 훨씬 좋습니다. 계획이 정확할 필요는 없지만 로드맵을 볼 때 개발 매니저가 가장 먼저 심각한 병목 현상부터 발견하는 경우(예: 로드맵에 디자인이 매우 중요하며 프런트 엔드 중심이지만 팀에 디자이너가 한 명이고 지난 몇 개월 동안 프런트 엔드 주제로 어려움을 겪은 경우) 여러분 때문에 그들이 프레젠테이션의 나머지 부분 내내 로드맵 때문에 어려움을 겪을 것입니다.
팀과 함께 현실을 미리 확인하고 가정 시나리오를 플레이하세요. 모두에게 약속 이행을 요청하기 전에 답변과 명확한 행동 계획, "수행 방법"에 대한 간결한 고려가 필요합니다.
5. 크게 생각하고 작게 시작하기
현재 제품 및 팀 스킬이 있는 위치와 향후 있기를 원하는 위치를 알고 있어야 합니다. 팀에 새로운 스킬이 필요하거나 기존 기술에서 벗어나야 하는 새로운 분야로 진출하는 것은 좋지만 1년 후에 어디에 있고 싶은지에 대한 꿈을 적어만 두지는 말고, 현실적으로 도달할 방법을 생각하세요. 인재를 확보하려면 시간이 걸리고 새로운 기술을 도입하는 데도 시간이 걸리며 기존 제품을 포기하려면 명확한 이행 약속과 전환 계획이 필요합니다.
6. 비즈니스 사례 만들기
비즈니스 사례입니까? 비즈니스 사례라면 기술 팀은 이것을 중요하게 생각합니다. 고위 경영진과 같은 정도는 아닐 수도 있지만 전체 개발 팀은 무언가가 비즈니스와 관련된 이유, 실제 결과를 산출하는지, 또 어떻게 측정될지에 관심이 있습니다. 비즈니스 분야에 정통한 기술 팀의 지식을 활용하세요. 누구나 전체 비즈니스의 성공에 기득권을 가지고 있으며 피드백이나 추가 아이디어의 훌륭한 원천이 될 수 있습니다.
또한 비즈니스에 미치는 영향에 대한 완전한 명확성과 실제 효과를 확인하는 것은 큰 동기 부여가 될 수 있습니다. 결과를 이끌어내는 것은 단순히 기능을 구축하고 제공하는 것 이상으로 만족스럽습니다.
7. 일상과 동기 부여의 균형
엔지니어들은 자부심을 가질 수 있는 고유하고 혁신적인 제품을 만들고 싶어 합니다. 남들이 이전에 말한 적 있는 뻔한 이야기라면 사기가 떨어질 수 있습니다. 조사를 통해 스토리가 생각만큼 혁신적인지 확인하세요. 사기가 떨어지는 개발자도 문제지만 혁신 부족으로 인한 비즈니스 영향은 훨씬 더 나쁩니다.
물론 그렇다고 해도 로드맵은 항상 흥미진진한 새로운 기능과 기술적으로 너무 흥미롭지는 않지만 필수적인 기능 간의 균형 잡힌 행동이 될 것입니다. 평범한 일상조차도 로드맵에 동기를 부여하도록 확인하세요.
8. MVP와 v1을 뛰어넘는 생각
최소한의 실행 가능한 제품을 만든 다음 나오는 버전 1도 중요하지만 운영, 유지 관리, 사용자의 기능 요청, 지속적 개선 및 통합된 다른 제품 및/또는 플랫폼의 새 버전 등 제공 후 발생하는 모든 작업도 있습니다. 제공 후 과제와 장애물이 무엇인지 빠르게 생각하면 큰 노력 없이도 문제를 밝힐 수 있으며 엔지니어는 여러분이 현실을 무시하지 않았다는 사실에 고마워할 것입니다. 대략적인 추정에 따르면 새로운 기능을 구축하기 위한 초기 노력은 기능의 전체 수명 동안 소요되는 총 노력의 1/3에서 절반에 불과한 경우가 많습니다. 다시 말해 여파는 초기 빌드보다 비용이 많이 들고 일부 "빠른 소규모 작업"도 장기적으로는 매우 비용이 많이 듭니다.
9. 힘든 상황에 적응하기
추정은 좋은 일입니다. 참고 자료를 제공하며, 제품 매니저는 주어진 각 시점에서 자신이 아는 한 최선을 다해 만듭니다. 그러나 추정치에 대한 가정은 구현을 시작하거나 디자인을 구체화하면 매우 잘못된 것으로 판명되는 경우가 많습니다. 변화에 유연하게 대처할 수 있도록 로드맵을 준비하고 제시해야 합니다.
10. 솔직하고 열린 태도
참고 자료를 제공하는 로드맵이 있습니다. 실행에 대한 세부 계획이 아니며 모든 소프트웨어 팀원도 알고 있습니다. 실제와 다른 것이라고 속일 필요가 없습니다. 따라서 주제에 대한 모든 세부 정보가 아직 없다면 솔직하게 공개하세요. 현재 있는 정보, 의도, 미해결 질문, 해결해야 할 가장 큰 위험을 공유하세요. "무엇"을 파악하기 위해 실험과 더 많은 조사가 필요한 영역을 지적하세요. 계획할 때 이 실험 시간을 잊지 말고 포함하세요.
결론은 무엇입니까?
팀은 큰 그림을 명확하게 그리지만 현실을 무시하지는 않는 로드맵을 가질 자격이 있습니다. 또한 팀은 동기를 부여하고 흥미진진하며 충분한 세부 정보가 포함된 로드맵을 가질 자격이 있으므로 전체 소프트웨어 팀은 비즈니스에 중대한 영향을 미치는 훌륭한 결과를 얻을 수 있다는 확신 속에서 다음 1~2 스프린트 동안 무엇을 해야 하는지 알 수 있습니다.
추가 도움이 필요하십니까? Jira Software의 로드맵 기능 및 Jira의 제품 로드맵 템플릿을 확인해 보세요. 아니면 PM을 위한 Jira Product Discovery를 무료로 사용해 보세요.
