# [PGF 1기-박세준] 인스파이어드 사전 과제 # 아젠다 1. **PO/PM의 R&R** : 현재 자신이 속한 조직에서 부여된 PO/PM의 역할과 책임을(R&R) 설명해 주세요. 그리고 인스파이어드에서 정의한 이상적인 PO/PM의 R&R과는 어떤 차이가 있나요? 이 차이가 발생하는 원인이 무엇 때문이라 생각하는지 의견을 남겨주세요 > → 의견: **현재 자신이 속한 조직에서 부여된 PO/PM의 역할과 책임(R&R)** - 약 3년차 창업을 하고 있는 대표로서 초기 문제 발견부터 문제 정의 및 해결 방안 정리 등 사업계획 전반을 직접 맡고 있고, 외부 협력 회사를 만나 협업 구조를 만들고 파트너십을 따오는 사업개발도 함께 하고 있습니다. 또한 UI/UX 디자인과 개발도 직접 참여하기도 하면서 서비스가 출시되고 운영될 수 있게 정리·조율하고, 회계·세무, 노무, 자본조달(지원사업 및 투자금)과 관련된 준비·집행·정산, 각종 서류 처리와 법인 등기까지 회사에 필요한 일을 대부분 직접 처리하는 **잡부**입니다. **인스파이어드에서 정의한 이상적인 PO/PM의 역할과 책임(R&R)** - 우선, 해당 책에 의하면** 제품 관리자(PM)가 제품 소유자(PO) 를 포함하는 관계**이다. > **제품 소유자(Product Owner)** 라는 개념은 애자일 팀에서 제품 백로그를 책임지는 역할의 이름 이라고 한다. 책에 앞서 나오고 뒤에서 사용할 **백로그 관리자(backlog administrator)**가 이와 비슷한 단어인듯 하다. 책 부분 ![Image](https://upload.cafenono.com/image/slashpageHome/20260124/174823_iN4a7VCxISp99c1wjw?q=80&s=1280x180&t=outside&f=webp) - 가장 이상적인 제품 관리자(PM)는 세 가지 종류의 제품 관리자 중 **스스로 업무를 실행하는 사람**이다. 1. **백로그 관리자: **모든 이슈와 의사결정 안건을 CEO 에게 보고 한다. 2. **로드맵 관리자**: 이해관계**자**를 회의실에 불러모을 수 있고 그들끼지 끝장을 보도록 만든다. 주로, 큰 기업에서 자주 발견되는 모델. 3. **제품 관리자**: 스스로 업무를 실행하는 사람 - 가장 이상적인 제품 관리자(PM)는 **(1) 고객, (2) 데이터, (3) 비즈니스와 이해 관계자 (4) 시장과 산업**, 이 4가지에 대해서 **깊이 이해하는 것에 대해서 책임**을 가지고 있다. 1. **고객**: **그들의 이슈, 불편함 그리고 그들이 무슨 생각을 하는지 이해**해야 한다. 실제 제품에 대해서 모두가 인정하는 전문가가 되어야 한다. 2. **데이터: 정량적인 분석 역량과 정성적인 분석 역량** 모두 필요로 한다. 우리의 제품으로 무엇을 하는지에 대한 이해는 고객을 파악하는 데에 큰 비중을 차지한다. 3. **비즈니스: 어떻게 비즈니스 가치가 창출되는지, 제품은 어떤 역할을 해야하는지 잘 아는 것**. 다양한 이해관계를 파악하고 설득할 수 있어야한다. 설득하기 위해서 각 주체의 제약사항을 확실히 이해하고 반영된 솔루션을 제공해야한다. 4. **시장관 산업: 경쟁하고 있는 시장과 산업에 대한 깊이 있는 지식**. 경쟁사를 이해하는 것을 포함하여 주요 기술의 변화, 고객의 행동과 기대사항, 관련 산업 분석가의 자료 모니터링, 시장과 고객을 위한 소셜미디어의 영향력의 이해등이 해당한다. - 가장 이상적인 제품 관리자(PM)는 **똑똑하고** **창의적이고** **집요하며** **열정적이고 진정한 리더쉽**을 가졌다. 1. **똑똑함**: 단순히 IQ 가 아닌 지적호기심과 빠른 학습능력, 그리고 배운 기술에 대한 적용력 2. **창의력**: 평범한 제품 기능의 범위를 뛰어넘는 비즈니스 문제 해결력 3. **집요함**: 완강한 저항에도 불구하고, 적당함과 타협하지 않는 추진력 4. **열정**: 제품 및 고객 문제 해결에 대한 열정 5. 리더쉽**: 진정한 리더쉽**이 좋은 제품관리자와 위대한 제품 관리자를 구분하는 중요한 요소다. **차이점** - 일단은 저는 **제품 관리자**는 맞지만, **이상적인 제품관리자**는 아닙니다. - 이는 창업을 시작한 대표자로서 얻어진 것이지 제가 좋은 제품 관리자가 되고자 노력하여 얻은 것과는 구별된다고 생각합니다. - 이상적인 제품관리자와의 차이점 - 책임: 4가지의 책임 중에서 데이터, 비즈니스, 시장과 산업 부분에서 부족합니다. - 데이터: 최근에야 B2B 로 피봇하고, 대학교 영업이 어렵다보니 아직은 분석할 데이터가 부족하며, 어떤 데이터가 필요하고 어떻게 분석해야할 지 아직 잘 모르겠습니다. - 비즈니스: 어떤 식으로 비즈니스 가치가 창출되는 지, 제품이 어떤 역할을 해야하는 지 어느 정도는 알지만 아직 정확하게 어느 정도의 가치를 창출하는 지는 정확히 알지 못합니다. 그리고 대학교 영업에 있어서 의사결정자인 대학교 국제처장과 함께 실무자인 대학교 국제처 직원분과 대학교 총장님, 대학교 재무부(등록금 납부), 대학교 IT 담당부서(API 연동 등) 등과 사용자인 대학교 유학생 등 다양한 주체의 제약사항을 아직은 정확하게 이해하고 있는 지 모르겠습니다. 계속 알아가는 중이고 좀 더 발로 뛰어야하는데 자꾸 책상에 앉아서 머리로만 생각하는 듯 합니다. - 시장과 산업: 마케팅 역량이 너무 부족해서 지금 투자받은 거나 서대문구와 협약을 맺은 등 다양한 부분에서 외부 PR 을 해야하는 데 제품 개발에만 집중하며 소셜미디어의 영향력의 이해 등의 부분에서 부족함이 많습니다. - 특징 - 똑똑함: 뭐든지 빠르게 배우고 적용하는 아이디어는 있지만 해당 기술력을 직접 구현하는 부분에 대해서는 좀 더 디테일함이 필요할 듯 합니다. - 집요함: 제품 기한 등에 있어서나 MVP 및 린 이라는 프로세스 에 대한 잘못된 이해로 적당함과 타협했던 적이 많습니다. - 리더쉽: 리더쉽이라는 것이 정확히 무엇인지 정의하기 어려운 듯 하지만, 카리스마가 필요하다고 생각합니다. 꼭 무서운 카리스마 뿐만 아니라 부드러운 카리스마도 있다고 생각하는데, 그러한 카리스마가 좀 부족하다고 생각합니다. **차이점 발생 원인** - 데이터: 데이터에 대한 중요성을 그렇게 인지하고 있지 않았습니다. - 비즈니스: 좀 더 발로 뛰어야 하는데 자꾸 책상에서 GPT 와 대화하는 듯 - 시장과 산업: 마케팅은 좀 귀찮다..고 느끼고 있는 것인지, 아니면 좀 부족함을 드러날까봐 두려워서 어떤 반응이 있을지 두려워서? 본질적으로는 실패를 두려워서가 아닐까 싶습니다. - 똑똑함: 기술에 대해서 좀 더 완성도있게 공부하기는 귀찮아서 개념 정도 및 간단한 적용 방법 정도만 공부하는 듯 - 집요함: B2B 쪽 고객 일 때나 투자사에게 보여줘야할 것이 필요할 때에 적당함과 타협한 경우가 많고, 해야할 역할이 많아서 정신이 없다보니 본질에 집중을 못하는 경우가 많았던 것 같습니다. - 리더쉽: 카리스마.. 음 나이도 아직 엄청 많지는 않고 만만하게 생기고 슬리퍼 신고 편하게 대해서 그런가.. 잘 모르겠습니다. 2. **PMF 검증을 위한 MVP** : 진행했던 프로젝트 중 아이디어 검증 과정을 통해 PMF를 목표로 MVP를 정의해 구축 출시 후 단계별로 제품을 성장시켜 본 적이 있다면 그 과정과 결과를 공유해 주세요. 만약 PMF와 MVP를 적용해 본 적이 없다면, 어떻게 아이디어를 검증하고, 출시 스펙을 결정했는지, 그리고 그 결과는 어떠했는지 공유해 주세요. > → 의견: **아이디어 검증 과정을 통해 PMF를 목표로 MVP를 정의해 구축 출시 후 단계별로 제품을 성장시켜 본 경험 (과정과 결과) 공유** - 유니포트는 외국인 유학생/외국인 거주자가 한국에 들어와 정착하는 과정에서 반복적으로 막히는 지점(전화번호 개통, 서류·비자/ARC 절차, 본인확인, 결제/정산 등)을 **현장에서 직접 겪고 관찰**하면서 출발했습니다. 특히 독일인 아내(당시 여자친구)가 한국 생활을 준비·적응하는 과정에서 제가 옆에서 실무적으로 도와주며 "어디에서 시간이 가장 많이 소모되고, 어떤 안내가 부족하며, 어떤 단계에서 불안과 이탈이 발생하는지"를 구체적으로 확인했습니다. 또한 대학교 국제처 업무를 실제로 경험하면서, 학생 관점뿐 아니라 국제처 실무자 관점에서 발생하는 운영 부담(반복 문의, 서류 확인, 일정 관리, 안내 표준화 부족)도 함께 체감했습니다. - 다만 과정이 INSPIRED에서 말하는 이상적인 방식처럼 **처음부터 '문제-가설-검증-학습'이 체계적으로 돌아가진 않았고**, 현실적으로는 **운영 이슈와 데드라인 중심의 단계형 진행(워터폴에 가까운 흐름)**이 많았습니다. 빠르게 출시하는 데 집중하다 보니, 개발 전에 프로토타입/사용자 테스트로 충분히 검증하기보다는 "일단 만들고 출시한 뒤 CS/현장 피드백으로 고치는" 방식이 반복되었고, 그 결과 리스크(사용성/정책/운영)가 출시 이후에 터지면서 수정 비용과 컨텍스트 스위칭이 커지는 구간이 있었습니다. 또한 대표가 PO/PM/디자인/운영/대외협력까지 동시에 맡는 구조라, 지표 기반으로 실험을 설계하고 체계적으로 측정하기보다는, 당장 들어오는 문의와 파트너 요청을 우선 처리하며 우선순위가 흔들리는 한계도 있었습니다. - 그럼에도 이런 현실적 제약 속에서 "정착 과정에서 반드시 필요한 최소 기능"을 기준으로 MVP를 정의해 빠르게 구축·출시했고, 출시 후에는 실제 사용자 문의/이탈 지점과 파트너(학교/협력사) 피드백을 기반으로 가입·온보딩 흐름, 안내 문구, 서류 처리 방식, CS 템플릿과 운영 프로세스를 단계적으로 정리하며 제품을 성장시켜 왔습니다. 동시에 부족했던 부분(사전 검증, 지표 기반 실험, 백로그 우선순위 고정)을 보완하기 위해, 이후에는 작은 단위로 더 자주 내보내고(릴리즈 단위 축소), 검증을 먼저 하는 습관(간단한 테스트/사전 확인)을 점진적으로 도입하는 방향으로 개선해 왔습니다. 3. **프로덕트 구축/개선 프로세스** : 현재 조직의 프로덕트를 구축/개선하는 과정과 인스파이어드에서 소개하는 이상적인 과정과 어떤 차이가 있나요? 애자일 방법론을 경험해 보신적이 있다면 어떤 장점과 단점이 있었는지 공유해 주세요. +(옵션) 회사의 제품 구축 프로세스와 체계를 구축하는 시점은 언제부터 필요할까요? > → 의견: **현재 조직의 프로덕트를 구축/개선하는 과정** > 리소스와 일정 제약 때문에 기획→디자인→개발로 이어지는 단계형(워터폴에 가까운) 방식으로 운영되는 경우가 많았습니다. 다만 운영 이슈와 고객 피드백이 수시로 들어와서, 실제로는 단계형 + 긴급 대응이 섞인 하이브리드에 가까웠습니다. **인스파이어드에서 소개하는 이상적인 과정** - 문제부터 시작: "무엇을 만들까"가 아니라 "누구의 어떤 문제를 어떤 결과로 개선할까(전환/유지/CS 등)"부터 정의한다. - 리스크를 먼저 줄임: 개발에 들어가기 전에 고객이 진짜 원하는지(가치), 쓸 수 있는지(사용성), 기술적으로 되는지(구현 가능), 사업/정책에 맞는지(적합성)를 빠르게 확인한다. - 프로토타입/테스트 중심: 완성품을 만들기 전에 가볍게 만들어 사용자 반응과 데이터를 통해 검증하고 학습한다. - 검증된 것만 개발로: 아이디어를 바로 개발 백로그로 넣지 않고, 검증을 통해 "할 만하다고 확인된 것"만 개발 단계로 넘긴다. - 짧은 주기로 반복: 한 번에 크게 만들기보다, 작은 단위로 자주 릴리즈하고 측정한 뒤 다음 개선으로 이어가는 루프를 계속 돌린다. - Discovery와 Delivery를 동시에: 한쪽은 다음 개선안을 검증(발견)하고, 다른 한쪽은 검증된 것을 구현(개발)하면서 병렬로 굴린다. **차이점** - A. 문제를 명확히 잡는다 (Problem Framing) - 이상적: "누구의 어떤 문제를, 어떤 지표(전환/유지/CS 등)로 개선할 것인가"를 먼저 확정하고 그 범위 안에서 움직임 - 유니포트: 운영 이슈, 파트너 요청, 데드라인 등 "당장 처리해야 하는 일"이 출발점이 되는 경우가 많아 문제/지표가 뒤로 밀리거나 문서화가 최소화되는 경향 - B. 위험을 먼저 깎는다 (De-risking) - 이상적: 개발 전에 가치/사용성/기술 가능/사업 적합 리스크를 빠르게 확인해 실패 비용을 줄임 - 유니포트: 리소스·시간 제약으로 "만들면서 확인"이 많아 리스크가 개발 후반 또는 출시 직후(운영/CS)에서 터지는 비중이 커짐 - C. 프로토타입으로 빠르게 검증한다 (Prototyping & Testing) - 이상적: 가벼운 프로토타입/테스트로 고객 반응을 먼저 보고 학습한 뒤 확실한 것만 개발로 이동 - 유니포트: 프로토타입 검증을 충분히 하기보다 바로 구현해서 MVP로 내보내고 반응/이슈로 수정하는 "사후 학습" 비중이 높아짐 - D. 검증된 것만 개발 백로그로 만든다 (Validated Backlog) - 이상적: 백로그는 "아이디어 목록"이 아니라 "검증을 통과한 항목" 중심으로 구성됨 - 유니포트: 요청/이슈/급한 일정이 곧바로 태스크로 들어오는 경우가 많아 검증 여부와 무관하게 백로그가 쌓이고 우선순위가 자주 흔들릴 수 있음 - E. 구현은 빠르게, 자주 내보낸다 (Build/Test/Deploy) - 이상적: 작은 단위로 자주 릴리즈하며 품질 기준과 릴리즈 루틴이 안정적으로 유지됨 - 유니포트: 기획→디자인→개발의 단계형(워터폴에 가까운) 흐름이 많고, 중간에 운영 이슈가 끼어들어 릴리즈가 "묶음 배포" 또는 "긴급 패치" 형태로 흔들릴 수 있음 - F. 출시 후 측정하고 다시 반복한다 (Measure & Iterate) - 이상적: 지표/데이터로 효과를 측정하고 학습을 다음 사이클의 문제정의로 연결하는 루프가 명확함 - 유니포트: 지표 기반의 체계적 반복보다는 CS/운영 이슈 중심의 개선(불만 해소, 장애 대응)이 우선되면서 "측정→학습→재설계" 루프가 약해지기 쉬움 **애자일 방법론 경험 여부** - 해당 단어를 사용해본 적은 있지만 해당 개념에 부합한 경험은 아니었습니다. **+(옵션) 회사의 제품 구축 프로세스와 체계를 구축하는 시점은 언제부터 필요할까요?** - 저도 좀 궁금하긴 합니다. 일단은 인건비를 사용할 때에는 필요하지 않을까 싶습니다. 효율적으로 비용 관리를 하기 위해서는 그렇고 그 이전에 최대한 코파운더와 하거나, 정부 지원사업 지원금을 활용할 때에 가장 효율적인 시스템을 검증하며 찾아봐야하지 않을까 싶습니다. For the site tree, see the [root Markdown](https://slashpage.com/pgf.md).