Planning · PM/프로젝트 · PM

올해 남은 두 달, 끝내고 싶은 네 가지를 정리하며

11월도 벌써 일주일이 지났습니다.올해가 끝나기까지 8주 남짓 남았어요.이쯤에서 "올해 안에 끝내고 싶은 일"을 한 번 적어 두려고 해요.목표를 많이 세우면 오히려 하나도 끝내지 못한다는 걸 이번 한 해 동안 여러 번 느꼈기 때문에, 이번에는 네 가지로 줄였습니다. aiatti 신규 버전 1차 정리FIVO 서비스 오픈1년 현황판(가칭) 만들기스팩브릿지 GitHub 공개 일의 성격이 서로 달라서 같은 방식으로 관리하면 안 될 것 같았어요.그래서 네 가지 모두 "무엇이 되면 끝인가"를 먼저 적고, 각각의 남은 일과 위험을 정리해 보겠습니다. 1. AIATTI 신규 버전, 우선은 "정리"부터aiatti는 공간 예약과 운영을 위한 통합 플랫폼입니다.여러 모듈을 조합해서 공간마다 필요한 방식으로 자유롭게 운영할..

AI가 만든 결과를 내가 이해하고 있다고 말하려면, 기획자의 확인 기준

AI로 목업을 만들고, 스팩브릿지를 만들고, 예약 시스템의 정책 문서를 쓰는 것이 요즘 제 일과의 대부분이에요.결과물이 나오는 속도는 예전과 비교가 되지 않습니다.그런데 결과물이 쌓일수록 같은 질문이 따라와요."이걸 내가 정말 이해하고 있나."화면이 그럴듯하게 나오면 이해한 것 같은 기분이 듭니다.정책 문서가 매끄럽게 정리되면 빠진 게 없다고 느끼기도 쉬워요.하지만 기분과 이해는 다르다는 걸, 설명 없는 목업 때문에 개발자와 소통이 막혔던 경험에서 한 번 배웠습니다.화면만 보면 다 정해진 것 같은데, 정작 정책은 제 머릿속에만 있었거든요.그러던 차에 GeekNews에서 제목부터 이 고민과 닮은 글을 봤습니다.오늘은 그 토론을 짧게 훑고, 코드를 읽지 못하는 기획자가 무엇을 근거로 "이해했다"고 말할 수 ..

생성형 AI 저작권과 윤리, 공부하며 정리한 쟁점

생성형 AI를 공부하다 보면 기술 이야기만큼 자주 만나는 주제가 저작권과 윤리입니다.서비스에 AI 기능을 넣는다면 이 문제를 피해갈 수 없을 것 같아서, 기사와 공개된 논의를 읽으며 쟁점을 정리해보았습니다.먼저 분명히 해둘 점이 있습니다.저는 법률 전문가가 아니고, 이 글은 공부한 내용을 정리한 메모일 뿐 법률 자문이 아닙니다.이 분야는 아직 논의 중인 부분이 많아서, 실제 서비스에 적용할 때는 반드시 전문가의 검토와 최신 공식 안내를 확인해야 한다고 생각해요. 가장 먼저 눈에 띄는 쟁점은 모델이 무엇으로 학습했느냐입니다.이미지나 글을 생성하는 모델은 방대한 데이터로 학습하는데, 그 안에 창작자가 만든 작품이 들어 있을 수 있다는 점이 논란의 중심이에요.창작자 입장에서는 허락 없이 자신의 작품이 학습에 ..

Build-Measure-Learn, 작게 돌려보기

린 스타트업에서 가장 유명한 개념이 Build-Measure-Learn, 즉 만들고, 재고, 배우는 순환입니다.책으로 읽을 때는 당연한 이야기처럼 들리는데, 막상 제 아이디어에 적용하려고 하면 "그래서 일주일 동안 뭘 하라는 거지?" 싶었어요.그래서 이 루프를 1~2주 단위로 잘게 쪼개서 실제로 돌려본다면 어떻게 하는지, 가정 예시와 함께 정리해봤습니다. 이 순환은 Build에서 시작하는 것처럼 보이지만, 책에서도 계획은 거꾸로 세우라는 취지로 설명한다고 이해했습니다.먼저 배우고 싶은 것(Learn)을 정하고, 그걸 확인하려면 무엇을 재야 하는지(Measure) 정한 다음, 마지막으로 그걸 재기 위해 최소한 무엇을 만들면 되는지(Build)를 정하는 식입니다.저는 이 순서가 중요하다고 느꼈어요.만들고 나..

기능 우선순위 프레임워크 비교, 1인 프로젝트에 ICE·RICE·Kano 적용해보기

기능 우선순위를 정하는 방법은 예전부터 많이 읽어왔는데, 막상 혼자 작은 서비스를 만들어보려니 어디에 어떻게 써야 할지 감이 오지 않았어요.읽을 때는 다 이해한 것 같은데, 내 기능 목록 앞에 앉으면 결국 "이것도 필요할 것 같고 저것도 필요할 것 같고"로 끝나더라고요.그래서 이번에는 대표적인 세 가지 방법(ICE, RICE, Kano)을 같은 기능 목록에 하나씩 적용해보고, 어떤 차이가 나는지 정리해봤습니다. 예시로 쓸 서비스는 실제로 만들고 있는 것이 아니라, 연습을 위해 가정한 것입니다.동네 독서모임 운영자가 모임 일정을 정할 때 단체 대화방에서 날짜를 일일이 묻는 게 번거롭다고 가정해볼게요.그래서 일정 후보를 올리면 참석자들이 투표하고, 가장 많이 가능한 날짜가 자동으로 정리되는 작은 웹서비스를 ..

MVP 범위 자르기 - 기능을 어디까지 빼야 하나

MVP(Minimum Viable Product)라는 말은 창업 책을 읽으면 어디서나 나옵니다.그런데 막상 내 아이디어에 적용하려고 하면, "최소"가 어디까지인지가 가장 어려웠어요.기획자로 일할 때 범위를 줄이는 일을 자주 해봤다고 생각했는데, 내 아이디어 앞에서는 전혀 다른 문제가 되더라고요.기능 하나하나가 다 소중해 보이니까요.이번 글에서는 범위를 자르는 순서와, 제가 여러 번 빠졌던 함정을 적어봅니다. 기능 목록을 쓰기 전에 먼저 하는 일이 있습니다.이 서비스가 고객에게 주는 핵심 가치를 한 문장으로 쓰는 것입니다.예를 들어 소규모 업장용 예약 서비스를 가정해볼게요."전화나 메신저로 받던 예약을 놓치지 않고 한곳에서 확인할 수 있다."이 정도가 한 문장의 예입니다.이 문장에는 "놓치지 않는다"와 "..

린 캔버스로 아이디어 검증하기

신규 아이디어가 나올 때마다 바로 기획서를 쓰기 시작하면, 절반은 중간에 방향이 바뀌고 절반은 그냥 흐지부지됩니다.저도 예전엔 아이디어가 나오면 바로 와이어프레임부터 그렸는데, 나중에 보면 "이게 정말 필요한 서비스인가"라는 근본적인 질문에 답을 못 하는 경우가 많았어요.그래서 요즘은 신규 아이디어가 나오면 제일 먼저 린 캔버스(Lean Canvas)를 채워보는 걸 습관으로 만들었습니다. 린 캔버스는 문제, 고객군, 고유의 가치 제안, 솔루션, 채널, 수익 구조, 비용 구조, 핵심 지표, 경쟁 우위까지 한 장에 정리하는 프레임워크예요.비즈니스 모델 캔버스와 비슷하지만, 스타트업 초기 아이디어 검증에 맞게 "문제"와 "솔루션"을 앞쪽에 배치한 게 특징입니다.저는 이 순서가 특히 마음에 들었어요.솔루션부터 ..

애자일 팀의 회고(Retrospective) 잘 하는 법

회고를 몇 년째 진행하다 보면, 어느 순간 회고 자체가 형식이 되어버리는 시기가 옵니다.저희 팀도 그랬어요.매 스프린트 끝나면 회의실에 모여서 포스트잇에 Keep, Problem, Try를 적고, 다 같이 붙이고, 몇 개 투표하고 끝내는 패턴이 반복됐습니다.그런데 어느 순간 팀원 한 명이 "우리 이거 3주 전에도 똑같이 얘기했던 것 같은데요"라고 말했고, 그 말에 다들 조용해졌던 기억이 있어요. 회고에서 나온 Problem이 다음 스프린트에 실제로 개선되지 않으면, 회고는 그냥 감정 배출구가 되어버립니다.저희가 겪었던 문제는 Try 항목이 "노력하자", "신경 쓰자" 수준의 다짐으로 끝나는 경우가 많았다는 거였어요."코드 리뷰를 더 꼼꼼히 하자"는 Try는 누가 언제 무엇을 다르게 할지가 없으니, 다음 ..

PM과 개발자 사이 커뮤니케이션 갭 줄이기

"이거 금방 되는 거 아니에요?"라는 말을 PM이 하는 순간, 개발자의 표정이 굳는 걸 몇 번이나 봤습니다.저도 예전에 이 말을 자주 했었고, 지금 생각하면 왜 그 말이 그렇게 문제였는지 뒤늦게 이해하게 됐어요.PM과 개발자 사이의 갭은 능력 차이가 아니라, 서로 보고 있는 정보의 종류가 다른 데서 시작되는 경우가 훨씬 많았습니다. PM은 화면과 사용자 경험을 기준으로 난이도를 가늠하고, 개발자는 코드 구조와 기존 시스템과의 연결을 기준으로 가늠합니다.저희 팀에서 있었던 일인데, "상품 상세 페이지에 최근 본 상품 목록 추가"라는 요청을 제가 "그냥 목록 하나 더 보여주는 거니까 간단하겠다"고 생각했어요.그런데 개발팀 입장에서는 최근 본 상품을 저장할 저장소를 정하고, 비로그인 사용자는 어떻게 처리할지,..

기능 우선순위, 이해관계자 설득하는 법

우선순위 회의만큼 감정 소모가 큰 회의가 없다고 느낄 때가 많습니다.영업팀은 "이 고객사가 요청한 기능을 안 하면 계약이 위험하다"고 하고, 디자인팀은 "지금 UI 부채를 안 갚으면 나중에 더 힘들어진다"고 하고, 개발팀은 "기술 부채부터 해결해야 신규 기능도 빨리 나온다"고 합니다.다 맞는 말이라서 반박하기도 어려운데, 결국 자원은 한정되어 있으니 뭔가는 뒤로 밀려야 해요.이 과정을 몇 년 겪으면서 제가 나름대로 정리한 설득 방법을 공유해봅니다. 가장 먼저 바꾼 건, 우선순위 논의를 "제 생각엔"으로 시작하지 않는 것이었습니다.예전엔 회의에서 "제가 보기엔 이게 더 급한 것 같아요"라고 말하곤 했는데, 이렇게 시작하면 상대방도 "저는 아닌 것 같은데요"로 맞받아치고, 결국 누구 목소리가 더 크냐의 싸움..

사용자 피드백을 백로그로 전환하는 프로세스

앱스토어 리뷰, CS 문의, 슬랙에 올라오는 영업팀의 "고객이 이런 걸 원한대요" 같은 이야기들.사용자 피드백은 사방에서 쏟아지는데, 이걸 실제로 백로그에 반영하는 과정이 없으면 결국 다 흩어지고 사라집니다.저희 팀도 예전엔 피드백을 받으면 그때그때 슬랙에서 반응만 하고, 정리해서 백로그로 만드는 절차가 없었어요.같은 요청이 세 달 뒤에 또 올라오는 걸 보고서야, 이건 프로세스로 만들어야 한다는 걸 깨달았습니다. 가장 먼저 한 일은 피드백이 들어오는 채널을 파악하고, 이걸 한 곳으로 모으는 구조를 만드는 것이었습니다.저희는 앱스토어 리뷰, CS 문의, 영업팀 슬랙 채널, 사용자 인터뷰 노트까지 네 개 채널에서 피드백이 들어오고 있었어요.채널마다 형식이 다 달라서, 이걸 노션 데이터베이스 하나로 모으는 작..

PM의 문제 정의 능력, 어떻게 기르나

PM 3년 차쯤 되니까 "이 사람은 문제를 잘 정의하네"라는 평가를 듣는 동료와, 그렇지 않은 동료가 확실히 나뉜다는 걸 느꼈습니다.둘 다 회의도 열심히 하고, 문서도 열심히 씁니다.그런데 결과물의 질이 달라요.저는 한동안 후자에 속했던 사람이라, 이 차이가 어디서 오는지 꽤 오래 고민했습니다.그 고민을 정리해보려 합니다. 입사 초반에 저는 "이탈률이 높다"는 걸 문제라고 정의하고 프로젝트를 시작한 적이 있습니다.디자이너와 개발자를 모아서 온보딩 화면 UI를 통째로 뜯어고쳤어요.두 달을 갈아 넣었는데 이탈률은 거의 그대로였습니다.나중에 데이터를 다시 파보니, 이탈이 몰리는 지점은 온보딩 화면이 아니라 결제 수단 등록 화면이었어요."이탈률이 높다"는 증상이었고, 진짜 문제는 결제 수단 등록 단계에서 인증 ..