프로덕트 라이프 사이클 4단계
이번 챕터에서는 프로덕트의 생의 주기. 즉 라이프 사이클과, 프로세스, 프레임워크에 대해 배운다.
기업을 시작하거나 프로덕트를 새로 개발하면 프로덕트 수명 주기를 거친다. 이를 PLC product life cycle 프레임워크라고 한다
1단계 -도입
기업이 프로덕트를 출시 하는 시점. 즉시 구매하는 유저는 얼리어답터 뿐이다.
2단계-성장
시장에서 반응이 생기고 판매 증가. 경쟁력을 갖추기 위한 기능 개선
3단계-성숙
판매가 정점에 도달. 경쟁자 등장. 시장 파이 확대
4단계-쇠퇴
판매 감소. 대체로 모든 프로덕트가 시장에서 단계적으로 퇴출됨. 새로운 기능이나 내용으로 채워 탈바꿈 해야한다
> 오노브의 오프라인 상품은 도입과 성장 사이에 있으며, 온라인은 아직 도입 전에 있다고 봐도 되겠다. 물론 오노브 웹사이트를 통한 참가 신청이 유일한 경로이기 때문에 사용자가 있지만, 리탠션 없는 일회성 사용이기 때문에 큰 의미가 없다. 지속적으로 우리 프로덕트를 사용할 이유가 있는 기능을 개발하고 배포하면 그때가 본격적인 도입 시점이 될 것이다.
프로덕트를 개발하는 일련의 단계를 프로덕트 개발 프로세스 수명 주기 product development process life cycle 이라고 한다. 주요 일곱 단계는 이러하다
1단계 - 연구
리서치, 디스커버리 단계로 사용자 문제를 수집하고 아이디어나 솔루션을 브레인스토밍한다. 만들고자 하는 것이 무엇인지 명확하게 하는 시점으로, 기업 내 직원들, 팀원들이 가장 큰 출처가 된다.
2단계 - 계획
시장조사는 이 단계에서 한다. 1단계에서 논의된 아이디어가 시장에서 통할지 조사한다. 이때 조사는 직접 프로덕트를 시장에 던져 반응을 보는 방법이 있겠고, 아니면 인터뷰나 설문조사로 수요를 파악할 수도 있다. 해당 프로덕트로 수익을 만들 수 있을지 확인하고, 얼마나 오랜 시간이 소요될지, 어떤 시점에 프로덕트의 특정 기능을 배포할 지 등의 전체 로드맵을 작성한다.
3단계-개발
가장 중요하고, 가장 바쁜 단게다. 사용자 스토리를 그려보고 각 동작 사양을 구체화한다. 각 기능 개발에 소요될 시간을 파악한다. 오노브는 필요한 기능을 정성적인 문장 단위로 작성한 후, 개발자에게 명료한 문장으로 치환해 백로그를 쌓는다. 타임라인을 캘린더에 추가하고 기한에 맞춰 백로그를 스프린트로 옮겨 완성해나간다. 모든 과정에서 활발한 커뮤니케이션을 잊지 않으며, MVP minimun viable product 사양은 검정 전까지 변경하지 않는다.
4단계-검증
MVP를 사용하도록 하고 사용자에게 초기 피드백을 받는다. 처음 세웠던 가설, 가정을 검증한다. 이때는 알파나 베타 같은 이름으로 한계를 두고 테스트에 집중한다. 출시 전이다.
5단계- 프로덕트 출시
마케팅팀, 법무팀이 따로 없는 오노브는 검증 단계 후 잘 패키징해 출시하면 된다. 아이폰은 출시를 위한 앱스토어 테스트에서 몇번 떨어질 수도 있다. 심사는 빨리 되는 편이나, 출시일을 공표해두었다면 곤란할 수 있다.
6단계- 극대화
시장 반응에 따라 기능을 개선하고 추가해가며 가치를 극대화한다. 사용자가 프로덕트를 사용하는 방법에 대한 지표를 수집하고 분석한 후, 프로덕트를 최적화해나간다.
7단계 - 유지 또는 종결
수집한 데이터를 바탕으로 유지 또는 종결을 결정한다.
*얼마나 자주 소비자들이 우리 제품을 구매한느가?
*우리는 시장 리더 위치에 있는가?
*현재 프로덕트 상태로 경쟁력이 있는가?
*현재 상태를 유지하기 위해 얼마나 많은 비용을 지출하는가?
-소프트 랜딩 soft landing 이라고도 하는데, 프로덕트를 종결시키기 전에 사용자들에게 메세지를 보내 현재 제품 관련 어떤 일이 일어나는지 설명하는 것이다. 데이터를 저장하는 프로덕트라면 라이프 사이클을 최종 종료하기 전에 데이터 백업을 허용하는 것이 그것이다.
메일링크를 1년간 운영하면서 나름대로 위의 라이프 사이클을 거쳤다고 할 수 있겠다. 다만 종결 단계에서 소프트랜딩을 정성적으로 진행하지 못한 아쉬움이 있다. 앱 내 알람이나 푸시 알람을 통해 공지했으면 좋았을 것을, 인스타 게시물 공지로 대체하게 되었다. 작가의 글을 데이터로 저장하는 프로덕트의 특성으로, 추후에 요청자에 한에 지금까지 작성한 글을 메일로 모아 발송해주는 에프터서비스를 진행했다.
일종의 프로젝트 관리 프레임워크다. 리소스를 낭비하지 않도록 하며, 요청사항은 백로그라고 한다. 오노브가 자연스럽게 취하고 있는 방식과 가장 가까운 프래임워크다.
열가지 기능이 필요한 앱이라면, 가장 중요한 두가지만 연구하고 개발한다. 우선순위로 기능을 선택하고 가장 중요한 기능이라는 것을 이해관계자, 팀원들에게 설명한다. 설계하고 개발한 후 출시한다. 마지막으로 사용자 피드백을 확인한다. 이후 마찬가지 사이클로 기능을 개선하거나 추가해나간다.
구체적인 애자일 프로세스를 개발에 적용한 프레임워크로는 스크럼이 있다.
스크럼은 이렇게 진행된다.
1 스프린트 계획 회의 진행. 전체 프로덕트 백로그에서 가장 중요한 몇가지를 스프린트 백로그로 옮긴다. (프로덕트 백로그는 전체 프로덕트의 목표를 정리한 기능이고, 스프린트 백로그는 특정 스프린트의 목표에만 해당한다는 용어 구분이 있다. )전체에서 제일 중요한 걸 순서대로 골라 to do list 에 올린다는 뜻이다.
2 프로덕트 개발 개시. 일반적으로 2주간의 시간을 기준으로 스프린트 백로그에 옮겨진 작업을 진행중으로 옮겨 최종적으로 완성한다.
3 스탠드업 미팅이나 리뷰. 구성원이 마지막으로 작업한 내용이나 다음에 작업할 내용을 공유한다. 간단하게 전달한다.
4 회고 회의. 개발만큼이나 중요한 요소이다. 최근에 마친 스프린트의 주요사항을 이야기한다. 잘된 것과 개선할 부분, 발전을 위한 소재를 찾는다.
-----
2 챕터의 여러 내용 중 현재의 나와 팀에게 유용할 내용, 해당되는 내용만 추렸다. 스크럼의 4단계를 자연스럽게 소화하고 있지만 조금 더 체계를 잡아서 진행하면 매주 하는 회의가 더 효율적인 시간이 될 거 같다.