product designers가 PM 역할을 흡수하려면 무엇을 해야 하나요, 특히 비즈니스 측면에 노출되지 않았을 때?

How can product designers do to absorb the PM role instead of the other way around, especially when they are not exposed to business side of things?

Reddit2026-03-20/u/Opposite_Might_6276

원문 보기 →

배경 및 소개

게시글은 최근 팀에서 PM이 아이디어를 스스로 프로토타이핑하고 Engineers와 바로 협업하면서 Design 단계를 건너뛰는 현상이 보편화됐음을 지적한다. 회의 중 즉석으로 “vibe coding”을 하거나 문제 정의 이전에 반짝이는 데모가 올라오면, 비즈니스 목표나 사용자 니즈 같은 기본 질문은 사라지고 “멋지다”는 이유로 다음 단계로 밀고 나간다는 것이다. 이 흐름이 고착되면 목소리가 큰 PM이 Design 역할을 흡수할 수 있다는 우려가 제기되고, 반대로 비즈니스에 노출되지 않은 Designers가 PM 역할을 흡수하려면 무엇을 해야 하느냐는 질문이 나온다. 커뮤니티 토론은 UX 역량이 가진 차별성과 한계, 조직 문화와 프로세스 문제, 그리고 디자이너가 스스로 비즈니스·엔지니어링으로 범위를 확장하는 실천 방안을 중심으로 전개된다.

주요 내용

핵심 논지는 Product Designer가 사용자 경험의 원리와 전체 여정을 보는 능력에서 분명한 우위를 가지지만, cost of delay, ROI, target markets, runway, 런치 후 마케팅 같은 비즈니스 기본과 아키텍처 스타일, 시스템 제약, 난이도 산정 같은 엔지니어링 기본이 부족해 경쟁에서 밀리기 쉽다는 진단이다. 이에 대한 처방으로 T-shaped 역량을 강조한다. 인접 역할의 언어와 제약을 이해하고 함께 일하는 법을 익히면 역할 경계가 흔들릴 때도 여러 모자를 쓸 수 있다는 것이다. 또 하나의 축은 접근성이다. 비즈니스에 노출되지 않았다는 이유로 물러서기보다, 재무·운영·임원에게 직접 컨택해 15~30분 대화를 잡거나 짧은 설문을 돌려 의사결정의 근거를 확보하라고 조언한다. 만약 Product 조직이 이를 게이트키핑한다면 그 자체가 나쁜 조직 신호다. 실천 측면에서는 중복 역할을 배척하기보다 수용하되, 디자인 문제를 타인이 더 일관되게 다루도록 돕는 시스템과 가드레일을 구축하는 접근이 제안된다. Design system과 패턴, 문제정의 프레임, 의사결정 기준을 명문화해 “좋은” 해결책으로 수렴하게 만들면, 즉흥 프로토타입의 유혹 속에서도 품질을 방어할 수 있다. 한편 시니어 PD들은 로드맵, 전략, 정렬 회의에 상시 참여하며 단기 비전까지 리드하는 것이 일반적이라고 말한다. 결국 자리를 “초대받는” 것을 기다리기보다 연구 인사이트와 데이터로 논의를 열고, 그 자리에 스스로 들어가야 한다. 이러한 맥락에서 사용자 인터뷰, 사용 행태 데이터, 실험 결과를 수집해 디자인 결정이 어떤 지표와 목표에 기여했는지 연결하면, 반짝이는 데모보다 강한 설득력을 갖는다. 즉흥적 vibe coding은 패턴 불일치, 사용자 mental model 위반, 플로우 파손을 낳기 쉬운데, 전체 여정의 시작과 끝을 보는 Product Designer의 시야가 바로 그 리스크를 줄인다. 조직 차원의 해법도 제시된다. PM, Engineers, Head of Product/Design과 함께 프로세스를 재정의해, 아이디어 커밋 이전에 Design이 브레인스토밍과 문제정의 단계에 공식적으로 관여하도록 명확히 하라는 것이다. 설계 배제는 다운스트림 리스크와 리워크 비용을 키운다는 점을 리스크 관리 언어로 제기하면 효과적이다. 동시에 디자이너가 PM을 ‘흡수’하려 하기보다, 의사결정 근거를 지표와 목표, 사용자 임팩트에 묶고, 라이브 데모에 맞설 수 있도록 사고 과정과 안을 자주·가볍게 공유하는 가시성을 높이는 실천도 강조된다.

결론 및 시사점

토론의 결론은 역할 경계의 중첩이 가속화되는 환경에서 생존 전략은 수성보다 확장에 가깝다는 것이다. UX의 강점을 축으로 하되 비즈니스와 엔지니어링의 기본기를 체화해 T-shaped로 진화하면, PM의 즉흥 솔루션이 주도권을 빼앗는 상황에서도 문제정의, 근거 기반 우선순위, 실행 가능성 판단을 연결하는 허브 역할을 맡을 수 있다. 동시에 가시성과 내러티브가 중요하다. 연구 인사이트를 지표와 목표에 맵핑하고, 결정의 이유를 짧고 자주 공유하면, “멋져 보이는” 프로토타입보다 신뢰를 얻는다. 조직 레벨에서는 아이디어 커밋 이전의 Design 관여를 명문화하고, 패턴 일관성·여정 완결성·리워크 비용 같은 리스크를 근거로 프로세스를 바로잡아야 한다. 다만 디자이너가 비즈니스 권한과 인센티브 없이 PM 역할을 전면 흡수하기는 어렵고, 리더십의 후원과 공동 책임 구조가 필요하다는 한계도 분명하다. 결국 해법은 Turf war가 아니라, 문제를 더 잘 정의하고 더 빨리 학습하며 더 작은 비용으로 올바른 결정을 내리는 시스템을 디자이너 주도로 설계·운영하는 데 있다.

💡 UX/HCI 실무자는 T-shaped 역량을 목표로 비즈니스·엔지니어링 기본기를 익히고, 연구 인사이트를 지표와 목표에 연결해 설계를 설득하라. 동시에 초기 문제정의 단계에 공식적으로 관여하는 프로세스와 디자인 가드레일을 마련해 즉흥 프로토타입의 리스크를 통제하라.