[PGF 1기-김하경] 인스파이어드 사전 과제
작성자
- 조영수
과제
제출
모임
참석
아젠다
PO/PM의 R&R
: 현재 자신이 속한 조직에서 부여된 PO/PM의 역할과 책임을(R&R) 설명해 주세요. 그리고 인스파이어드에서 정의한 이상적인 PO/PM의 R&R과는 어떤 차이가 있나요? 이 차이가 발생하는 원인이 무엇 때문이라 생각하는지 의견을 남겨주세요
→ 의견:
현재 제가 속한 조직에는 PO/PM이라는 역할이 명확하게 정의되어 있지는 않습니다. 총 5명의 팀원으로 구성된 팀에서 저는 현재 서비스 기획자에 가까운 역할을 맡고 있으며, 주로 서비스 흐름과 사용성 개선에 집중하고 있습니다.서비스 기획자에 가까운 역할을 맡고 있으며, 주로 서비스 흐름과 사용성 개선에 집중하고 있습니다.
다만 팀 내에서 발생하는 여러 문제를 마주하며, 기존 역할 범위를 넘어 PM(Product Manager)의 역할을 점진적으로 수행할 필요성을 느끼고 있는 상황입니다.
현재 조직에서 제가 수행하고 있는 역할과, 인스파이어드에서 정의한 이상적인 PM의 R&R을 비교해보면 다음과 같은 차이가 있다고 생각합니다.
1.
제품의 성공 혹은 실패에 대한 최종 책임을 부여받았다고 보기는 어렵습니다.
2.
팀 내·외에서 제품에 대해 가장 잘 알고 있는 '제품 전문가'의 위치에 있다고 느끼지 못합니다.
3.
책에서 강조하는 것처럼, 명확한 목표와 그에 따른 정량적 핵심 성과를 제시하고 이끄는 역할을 수행하고 있지는 않습니다.
이러한 차이가 발생하는 이유는 몇 가지 구조적·개인적인 요인이 함께 작용했다고 생각합니다.
첫째, 조직 내에 제품을 총괄하는 포지션이 존재하지 않았고, 자율적인 분위기 속에서 업무가 진행되다 보니 PM으로서의 책임이 명확히 정의되지 않았습니다. 다만 팀이 한계에 부딪히는 지점을 경험하면서, 이제는 주어진 역할과 무관하게 스스로 PM의 역할을 수행해야겠다는 필요성을 느끼고 있습니다.
둘째, 입사 당시 제품은 출시를 앞둘 정도로 이미 상당 부분 개발이 진행된 상태였고, 그 과정에서 서비스 기획자나 PM이 부재했던 팀이었습니다. 이로 인해 초기에는 제품의 구조와 흐름을 정리하는 데 많은 시간과 에너지를 쓰는 것이 우선순위가 될 수밖에 없었다고 생각합니다. 팀의 시기와 상황에 따라 PM의 역할이 유동적으로 정의될 수 있다는 점도 함께 느꼈습니다.
마지막으로, 개인적으로도 서비스 기획자와 PM의 R&R에 대한 명확한 인식이 부족했습니다. 인스파이어드를 읽으며 PM의 책임과 역할을 정리해보는 과정이, 현재 팀이 겪고 있는 문제를 어떻게 풀어가야 할지 방향을 잡는 데 큰 도움이 되었습니다. 결국 앞서 언급한 세 가지 책임을 점차적으로 떠안는 것이, 지금 상황에서 제가 할 수 있는 가장 현실적인 해결책이라고 생각합니다. 이 책을 조금 더 일찍 읽었다면, 제품 전문가로서의 영향력을 더 빠르게 만들 수 있었을 것 같다는 아쉬움도 남습니다.
PMF 검증을 위한 MVP
: 진행했던 프로젝트 중 아이디어 검증 과정을 통해 PMF를 목표로 MVP를 정의해 구축 출시 후 단계별로 제품을 성장시켜 본 적이 있다면 그 과정과 결과를 공유해 주세요. 만약 PMF와 MVP를 적용해 본 적이 없다면, 어떻게 아이디어를 검증하고, 출시 스펙을 결정했는지, 그리고 그 결과는 어떠했는지 공유해 주세요.
→ 의견:
질문에 제시된 방식과 완전히 동일한 형태의 PMF 검증은 아니지만, 현재 소속된 팀에서 개발 중인 제품을 단계적인 성장에 초점을 두고 MVP 형태로 구축하고 있습니다.
팀 내에서 먼저 최소 단위의 제품을 정의한 뒤, 프로토타입을 제작해 사용성 테스트와 고객 인터뷰를 진행했습니다. 이 과정을 통해 정성적인 데이터를 확보했고, 이를 바탕으로 팀 내부 논의를 거쳐 앞으로의 제품 방향을 발견하고 우선순위를 정하는 방식으로 진행했습니다.
검증 단계에 들어가기 전에는 해당 제품이 실제로 어떤 상황에서, 어떤 방식으로 사용될 수 있을지에 대한 가설을 먼저 세웠습니다. 이후 유사한 환경 혹은 전혀 다른 환경에 있는 고객들과 인터뷰를 진행하며 다양한 유즈 케이스를 확보하는 데 집중했습니다. 이때 아직 개발 중인 제품임을 명확히 전달하고, "어떤 모습의 제품이 되어야 현재 사용자의 환경에서 의미 있게 쓰일 수 있을지"를 중심으로 질문하면서 예상보다 많은 아이디어를 얻을 수 있었습니다.
또한 일부 인터뷰에서는 실제 사용 장면을 현장에서 관찰하며 UI/UX 관점에서의 개선 포인트도 함께 정리할 수 있었습니다.
현재는 이러한 과정에서 얻은 아이디어와 인사이트를 바탕으로 다음 메이저 스프린트의 범위를 산정하고 있으며, 다음 프로토타입 제작과 추가 인터뷰 및 사용성 테스트를 준비 중에 있습니다.
프로덕트 구축/개선 프로세스
: 현재 조직의 프로덕트를 구축/개선하는 과정과 인스파이어드에서 소개하는 이상적인 과정과 어떤 차이가 있나요? 애자일 방법론을 경험해 보신적이 있다면 어떤 장점과 단점이 있었는지 공유해 주세요.
+(옵션) 회사의 제품 구축 프로세스와 체계를 구축하는 시점은 언제부터 필요할까요?
→ 의견:
현재 조직의 프로덕트 구축 및 개선 과정은 전반적으로 애자일에 가깝게 운영되고 있지만, 인스파이어드에서 소개하는 이상적인 과정과는 몇 가지 분명한 차이가 있다고 느끼고 있습니다.
첫 번째 차이는 제품 발견 단계에서의 협업 방식입니다.
책에서는 제품 관리자, 제품 디자이너, 엔지니어가 함께 모여 기능성, 사용자 경험, 가용 기술을 동시에 고려하며 아이디어를 탐색하는 과정을 강조하지만, 현재 조직에서는 이러한 논의의 시간이 충분하지 않습니다. 실제로는 결과물이 어느 정도 나온 이후에야 논의가 시작되는 경우가 많고, 그 과정에서 기술적 제약이 드러나며 기획 방향이 수정되는 일이 종종 발생합니다.
개인적으로는 혁신적인 아이디어나 더 나은 해결책이 다른 직무의 팀원으로부터 나올 수 있다는 점에 공감하고 있어, 제품 발견 단계에서 더 많은 대화를 나누고 싶다는 생각을 하고 있습니다. 다만 각자 맡은 업무량이 많은 상황에서, 어떤 방식으로 논의를 열어야 할지에 대한 확신이 부족해 충분한 시간을 확보하지 못하고 있는 것이 현실입니다.
이 문제의 근본적인 원인은 고객의 문제와 비전을 지속적으로 공유하며 팀을 이끄는 제품 에반젤리즘 역할의 부재라고 생각합니다. 만약 고객의 문제와 우리가 만들고자 하는 방향성이 자주 공유된다면, 별도의 요청 없이도 팀원들이 자연스럽게 논의에 참여할 수 있는 환경이 만들어질 수 있을 것이라 생각합니다.
두 번째 차이는 프로토타입을 활용한 제품 발견 테스트 주기입니다.
인스파이어드에서는 주 단위로 프로토타입을 반복하며 사용자와 상호작용하는 것을 이상적인 방식으로 제시하지만, 현재 조직에서는 실제 사용자 테스트를 1년에 2~3회 정도 진행하고 있습니다. 팀 규모가 5명으로 비교적 작은 상황에서, 각자의 업무를 병행하며 짧은 주기로 프로토타입을 제작하고 테스트하는 것이 현실적으로 가능할지에 대해서는 아직 명확한 답을 찾지 못한 상태입니다.
그럼에도 불구하고 이 간극을 인식하게 된 것 자체가 의미 있다고 생각하며, 앞으로는 테스트의 '완성도'보다 빈도와 학습 속도를 높이는 방향을 고민해보고 싶습니다.
(옵션)
회사의 제품 구축 프로세스와 체계는 빠르면 빠를수록 필요하다고 생각합니다. 다만 초기 단계부터 완벽한 프로세스를 설계하는 것은 현실적으로 어렵기 때문에, 회사 차원의 사업 목표와 핵심 성과를 기준으로 팀이 구성되는 시점에 최소한의 프로세스를 함께 정의하고, 왜 이 방식을 선택했는지에 대해 충분히 논의하는 과정이 중요하다고 느낍니다. 이후 상황에 따라 조정해 나갈 수 있는 유연함을 유지하되, 이 프로세스가 존재하는 이유를 주기적으로 되짚으며 형식적으로 흐르지 않도록 관리하는 노력이 함께 필요하다고 생각합니다.