제품 수명 주기: 제품 기능의 여정

이것은 제품 지망자가 제품 관리의 세계에 들어갈 수 있도록 돕기 위해 작성하는 5부작 시리즈의 네 번째 게시물입니다.

지난 게시물 에서 저는 제품 관리 지망자가 회사 내에서 또는 일반적으로 자신의 경력 궤적을 이해하도록 돕기 위해 제품 관리 분야를 네 부분으로 분류했습니다. 이 게시물에서 저는 제품 관리 지망자가 제품 관리자의 역할에 대해 360도 관점을 갖도록 돕기 위해 아이디어 구상에서 포기까지 제품 기능의 삶의 여정에 대해 이야기할 것입니다.

T – 30일

필요는 발명의 어머니라는 말이 있다. 말 그대로 제품 기능의 탄생이 관련된 경우입니다. 모든 것은 어느 정도의 불편함에서 시작됩니다.
회사의 일부 직원은 일상적인 작업 중 하나를 수행하는 데 불편함을 겪고 있습니다. 사용자 기반이 증가하여 이전 프로세스로 이를 관리할 수 없을 수도 있습니다. 회사의 일부 임원은 엑셀 시트를 보고 많은 수의 제품 취소로 인해 회사가 너무 많은 손실을 보고 있다고 생각합니다. 또는 경쟁업체가 고객이 해당 회사의 제품을 떠나도록 하는 제품 기능을 출시했을 수도 있습니다. 마케팅 전환 유입경로를 보고 있는 누군가는 특정 단계에서 높은 하락을 발견했고 최적화가 분기별 목표를 달성하는 데 도움이 될 수 있다고 느꼈습니다. 또는 일반적인 문제에 대한 많은 고객 불만에서부터 지난 주에 설문조사에 참여한 대다수의 사용자가 요구하는 새로운 기능에 이르기까지 100가지 다른 이유가 있을 수 있습니다. 요점은 – 모든 것이 어느 정도의 불편함에서 시작된다는 것입니다.

이제 이 불편함을 제품 관리자에게 알립니다. 또는 제품 관리자가 이를 가장 먼저 알아차리는 사람일 수도 있습니다. 이것은 새로운 기능의 탄생으로 이어질 수 있는 일련의 이벤트를 시작하는 지점입니다.

T – 25일

이제 제품 관리자가 문제 설명을 곰곰이 생각해 볼 시간입니다. 불편함을 보고한 고객이나 내부 이해관계자, 그리고 실제로 경험한 사람들에게 직접 찾아가 이야기를 나눈다. 그가 '근본' 문제 진술을 식별했는지 확인하는 단일 목표로 이 모든 것을 수행했습니다. 이 단계를 가볍게 여기거나 제품 관리자가 이에 충분한 시간을 할애하지 않으면 태어난 제품 기능은 깨지기 쉽고 왜곡되어 매우 빨리 끝납니다.
제품 관리자가 핵심 문제 설명을 식별하면 해결할 가치가 있는지 결정합니다. 그 불편함은 정말로 큰 것입니까, 아니면 과장된 것입니까, 아니면 그냥 꾸며낸 것입니까? 이 문제를 해결하면 실제로 고객 및/또는 회사에 상당한 가치를 추가할 수 있습니까? 이를 해결하지 않으면 고객 및/또는 회사에 상당한 불이익이 부과됩니까? 프로세스를 약간 수정하거나 제품 변경이 필요하지 않은 활동을 통해 이 문제를 해결할 수 있는 방법이 있습니까? 추가 직원, 콘텐츠, 그래픽, 클릭 유도문안 버튼 등의 변경 사항이 있습니까?

기본적으로 제품 변경을 포함하지 않는 방법에서 유사한 부가가치를 얻을 수 있는 방법이 있다면 추가 또는 제거를 의미하는 제품의 모든 것을 변경하는 것보다 그 방법을 택할 것입니다. 제품 관리자가 문제 설명을 해결하는 것이 상당한 가치를 제공하고 제품 수준 변경이 비제품 수준 변경보다 훨씬 더 많은 ROI(시간, 비용 및 노력 대 가치 고려)를 제공한다고 확신하면 새로운 제품의 특징이 심어집니다.

T – 15일

제품 관리자가 사전 경험이 있는 경우 해당 경험을 기반으로 솔루션을 제안할 수 있습니다. 그러나 그것이 모든 경우에 최선의 해결책은 아닐 수도 있습니다.
문제 설명에 고도로 기술적인 솔루션이 필요한 경우 제품 관리자는 개발자 및 엔지니어링 관리자와 동일한 내용을 논의하고 최선의 방법에 대한 조언을 받습니다. 솔루션에 설계 수준 변경이 필요한 경우 UX 리드와 상의할 수 있습니다. Product Manager와 UX 담당자가 디자인 스프린트를 구성하고 해당 기능의 실제 사용자에게 좋은 솔루션을 선택했을 수 있습니다. 때로는 문제가 완전히 비즈니스와 관련되어 고위 경영진의 동의가 필요합니다.
따라서 솔루션을 마무리할 수 있는 여러 가지 방법이 있을 수 있습니다. 그러나 일단 그렇게 되면 제품 관리자는 그 이론적인 솔루션을 활성 제품 기능으로 변환할 책임이 있습니다.

T = 0(제품 기능의 탄생이라고도 함)

특정 솔루션이 식별되면 제품 관리자가 관련 팀과 협력하여 솔루션의 기본 개요를 설명합니다. 솔루션의 프로토타입을 포함하거나 포함하지 않을 수 있습니다. 때로는 사용자에게 특정 CTA를 표시할 때 등을 위해 작성된 'if-then' 조건이 있는 기본 Excel 시트일 때도 있습니다.
제품 관리자는 관련 PRD(제품 요구 사항 문서)에 솔루션을 설명합니다. 기능이 작은 경우 더 큰 기능에 대한 기존 PRD의 단락일 수 있습니다. 때로는 기능이 너무 커서 제대로 자세히 설명하기 위해 완전한 PRD가 필요합니다. PRD는 관련 팀에서 운영하며 제품 관리자는 해당 기능에 대해 광범위한 합의가 있는지 확인합니다.

T + 15일

작은 기능이 고정되는 데 하루 미만이 소요될 수 있습니다. 큰 기능의 경우 모든 사람이 작업을 진행하는 데 30일 이상이 소요되는 경우가 있습니다.
개발자들에게 새로운 기능을 소개하는 시간이라고 하기까지 평균 15일이 소요된다고 가정해 보겠습니다. 프로젝트에서 작업하는 개발자에게 5W(What, Why, When, Where, Who) 및 테스트 케이스(기능이 릴리스된 후 작동해야 하거나 작동하지 않아야 하는 방식)에 대해 알려주는 적절한 설계 및 PRD 핸드오버가 발생합니다. .
엔지니어링 관리자와 함께 기능에 대한 적절한 릴리스 일정이 결정되며, 개발 종료 시점, 테스트 시작 시점, 보고된 버그 수정 시점 및 최종 출시 날짜가 마감됩니다. 그런 다음 전체 타임라인을 측정 가능한 스프린트로 나눕니다(보통 15일). 개발자가 만족하면 개발이 시작됩니다.

T + 30일

스프린트 1이 종료됩니다. 제품 기능의 일부가 롤아웃됩니다. 아직 고객을 대면하지 않을 수도 있지만 오늘날 대부분의 팀은 소프트웨어 개발을 위해 애자일 방법론을 따릅니다 . 즉, 점진적이고 반복적으로 빌드합니다. 따라서 6개월 만에 큰 기능을 구축하고 한 번에 모두 릴리스하는 대신, 자체적으로 작동할 수 있고 신속하게 검토 및 반복할 수 있는 독립적인 부분(일련의 사용자 스토리)으로 전체를 나눕니다.
제품 관리자는 일일 스크럼 회의와 프로젝트에서 작업하는 관련 엔지니어링 관리자와의 토론을 통해 릴리스 일정이 제대로 진행되고 있는지 확인합니다. 지연이 있는 경우 그에 따라 타임라인이 조정되거나 릴리스가 정시에 이루어지도록 기능의 작은 부분이 삭제됩니다. 각 스프린트 후에 진행 상황은 회의에서 제품 관리자 및 관련 이해 관계자에게 제공되고 승인 후 릴리스됩니다.
UpGrad의 제품 관리 프로그램 1년

T + x일

'n'번의 스프린트 후에 개발이 완료되고 전체 기능이 종료됩니다. 고객이 완전히 릴리스된 경우에만 이 기능을 사용할 필요는 없습니다. 그들은 스프린트 1 자체가 끝날 때 릴리스 이후로 사용할 수 있습니다. 각 후속 스프린트 주기 릴리스는 기능을 더욱 강력하게 만들고 의도한 것에 더 가깝게 만듭니다.
기능을 시작하는 것은 그 자체로 예술이며 우리가 건너뛸 많은 단계를 포함하고, 많은 드럼 연주와 가슴 두근거리는 후에 기능이 출시되었다는 것이 세상에 선언되었다고 가정합니다. 이것은 CEO 자신이 새로운 출시에 대해 이야기하는 본격적인 보도 자료만큼 복잡할 수도 있고, 기능을 사용할 특정 부서에 메일을 보내고 아마도 다음에서 요청했을 수도 있습니다. 첫 번째 장소. 이제 기능이 출시되었으므로 이 기능에 Mr. Feature라는 이름을 지정하겠습니다.

T + y일

최종 릴리스 후에도 가끔 문제가 발생합니다. 한때 빛나고 귀한 존재였던 Mr. Feature는 더 이상 예전 같지 않을 수 있으며, 여기에는 여러 가지 이유가 있을 수 있습니다. 제품 주기의 이 단계는 제품을 지원하는 단계입니다. 어느 좋은 날 Mr. Feature가 의도하지 않은 방식으로 수행되도록 하는(일명 버그가 됨) 또 다른 릴리스가 만들어졌거나 Mr. Feature에 일부 종속성이 있는 다른 기능이 제거되어 버그가 발생했습니다. 기능이 만들어졌을 때 우리가 그것을 사용할 사용자의 수를 과소평가했거나 모든 사용 사례를 계획하지 않았기 때문에 이제 기능을 이러한 많은 사용자 또는 사용 사례로 확장할 수 없을 수도 있습니다.

이것은 테스트 팀이 정기 검토에서 보고하거나 기능을 사용하는 동안 방금 발견한 일부 팀원이 보고합니다. 고객 대면 기능의 경우 이러한 불만은 제품의 실제 고객으로부터 올 수 있으며 고객 경험 팀을 통해 제품 관리자에게 전달됩니다.

제품 관리자는 버그의 근본 원인을 이해하려고 시도하고 우선 순위에 따라 다음 릴리스 주기에 대한 수정 일정을 잡습니다. 우선 순위가 높거나 후속 스프린트인 경우 현재 스프린트에 추가될 수 있습니다. 버그가 수정되고 릴리스된 후 Mr. Feature는 제품 관리자와 엔지니어링 팀 덕분에 개선된 형태인 Mr. Feature 2.0에도 불구하고 또 다른 하루를 보게 됩니다. 명성!

T + Z일

좋은 일은 다 끝나야 한다는 말이 있다. 슬프게도 Mr. Feature도 버전에 상관없이 마찬가지입니다. 아마도 Mr. Feature 9.263.75일 것입니다! 즉, Mr. Feature는 길고 행복한 삶을 살았지만 이제 길의 끝이 여기에 있습니다.
다양한 이유 때문일 수 있습니다. Mr. Feature의 필요성을 완전히 불필요하게 만드는 새로운 기능이 제공되었습니다. 회사에서 이 기능이 사용자에게 가치를 더하고 있지만 더 이상 사용자에게 경제적 의미가 없다고 결정한 것처럼 극단적인 것일 수도 있습니다.

이유가 무엇이든, Mr. Feature의 서비스가 더 이상 필요하지 않을 것이라는 것이 제품 관리자(또는 그가 토론을 시작하는 사람)에게 전달됩니다. 이제 가슴 아픈 일이지만 제품 관리자는 피처 씨를 쉬게 할 의무가 있습니다. 그 전에 Mr. Feature를 사용하던 사용자에게 특정 날짜부터 사용할 수 없음을 알리는 것과 같은 몇 가지 사항을 확인해야 하지만, 새로운 기능은 Mr. Feature를 제거하기 전에 잘 작동합니다. Mr. Feature가 사라지면 흐름이 영향을 받습니다.

이제 Mr. Feature에게 RIP를 말할 시간입니다. 제품 관리 경력에서 이 작업을 여러 번 수행해야 합니다. 그러나 한 기능의 끝은 다른 기능의 시작이며 주기는 계속된다는 점을 기억하십시오. 이것이 바로 상품관리 인생이다!

세계 최고의 대학에서 온라인으로 제품 관리 과정 을 공부 하십시오. 석사, 이그 제 큐 티브 PGP 또는 고급 인증 프로그램을 획득하여 경력을 빠르게 추적하십시오.

추천 프로그램: Duke CE의 디자인 사고 인증 프로그램