제품 관리 직책이 높을수록 제품 포트폴리오 관리에 대한 필요성이 커집니다. 이는 여러 제품 라인 또는 이니셔티브가 동시에 구축, 개선 또는 유지되고 있고 계획 및 활동이 제품 목표와 일치하도록 프로세스를 쿼터백하는 경우에 발생합니다.

대부분의 경우 주요 제품 포트폴리오 관리는 대기업에서 이루어집니다. 즉, 이러한 대규모 회사 프로세스는 일반적으로 리소스를 대규모로 적용하고 일반적으로 더 넓은 범위의 제품 제공으로 인해 작동합니다. 대규모 제품(또는 프로젝트) 포트폴리오를 관리해야 하는 경우 일정 수준의 일관되고 광범위한 커뮤니케이션을 보장하는 것이 훨씬 더 어렵습니다. 그러나 규모가 작은 기업도 프레임워크와 프로세스를 통해 제품을 빠르고 효율적으로 출시할 수 있으며 일정 수준의 일관된 커뮤니케이션이 필요합니다.

대기업과 소기업 모두 "날짜 및 관문"을 충족하면서 제품을 구축하고, 커뮤니케이션하고, 더 많은 기술적 측면을 "비즈니스 대화"로 변환하기 위한 프레임워크가 필요합니다. 이러한 측면은 애자일, SCRUM 또는 폭포수 방법론을 사용하는지 여부에 관계없이 제품 출시 또는 향상의 성공에 매우 중요합니다. 결국, 모든 제품 개발 수명 주기에 대한 예상 수익이 있는 투자가 있으며 회사와 이사회는 해당 투자가 어디에 있는지 알 권리가 있습니다!

소규모/성장/혁신 중심 기업에 대한 성향을 감안할 때 대기업에서 몇 년 동안 배운 모범 사례와 프로세스 중 일부를 소규모 기업에서 일하도록 조정했습니다. 전직 CMO 동료가 최근에 회사의 제품 조직을 돕기 위해 이 프레임워크를 보내달라고 요청했습니다.

내가 사용하는 시스템은 RAPIDS 라고 부릅니다 . 모든 엔지니어는 이 시스템이 일반적인 SDLC와 유사하다는 것을 알게 될 것이며 이전에 이 작업을 수행한 사람은 대기업에서 사용했던 것과 일부 중복되는 것을 볼 수 있습니다. 제품이 처음부터 프로토타입, 출시, 나머지 제품 라이프사이클에 이르는 과정을 명확하게 보여줍니다.

이정표/단계는 다음과 같습니다.

RA= 연구 및 분석

P= 계획

I= 구현

D= 배송

S= 안정화

이 니모닉 도구 및 프로세스는 시작 제품 세트에 이르기까지 연간 계획 및 예산 주기가 있는 거대한 제품 포트폴리오에 대해 동일하게 확장됩니다. 주요 차이점은 1) 플레이북을 이해하는 데 필요한 사람의 수와 2) 단계에서 단계로 진행되는 속도입니다.

확장되는 이유는 다음과 같은 중요한 정보를 항상 공유해야 하기 때문입니다.

1. 이 제품에 얼마를 투자하고 있습니까?
2. 완료될 때까지 얼마나 걸립니까?
3. 고전적인 "아직 거기에 있습니까?" 질문…
4. 제품의 성공을 나타내는 지표는 무엇입니까?
5. 이 솔루션을 어떻게 수익화할 것인가?

RA= 연구 및 분석

• 목표: 제품/이니셔티브의 진행/진행 불가
• 타임라인: 목표는 일/주입니다.
• 답변된 주요 질문:
  - 시장 기회/비즈니스 사례 식별
  - 이상적인 고객 프로필(ICP)
  - 초기 제품 또는 기능 세트 가정
  - 초기 제품 또는 KPI 지표 가정
  - 관련 공급업체 가정
  - 핵심 서비스/플랫폼 가정(기존 플랫폼을 구축하는 경우)

1-페이저

한 페이지는 다음을 포함하는 각 이니셔티브에 대한 간략한 설명입니다.

• 기회/문제 설명 - 이니셔티브가 해결하는 것, 이상적인 고객 프로필 및 예상 분포에 대한 요약
• 범위 - 주요 가정 및 이니셔티브가 달성하지 못하는 것. 후자가 핵심입니다. 아마도 이것은 단계적 접근 방식이거나 MVP 일 것입니다.
• From → To - 현재와 미래의 수익률을 보여주는 간단한 방법입니다. 여기에 비즈니스 사례의 성공 메트릭을 포함할 수 있습니다.
• 가정 : 필요한 공급업체/파트너, 필요한 시간, 기타 이니셔티브 또는 리소스 종속성
• 노력/영향 - 이것은 비즈니스 결과에 큰 영향을 미칠 수 있는 수행해야 할 노력이 적은 항목이 있는지 확인하는 빠른 방법입니다("낮은 열매" 항목).

참고- 이 단계가 스프레드시트를 사용하여 비공식적으로 수행되는 것을 보았습니다. 나는 그것을 신경 쓰지 않지만 궁극적으로 이 정보를 더 광범위하게 공유해야 한다는 것을 기억하십시오. 따라서 일종의 슬라이드 공유 도구를 사용하여 1페이지 분량의 문서를 작성할 수도 있습니다.

P= 계획

• 목표: 요구 사항, 비용, 일정 식별 및 범위 지정
• 일정: 주/월
• 답변된 주요 질문:
  - 제품 에픽 및 프로토타이핑
  - 주요 UX 워크플로 개발
  - 공급업체 선택 및 심사(필요한 경우)
  - 핵심 서비스/플랫폼 검토(필요한 경우)
  - 비즈니스 사례 마무리
  - 초기 운영 및 내부 검토

모든 DIY 주택 개조 유형이 이해하는 이 단계에 대한 나의 진언은 "두 번 측정하고 한 번 자르십시오."입니다.

이 단계는 팀의 제품 담당자로서 빛을 발해야 하는 단계입니다. 다음 단계는 조직의 다른 부분으로 책임을 이전하는 단계이므로 제품 및 시장에 대한 지식을 보여줄 수 있는 능력을 가지고 계획 단계를 종료해야 합니다.

마지막으로 진행 상황과 계획에 대해 내부적으로 공식적으로 소통하기 시작하는 곳입니다. 운영 및 지원 팀, 재무 팀, 법무 및 규정 준수 팀(필요한 경우)의 보다 까다로운 질문에 답할 수 있는 충분한 정보가 있습니다. 지금은 연필을 깎고 도전적인 가정으로 돌아가야 할 때입니다. 이 단계가 끝날 때 비즈니스의 모든 측면에서 초록불 합의가 있을 것으로 기대하기 때문입니다. 또한 이 단계에서 업데이트된 정보로 1페이지를 업데이트할 계획을 세우십시오.

로드맵을 구축하고 전달하는 방법에 따라 PLAN 단계에 도달하는 항목은 가동 날짜와 유사한 로드맵에 있어야 합니다.

I= 구현

• 목표: 제품 배송을 위한 빌드 및 준비
• 타임라인 : 일반적으로 주/월
• 답변된 주요 질문:
  - 소프트웨어 개발
  - UX 마무리
  - 알파/베타 릴리스
  - 초기 운영 및 내부 검토
  - 시장 출시 시작

이 단계의 타임라인은 몇 주 또는 몇 달이 될 수 있습니다. 그럼에도 불구하고 Go-To-Market 프로세스를 아직 시작하지 않은 경우 여기에서 마케팅 또는 제품 마케팅이 훨씬 더 많이 관여하게 됩니다. 제품 담당자로서 이 단계의 대부분은 엔지니어링에 의해 수행되는 작업이므로 다른 많은 다기능 업무를 수행할 수 있습니다.

D= 배송

• 목표: 제품이 원활하게 시장에 출시되도록 보장
• 일정 : 일반적으로 몇 주
• 주요 질문 답변/완료 항목:
  - 고객 계약 요구 사항 확정
  - 내부 교육 및 자료
  - 영업 및 마케팅 교육
  - 최종 운영 및 내부 검토

이 단계의 대부분은 특히 영업 및 마케팅에 일을 넘길 수 있는 단계입니다. 해결하려는 문제에 대한 흥분을 공유할 수 있는 기회가 있으므로 가능한 한 많은 외부 회의에 참석하고 싶을 것입니다! 그러나 추가할 다음 보조 기능 세트를 찾고 싶기 때문에 잠재 고객의 단서를 듣고 있는지 확인하십시오.

S= 안정화

• 목표: 제품이 안정적인지 확인하고 다음 기능 세트에서 반복
• 타임라인 : 일반적으로 몇 개월
• 답변된 주요 질문/성취된 항목:
  - 지표 및 측정
  - 제품 버전 관리, 업그레이드, 새로운 기능
  - 사후 검토

여기에서 측정해야 할 또 다른 주요 측면은 고객 서비스 비용입니다. 초기 비즈니스 사례는 필요한 고객 서비스 에이전트 수, 플랫폼 비용 및 지속적인 유지 관리 비용에 대해 가정했을 가능성이 큽니다. 제품의 수익성을 진정으로 결정하므로 여기에서 이를 분석하는 것을 잊지 마십시오.

회사의 규모에 따라 제품이 한동안 이 단계에 있으면 유지 관리 모드 또는 간헐적인 업데이트 모드로 전환되어 반년 정도에 기능이 추가될 수 있습니다. 이 경우 일반적으로 팀의 PM에게 전달하거나 이 단계에 도달하는 제품을 관리하는 그룹이 있을 수 있습니다.

여울

작은 회사에서 나는 1-페이지를 사용했고 특히 우리가 회사로서 목표를 세웠을 때 1~2주 안에 RA에서 P로 물건을 가져왔습니다. 즉, 이에 대한 프레임워크가 있어도 회사의 모든 사람이 이해할 수 있도록 대화가 정상화됩니다. 또한 예를 들어 Ops 팀을 위해 무언가를 추가해야 하는 경우 이제 이를 위한 장소가 있음을 의미합니다.

요약하면 이 도구는 다양한 규모와 복잡성 수준의 회사에 매우 유용했습니다. 회사 규모에 맞게 세부 수준과 단계별 이동 시기를 변경했지만 사용할 기본 프레임워크가 있어 즐거웠습니다.

유사하거나 아마도 크게 다른 많은 다른 프레임워크가 있다고 확신합니다. 나에게 그것은 당신이 알고 있는 케이크 레시피가 항상 놀라운 맛으로 판명되는 것과 같지만 때로는 시간, 맛 또는 욕구를 위해 그것을 조정하고 싶을 때가 있습니다!