제품 전략에서 제품 로드맵(From Product Strategy to the Product Roadmap)

이 글은 Nima TorabiFrom Product Strategy to the Product Roadmap 글을 번역했습니다. 저의 모든 글은 허가를 받고 진행 하였습니다

presentation
https://www.productplan.com/
제품 로드맵은 모든 제품 관계자에게 개발 계획을 조정하는 데 필요한 정보를 제공하는 민첩하고 장기적인 제품 개발 계획입니다. 올바르게 구축된 경우 제품 로드맵은 비즈니스의 성공에 매우 중요할 수 있으며 다음과 같은 몇 가지 이유가 있습니다.
  • 제품 로드맵은 제품 개발 프로세스에 대한 예측 가능성을 제공하여 제품의 모든 관계자가 향후 활동을 계획, 할당 및 조정할 수 있도록 합니다.
  • 제품 로드맵은 사업부의 리더 팀이 자사의 비즈니스 목표와 그에 따른 전략을 명확하게 설명하도록 강요합니다.
  • 제품 로드맵은 제품 개발 노력을 기업, 비즈니스 및 기능 전략에 맞게 조정합니다.
  • 제품 로드맵은 주요 이해 관계자를 정렬하고, 여러 기능의 통합(cross-functional)을 실현하며, 모든 사람이 효과적으로 협력할 수 있도록 지원합니다.
다양한 내부 및 외부 제품 관련 이해 당사자들이 제품 로드맵에 긍정적인 영향을 미칠 것입니다. 이러한 이해 관계자의 일부는 다음과 같습니다.
  • 특히 B2B 비즈니스의 경우 고객이 구매 및 실행 결정을 내리는 데 도움이 되는 제품 로드맵을 확인하고자 하는 경우가 많습니다.
  • 조직 내 고객 대상 팀(예: 영업, 마케팅 또는 고객 지원)입니다. 제품 로드맵을 사용하여 문서화 및 교육 등의 자료를 개발할 수 있습니다.
  • 투자자, 이사회 또는 스폰서들은 제품 로드맵을 사용하여 미래의 매출과 비용을 예측하고 어떤 자원을 할당할지 결정할 수 있습니다.
  • 설계자, 엔지니어 및 설계자를 포함한 제품 팀은 로드맵에서 제공하는 가시성을 활용하여 더 높은 품질의 제품을 만들 수 있습니다.
  • 인사팀, 채용 계획을 세우거나 변경해야 합니다.
  • 계약서를 작성해야 하는 법무팀입니다.

— 최종 로드맵 템플릿입니다.

  • 문서의 형식이나 아름다움은 제품 로드맵의 주요 목표보다 훨씬 덜 중요합니다. 즉, 지원을 구축하고 이해 관계자를 정렬하는 것입니다.
  • 조직마다 다양한 개발 프로세스, 영업 주기 및 의사 결정 프로세스가 있으므로, 모든 조직에 완벽하게 적합한 모든 형식 또는 템플릿은 없습니다.
이러한 점을 고려하여 Google '제품 로드맵'을 사용하고 다운로드할 템플릿을 많이 찾을 수 있습니다. 이러한 템플릿의 대부분은 PowerPoint와 같은 소프트웨어에서 쉽게 그릴 수 있는 그래픽 레이아웃을 사용하고, 하단의 x축에 따른 향후 시간 기간(주, 월 또는 년)을 표시하며, y축을 따라 다양한 제품을 보여주며, 그리드에 걸쳐 각 제품의 향후 이정표를 표시합니다. 각 이정표는 비즈니스에 큰 영향을 미칠 새로운 기능 기능을 의미 있게 그룹화합니다.
전반적으로 제품 로드맵은 조직 내 모든 사람이 쉽게 이해할 수 있는 간단한 문서입니다. 어려운 부분은 제품 전략(product strategy)을 구현하고 모든 이해당사자들이 그에 맞춰 정렬할 수 있도록 올바른 릴리스 날짜와 함께 로드맵을 만드는 것입니다.

— 제품 백로그 vs 로드맵을 비교합니다.

민첩한 제품 개발 팀(주로 신생업체)에는 제품 백로그, 가장 중요한 버그, 제품 개발 작업 또는 사용자 스토리가 있습니다. 백로그를 제품 로드맵으로 잘못 해석해서는 안 됩니다. 제품 로드맵은 이해당사자들이 노력을 조정하는 데 필요한 정보를 제공하도록 설계되었습니다.
고객, 마케팅 또는 재무 담당자와 같은 이해관계자는 일반적으로 신규 고객 또는 수익을 창출할 이정표와 언제 이정표가 출시될지를 아는 데 관심이 있습니다. 그러나 백로그는 이 정보를 제공하지 않습니다. 백로그와 로드맵 사이에는 밀접한 관계가 있으며, 이에 따라 로드맵에 표시된 각 이정표는 백로그의 대규모 작업 세트로 전환되어야 합니다. 백로그는 제품 로드맵에 의해 지시되며, 제품 개발 팀의 활동이 회사 전체의 요구와 목표에 부합하도록 보장할 수 있는 한 가지 방법입니다.
이정표의 시기에 관해서는 일반적으로 제품 개발 팀에서 수행한 하향식 추정치입니다. 견적이 가까운 한 제품 로드맵의 목적에 부합할 수 있습니다. 다양한 제품 관계자들 간의 조정이 가능합니다.

— 초기 단계 제품입니다.

초기 단계 제품을 개발하고, 새로운 시장, 새로운 고객 및 제품을 탐색할 때, 먼 미래에 무엇을 개발할 것인지를 계획하는 것은 현명하지 못한 일일 것입니다. 이 팀은 제품의 초기 단계에서 일부 미충족 고객 요구 사항과 비즈니스 가치를 창출할 수 있는 가능한 솔루션에 대한 아이디어를 가지고 있습니다.
이 경우 제품 개발의 목적은 시장과 고객에 대해 알아보고 나중에 제품 전략(product strategy)의 기초를 형성할 가설을 검증하는 것입니다. 제품이 제품 시장에 적합하게 들어맞고 견고한 시장 지식에 기반한 제품 전략(product strategy)을 명확히 할 수 있게 되면 제품 로드맵이 필요합니다.
제품 시장의 적합성이 실현되지 않는 많은 단서들을 볼 수 있습니다.
  • 고객은 제품을 제대로 이해하지 못하거나 제품의 최대 가치를 인식하지 못합니다.
  • 입소문이 퍼지지 않고 있습니다.
  • 리뷰가 희박하거나 보통입니다.
  • 판매 주기가 길거나 고객 구매 비용이 매우 높습니다.
반면, 제품 시장의 적합성은 다음과 같습니다.
  • 성장 곡선이 인상적입니다.
  • 돈이 소비되는 것보다 더 빨리 들어오고 있습니다.
  • 딜은 마감하기 쉽습니다.
  • 외부 마케팅 캠페인으로 고객이 들어오고 있습니다.
  • 언론은 끊임없이 정보를 찾고 있습니다.

I. 로드맵을 작성합니다.

— 포괄적인 프로세스를 실행합니다.

만약 주요 제품 이해 관계자들은 그 주변에 올바르게 정렬되지 않는 제품 로드맵이 아무리 대단한 전략적 사고, 계획, 우선 순위를 매기는 아무런 가치도 없어요 자칫 잘못하고 제품 로드맵 이해 관계자 낙찰을 가지고 있지 않기 시작하면, 모든 사람들이 단점에 대해 서로를 비난하기 시작할 것이에요. 이 꿈을 이루려는 이유는 로드맵 챔피언, 대개 제품 지도자가 전체 팀과 이해 관계자들은 로드맵에 정렬되 가지 않았다는 것이에요. 불행히도, 제품 개발은 진공상태에서 일어나지 않아요.
제품 개발의 목적은 고객의 충성도를 얻어 궁극적으로 수익을 창출함으로써 비즈니스에 봉사하고 회사의 전반적인 전략을 지원하는 것입니다. 또한 수익은 회사의 모든 다양한 팀, 영업, 마케팅, 고객 지원 등이 상호의존적인 방식으로 협력해야 합니다. 이해당사자가 참여하지 않거나 제 역할을 하지 않는다면 제품 로드맵의 성공에 큰 장애물이 될 것입니다.
제품 로드맵을 조정하기 위해 다음과 같은 작업을 수행해야 합니다.
  • 프로세스 초기에 이해 관계자를 참여시킵니다.
  • 피드백을 요청하고 주소를 지정합니다.
  • 계획이 구체화되고 최종 양식으로 발전할 때 업데이트를 전송합니다.
사람들이 무언가를 만드는 데 관여하면 소유권을 느끼고이를 홍보하고 방어합니다. 제품 로드맵을 사용하면 이해 관계자 정렬이 궁극적 인 목표이며 결과 제품 로드맵 문서는 사용자가 정렬 한 것을 상기시키기위한 것입니다.

— 성공 요인

성공적인 제품 로드맵은 다음을 필요로 합니다.
  • 올바른 제품 전략(product strategy)을 기반으로 합니다.
  • 현실적이 되세요.
  • 주요 제품 관계자의 전폭적인 지원을 받습니다.
일반적으로 스타트 업 창립자, CEO, GM 또는 CRO와 같은 강력한 개인은 경험과 직관을 사용하여 제품 로드맵에 영향을 미치고이를 조직 전체에 적용하여 로드맵에 실패합니다. 제품 리더로서이 사람의 직관이나 권력을 아무리 잘 알고 있더라도 로드맵을 지시하지 않는 것이 매우 중요합니다.
참고 :
  • 직관이 잘못되어 시장에 대한 결함이 있거나 비현실적인 가정을 기반으로 한 로드맵이 남을 수 있습니다.
  • 의사 결정 과정에서 이해 관계자의 참여가 적 으면 정렬이 부족해집니다. 사람들이 그것을지지하지 않거나 더 나쁘게하지 않을 것
  • 프로젝트 선택에 밑줄을 긋는 사고에 대해 이해 관계자에게 문의하십시오. 가설과 제안의 이유를 자세히 살펴보고 올바른 추론을 바탕으로 작성했는지 확인하십시오.
  • 프로세스에 다른 제품 이해 관계자를 포함시키는 것의 중요성에 대해 개인을 교육하십시오. 의견을 구하고 통합 할 경우 이해 관계자가 계획을 수립하고 적극적으로 지원할 가능성이 높다는 사실을 알리십시오.

— 대상 이해 관계자

로드맵을 작성하는 주요 파트너 또는 이해 관계자는 다음과 같습니다.
  • 직속 비즈니스 리더, 해당 부서의 CEO 또는 총괄 책임자. 비즈니스 리더는 직원 수와 같은 리소스를 할당합니다. 로드맵 개발의 모든 단계에서 완전한 소유권을 느껴야합니다.
  • 제품 로드맵을 기반으로 영업 목표를 달성해야하기 때문에 영업 VP 또는 최고 영업 책임자와 같은 영업 리더
  • 이정표를 제공하기 위해 제품 팀을 구성하고 동기를 부여하는 제품 개발 리더. 많은 회사에서 이것은 CTO 또는 엔지니어링 부사장이 될 것입니다.
프로세스에 다른 이해 관계자를 포함시키는 것도 유용 할 수 있습니다. 예를 들어, Uber 또는 Deliveroo와 같은 회사에서 주로 비즈니스를 기반으로하는 회사에서는 COO (최고 운영 책임자) 또는 고객 서비스 VP가이 프로세스에 가치가 있습니다. 그러나 당신이 포함하기로 선택한 사람은 그들이 프로세스를 추가하고 방해하지 않도록해야합니다.

— 건전한 제품 전략(product strategy) 개발

고객 지식은 제품 관리자의 기본 통화입니다. PM이 고객과 시장에 대해 더 많이 알수록 특정 제품 개발 옵션의 영향에 대해 권위적으로 이야기 할 수 있습니다.
고객에 대한 깊은 이해를 통해서만 제품 로드맵이 비즈니스 목표를 달성하기위한 의도 된 영향을 미치게됩니다. 사용자를 더 잘 이해하려면 회사는 고객 통찰력과 연구를 수집하고 포괄적이고 세부적인 지향적 제품 전략(product strategy)을 세우는 데 투자해야합니다. 고객 조사에서 다음 옵션을 고려하십시오.
  • 현재 사용 가능한 사용자 통계 검토
  • 새로운 연구 프로젝트 시작
  • 설문 조사를 설계하고 대상 고객의 작은 샘플에서 실행
  • 영업 또는 고객 서비스 회의에 참여
  • 개인 전화 나 이메일을 통해 소수의 고객에게 직접 연락하고 탐색 또는 'open-ended'인터뷰
회사의 전략에 대해 알지 못하면 제품 로드맵의 품질을 평가할 수 없습니다. 따라서 로드맵 개발의 첫 번째 단계는 제품 전략(product strategy)을 명확하게 설명하는 것입니다. 제품 전략(product strategy)은 회사 또는 비즈니스 단위가 제품으로 비즈니스 목표를 달성하려는 방식에 대한 설명입니다. 올바른 제품 전략(product strategy)을 만들려면 다음과 같은 질문을하십시오.
  • 사업 목표는 무엇입니까? 그리고 어떻게 성공을 측정 할 것입니까?
  • 당신의 목표 고객은 누구입니까? 어떤 고객이 실제로 이기고 싶어합니까? 목표 고객의 핵심 요구 사항은 무엇이라고 생각하십니까? 귀사의 제품이 이러한 대상 고객에게 제공하는 주요 이점은 무엇입니까?
  • 제품의 주요 경쟁 업체는 무엇입니까? 고객에게 다른 옵션이 있습니까?
  • 귀사의 제품과 경쟁 제품의 주요 차이점은 무엇입니까?
제품 전략(product strategy)을 명확하게 설명하면 편견없는 피드백을주는 것이 더 편하고 피드백을 통합 한 후 모든 사람이 전략을 논의하고 동의하는 그룹 회의를 갖는 일대일 회의로 시작하여 각 제품 이해 관계자와 논의하십시오. 합의가 없으면 제품 전략(product strategy)으로 돌아가서 다시 작업해야합니다. 제품 전략(product strategy)을 수립하고 주요 제품 이해 관계자를 중심으로 로드맵을 구축 할 차례입니다.

II. 컨센서스 개발 및 추진

— 주요 이정표 식별 및 우선 순위 지정
presentation
마일스톤 정의는 제품 로드맵 작성에서 가장 창의적인 부분이됩니다. 특정 제품 전략(product strategy)을 이해 관계자 팀과 조정 한 후에는 전략을 가장 잘 구현하는 일련의 이정표를 식별 할 차례입니다.
  • 제품 전략(product strategy)을 평가하여 시작하십시오. 성공의 장벽은 무엇입니까? 제품을 약간 변경하여 어떤 장벽을 제거하거나 개선 할 수 있습니까?
  • 고객 여정, 고객이 제품 사용을 선택할 때 내리는 결정을 이해합니다. 타겟 고객이 귀하의 제품을 채택하지 못하게하는 장애물은 무엇입니까? 전략적 목표에 원하는 영향을 미칠 것으로 예상되는 주요 제품 변경 사항에 유의하십시오.
  • 올바른 세부 수준의 사물에 대해 생각하고 있는지 확인하십시오. 중요 시점은 상당한 양의 연구, 디자인 및 개발 작업이 필요하고 백 로그의 수십 가지 작업에 해당하는 주요 제품 변경이어야합니다.
  • 각 이정표를 근거로하는 전략적 목표 및 이론적 근거와 연관 시키십시오. 근거는 수준이 높고 따라 가기 쉬워야합니다.
  • 대략적인 순서로 마일스톤 우선 순위 지정
  • 이정표를 스스로 브레인 스토밍하기 위해 최선을 다한 후에는 각 제품 이해 관계자와 만나 그들이 놓친 부분에 대해 생각할 수 있는지 확인하는 것이 좋습니다. 그룹 회의를 열기 전에 각 이해 관계자를 일대일로 만나십시오.
  • 각 회의가 시작될 때 제품 전략(product strategy)을 검토 한 다음 해당 전략을 가장 잘 뒷받침 할 이정표에 대한 아이디어를 요청하십시오.
  • 아이디어를 모두 익힌 후에는 수집 한 다른 모든 이정표를 검토하고 우선 순위뿐만 아니라 피드백을 요청하십시오.
이 프로세스가 끝나면 일련의 제품 이정표로 끝나야합니다. 각 단계는 전략적 목표 중 하나에 상당한 영향을 미치고 함께 제품 전략(product strategy)을 구현할 것입니다.

— 평가 노력

평가 노력은 로드맵에 가능한 한 현실적인 날짜를 표시하는 데 도움이됩니다. 이를 위해서는 제품 개발 팀과 협력해야합니다.
  • 개발 팀의 용량 및 제품 개발에 할당 할 수있는 양에 대한 현실적인 추정치를 수집하십시오. 일반적인 제품 개발 팀의 시간은 버그 수정, 제품 유지 관리, 새로운 기능 개발 및 엔지니어링 프로젝트에 소비됩니다.
  • 일반적으로 개발자 일, 개발자 주 또는 개발자 개월과 같은 개발자 시간 단위로 측정되는 사용 가능한 개발 시간 용량을 알면 각 이정표가 소요될 가능성이있는 개발 시간을 추정하십시오.
참고 :이 단계에서는 개발 팀에 추정치에 전념하도록 요구하지 않으므로 아직 압력이 없습니다.
참고 : 범위를 지정한 후 일부 이정표가 너무 작은 경우 전략의 일부 요소를 지원하는 더 큰 이정표로 그룹화 할 수 있습니다. 그리고 일부가 너무 큰 경우에는 작은 규모로 분해하고 각각이 유효한 비즈니스 영향을 미치도록하십시오.
이 단계를 완료 한 후에는 팀이 완료하기에 현실적인 이정표가있는 제품 로드맵을 작성하기에 충분한 정보가 포함 된 스프레드 시트가 있어야합니다.

— 첫 번째 초안 공유

제품 로드맵의 첫 번째 버전 또는 첫 번째 초안은 팀의 승인을 받기 전에 변경 될 수 있습니다. 생산적인 토론을 할 가능성이 높으므로 팀과 만나기 전에 초안을 작성하는 것이 좋습니다. 회의에서 :
  • 제품 전략(product strategy) 지원에 미치는 영향 측면에서 마일스톤을 시퀀싱하십시오. 한 번에 하나씩 살펴보고 각각의 이론적 근거를 상기시키고 우선 순위를 정하십시오.
  • 로드맵에 이정표를 예약하십시오. 우선 순위가 가장 높은 첫 번째 이정표를보십시오. 제품 개발 리더가 제공 한 노력 추정량과 팀의 개발 능력을 사용하여 달력에서 언제 제공 될 것으로 예상되는지 파악하십시오. 그런 다음 두 번째 우선 순위가 높은 마일스톤을 선택하고 첫 번째 마일스톤이 정시에 완료되었다고 가정 할 때 동일한 방식으로 스케줄하십시오.
  • 다음 4 분기와 같은 미래의 기간을 살펴보십시오. 첫 번째 기간에 함께 완료 할 수있는 우선 순위가 높은 이정표와 두 번째 기간에 대한 우선 순위가 낮은 이정표 등을 식별하십시오.
대규모 제품 개발 프로젝트에서는 여러 개발 팀이 병렬로 다른 제품을 사용하게 될 것입니다.
  • 팀이 서로 다른 제품 또는 고객을 중심으로 구성되어있는 경우 각 팀마다 별도의 이정표가있을 수 있으므로 별도로 예약해야합니다.
  • 팀이 기능적으로 구성되어 각 팀이 프런트 엔드 팀 및 백 엔드 팀과 같은 다른 구성 요소를 소유하도록하려면 각 팀에 필요한 역량과 노력을 별도로 파악해야합니다. 또한 각 팀이 예정된 시간에 이정표를 완료하는 데 충분한 역량을 갖추면서 최종 제품을 담당 업무 부서에 전달할 수 있도록 이정표를 예약해야합니다.
완료되고 일정이 완료되면 몇 가지 관점에서 정확한 검사를 실행하십시오.
  • 그것이 당신의 제품 전략(product strategy)을 구현하는지 스스로에게 물어보십시오. 제품 전략(product strategy)에 미치는 영향을 최대화하도록 조정하십시오.
  • 스스로에게 물어보십시오. 그것은 개발 자원 관점에서 가능합니까? 개발 리더가 다시 실행하고 필요한 것으로 조정하십시오.
  • 잘 되었다고 생각되면 나머지 팀원들과 공유하십시오.

— The buy-in meeting

presentation
대부분의 제품 이해 관계자를 직접 관리하고 참여를 요청할 권한이 있으므로 비즈니스 리더와 긴밀히 협력하여이 회의를 계획하고 운영하고 싶을 것입니다.
  • 회의가 시작될 때 목표를 설명하십시오. 모든 이해 관계자가 자신의 계획에 완벽하게 지원하고 사용할 수있는 공유 제품 로드맵으로 등장합니다.
  • 제품 전략(product strategy)을 빠르게 검토하십시오. 이것이 기본이며 로드맵은 전략을 구현하도록 설계되어야한다고 설명합니다. 지금까지 팀을 전략에 맞게 조정해야합니다.
  • 팀의 개발 능력을 검토하십시오. 개발 책임자에게 팀의 역량을 소개하고 신제품 개발 이외의 작업에 시간을 어떻게 소비하는지 설명하십시오.
  • 첫 번째 초안을 연습하십시오. 전략적 목표뿐만 아니라 한 번에 하나씩 이정표를 제시하십시오. 사람들이 고려중인 모든 것을 알 수 있도록 변경하기 전에 모든 이정표를 살펴보십시오.
  • 팀원들에게 그들이 원하는 것이 무엇인지 물어보십시오. 이 단계에서 로드맵에 대한 다양한 의견을 듣는 것이 중요합니다. 이것이 비즈니스가 직면 한 중요한 문제를 해결하는 방법입니다.
  • 모든 사람이 결과를 볼 수 있도록 회의에서 제품 로드맵을 직접 수정하십시오. 생생하고 시각적으로 공식화 된 스프레드 시트를 사용하십시오. 팀에게 그들이 내리고있는 결정의 균형을 보여주십시오. 때때로 이것은 팀 구성원 간의 협상 또는 거래로 이어질 수 있습니다.
  • 그룹에게 더 큰 이익에 대한 합의를 구축하기 위해 자신의 이익보다는 사업의 성공에 대해 생각해 보라고한다.
  • 전체 팀이 최종 결정과와 일치하는지 확인하십시오. 또한 최종 결정을 내리고 나머지 팀과의 일치 여부를 확인하는 것은 비즈니스 리더의 책임입니다.
  • 회의가 끝날 때까지 합의점에 도달하지 않은 경우 후속 세션을 예약하여 프로세스를 재개하십시오.
  • 회의가 끝날 때마다 모든 사람은 수정 된 제품 로드맵을 가지고 공개적으로 지원하기로 합의했습니다.

III. 일반적인 과제에 대한 간단한 솔루션

— 로드맵을 더 많은 이해 관계자에게 푸시
주요 제품 이해 관계자가 검토하고 승인 한 로드맵을 확보 한 후에는 미팅에 참여하지 않았지만 로드맵을 지원하고 앞으로 사용해야하는 사람들 사이에 로드맵을 작성해야합니다.
  • 제품 로드맵의 핵심 요소 및 결정 사항과 그 근거를 제시하는 간단한 프레젠테이션을 작성하십시오. 제품 전략(product strategy), 최상위 비즈니스 목표, 대상 고객 및 고객을 이길 방법에 대한 슬라이드로 시작하십시오.
  • 하나의 중요한 프로젝트를 다른 프로젝트보다 선호해야하는 각 주요 결정마다 하나씩, 제품 로드맵 다이어그램과 몇 가지 근거 슬라이드가 포함됩니다.
  • 영향을받을 수 있지만 운영 리더, 고객 서비스, 기술 지원, 재무, 로드맵, 법률 등과 같은 로드맵 개발 프로세스에는 참여하지 않은 제품 이해 관계자에게 새로운 로드맵을 제시하는 일련의 일대일 미팅을 예약하십시오.
  • 이 일대일 세션이 끝날 때마다 정렬을 다시 확인해야합니다. 의사 결정 팀이 놓친 주요 문제가 있으면 그룹 전체로 다시 제기해야합니다.
  • 일대일 회의가 모두 완료되고 이해 관계자가 조정되면 전체 회사 또는 사업부에 로드맵을 적용하여 영향을 미칩니다.
  • 팀 노력의 결과로 항상 제품 로드맵을 제시하십시오. ‘우리의 로드맵이며 결정했습니다.’

— 로드맵 보호 및 업데이트

제품 로드맵은 동적 문서입니다. 그들은 특정 시점에서 조직의 개발 계획을 나타내며 특정 시점에서 사용 가능한 최상의 정보를 기반으로합니다. 고객 또는 시장에 대한 새로운 정보를 기반으로 고객을 업데이트해야합니다.
로드맵을 변경시킬 수있는 몇 가지 유형의 정보가있을 수 있습니다.
  • 고객 요구와 욕구 변화
  • 경쟁사에 대한 정보
  • 제품 개발 시간 또는 비용
  • 내부 요청, 때로는 팀원이 로드맵 변경을 요청할 수 있습니다. 이러한 경우에는 변경 이유로 배운 새로운 정보를 이해하는 것이 중요합니다
  • 제품이 수명주기의 초기 단계 인 경우 항상 새로운 정보를 배우는 것이므로 로드맵이 매우 자주 변경 될 수 있습니다.

IV. 요약하자면…

  • 고객의 요구와 제품에 대한 고객의 생각을 깊이 이해해야합니다.
  • 주요 제품 이해 관계자가 누구인지 파악하고 모든 사람들이 제품 전략(product strategy)에 맞게 전략 회의를 예약하십시오.
  • 로드맵의 첫 번째 초안을 작성하고, 전략을 가장 잘 구현할 이정표를 식별하고, 주요 이해 관계자에게 범위를 지정하고, 현실적인 일정을 도출하고, 공유하고 필요한 '구매 및 승인'을 얻습니다.
  • 회사의 다른 부서와 공유
  • 시장과 비즈니스의 기본 추진 가정을 지속적으로 검토하여 로드맵을 적절하게 유지

이 글은 번역 글입니다. 원본 링크입니다.


안녕하세요! Early adopter입니다.
페이스북 [DTF] 디자인 번역 공장 - Design Translation Factory 그룹도 많이 가입해주시길 바랍니다.
"보버"에서 "디자인 번역 공장" 연재를 저와 함께 해주실 분을 찾습니다. 하단 "리뷰" 또는 "페이스북"으로 편하게 메시지 주세요!
PS. 제가 사용하는 블로그 "보버"에 "함께 쓰는 블로그"라는 기능이 요번에 추가됐네요 ㅋ (미디엄에 퍼블리케이션 같은 기능..)
하단 링크 글을 보시면 "디자인 번역 공장"에 어떻게 함께 연재할 수 있는지 자세히 설명되어있습니다. 또는 쉽게 FB 메시지 주세요!
https://bit.ly/2LxR0Bz