Roles aren''t converging—they''re expanding

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

Roles aren't converging—they're expanding를 중심으로, 제품 관리자의 목적은 그대로다. 제품·시장 적합성을 찾고, 고객이 좋아하며 비용을 지불할 제품을 만드는 책임은 유지되지만 이를 수를 핵심 판단 포인트로 압축 정리한다.

📌 핵심 요점

1. 제품 관리자의 목적은 그대로다. 제품·시장 적합성을 찾고, 고객이 좋아하며 비용을 지불할 제품을 만드는 책임은 유지되지만 이를 수행하는 도구와 방식이 달라졌다.
2. AI의 효과는 조직 맥락과 결합할 때 커진다. 발표자는 조직 정보를 연결하면 회의 기록, 진행 상황 확인, 주간 보고 같은 업무를 줄이고 더 중요한 판단에 시간을 쓸 수 있다고 설명한다.
3. 직접 코딩이 유효한 상황이 있다. Confluence 사례에서는 비개발자 제품 관리자가 엔지니어의 도움으로 프런트엔드 수정에 참여해 한 달 동안 PR 26건을 제출했고, 팀은 평가·디자인 수정·테스트 생성도 개선했다.
4. 제품 관리자가 코딩에서 물러나야 할 상황도 있다. 신규 프로젝트에서는 초기 구현 이후 방향 설정과 우선순위 조정으로 전환했고, 복잡한 Jira에서는 운영 코드에 직접 기여하지 않고 프로토타입과 피드백 처리로 개발을 지원했다.
5. 조직 차원의 확산에는 교육과 성과 측정이 필요하다. Atlassian은 AI 숙련도 지표와 분기별 실습 교육을 운영하며, 실제 배포된 PR·전달된 기능·고객 사용까지의 흐름을 살핀다. 다만 발표자는 생산성 측정법이 아직 완성되지 않았다고 인정한다.

🧩 배경과 문제 정의

제목에서 Atlassian CPO로 소개된 타마르 예호슈아는 제품 리더들을 대상으로 AI가 제품 관리자의 일을 어떻게 바꾸는지 설명한다. 논의의 출발점은 직무 소멸에 대한 불안과 여러 역할을 수행하는 ‘AI 빌더’의 등장이다. 발표자는 이러한 변화가 소규모 창업팀에만 해당하는지, 1만 명이 넘는 조직에서는 어떤 방식으로 적용되는지를 묻는다.

핵심 문제는 제품 관리자가 직접 무언가를 만드는 일과 팀의 방향을 정하는 일 사이에서 어디에 시간을 써야 하는가다. 발표는 기존 제품의 신규 기능, 처음부터 만드는 제품, 복잡한 대규모 기존 제품이라는 세 상황을 비교한다. 이후 조직 맥락, 업무 자동화, 역량 개발, 성과 측정을 연결해 역할 확장을 실제 업무 방식으로 정착시키는 조건을 제시한다.

🕒 시간순 섹션별 상세정리

1. 직무 소멸 논쟁에서 AI 빌더의 등장으로

• 발표자는 제품 리더들과 나눠 온 대화를 바탕으로, 제품 관리자·엔지니어·디자이너가 서로의 일자리가 사라질 것이라고 말하던 분위기를 돌아본다. [00:55]
• 최근에는 역할의 중첩과 AI 빌더가 화두이며, 일부 스타트업은 제품 관리자나 디자이너 대신 빌더를 채용한다고 보여준다. 창업자가 여러 역할을 맡아 온 것과도 연결한다. [01:45]
• 1만 명 이상 조직에서는 어떻게 적용되는지를 질문하고, Atlassian의 엔지니어링 전반보다 제품 관리자의 변화에 초점을 맞춘다. [02:20]

2. 변하지 않는 제품 관리의 목적

• 역할은 서로 겹치면서도 확장된다. 사람들은 이전에 하지 못했던 일을 더 많이 할 수 있게 됐다는 것이 발표자의 관찰이다. [02:34]
• 제품·시장 적합성을 찾고, 사랑받는 제품과 고객이 비용을 지불할 사업을 만드는 목적은 유지되며 달라진 것은 수행 방식이다. [02:57]
• 모든 AI 도구의 발전을 따라잡으려 하기보다, 온라인 주장에 휩쓸리지 않고 고객에게 실제로 유용한 도구와 활용법에 집중하라고 조언한다. [03:29]

3. 조직 맥락과 정보 접근이 바꾸는 업무

• Atlassian의 팀워크 그래프는 조직 맥락을 연결하는 사례로 묶인다. 발표자는 회의 기록, 후속 조치 확인, 출시 일정 문의 등을 도구가 대신할 수 있다고 보여준다. [04:05]
• CEO가 출시 일정을 직접 물었다가 Rovo에서 답을 찾아 확인한 일화는 정보 접근 방식의 변화를 보여 준다. 실제 사용을 유도하는 변화 관리도 필요하다고 덧붙인다. [04:32]
• 팀의 속도를 높이는 요소로 모델의 지능과 조직 맥락의 결합을 제시한다. 제품 관리자가 직접 ‘노를 저을지’, 방향을 ‘조타할지’는 제품 종류와 단계에 달려 있다고 보여준다. [05:39]

4. Confluence 신규 기능과 제품 관리자의 코드 기여

• 세 가지 사례를 예고한 뒤, 텍스트를 여러 형식으로 바꾸는 Remix와 페이지를 발표 자료로 바꾸는 Confluence Slides를 보여준다. [06:26]
• 코딩과 터미널 경험이 없던 제품 관리자는 엔지니어가 마련한 보조 도구로 프런트엔드 코드에 기여했고, 한 달 동안 PR 26건을 제출했다고 한다. [07:19]
• 목적은 부족한 엔지니어링 자원 때문에 밀린 사용자 경험 수정을 처리하고, 엔지니어가 더 높은 수준의 작업에 집중하도록 돕는 것이었다. [07:36]

5. 평가·디자인 수정·테스트를 함께 개선한 결과

• 제품 관리자가 평가 기준을 엔지니어와 공유하고 언어 모델 플랫폼에서 프롬프트 문제를 찾아 전달했다. 발표자는 평가 생산성이 2배가 됐다고 보여준다. [08:23]
• Figma MCP와 코딩 에이전트를 연결해 디자인 불일치 약 14건을 한 시간에 수정했고, 테스트 생성 시간은 반나절에서 10분으로 줄었다고 한다. [08:54]
• Remix는 6주, 이어 언급된 Confluence 기능은 8주에 출시됐다고 보여준다. 약 6개월에서 6주로의 단축 사례와 촘촘한 피드백 반복을 강조하며, 분리된 저장소와 사전에 정한 기여 방식이 기반이었다고 정리한다. [10:07]

6. 신규 제품에서는 구현에서 방향 설정으로 전환

• 자막상 ‘로보 클로’라는 신규 프로젝트에서 제품 관리자 조시와 디자이너 케빈이 초기 버전을 만들고 내부 사용을 거쳐 엔지니어를 합류시켰다. 기존 Rovo의 기능 개발과는 구분해 보여준다. [10:37]
• 조시는 자신의 코딩 때문에 팀 방향 관리가 소홀해진다고 판단해 우선순위 설정과 장애물 제거로 중심을 옮겼다. 초기 구현 경험은 기술적 제약을 이해하는 데 도움이 됐다. [11:26]
• 주간 업데이트는 개발 중인 제품 안의 에이전트로 자동화했다. 이 사례의 교훈은 프로젝트 단계에 맞춰 직접 구현과 조타를 오가며 영향력이 큰 활동에 집중하는 것이다. [12:21]

7. 복잡한 Jira에서는 직접 코드 기여의 경계를 설정

• Jira는 20년 넘게 축적된 복잡한 코드베이스와 다양한 배포·규정 준수 요구를 가진 제품으로 묶인다. 발표자는 이런 환경에서 제품 관리자의 직접 코드 기여가 위험할 수 있다고 보여준다. [12:55]
• 팀은 Jira를 AI 중심으로 바꾸고 에이전트에 작업을 배정하는 등 개발 업무 흐름을 재구성하려 했다. [13:23]
• 발표자는 구현부터 출시까지의 생산성이 평소의 3배였으며, 10주 동안 사용자 대상 기능 22개를 출시했다고 드러낸다. [13:36]

8. 실제 개발 환경에 연결된 프로토타입

• Loom으로 변경할 화면이나 Figma 디자인을 설명하면 녹화 내용에서 작업 항목을 만들고, 이를 실행 단계로 옮겨 코딩 에이전트를 작동시키는 흐름을 보여준다. [14:17]
• 클라우드에서 관리되는 에이전트가 실제 프런트엔드 저장소에서 작업해 제품 관리자의 로컬 환경 설정 부담을 줄였다고 한다. [14:30]
• 기존 디자인 언어와 접근성에 맞는 프로토타입을 만들 수 있어 개발자에게 넘기는 과정이 빨라졌으며, 적절한 프로토타입 환경이 중요했다고 강조한다. [14:56]

9. 피드백 분류와 사용자 조사로 개발 병목 해소

• Slack으로 들어오는 피드백과 버그를 Jira 에이전트가 분류하고 코딩 에이전트로 전달해 수정하는 흐름으로 엔지니어링 시간을 절약했다고 보여준다. [15:22]
• 사용자 조사에서 얻은 900건 이상의 관찰·피드백을 에이전트로 분류하고 정리해 개발팀에 전달할 수정 대상을 파악했다. [15:50]
• 이 사례에서 제품 관리자는 피드백 처리와 재사용 가능한 프로토타입에 집중해 팀을 이끌었으며, 운영 환경의 코드에는 직접 기여하지 않았다고 명시한다. [16:17]

10. 확장된 업무와 AI 숙련도 개발 기준

• 제품 관리자는 프로토타입, 테스트, 평가, 고객 피드백 분석을 더 많이 수행하고, 수동 업데이트·조사 취합·슬라이드 작성은 줄였다고 한다. 동기식 회의가 사라졌다는 주장은 과장이라고 선을 긋는다. [16:58]
• 기존 구성원의 역량 개발을 위해 여섯 역량과 1~5단계로 구성된 AI 숙련도 지표를 도입했다. 도구 사용, 평가 작성, 데이터 인사이트 자동화, 프로토타입, 기술 이해 등이 나온다. [17:53]
• 이 지표는 승진 기준이 아니라 학습 방향을 정하는 수단이다. 장기적으로 모든 영역에서 3단계를 기대하며, 팀에 특히 중요한 영역에서는 5단계를 목표로 삼도록 보여준다. [18:29]

11. 분기별 실습 교육으로 업무 방식 정착

• 분기마다 한 주를 확보해 제품 관리자와 디자이너를 교육하는 AI 빌더 주간을 운영한다. 외부 강연, 숙련된 동료의 교육, 실제 프로젝트 수행을 결합한다. [19:13]
• 발표자는 1천 명 이상이 참여했고, 교육 후에도 사용하는 새로운 업무 흐름이 120개 이상 만들어졌다고 보여준다. 주제는 프로토타입, 평가, 에이전트 구축, 코드 관련 실습으로 이어졌다. [19:35]
• 고객도 참고할 수 있도록 교육 일정과 운영 방식을 담은 실행용 자료를 웹사이트에 제공한다고 보여준다. [19:47]

12. 생산성은 배포와 고객 사용까지 측정

• 발표자는 성과 측정의 완전한 해법을 아직 찾지 못했다고 인정한다. 작성한 PR보다 실제 운영 환경에 배포된 PR과 전달된 기능을 측정한다고 보여준다. [20:16]
• 아이디어에서 고객에게 전달되고 사용되는 시점까지의 흐름, 목표와 핵심 결과, 전체 생산성을 함께 보려 하지만 기능의 시작 시점을 정하기도 쉽지 않다고 드러낸다. [20:29]
• 개별 팀뿐 아니라 조직 전체도 빨라지는지 확인해야 하며, 분기마다 서로 다른 방식의 실험과 결과 측정을 이어 간다고 보여준다. [20:50]

13. 역할 확장의 최종 목적은 고객 가치

• 마무리에서 모든 역할이 확장되고 진화하며, 제품 관리자는 자신의 일을 더 효과적으로 수행하고 고객에게 더 많은 가치를 줄 수 있다고 강조한다. [21:09]
• 발표자는 제품 관리자로 일하기에 흥미로운 시기라는 낙관적 전망을 전하고, 10년 뒤에도 함께할 것이라는 기대와 감사로 강연을 끝낸다. [21:26]

🧾 결론

• 제품 관리자의 역할 확장은 모든 사람이 항상 코딩해야 한다는 뜻이 아니다. 현재 팀의 병목을 가장 효과적으로 해소하는 활동을 선택하는 것이 핵심이다.
• 직접 구현한 경험은 기술적 제약과 장애물을 이해하는 데 도움이 되며, 이후 팀의 방향을 정하는 역량으로 이어질 수 있다.
• 도구 도입과 함께 기여 범위, 개발 환경, 협업 방식, 교육을 설계해야 조직 전체의 속도 개선으로 연결할 수 있다.
• 발표의 낙관론은 고객에게 더 나은 결과를 제공할 수 있다는 데 있다. 직무의 장기적 존속이나 모든 조직의 동일한 성과를 입증한 것은 아니다.

📈 투자·시사 포인트

• 기업용 AI를 평가할 때 모델 성능뿐 아니라 조직 정보에 접근하고 실제 업무 흐름에 연결되는지를 살필 필요가 있다. 발표는 조직 맥락과 실행 도구의 결합을 반복해서 강조한다.
• 개발 생산성 개선은 코드 생성 외에도 평가, 디자인 수정, 테스트, 피드백 분류, 보고 자동화에서 발생한다. 도입 효과를 검토할 때 이 업무들을 함께 관찰할 수 있다.
• 기존 대규모 제품에서는 보안·규정 준수·고객 영향이 속도 개선의 조건이다. 스타트업의 출시 속도를 그대로 비교 기준으로 삼기 어렵다.
• 제시된 생산성 수치는 발표자의 내부 사례다. 매출, 이익률, AI 운영 비용에 관한 자료는 없으므로 이를 기업 가치 상승이나 투자 수익으로 곧바로 연결할 근거는 부족하다.

⚠️ 불확실하거나 확인이 필요한 부분

• 평가 생산성 2배, Jira 생산성 3배, 개발 기간 약 6개월에서 6주로 단축됐다는 수치는 발표자의 설명이다. 비교 대상, 인력 투입량, 품질 변화, 측정 방식은 충분히 제시되지 않는다.
• 아랍어 자막에는 고유명사 표기와 문맥상 불일치가 있다. 신규 프로젝트의 ‘로보 클로’와 플랫폼 ‘Rise’의 정확한 영문 명칭은 확인이 필요하며, 8주 출시 대상도 앞에서는 Confluence Slides로 소개되지만 해당 대목에서는 Confluence로 축약된다.
• AI 숙련도 지표는 여섯 역량으로 구성된다고 설명하지만, 자막만으로 여섯 항목 전체의 공식 명칭과 평가 기준을 확정하기 어렵다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• 현재 제품을 기존 제품의 신규 기능, 초기 신규 제품, 복잡한 기존 제품 중 어디에 가까운지 분류하고 제품 관리자의 기여 범위를 정한다.
• 팀의 병목을 기록한 뒤 직접 구현, 방향 설정, 피드백 정리 중 가장 효과가 클 활동 하나를 선택한다.
• 직접 코드에 기여한다면 엔지니어와 협력해 분리된 작업 환경과 역할 분담을 먼저 마련한다.
• 주간 보고, 피드백 분류, 평가 등 반복 업무 하나를 골라 자동화를 실험하고 결과의 정확성과 절약 시간을 확인한다.

❓ 열린 질문

• 제품 관리자가 직접 구현을 멈추고 방향 설정에 집중해야 하는 전환 시점은 어떤 신호로 판단할 수 있을까?
• 기능 수와 PR 수 증가가 고객 가치, 제품 품질, 조직 전체의 속도 개선으로 이어졌는지 어떻게 구분할 수 있을까?
• 조직 맥락이 불완전하거나 정보 접근이 제한된 환경에서도 같은 수준의 자동화 효과를 얻을 수 있을까?