UX 디자이너로 살기

PM(프로덕트 매니저)과 PO(프로덕트 오너)는 이름만 보면 비슷하지만,실무에서의 역할과 시선은 꽤 다릅니다. 특히 기획자 출신 PM이 PO 역할을 맡게 되면,“생각보다 다른 일인데?“라는 당황스러움을 자주 겪죠. 오늘은 실무에서 느낀 PM과 PO의 진짜 차이, 그리고 PM이 PO로 전환하려면 어떤 준비가 필요한지 정리해봅니다. 1. PM과 PO, 이름은 비슷한데 뭐가 다를까?항목PMPO주요 시선프로젝트 진행비즈니스 성과책임 대상기능/서비스 완성도제품의 수익성과 전략협업 주체디자이너, 개발자비즈니스 오너, 이해관계자주요 활동요구사항 정의, 우선순위 정리, 일정 조율제품 방향 제시, 고객/시장 관점 의사결정 → 한마디로 말하면, PM은 운영 중심, PO는 비즈니스 중심입니다. 2. 실무에서 가장 혼동되는..

기획자와 개발자가 자꾸 싸우는 이유기획자와 개발자는 함께 일해야 할 파트너입니다. 하지만 현실에서는 사소한 충돌이 자주 생기죠. “왜 이걸 이렇게 기획했어요?” “이건 구현이 너무 복잡해요.” “그건 개발팀이 알아서 할 줄 알았는데요?” 서로의 역할은 다른데, 일의 목적은 같아야 하죠. 그 차이를 이해하지 못하면 갈등은 반복됩니다. 오늘은 기획자와 개발자가 왜 자주 싸우는지, 그리고 그걸 줄이기 위한 실전 팁을 정리해봅니다. 서로의 관점이 다르다 기획자는 "사용자의 문제 해결"에 초점을 맞추고, 개발자는 "기술적 제약과 효율"을 고려합니다. 기획자는 "이게 사용자에게 필요하다"고 주장하고, 개발자는 "그건 너무 비효율적이고 시간도 오래 걸린다"고 반박하죠. 이건 싸움이 아니라, 관점 차이..

기획자가 회의를 리드할 수밖에 없는 이유“회의가 너무 산으로 간다”는 말, 들어본 적 있나요? 회의는 의견을 정리하고 결론을 내리는 자리지만, 실제로는 목적 없이 길어지거나, 끝나고 나서도 “그래서 뭐 하기로 했지?” 싶을 때가 많습니다. 이럴 때 필요한 역할이 바로 PM입니다. 기획자가 회의의 흐름을 잡지 않으면, 회의는 논의가 아니라 잡담으로 끝나버릴 수 있어요. 오늘은 왜 PM이 회의를 리드해야 하는지, 그리고 실무에서 유용한 회의 운영 방식에 대해 정리해봅니다. 회의는 '진행자'가 없는 순간 산으로 간다회의는 자동으로 굴러가지 않습니다. 누군가가 목표를 제시하고, 흐름을 정리해주고, 결론까지 이끌어야 하죠.PM이 회의 리딩을 맡아야 하는 이유는 간단합니다.서비스 전체 맥락을 가장 잘 아는 사람여러..

PM은 팀 내에서 가장 많이 말하는 역할 중 하나입니다. 회의를 주도하고, 요구사항을 정리하고, 커뮤니케이션을 계속 이어가야 하죠.그런데 실무에서는 이런 말을 종종 듣습니다."PM은 말만 많고 실질적인 아웃풋이 없다."이 오해는 어디서 오는 걸까요? 오늘은 PM이 말 많다는 오해를 받는 이유와, 그 오해를 줄이기 위한 커뮤니케이션 팁을 정리해봅니다. 오해 1: 말은 많은데 실행이 없다?PM의 역할은 문제 정의, 요구사항 도출, 협업 조율입니다. 그 자체가 '보이지 않는 일'이기 때문에, 결과물이 코드나 디자인처럼 눈에 잘 안 보이죠. 그래서 "말만 하고 끝났네?"라는 인상을 주기 쉽습니다. 하지만 이는 단지 성과의 가시화 문제일 수 있어요.팁 : 말한 내용을 정리해서 문서로 남기기회의록, 이슈 리스트, ..

기획서를 다 써놓고 “이제 개발팀에 넘기면 되겠다” 싶은 순간, 꼭 다시 한번 생각해봐야 해요. 정말 이 기획서, 이해하기 쉬울까?협업자가 헷갈리는 건 없을까? 기획서 자체는 ‘문서’지만, 그 안에는 PM의 사고 흐름, 정책, UX 철학이 전부 들어있어요.그래서 혼자 완성했다고 끝이 아니라, 스스로 점검하는 루틴이 중요합니다. 기획서 셀프 점검 체크리스트1. 기능 누락은 없는가?화면 간 이동 흐름이 빠짐없이 정리돼 있는가조건별로 다르게 작동하는 기능이 누락되지 않았는가2. 플로우에 막히는 구간은 없는가사용자 여정에서 갑자기 끊기는 지점은 없는지진입 → 행동 → 완료까지 자연스럽게 이어지는가3. 정책적 예외 상황도 설계되어 있는가?인증 실패, 결제 오류, 제한 조건 등 고려했는가실패/예외 상황일 때의 UX..

PM은 주로 서비스의 기능, 흐름, 정책을 설계하죠. 반면 마케팅 팀은 유저 유입과 행동을 이끌어내는 역할을 합니다. 같은 서비스, 같은 유저를 바라보지만 접근 방식이 다르기 때문에 자주 충돌하거나 오해가 생겨요. 오늘은 PM이 마케팅 팀과 협업할 때 꼭 챙겨야 할 실무 포인트들을 정리해볼게요. PM과 마케터는 기본 시선이 다르다역할초점PM기능 구현, 구조, 플로우, 정책마케터유입, 클릭, 전환, 반응 이 차이를 이해하지 못하면 마케팅 팀은 “기획이 너무 어렵다”고 하고 기획자는 “왜 그렇게 무리한 캠페인을 요구하냐”고 하게 됩니다. 캠페인 설계 시 공유해야 할 핵심 3가지1. 유저 세그먼트어떤 타겟을 위한 캠페인인지신규 유저? 재방문 유저? 특정 조건 유저?2. 진입 경로 & 도달 지점이벤트 페이지/..

PM 회의에서 자주 듣는 말이 있어요.“우리 이번 분기 KPI는 뭐로 잡을까요?” 근데 그때 정한 KPI, 나중엔 아무도 안 보거나 “이걸로 뭘 하라는 거지…?” 하는 경우 많지 않나요? 사실 실무에서 KPI는 숫자를 세는 게 아니라 방향을 잡는 도구예요. 오늘은 KPI 설정 시 흔히 하는 실수와, 실전 팁을 정리해볼게요. 흔한 실수: KPI = 그냥 숫자?많은 팀이 KPI를“방문자 수 30% 증가”“매출 2배”이런 식으로 설정해요. 겉으로 보기엔 명확해 보여도, 행동 유도가 안 되는 KPI는 실속 없는 수치일 수 있어요. 실행력 있는 KPI란?좋은 KPI는 팀이 ‘어디에 집중할지’ 명확하게 만들어줘야 해요.예시 “서비스 인지도 향상” → 추상적 “유입 채널별 신규회원 20% 증가” → 구체적좋은 KP..

기획자 입장에서 QA는 ‘개발팀 일이니까 난 패스’ 이렇게 생각하기 쉽죠. 하지만 기획자도 QA에 반드시 참여해야 합니다. 왜냐고요? 기획자의 의도와 실제 구현이 일치하는지를 확인하는 마지막 기회기 때문이에요. “기능만 잘 동작하면 됐지”는 위험한 생각버튼이 눌리고, 페이지가 열리면 기능은 ‘작동’한 거죠. 그런데 그게 사용자의 입장에서 자연스럽게 흘러가는가?이건 별개의 문제예요. 실제 서비스에서 기획 의도가 잘 전달되지 않으면→ 사용자 혼란→ 고객센터 문의 폭주→ 개발팀 핫픽스이런 악순환이 생깁니다. 기획자가 꼭 체크해야 할 항목 5가지 진입 경로가 자연스러운가? 갑자기 튀는 플로우 없이 이어지는가? 에러 시 복귀 동선이 명확한가? 잘못된 입력 → 어디로 돌아가야 하는지..

서비스 운영을 하다 보면 꼭 듣는 피드백이 있죠.“이 버튼 위치가 불편해요.”“이런 기능 있었으면 좋겠어요.”이건 왜 이렇게 복잡하죠?” 우리는 이 피드백을 최대한 빠르게 반영하려고 합니다. 고객 중심, 유저 퍼스트, 민첩한 대응… 다 맞는 말이죠. 그런데, 피드백을 곧장 기능으로 바꾸면 오히려 실패할 수 있어요.왜일까요? 피드백 = 니즈일까?고객이 말한 피드백은 대부분 ‘겉으로 드러난 불편’입니다. 하지만 그 말 뒤에는‘진짜 바라는 것’이 숨어 있어요. 예를 들어“즐겨찾기 버튼이 있었으면 좋겠어요.” 라고 말했을 때, 정말 즐겨찾기 버튼이 필요한 걸까요? 사실 그 사람은 자주 쓰는 기능을 빠르게 접근하고 싶다는 의미일 수도 있어요. 즉, 해결책을 말한 게 아니라, 겪고 있는 문제를 말한 것일 수도 있는..

기획서는 PM에게 있어 기본 중의 기본이죠. 하지만 정말 실무에선, 기획서보다 먼저 챙겨야 할 게 있습니다. 바로 ‘문제 정의’입니다. 아무리 기획서가 잘 짜여 있어도, 문제를 잘못 정의했다면 결국 잘못된 방향으로 리소스를 쓰게 돼요. 시간도, 비용도, 협업자의 노력도 엉뚱한 곳에 쓰이죠. 기획서보다 중요한 ‘문제 정의’많은 PM들이 실무에서 기능을 먼저 설계하려고 합니다. “뭘 만들까?”에 초점을 맞추죠.하지만 ‘왜 만들까?’, 이게 불분명하면 팀 전체가 흔들립니다. 기획서의 시작점은 기능이 아니라 문제여야 합니다. 문제가 명확해야, 그걸 해결하기 위한 설계가 명확해지고,개발자와 디자이너, 운영자 모두 같은 방향을 바라볼 수 있어요. 문제 정의가 잘못되면 생기는 일각자 다른 문제를 가정하고 설계함우선..