글러닝

브런치북 중간 회고 그리고 이야기

2025-06-30T12:20:17Z

오늘이 딱 31번째 글이다. 처음 브런치를 시작할 때 나의 의식의 흐름은 이랬다. 그냥 1주마다 1개의 글을 쓰자.주제는? 가장 많은 시간을 일하면서 보내니까 거기서 배운 걸 쓰자.무슨 요일? 제일 괴로운 월요일. 이겨내보자. 맨 처음에는 내가 하고 싶었던 말을 썼던 것 같다. PM을 하면서 아직도 계속 듣는 질문 중에 하나가 PM이 뭔가요?라서 그 설

심리적 안정감, 얼마나 중요할까?

2025-07-08T15:10:33Z

심리적 안정감은 겉으로 드러나지 않는다.하지만 문제를 해결해야 하는 순간, 그 차이는 분명히 드러난다. 얼마 전, 신입 모바일 개발자가 팀에 합류했다. 첫 릴리즈 이후 주요 지표가 눈에 띄게 하락했다. 무언가 잘못됐다는 느낌이 들어 “릴리즈 된 기능 중 이상한 부분이 있을까요?”라고 물었다. 하지만 돌아온 답변은 조심스러웠다. “큰 이슈는 없어요.” “

전사 OKR 적용해 보기

2025-06-16T12:30:08Z

회사가 성장하고 있다. 사람이 많아지고 아이디어는 넘치고, 리소스는 늘 부족하다. 그러다 보면 우선순위는 자주 바뀌고, 팀마다 다른 문제를 바라보기도 했다. 지금 문제가 일어나기까지 각 팀은 자율적으로 움직였다. 제품팀은 제품 OKR을 기준으로 일했고, 사업팀은 KPI에 맞춰 숫자를 관리했다. 방향이 완전히 다르진 않았지만, 점점 팀마다 일하는 방식과

우리가 추적해야 할 지표는요?

2025-06-09T13:54:48Z

전환율 실험을 자주 하다 보면 자연스럽게 매트릭(지표)에 많이 신경 쓰게 된다.하지만 처음부터 매트릭을 잘 썼던 건 아니다. 제품을 만들다 보면 항상 계획대로만 흘러가진 않는다. 기획 단계에서 고려하지 못했던 문제가 생기기도 하고 릴리즈 일정에 쫓겨서 제품 스펙을 줄이게 되는 경우도 많다. 그럴 때 팀에서는 이런 질문이 자주 나온다. “지금 이게 진짜 문

대표님이 인터뷰를 요청한 이유

2025-06-02T14:21:12Z

일을 하다 보면 누군가에게 인터뷰를 요청해야 할 때가 있다. 신규 고객을 이해하거나, 내부 프로세스를 파악할 때, 정보를 얻기 위한 수단으로 인터뷰는 자주 쓰이는 도구다. 그런데 이번엔 조금 달랐다. 대표님이 갑자기 와서는 “저를 좀 인터뷰 해줘요.” “아무도 저한테, 제가 무슨 문제를 겪고 있는지 물어보질 않네요.” 많은 인터뷰를 해봤지만, 당사자에

PM은 어디까지 책임져야할까?

2025-05-26T15:23:31Z

제품팀에서 PM이 오너십을 가진다는 건 구체적으로 어떤 모습일까? 실험이 실패했을 때, 고객 지표가 떨어졌을 때, 릴리즈가 미뤄졌을 때.그럴 때마다 PM은 어디까지 오너십을 가져야 할까? 솔직히 말하면, 주니어 PM이던 시절의 나는 마음 편하게 남 탓을 하곤 했다. 하필 실패하면 외부 환경이 너무 불안정해보였고, 리소스는 늘 부족해보여 때로는 ‘운이 안

확증 편향에 대해서 아시나요?

2025-05-19T13:33:17Z

PM에게 확증 편향은 특히 더 조심해야 할 영역이다. 문제를 정의하고, 방향을 만들고, 팀을 설득하는 역할이기 때문에 한 사람이 가진 확신이 곧 여러 사람의 실행이 된다. 물론, 생각이 맞을 때도 있다. 일의 연속성과 경험에서 나오는 직감은 때로는 데이터보다 빠르고 정확하게 상황을 꿰뚫기도 한다. 그래서 더 조심하려고 한다. 맞을 수도 있지만, 틀릴 수도

PM이 문제를 다루는 자세

2025-05-15T05:06:17Z

PM은 늘 문제와 함께 일한다. 그래서 자연스럽게 문제를 풀어야 하는 사람이라고 느끼기 쉽다.그리고 실무에선 문제를 뾰족하게 만들어야 한다는 조언도 자주 듣는다. 그래서 나도 그랬다. 혼자 문제를 정의하고 구조화해서 팀 앞에 "이게 문제입니다"라고 설명하고 이끄는 게 나의 일이고, PM으로서 잘해야 하는 일이라고 생각했다. 잘 정리된 PRD, 명확한 유

PM은 얼마나 중요할까?

2025-05-05T15:12:54Z

PM은 얼마나 중요한 역할일까. 가끔 그런 생각이 든다. 예전에는 기획의 빈틈이나 구현에서 막히는 부분이 생기면 나를 찾아왔다. 그런데 요즘은 다들 AI에게 데이터 분석을 시키고, 리서치를 하고, 기술적인 의사결정도 스스로 처리한 뒤 구현해서 보여준다. 그래서인지 PM을 찾는 빈도도 조금 줄어든 것 같다. 그게 편하면서도, 한편으론 조금 낯설다. PM의

PM이 결정(decision)을 하는 방법

2025-06-16T14:07:49Z

PM에게 요구되는 것 중 하나는 '결정을 잘 내리는 것'이다.하지만 모든 결정을 똑같은 방식으로 내릴 수는 없다. 내가 PM 일을 하면서 느낀 건, 결정에는 세 가지 종류가 있다는 것이다. 빠른 결정 함께 하는 결정 시점을 늦추는 결정 상황마다 어떤 결정을 해야 할지를 구분하는 것, 그게 진짜 '결정을 잘한다'는 의미가 아닐까 생각한다. 1.

PM 업무에 Cursor(커서) 적용하기

2025-06-15T15:36:11Z

회의 흐름을 바꾼 작은 계산기 실험기 요즘 우리 팀은 금액 구조를 새로 설계하고 있다. 그중 가장 먼저 시작한 건, 총액에서 공급가액과 VAT를 분리해 명시하는 정책과 기능을 만드는 일이다. 원래는 “총액”만 말하면 됐는데, 이제는 “공급가액” 기준으로 말하려니 자연스럽게 계산이 자주 필요해졌다. 흐름을 끊는 건 언제나 숫자였다. “62,500원이 공

PM이 회의를 리딩하는 방법

2025-05-06T11:50:21Z

사용자를 생각해서 UX를 만들었다. 하지만 제품 개발은 리소스와 현실을 고려해야 한다. 가설, 사용자 UX, 개발 사이에서 어떻게 조율하는지 이 글은 PM으로서 내가 그런 순간을 어떻게 풀어내는지 기록하는 글이다. 2주 안에 출시해야 하는 기능이 있었다. 백엔드, 웹, iOS, 안드로이드 개발자들과 함께 기능 구현 회의를 시작했다. 나는 유저 흐름을

망한 실험을 왜 또해요?

2025-04-08T03:22:49Z

얼마 전, 결제 전환율을 높이기 위한 실험을 해보자고 스쿼드에 제안했다. 하지만 내게 오는 피드백은 냉철했다. "그거 저번에 다른 스쿼드에서 실험해봤는데 완전 망했었어요." "헉. 혹시 UX나 지표 볼 수 있을까요?" "조금 오래됐는데.. 잠시만요" 이전 실험 문서를 보니 가설은 비슷하고 접근은 조금 달랐다. 내가 생각할 땐 그 사이 제품 UX 흐름도

디자인 스프린트가 진짜 강력해지는 순간

2025-03-31T10:33:40Z

디자인 스프린트란? 디자인 스프린트는 짧은 시간 안에 문제를 정의하고, 아이디어를 도출하고 서로 공유된 이해와 공유된 결정을 하게 도와주는 협업 방법론이다. 우리 팀은 중요한 이슈나 손에 안 잡히는 이슈를 해결해야 할 때 디자인 스프린트를 진행한다. 내가 생각하는 디자인 스프린트가 가장 강력해지는 순간은? 문제 정의가 흐릿하고, 팀의 관점이 어긋나고,

교통정리가 필요한 순간들

2025-03-24T12:42:29Z

PRD와 디자인이 나왔다고 해서 모든 게 자동으로 흘러가지는 않는다. 개발이 시작된 후에도 PM은 일정, 리소스, 우선순위 사이에서 끊임없이 결정을 내리고, 조율해야 한다. 특히 다음과 같은 순간에는 교통정리가 반드시 필요하다. 1. 일정이 겹칠 때 디자이너는 한 명이고, 동시에 수정 요청이 들어올 때, 스프린트 내에 끝내야 하는 기능이 있는데 VoC가

건강한 갈등 만들기

2025-03-17T13:24:15Z

갈등 없는 팀이 있을까? 모두의 생각이 한 번에 하나로 모이는 게 사실은 쉽지 않다. 기적적으로 초반에 팀원의 생각이 하나로 모였다고 하더라도 디자이너는 디자인, 개발자는 코딩을 하며 각자의 생각이 증폭되고 그러면서 자연스럽게 제품을 바꾸고 의도치 않게 방향을 바꾸기도 한다. 특히 에너지가 넘치는 팀일수록 자유롭게 서로의 아이디어를 공유하고 서로의 생각을

PM은 어디까지 예측해야 할까?

2025-03-10T19:40:20Z

제품 관리자로서 우리는 데이터를 분석하고, 사용자의 문제를 탐색하며, 지금 최선의 제품 방향을 결정한다. 우리의 결정으로 어떤 일이 일어날지, 이다음 스텝이 뭔지 여러 가지 시나리오가 생긴다. PM은 어디까지 예측해야 하는가? 모든 변수를 생각하고 완벽한 계획을 세울 수 있을까? PM(Product Manager)의 핵심 역할 중 하나는 "올바른 방향으로

저 잘하고 있는 거겠죠?

2025-03-03T17:28:22Z

PM을 하면서 수백만번은 마음속으로 했던 질문이다. '내가 잘하고 있는 걸까?' 성장하지 않으면 살아남을 수 없는 이곳에서 누구한테 물어보기에도 좀 그렇고 나 혼자 질문하고 나 혼자 대답하며 5년 차 PM이 되었다. 그동안 내가 이리저리 흔들리면서도 버틸 수 있었던 나만의 성장 척도를 보는 방법을 적어보려 한다. 첫 번째. 과거의 나와 비교하기 사

PM이지만 마케터 아니 데이터 분석가입니다

2025-02-24T13:26:53Z

나의 팀을 간단하게 소개하면 개발자 20명, 디자이너 3명, PM 3명인 조직에서 제품을 만들고 있다. 저렇게 보면 26명이 한 팀으로 작은 조직은 아니지만 CMO가 없고, 인사팀이 없고, PR 매니저, 데이터 분석가도 없이 제품팀에서 제품을 만들고 그 제품이 우리가 원하는 결과가 나올 때까지의 모든 일을 처리하고 있다. PM의 역할은 단순하지 않다.

실패를 계속하는 방법

2025-02-17T13:40:33Z

비즈니스 임팩트를 위해 필요한 기능을 a/b 테스트를 진행했다. 오전 10시쯤 배포 완료를 하고, 그날 오후 3시에 우리는 긴급하게 다시 모였다. "다들 지표 보셨나요?" "껄껄. 결과가 확실해서 너무 좋네요. 뭐부터 고치면 될까요?" "단계를 둬서 UX를 전개했던 게 사용자들을 더 혼란스럽게 만든 거 같아요, 단계를 풀고 처음부터 전체를 노출시키는