# [PGF 1기-조단비] 인스파이어드 사전 과제 

1. **PO/PM의 R&R**: 현재 자신이 속한 조직에서 부여된 PO/PM의 역할과 책임을(R&R) 설명해 주세요. 그리고 인스파이어드에서 정의한 이상적인 PO/PM의 R&R과는 어떤 차이가 있나요? 이 차이가 발생하는 원인이 무엇 때문이라 생각하는지 의견을 남겨주세요

→ 의견:

현재 조직에서의 PO/PM 역할과 책임

현재 뷰릿에서 "이걸 왜 만들어야 하는가?"에 대한 최종 의사결정은 대표가 담당하고 있다.

대표는 회사의 방향성과 제품 철학, 그리고 운동 도구 및 서비스 전반의 구조를 가장 깊이 이해하고 있는 핵심 인물로, 주요 제품 및 서비스 방향은 대표의 판단을 중심으로 결정된다.

내가 담당하고 있는 PO 역할은 고객 설문, CX 데이터, 운영 과정에서 발견되는 문제를 정리하고 개선 아이디어를 제안하는 것이다. 이후 대표가 설정한 방향을 바탕으로 개발자, CX 매니저, 콘텐츠 관련 인력과 협업하며 실행 가능한 형태로 구체화하고, 출시 후 결과를 관찰해 추가 개선을 제안하는 역할을 맡고 있다. 즉, 문제 정의와 방향 제안에는 관여하지만 최종적인 "무엇을 만들지"에 대한 결정 권한은 제한적인 상태이다.

INSPIRED에서 정의하는 이상적인 PO/PM의 R&R과의 차이

《INSPIRED》에서 정의하는 이상적인 PO/PM은 문제 정의부터 해결 방향 결정까지 전 과정에 대한 오너십을 가진다. 고객의 문제를 발견하고, 이를 가설로 정리한 뒤 실험을 통해 검증하며, 경우에 따라 "이것은 만들지 않는다"는 결정을 내릴 수 있는 권한과 책임을 가진다.

반면 현재 뷰릿에서의 PO 역할은 주로 대표가 설정한 방향을 빠르게 실행하고 안정화하는 데 초점이 맞춰져 있다. 즉, 이상적인 PO가 "무엇을 만들어야 하는가"를 책임진다면, 현재의 역할은 "어떻게 잘 만들 것인가"에 더 가까운 형태이다.

차이가 발생하는 원인에 대한 의견

이러한 차이는 개인의 역량보다는 조직의 단계와 구조에서 비롯된다고 생각한다. 뷰릿은 아직 명확한 PMF 이후의 확장 단계라기보다는, 지속적으로 문제–해결 적합도를 탐색 중인 조직이다. 또한 대표가 제품의 발명자이자 도메인 전문성을 가장 깊이 보유한 구조이기 때문에, 전략적 의사결정이 대표 중심으로 이루어지는 것이 자연스러운 상황이다. 이로 인해 PO에게 문제 정의와 실험 실패를 감당할 수 있는 권한과 리소스가 충분히 위임되기 어려운 구조가 형성되어 있다.

1. **PMF 검증을 위한 MVP**: 진행했던 프로젝트 중 아이디어 검증 과정을 통해 PMF를 목표로 MVP를 정의해 구축 출시 후 단계별로 제품을 성장시켜 본 적이 있다면 그 과정과 결과를 공유해 주세요. 만약 PMF와 MVP를 적용해 본 적이 없다면, 어떻게 아이디어를 검증하고, 출시 스펙을 결정했는지, 그리고 그 결과는 어떠했는지 공유해 주세요. 

→ 의견:

뷰릿의 미션은 "우리는 건강한 아름다움을 위해 노력한 하루가 삶을 바꾼다고 믿습니다"이다. 초기에는 자체 운동 도구를 중심으로 제품을 판매했으나, 고객들이 제품을 구매한 이후에도 운동을 지속하지 못하는 문제가 반복적으로 관찰되었다. 무료 콘텐츠나 기존 온라인 강의 방식만으로는 행동 변화를 만들기 어렵다는 한계를 확인했다.

이 문제를 해결하기 위해 '운동을 지속하게 만드는 구조'에 대한 가설을 세웠고, 그 결과 정해진 시간에만 참여할 수 있으며 일정 시간이 지나면 사라지는 형태의 운동 콘텐츠를 실험적으로 운영하게 되었다. 초기에는 소규모 참여자를 대상으로 테스트를 진행했고, 재참여 여부를 주요 검증 지표로 삼아 서비스의 유효성을 판단했다.

그 결과 일정 수준 이상의 재참여가 확인되었고, 이를 바탕으로 점진적으로 서비스 규모를 확장했다. 이 과정은 당시 MVP라는 용어를 사용하지는 않았지만, INSPIRED 관점에서 보면 명확한 문제 가설을 설정하고 최소한의 실험을 통해 PMF을 검증한 사례라고 볼 수 있다.

다만 서비스 확장 이후에는 사용자 유입 대비 장기적인 잔존율과 가치 창출 측면에서 한계가 드러났고, 이는 초기 문제 해결에는 효과적이었지만 지속 가능한 PMF는 추가적인 검증이 필요하다는 신호로 인식하고 있다. 현재는 시간 제한이 강한 서비스와 보다 유연한 이용 구조를 가진 서비스를 병행 운영하며, 시간확장 등 서로 다른 고객 니즈를 검증하는 단계에 있다.

1. **프로덕트 구축/개선 프로세스**: 현재 조직의 프로덕트를 구축/개선하는 과정과 인스파이어드에서 소개하는 이상적인 과정과 어떤 차이가 있나요? 애자일 방법론을 경험해 보신적이 있다면 어떤 장점과 단점이 있었는지 공유해 주세요. +(옵션) 회사의 제품 구축 프로세스와 체계를 구축하는 시점은 언제부터 필요할까요?

→ 의견:

현재 뷰릿의 프로덕트 구축 및 개선 프로세스는 다음과 같다.

코어클럽 기수별 설문과 데일리 설문을 통해 고객 불편사항을 수집하고, 회의를 통해 주요 액션 아이템을 도출한다. 이후 대표와 함께 회사의 방향성을 고려해 우선순위를 정하고, CX 매니저, 개발자, 그리고 PO가 함께 구체적인 해결 방안을 논의한다. 이후 각자의 액션 아이템을 실행하고 테스트를 거쳐 배포한 뒤, 실제 사용성과 개선 효과를 확인하고 추가 수정 여부를 다시 논의한다.

이 과정은 빠른 피드백과 반복적인 개선이 가능하다는 점에서 애자일한 방식이라고 느껴진다. 특히 소규모 팀 구조 덕분에 커뮤니케이션 비용이 낮고, 고객 불편사항을 비교적 빠르게 해결할 수 있다는 장점이 있다.

반면 INSPIRED에서 소개하는 이상적인 프로세스와 비교하면, 구현 이전 단계에서의 문제 정의와 가설 검증이 충분하지 않다는 차이가 있다. 현재의 프로세스는 실험과 학습보다는 "문제를 발견하면 빠르게 해결한다"는 실행 중심의 흐름에 가깝다. 즉, 무엇을 만들기 전에 충분히 검증하기보다는, 만들고 나서 반응을 확인하는 방식이 주를 이루고 있다.

(옵션) 제품 구축 프로세스가 필요한 시점에 대한 의견

제품 구축 프로세스와 체계는 팀 규모가 커질 때보다는, 잘못된 결정을 되돌리기 어려워지는 시점부터 필요하다고 생각한다. 뷰릿처럼 제품과 서비스가 동시에 운영되고, 실험 비용과 운영 리소스가 점점 커지는 단계에서는 최소한의 문제 정의와 가설 검증 프로세스가 없다면 비효율이 커질 수 있다. 따라서 현재는 완전한 체계보다는, 구현 이전에 "이 문제를 왜 해결해야 하는가"를 한 번 더 검증하는 최소한의 프로세스가 필요한 시점이라고 판단한다.

For the site tree, see the [root Markdown](https://slashpage.com/pgf.md).