<?xml version="1.0" encoding="UTF-8"?><rss xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:atom="http://www.w3.org/2005/Atom" version="2.0"><channel><title><![CDATA[Product Campus]]></title><description><![CDATA[Product Campus]]></description><link>https://www.productcampus.co.kr/blog</link><generator>RSS for Node</generator><lastBuildDate>Thu, 17 Sep 2026 10:02:39 GMT</lastBuildDate><atom:link href="https://www.productcampus.co.kr/blog-feed.xml" rel="self" type="application/rss+xml"/><item><title><![CDATA[AI 시대의 프로덕트 매니저: 새로 필요한 역량]]></title><description><![CDATA[# AI 시대의 프로덕트 매니저: 새로 필요한 역량  AI가 모든 것을 바꾸고 있다는 이야기가 넘쳐납니다. 프로덕트 매니저들 사이에서도 "AI 시대엔 PM의 역할이 완전히 달라진다"거나 "PM이 없어진다"는 말이 돕니다. 하지만 진실은 좀 더 균형 잡혀 있습니다. AI가 프로덕트 매니지먼트를 뿌리째 뒤집는 것은 아니며, 오히려 기존 역량 위에 새로운 층이 더해지는 것에 가깝습니다. 이 시리즈의 마지막 글에서, AI 시대에 프로덕트 매니저에게 무엇이 달라지고 무엇이 그대로인지 정리하겠습니다.  ## 변하지 않는 것들  먼저 강조하고 싶은 것은, 프로덕트 매니지먼트의 근본은 변하지 않는다는 점입니다.  고객의 진짜 문제를 발견하고, 올바른 것을 만들고, 사용자와 공감하고, 우선순위를 정하고, 팀을 정렬시키고, 데이터로 판단하는 이 모든 역량은 AI 시대에도 그대로 필요합니다. 오히려 더 중요해질 수도 있습니다. AI가 무엇이든 빠르게 만들 수 있게 될수록, "무엇을 왜 만들...]]></description><link>https://www.productcampus.co.kr/post/ai-%EC%8B%9C%EB%8C%80%EC%9D%98-%ED%94%84%EB%A1%9C%EB%8D%95%ED%8A%B8-%EB%A7%A4%EB%8B%88%EC%A0%80-%EC%83%88%EB%A1%9C-%ED%95%84%EC%9A%94%ED%95%9C-%EC%97%AD%EB%9F%89</link><guid isPermaLink="false">6a7bafdef1f88bc38bdbb3c2</guid><pubDate>Tue, 11 Aug 2026 23:28:11 GMT</pubDate><enclosure url="https://static.wixstatic.com/media/41ce11_eacc55742c434abd87747e462bc34f14~mv2.png/v1/fit/w_1000,h_720,al_c,q_80/file.png" length="0" type="image/png"/><dc:creator>js ahn</dc:creator></item><item><title><![CDATA[프로덕트 주도 성장(PLG): 제품이 성장을 이끈다]]></title><description><![CDATA[# 프로덕트 주도 성장(PLG): 제품이 성장을 이끈다  전통적으로 제품의 성장은 마케팅과 영업이 이끌었습니다. 광고로 알리고, 영업이 설득해 파는 것이죠. 그런데 언젠가부터 다른 방식이 주목받기 시작했습니다. 제품 자체가 성장의 엔진이 되는 방식, 바로 프로덕트 주도 성장(PLG)입니다. 사용자가 제품을 쓰다가 스스로 가치를 느끼고, 결제하고, 남에게 추천하는 흐름이죠. 이 글에서 PLG를 정리하겠습니다.  ## PLG란 무엇인가  프로덕트 주도 성장(Product-Led Growth, PLG)은 제품 그 자체가 사용자 획득, 전환, 확장의 주된 동력이 되는 성장 방식입니다. 마케팅이나 영업이 앞장서서 끌어오는 것이 아니라, 제품을 직접 경험한 사용자가 그 가치에 이끌려 스스로 고객이 되고 제품을 퍼뜨리는 것이죠.  핵심은 "제품이 스스로를 판다"는 것입니다. 사용자가 제품을 써보고 "이거 좋다"고 느끼면, 별다른 설득 없이도 계속 쓰고, 유료로 전환하고, 동료에게...]]></description><link>https://www.productcampus.co.kr/post/%ED%94%84%EB%A1%9C%EB%8D%95%ED%8A%B8-%EC%A3%BC%EB%8F%84-%EC%84%B1%EC%9E%A5-plg-%EC%A0%9C%ED%92%88%EC%9D%B4-%EC%84%B1%EC%9E%A5%EC%9D%84-%EC%9D%B4%EB%81%88%EB%8B%A4</link><guid isPermaLink="false">6a7bafa960971ea08f8ecd6a</guid><pubDate>Tue, 11 Aug 2026 23:26:47 GMT</pubDate><enclosure url="https://static.wixstatic.com/media/41ce11_eacc55742c434abd87747e462bc34f14~mv2.png/v1/fit/w_1000,h_720,al_c,q_80/file.png" length="0" type="image/png"/><dc:creator>js ahn</dc:creator></item><item><title><![CDATA[A/B 테스트와 실험 문화: 감이 아니라 데이터로]]></title><description><![CDATA[# A/B 테스트와 실험 문화: 감이 아니라 데이터로  "이 버튼을 파란색으로 할까 초록색으로 할까?" 회의실에서 이런 논쟁이 벌어지면, 대개 가장 목소리 크거나 직급 높은 사람의 의견이 이깁니다. 하지만 정말 어느 쪽이 나은지는 아무도 모릅니다. 이 소모적인 논쟁을 끝내는 방법이 있습니다. 둘 다 실제로 시험해보고 데이터로 답을 얻는 것이죠. 이것이 A/B 테스트이고, 그 바탕에 실험 문화가 있습니다. 이 글에서 정리하겠습니다.  ## A/B 테스트란 무엇인가  A/B 테스트는 두 가지 버전을 실제 사용자에게 나눠 보여주고, 어느 쪽이 더 나은 결과를 내는지 비교하는 방법입니다. 사용자의 절반에게는 A 버전을, 나머지 절반에게는 B 버전을 보여주고, 어느 쪽이 목표 지표에서 더 좋은 성과를 내는지 측정하는 것이죠.  A/B 테스트의 힘은 논쟁을 실증으로 대체한다는 데 있습니다. "내 생각엔 A가 나을 것 같아"라는 의견 대결 대신, 실제 사용자의 행동이라는 객관적 증거로 답을...]]></description><link>https://www.productcampus.co.kr/post/a-b-%ED%85%8C%EC%8A%A4%ED%8A%B8%EC%99%80-%EC%8B%A4%ED%97%98-%EB%AC%B8%ED%99%94-%EA%B0%90%EC%9D%B4-%EC%95%84%EB%8B%88%EB%9D%BC-%EB%8D%B0%EC%9D%B4%ED%84%B0%EB%A1%9C</link><guid isPermaLink="false">6a7baf70bc8e587d4397327d</guid><pubDate>Tue, 11 Aug 2026 23:25:52 GMT</pubDate><enclosure url="https://static.wixstatic.com/media/41ce11_d446ef7ddc1d498dbd2e2d89a8a03fc9~mv2.png/v1/fit/w_1000,h_720,al_c,q_80/file.png" length="0" type="image/png"/><dc:creator>js ahn</dc:creator></item><item><title><![CDATA[리텐션과 코호트 분석: 진짜 성장을 읽는 법]]></title><description><![CDATA[# 리텐션과 코호트 분석: 진짜 성장을 읽는 법  신규 사용자가 매달 늘어나면 제품이 성장하는 것처럼 보입니다. 하지만 그 뒤에서 기존 사용자가 그만큼 빠져나가고 있다면, 그것은 성장이 아니라 '밑 빠진 독에 물 붓기'입니다. 진짜 성장인지 아닌지를 가르는 핵심 지표가 리텐션, 즉 유지율입니다. 그리고 이를 제대로 보는 방법이 코호트 분석입니다. 이 글에서 진짜 성장을 읽는 법을 정리하겠습니다.  ## 리텐션이 왜 중요한가  리텐션(Retention)은 사용자가 제품을 계속 쓰며 돌아오는 정도입니다. 한 번 쓰고 떠나는 것이 아니라, 지속적으로 다시 찾아오는가를 나타내죠.  리텐션이 프로덕트에서 가장 중요한 지표로 꼽히는 이유가 있습니다. 리텐션은 제품이 진짜 가치를 주는지를 가장 정직하게 보여주기 때문입니다. 사용자가 계속 돌아온다는 것은 제품이 그들에게 지속적인 가치를 준다는 뜻입니다. 반대로 아무리 신규 유입이 많아도 사용자가 금방 떠난다면, 그 제품은 근본적인 가치...]]></description><link>https://www.productcampus.co.kr/post/%EB%A6%AC%ED%85%90%EC%85%98%EA%B3%BC-%EC%BD%94%ED%98%B8%ED%8A%B8-%EB%B6%84%EC%84%9D-%EC%A7%84%EC%A7%9C-%EC%84%B1%EC%9E%A5%EC%9D%84-%EC%9D%BD%EB%8A%94-%EB%B2%95</link><guid isPermaLink="false">6a7baf372ca7f56c717dc116</guid><pubDate>Tue, 11 Aug 2026 23:24:58 GMT</pubDate><enclosure url="https://static.wixstatic.com/media/41ce11_8d2afb4a4e7443c9a1666b2fb8d8f63b~mv2.png/v1/fit/w_1000,h_720,al_c,q_80/file.png" length="0" type="image/png"/><dc:creator>js ahn</dc:creator></item><item><title><![CDATA[프로덕트 지표의 이해: North Star Metric과 AARRR]]></title><description><![CDATA[# 프로덕트 지표의 이해: North Star Metric과 AARRR  "우리 제품 잘 되고 있나요?"라는 질문에 명확히 답하려면 지표가 필요합니다. 그런데 지표가 너무 많으면 오히려 무엇이 중요한지 혼란스럽고, 너무 적으면 제품을 제대로 이해하지 못합니다. 좋은 지표 체계는 "무엇 하나에 집중할지"와 "전체를 어떻게 볼지"를 함께 제공합니다. 그 대표적인 틀이 North Star Metric과 AARRR입니다. 이 글에서 프로덕트 지표를 정리하겠습니다.  ## 왜 지표가 중요한가  지표는 제품의 상태를 객관적으로 보여주는 신호입니다. 감이나 인상이 아니라 숫자로 "우리 제품이 어떤 상태이고 어디로 가는가"를 알려주죠.  지표가 중요한 이유는 두 가지입니다. 하나는 판단의 근거가 된다는 것입니다. 무엇이 효과가 있고 없는지를 지표로 확인해 결정을 내립니다. 다른 하나는 방향을 정렬시킨다는 것입니다. 팀이 같은 지표를 바라보면, 무엇을 위해 일하는지에 대한 공통의 기준이...]]></description><link>https://www.productcampus.co.kr/post/%ED%94%84%EB%A1%9C%EB%8D%95%ED%8A%B8-%EC%A7%80%ED%91%9C%EC%9D%98-%EC%9D%B4%ED%95%B4-north-star-metric%EA%B3%BC-aarrr</link><guid isPermaLink="false">6a7baf052ca7f56c717dc096</guid><pubDate>Tue, 11 Aug 2026 23:24:02 GMT</pubDate><enclosure url="https://static.wixstatic.com/media/41ce11_8d2afb4a4e7443c9a1666b2fb8d8f63b~mv2.png/v1/fit/w_1000,h_720,al_c,q_80/file.png" length="0" type="image/png"/><dc:creator>js ahn</dc:creator></item><item><title><![CDATA[출시 후 분석: 런치는 끝이 아니다]]></title><description><![CDATA[# 출시 후 분석: 런치는 끝이 아니다  출시일. 많은 팀이 이 날을 결승선으로 여깁니다. 몇 달간 고생한 끝에 제품을 내놓았으니, 축하하고 한숨 돌리고 싶은 마음이 들죠. 하지만 프로덕트의 관점에서 출시는 결승선이 아니라 출발선입니다. 진짜 중요한 일은 출시 이후에 시작됩니다. 제품이 실제로 어땠는지 확인하고 배우는 것, 그것이 출시 후 분석입니다. 이 글에서 정리하겠습니다.  ## 출시는 시작이다  앞서 여러 번 강조했듯, 제품은 프로젝트처럼 완료되는 것이 아닙니다. 출시는 "다 만들었다"의 순간이 아니라 "이제 진짜 시작"의 순간입니다.  출시 전까지 우리가 가진 것은 대부분 가정과 예측이었습니다. "사용자가 이렇게 반응할 것이다", "이 기능이 이런 성과를 낼 것이다" 같은 것들이죠. 출시는 이 가정들이 현실과 만나는 순간입니다. 실제 사용자가 실제로 어떻게 반응하는지, 우리의 예측이 맞았는지가 비로소 드러납니다. 이것을 확인하고 배우지 않으면, 출시의 절반만 한...]]></description><link>https://www.productcampus.co.kr/post/%EC%B6%9C%EC%8B%9C-%ED%9B%84-%EB%B6%84%EC%84%9D-%EB%9F%B0%EC%B9%98%EB%8A%94-%EB%81%9D%EC%9D%B4-%EC%95%84%EB%8B%88%EB%8B%A4</link><guid isPermaLink="false">6a7baec9bc8e587d439730dc</guid><pubDate>Tue, 11 Aug 2026 23:23:06 GMT</pubDate><enclosure url="https://static.wixstatic.com/media/41ce11_9cdf8519859e4b4fb254970cb39426cd~mv2.png/v1/fit/w_1000,h_720,al_c,q_80/file.png" length="0" type="image/png"/><dc:creator>js ahn</dc:creator></item><item><title><![CDATA[포지셔닝과 메시징: 어떻게 기억되는가]]></title><description><![CDATA[# 포지셔닝과 메시징: 어떻게 기억되는가  같은 제품이라도 어떻게 설명하느냐에 따라 완전히 다르게 인식됩니다. "그냥 메모 앱"과 "생각을 정리하는 두 번째 뇌"는 같은 제품일 수 있지만, 사람들의 마음에 남는 인상은 전혀 다르죠. 제품이 사람들의 머릿속에 어떤 자리를 차지하는가, 이것이 포지셔닝입니다. 그리고 그 자리를 전달하는 언어가 메시징입니다. 이 글에서 포지셔닝과 메시징을 정리하겠습니다.  ## 포지셔닝이란 무엇인가  포지셔닝(Positioning)은 제품이 고객의 마음속에서 차지하는 자리입니다. "우리 제품은 어떤 것이고, 다른 것들과 어떻게 다르며, 왜 이 고객에게 의미 있는가"를 사람들의 인식 속에 자리매김하는 것이죠.  포지셔닝이 중요한 이유는, 사람들이 제품을 인식하는 방식이 곧 그 제품의 성패를 좌우하기 때문입니다. 아무리 좋은 제품도 "그게 뭔지, 왜 필요한지" 명확히 인식되지 않으면 선택받지 못합니다. 반대로 명확한 포지셔닝은 "아, 이건 나를 위한...]]></description><link>https://www.productcampus.co.kr/post/%ED%8F%AC%EC%A7%80%EC%85%94%EB%8B%9D%EA%B3%BC-%EB%A9%94%EC%8B%9C%EC%A7%95-%EC%96%B4%EB%96%BB%EA%B2%8C-%EA%B8%B0%EC%96%B5%EB%90%98%EB%8A%94%EA%B0%80</link><guid isPermaLink="false">6a7bae8d60971ea08f8ecad7</guid><pubDate>Tue, 11 Aug 2026 23:22:09 GMT</pubDate><enclosure url="https://static.wixstatic.com/media/41ce11_928a6ca376b24f338c37ae9d975fae85~mv2.png/v1/fit/w_1000,h_720,al_c,q_80/file.png" length="0" type="image/png"/><dc:creator>js ahn</dc:creator></item><item><title><![CDATA[출시 준비와 체크리스트: 빠짐없이 준비하기]]></title><description><![CDATA[# 출시 준비와 체크리스트: 빠짐없이 준비하기  출시일이 다가오면 프로덕트 매니저의 마음은 분주해집니다. 챙겨야 할 것이 한둘이 아니기 때문이죠. 그런데 이 많은 것을 머릿속으로만 관리하다 보면 반드시 무언가를 놓칩니다. 그리고 출시 당일에 "아, 그걸 안 했네!"라는 사고가 터지죠. 이를 막아주는 것이 체계적인 출시 준비와 체크리스트입니다. 이 글에서 출시를 빠짐없이 준비하는 법을 정리하겠습니다.  ## 출시는 여러 팀의 합동 작업  출시는 프로덕트 팀만의 일이 아닙니다. 개발, 디자인, 마케팅, 세일즈, 고객지원 등 여러 팀이 함께 준비해야 하는 합동 작업입니다.  제품이 준비되는 것과 별개로, 마케팅은 알릴 준비를, 세일즈는 팔 준비를, 고객지원은 문의에 답할 준비를 해야 합니다. 이 여러 팀의 준비가 출시 시점에 맞춰 정렬되어야 매끄러운 출시가 이루어집니다. 그래서 프로덕트 매니저는 출시를 앞두고 여러 팀의 준비 상황을 조율하는 허브 역할을 합니다.  ## 출시...]]></description><link>https://www.productcampus.co.kr/post/%EC%B6%9C%EC%8B%9C-%EC%A4%80%EB%B9%84%EC%99%80-%EC%B2%B4%ED%81%AC%EB%A6%AC%EC%8A%A4%ED%8A%B8-%EB%B9%A0%EC%A7%90%EC%97%86%EC%9D%B4-%EC%A4%80%EB%B9%84%ED%95%98%EA%B8%B0</link><guid isPermaLink="false">6a7bae16bc8e587d43972f29</guid><pubDate>Tue, 11 Aug 2026 23:20:58 GMT</pubDate><enclosure url="https://static.wixstatic.com/media/41ce11_d0807e82ef444360a0267ed996d68b26~mv2.png/v1/fit/w_1000,h_720,al_c,q_80/file.png" length="0" type="image/png"/><dc:creator>js ahn</dc:creator></item><item><title><![CDATA[Go-to-Market 전략: 제품을 시장에 소개하기]]></title><description><![CDATA[# Go-to-Market 전략: 제품을 시장에 소개하기  훌륭한 제품을 만들었다고 성공이 보장되는 것은 아닙니다. 아무리 좋은 제품도 사람들이 알지 못하면, 혹은 잘못된 방식으로 소개되면 실패합니다. "좋은 제품은 알아서 팔린다"는 순진한 믿음이 많은 제품을 무덤으로 보냈죠. 제품을 세상에 제대로 내놓는 계획, 그것이 Go-to-Market 전략입니다. 이 글에서 GTM 전략을 정리하겠습니다.  ## Go-to-Market 전략이란 무엇인가  Go-to-Market(GTM) 전략은 제품을 시장에 소개하고 고객에게 도달시키는 계획입니다. "누구에게, 어떻게 이 제품을 알리고, 어떻게 그들이 쓰게 만들 것인가"에 대한 전략이죠.  GTM이 중요한 이유는, 제품을 만드는 것과 제품을 성공시키는 것이 다른 일이기 때문입니다. 만드는 것은 절반이고, 나머지 절반은 그것을 올바른 사람들에게 올바른 방식으로 전달하는 것입니다. GTM 전략은 이 나머지 절반을 다룹니다.  ## GTM이...]]></description><link>https://www.productcampus.co.kr/post/go-to-market-%EC%A0%84%EB%9E%B5-%EC%A0%9C%ED%92%88%EC%9D%84-%EC%8B%9C%EC%9E%A5%EC%97%90-%EC%86%8C%EA%B0%9C%ED%95%98%EA%B8%B0</link><guid isPermaLink="false">6a7badd82ca7f56c717dbde6</guid><pubDate>Tue, 11 Aug 2026 23:19:06 GMT</pubDate><enclosure url="https://static.wixstatic.com/media/41ce11_4ef90e412a554772b307545c073faa4b~mv2.png/v1/fit/w_1000,h_720,al_c,q_80/file.png" length="0" type="image/png"/><dc:creator>js ahn</dc:creator></item><item><title><![CDATA[데이터 분석팀과의 협업: 데이터로 방향 찾기]]></title><description><![CDATA[# 데이터 분석팀과의 협업: 데이터로 방향 찾기  "감이 아니라 데이터로 결정하라"는 말은 프로덕트 세계의 금언입니다. 하지만 데이터로 결정하려면 데이터를 제대로 다룰 수 있어야 하고, 이는 많은 경우 데이터 분석 전문가와의 협업을 통해 이루어집니다. 프로덕트 매니저가 모든 분석을 직접 할 수는 없기에, 데이터 분석팀과 잘 협업하는 것이 데이터 기반 의사결정의 관건입니다. 이 글에서 데이터 분석팀과 협업하는 법을 정리하겠습니다.  ## 왜 데이터가 중요한가  프로덕트 매니지먼트에서 데이터가 중요한 이유는, 그것이 추측을 사실로 바꿔주기 때문입니다.  "사용자가 이 기능을 좋아할 거야", "이 화면에서 이탈이 많을 거야" 같은 추측은 틀릴 수 있습니다. 데이터는 이런 추측을 검증하거나 반박합니다. 실제로 사용자가 무엇을 하는지, 어디서 떠나는지, 무엇이 효과가 있는지를 객관적으로 보여주죠. 데이터에 기반한 결정은 개인의 감이나 목소리 큰 사람의 의견보다 훨씬 믿을 만합니다. ...]]></description><link>https://www.productcampus.co.kr/post/%EB%8D%B0%EC%9D%B4%ED%84%B0-%EB%B6%84%EC%84%9D%ED%8C%80%EA%B3%BC%EC%9D%98-%ED%98%91%EC%97%85-%EB%8D%B0%EC%9D%B4%ED%84%B0%EB%A1%9C-%EB%B0%A9%ED%96%A5-%EC%B0%BE%EA%B8%B0</link><guid isPermaLink="false">6a7bada160971ea08f8ec8ba</guid><pubDate>Tue, 11 Aug 2026 23:18:09 GMT</pubDate><enclosure url="https://static.wixstatic.com/media/41ce11_df209020a05b438dbf5421848b716cee~mv2.png/v1/fit/w_1000,h_720,al_c,q_80/file.png" length="0" type="image/png"/><dc:creator>js ahn</dc:creator></item><item><title><![CDATA[릴리스 관리와 품질: 안전하게 내보내기]]></title><description><![CDATA[# 릴리스 관리와 품질: 안전하게 내보내기  열심히 만든 기능을 드디어 사용자에게 내보내는 순간, 설렘과 함께 긴장이 밀려옵니다. "혹시 문제가 생기면 어쩌지?" 하는 걱정이죠. 실제로 릴리스는 위험한 순간입니다. 잘못 내보내면 사용자에게 나쁜 경험을 주고, 신뢰를 잃고, 수습에 큰 비용이 듭니다. 그래서 무엇을 만들지만큼이나 어떻게 안전하게 내보낼지가 중요합니다. 이 글에서 릴리스 관리와 품질을 정리하겠습니다.  ## 릴리스는 신중해야 하는 순간  릴리스(Release)는 만든 것을 실제 사용자에게 내보내는 것입니다. 개발이 끝났다고 곧바로 모두에게 공개하는 것이 아니라, 신중하게 관리해야 하는 과정이죠.  릴리스가 신중해야 하는 이유는, 이 순간이 사용자에게 직접 영향을 주기 때문입니다. 내부에서 아무리 잘 만들었어도, 실제 환경에서 예상치 못한 문제가 생길 수 있습니다. 그리고 그 문제는 곧바로 사용자의 경험을 해치고 신뢰를 무너뜨립니다. 그래서 릴리스는 "완성했으니...]]></description><link>https://www.productcampus.co.kr/post/%EB%A6%B4%EB%A6%AC%EC%8A%A4-%EA%B4%80%EB%A6%AC%EC%99%80-%ED%92%88%EC%A7%88-%EC%95%88%EC%A0%84%ED%95%98%EA%B2%8C-%EB%82%B4%EB%B3%B4%EB%82%B4%EA%B8%B0</link><guid isPermaLink="false">6a7bad62bc8e587d43972d7e</guid><pubDate>Tue, 11 Aug 2026 23:17:07 GMT</pubDate><enclosure url="https://static.wixstatic.com/media/41ce11_eeedbc1ddd884bb29c7e5a8d48278500~mv2.png/v1/fit/w_1000,h_720,al_c,q_80/file.png" length="0" type="image/png"/><dc:creator>js ahn</dc:creator></item><item><title><![CDATA[애자일·스크럼과 프로덕트 매니저: 함께 일하는 법]]></title><description><![CDATA[# 애자일·스크럼과 프로덕트 매니저: 함께 일하는 법  오늘날 대부분의 프로덕트 팀은 애자일 방식으로 일합니다. 짧은 주기로 만들고 피드백을 받아 개선하는 이 방식은 프로덕트 매니지먼트와 잘 맞습니다. 그래서 프로덕트 매니저는 애자일, 특히 스크럼을 이해하고 그 안에서 자신의 역할을 잘 수행해야 합니다. 그런데 여기서 프로덕트 매니저와 프로덕트 오너의 관계가 다시 등장합니다. 이 글에서 애자일 환경에서 프로덕트 매니저가 일하는 법을 정리하겠습니다.  ## 애자일이 프로덕트와 잘 맞는 이유  애자일은 짧은 주기로 만들고, 피드백을 받아, 방향을 조정하며 일하는 방식입니다. 이것이 프로덕트 매니지먼트와 잘 맞는 이유는 분명합니다.  제품 개발은 본질적으로 불확실합니다. 무엇이 성공할지 미리 다 알 수 없죠. 애자일은 이 불확실성을 다루기에 적합합니다. 작게 만들어 사용자 반응을 확인하고, 배운 것을 바탕으로 다음을 조정하는 애자일의 리듬은, 앞서 다룬 "만들고-측정하고-배우는"...]]></description><link>https://www.productcampus.co.kr/post/%EC%95%A0%EC%9E%90%EC%9D%BC-%EC%8A%A4%ED%81%AC%EB%9F%BC%EA%B3%BC-%ED%94%84%EB%A1%9C%EB%8D%95%ED%8A%B8-%EB%A7%A4%EB%8B%88%EC%A0%80-%ED%95%A8%EA%BB%98-%EC%9D%BC%ED%95%98%EB%8A%94-%EB%B2%95</link><guid isPermaLink="false">6a7bad2460971ea08f8ec78e</guid><pubDate>Tue, 11 Aug 2026 23:16:04 GMT</pubDate><enclosure url="https://static.wixstatic.com/media/41ce11_3a318e368f5d4e9585f783334b2aa127~mv2.png/v1/fit/w_1000,h_720,al_c,q_80/file.png" length="0" type="image/png"/><dc:creator>js ahn</dc:creator></item><item><title><![CDATA[프로덕트 딜리버리: 개발팀과 협업하는 법]]></title><description><![CDATA[# 프로덕트 딜리버리: 개발팀과 협업하는 법  디스커버리로 올바른 것을 찾고 계획까지 세웠다면, 이제 실제로 만들어 사용자에게 전달할 차례입니다. 이것이 딜리버리이고, 그 중심에는 개발팀과의 협업이 있습니다. 프로덕트 매니저가 개발을 직접 하지는 않지만, 개발팀과 어떻게 협업하느냐가 제품의 성패를 크게 좌우합니다. 좋은 협업은 좋은 제품을 낳고, 나쁜 협업은 좋은 아이디어도 망칩니다. 이 글에서 개발팀과 협업하는 법을 정리하겠습니다.  ## 딜리버리란 무엇인가  프로덕트 딜리버리(Delivery)는 정의되고 검증된 솔루션을 실제로 만들어 사용자에게 가치를 전달하는 활동입니다. 앞서 다룬 디스커버리가 "올바른 것을 찾는 일"이라면, 딜리버리는 "그것을 제대로 만드는 일"입니다.  딜리버리 단계에서 PM의 역할은 직접 만드는 것이 아니라, 개발팀이 올바른 것을 잘 만들 수 있도록 돕는 것입니다. 명확한 방향을 제시하고, 막힌 것을 풀어주고, 결정을 내리고, 팀이 집중할 수 있는...]]></description><link>https://www.productcampus.co.kr/post/%ED%94%84%EB%A1%9C%EB%8D%95%ED%8A%B8-%EB%94%9C%EB%A6%AC%EB%B2%84%EB%A6%AC-%EA%B0%9C%EB%B0%9C%ED%8C%80%EA%B3%BC-%ED%98%91%EC%97%85%ED%95%98%EB%8A%94-%EB%B2%95</link><guid isPermaLink="false">6a7bac40f1f88bc38bdbab59</guid><pubDate>Tue, 11 Aug 2026 23:12:13 GMT</pubDate><enclosure url="https://static.wixstatic.com/media/41ce11_dd01658f3421477f83cd75dc7e003856~mv2.png/v1/fit/w_1000,h_720,al_c,q_80/file.png" length="0" type="image/png"/><dc:creator>js ahn</dc:creator></item><item><title><![CDATA[이해관계자 관리: 권한 없이 설득하는 법]]></title><description><![CDATA[# 이해관계자 관리: 권한 없이 설득하는 법  프로덕트 매니저의 가장 큰 딜레마가 있습니다. 제품의 성공을 책임지지만, 정작 함께 일하는 사람들에 대한 직접적인 권한은 없다는 것입니다. 개발자에게 명령할 수도, 경영진의 결정을 강제할 수도 없죠. 그런데도 이 모든 사람을 같은 방향으로 움직여야 합니다. 이것이 이해관계자 관리이며, PM의 진짜 실력이 드러나는 영역입니다. 이 글에서 권한 없이 사람을 움직이는 법을 정리하겠습니다.  ## PM은 권한 없이 일한다  프로덕트 매니저는 흔히 "권한 없는 책임자"라고 불립니다. 제품에 관여하는 개발, 디자인, 마케팅, 영업, 경영진 등 수많은 사람에 대해 인사 권한이나 지휘 권한이 없습니다. 그럼에도 이들을 하나의 방향으로 정렬시켜 제품을 성공시켜야 하죠.  그래서 PM은 권한이 아니라 영향력으로 일합니다. 명령이 아니라 설득으로, 지시가 아니라 신뢰로 사람을 움직입니다. 이것이 PM에게 소프트 스킬이 그토록 중요한 이유입니다. 권한...]]></description><link>https://www.productcampus.co.kr/post/%EC%9D%B4%ED%95%B4%EA%B4%80%EA%B3%84%EC%9E%90-%EA%B4%80%EB%A6%AC-%EA%B6%8C%ED%95%9C-%EC%97%86%EC%9D%B4-%EC%84%A4%EB%93%9D%ED%95%98%EB%8A%94-%EB%B2%95</link><guid isPermaLink="false">6a7bac062ca7f56c717db94f</guid><pubDate>Tue, 11 Aug 2026 23:11:18 GMT</pubDate><enclosure url="https://static.wixstatic.com/media/41ce11_b700c3cf3a83497bb540bbb8aedc6795~mv2.png/v1/fit/w_1000,h_720,al_c,q_80/file.png" length="0" type="image/png"/><dc:creator>js ahn</dc:creator></item><item><title><![CDATA[사용자 스토리와 백로그 관리: 개발과 잇는 언어]]></title><description><![CDATA[# 사용자 스토리와 백로그 관리: 개발과 잇는 언어  PRD로 무엇을 만들지 정의했다면, 이제 그것을 개발팀이 실제로 작업할 수 있는 단위로 풀어야 합니다. 큰 요구사항을 그대로 던지면 개발팀은 어디서부터 손대야 할지 막막합니다. 이때 필요한 것이 사용자 스토리와 백로그입니다. 이 둘은 프로덕트 매니저와 개발팀을 잇는 공통 언어이자 작업의 원천입니다. 이 글에서 정리하겠습니다.  ## 사용자 스토리란 무엇인가  사용자 스토리(User Story)는 사용자의 관점에서 요구사항을 짧게 표현한 것입니다. 기술 명세가 아니라 "어떤 사용자가 무엇을 왜 원하는가"를 사람의 언어로 담습니다.  흔히 "누가, 무엇을, 왜"의 형식으로 씁니다. 예를 들어 "쇼핑몰 고객으로서, 주문 내역을 한눈에 보고 싶다, 왜냐하면 내가 무엇을 샀는지 쉽게 확인하기 위해"처럼요. 이 형식의 힘은 '왜'에 있습니다. 목적을 담으면 개발팀이 단순히 시키는 것을 만드는 것을 넘어, 그 목적을 이루는 최선의 방법을...]]></description><link>https://www.productcampus.co.kr/post/%EC%82%AC%EC%9A%A9%EC%9E%90-%EC%8A%A4%ED%86%A0%EB%A6%AC%EC%99%80-%EB%B0%B1%EB%A1%9C%EA%B7%B8-%EA%B4%80%EB%A6%AC-%EA%B0%9C%EB%B0%9C%EA%B3%BC-%EC%9E%87%EB%8A%94-%EC%96%B8%EC%96%B4</link><guid isPermaLink="false">6a7babcc2ca7f56c717db8b3</guid><pubDate>Tue, 11 Aug 2026 23:10:19 GMT</pubDate><enclosure url="https://static.wixstatic.com/media/41ce11_cf90ada958384d6f8b1f808ba20a1b4f~mv2.png/v1/fit/w_1000,h_720,al_c,q_80/file.png" length="0" type="image/png"/><dc:creator>js ahn</dc:creator></item><item><title><![CDATA[PRD 작성법: 명확한 제품 요구사항 문서]]></title><description><![CDATA[# PRD 작성법: 명확한 제품 요구사항 문서  무엇을 만들지 정했다면, 이제 그것을 팀에 정확히 전달해야 합니다. 아무리 좋은 아이디어도 개발자와 디자이너에게 제대로 전달되지 않으면 엉뚱하게 구현됩니다. 이 전달의 핵심 도구가 PRD, 즉 제품 요구사항 문서입니다. PRD는 프로덕트 매니저의 대표적인 산출물이지만, 잘 쓰기는 의외로 어렵습니다. 이 글에서 명확한 PRD를 쓰는 법을 정리하겠습니다.  ## PRD란 무엇인가  PRD(Product Requirements Document)는 만들려는 제품이나 기능이 무엇이고 왜 만드는지, 무엇을 충족해야 하는지를 정리한 문서입니다. 팀이 "무엇을, 왜 만드는가"에 대해 같은 이해를 갖게 하는 것이 목적이죠.  PRD의 핵심 역할은 정렬입니다. PM의 머릿속에 있는 그림을 문서로 명확히 해, 개발·디자인·기타 이해관계자가 모두 같은 것을 이해하도록 만드는 것입니다. 문서가 없으면 각자 다르게 이해하고, 나중에 "이게 아닌데"라는...]]></description><link>https://www.productcampus.co.kr/post/prd-%EC%9E%91%EC%84%B1%EB%B2%95-%EB%AA%85%ED%99%95%ED%95%9C-%EC%A0%9C%ED%92%88-%EC%9A%94%EA%B5%AC%EC%82%AC%ED%95%AD-%EB%AC%B8%EC%84%9C</link><guid isPermaLink="false">6a7bab91bc8e587d4397290a</guid><pubDate>Tue, 11 Aug 2026 23:09:23 GMT</pubDate><enclosure url="https://static.wixstatic.com/media/41ce11_b1f82afc4ba04bea8f6e1158d73b2359~mv2.png/v1/fit/w_1000,h_720,al_c,q_80/file.png" length="0" type="image/png"/><dc:creator>js ahn</dc:creator></item><item><title><![CDATA[우선순위 결정 프레임워크: RICE·ICE·MoSCoW·Kano]]></title><description><![CDATA[# 우선순위 결정 프레임워크: RICE·ICE·MoSCoW·Kano  프로덕트 매니저의 일상은 끝없는 선택의 연속입니다. 할 수 있는 일은 많고, 시간과 자원은 늘 부족하죠. "무엇을 먼저 할 것인가"라는 우선순위 결정이야말로 PM의 핵심 역량입니다. 그런데 감으로만 결정하면 일관성이 없고 설득하기도 어렵습니다. 이때 도움이 되는 것이 우선순위 프레임워크입니다. 이 글에서 대표적인 프레임워크들을 정리하겠습니다.  ## 왜 프레임워크가 필요한가  우선순위를 감으로 정하면 몇 가지 문제가 생깁니다. 결정이 일관되지 않고, 무엇을 왜 먼저 하는지 설명하기 어려우며, 목소리 큰 사람의 요청에 휘둘리기 쉽습니다.  프레임워크는 이 문제를 해결합니다. 우선순위를 정하는 명확한 기준을 제공해, 일관되고 방어 가능한 결정을 빠르게 내리게 해주죠. 여러 후보를 같은 잣대로 비교할 수 있어, "왜 이것을 먼저 하는가"를 논리적으로 설명할 수 있습니다. 중요한 것은 어느 프레임워크가 최고냐가...]]></description><link>https://www.productcampus.co.kr/post/%EC%9A%B0%EC%84%A0%EC%88%9C%EC%9C%84-%EA%B2%B0%EC%A0%95-%ED%94%84%EB%A0%88%EC%9E%84%EC%9B%8C%ED%81%AC-rice-ice-moscow-kano</link><guid isPermaLink="false">6a7baac92ca7f56c717db67a</guid><pubDate>Tue, 11 Aug 2026 23:05:59 GMT</pubDate><enclosure url="https://static.wixstatic.com/media/41ce11_8bc8bddec0aa4dbc8e19ddd9c9c5bbc2~mv2.png/v1/fit/w_1000,h_720,al_c,q_80/file.png" length="0" type="image/png"/><dc:creator>js ahn</dc:creator></item><item><title><![CDATA[프로덕트 로드맵 만들기: 기능 목록이 아니다]]></title><description><![CDATA[# 프로덕트 로드맵 만들기: 기능 목록이 아니다  프로덕트 로드맵은 프로덕트 매니저의 대표적인 산출물이지만, 동시에 가장 오해받는 것이기도 합니다. 많은 사람이 로드맵을 "언제 어떤 기능을 출시할지 적은 일정표"로 여기죠. 하지만 이렇게 만든 로드맵은 지키지 못할 약속이 되고, 팀을 기능 찍어내기로 몰아갑니다. 좋은 로드맵은 기능 목록이 아니라 전략의 표현입니다. 이 글에서 제대로 된 로드맵을 정리하겠습니다.  ## 로드맵이란 무엇인가  프로덕트 로드맵(Product Roadmap)은 프로덕트 비전과 전략이 구현되는 방법을 시간 중심으로 시각화한 것입니다. "우리가 어디로, 어떤 순서로 나아갈 것인가"를 보여주는 지도죠.  여기서 핵심은 로드맵이 비전과 전략의 표현이라는 점입니다. 로드맵은 진공 상태에서 나오는 것이 아니라, 앞서 세운 비전과 전략을 시간의 흐름으로 풀어낸 것입니다. 그래서 좋은 로드맵을 보면 "이 팀이 무엇을 이루려 하고, 그것을 어떤 순서로 접근하는가"라는...]]></description><link>https://www.productcampus.co.kr/post/%ED%94%84%EB%A1%9C%EB%8D%95%ED%8A%B8-%EB%A1%9C%EB%93%9C%EB%A7%B5-%EB%A7%8C%EB%93%A4%EA%B8%B0-%EA%B8%B0%EB%8A%A5-%EB%AA%A9%EB%A1%9D%EC%9D%B4-%EC%95%84%EB%8B%88%EB%8B%A4</link><guid isPermaLink="false">6a7baa55bc8e587d4397263d</guid><pubDate>Tue, 11 Aug 2026 23:05:05 GMT</pubDate><enclosure url="https://static.wixstatic.com/media/41ce11_9e50e0125b2a4d8a93bfc84f3571a446~mv2.png/v1/fit/w_1000,h_720,al_c,q_80/file.png" length="0" type="image/png"/><dc:creator>js ahn</dc:creator></item><item><title><![CDATA[디스커버리 vs 딜리버리: 듀얼 트랙]]></title><description><![CDATA[# 디스커버리 vs 딜리버리: 듀얼 트랙  프로덕트 팀은 두 가지 서로 다른 일을 동시에 해야 합니다. 하나는 "올바른 것을 찾는 일"이고, 다른 하나는 "제대로 만드는 일"입니다. 이 둘은 성격이 완전히 다른데, 많은 팀이 이를 하나의 흐름으로 뭉뚱그리다가 어려움을 겪습니다. 이 둘을 구분하고 병행하는 방식이 듀얼 트랙입니다. 이 글에서 디스커버리와 딜리버리, 그리고 그것을 함께 굴리는 법을 정리하겠습니다.  ## 두 가지 다른 일  프로덕트 개발에는 성격이 다른 두 종류의 활동이 있습니다.  **디스커버리(Discovery)** 는 "올바른 것을 찾는 일"입니다. 고객의 문제를 발견하고, 해결책을 탐색하고, 가설을 검증하는 활동이죠. 지금까지 다룬 리서치, 인터뷰, 문제 정의, 프로토타이핑, MVP 검증이 모두 디스커버리에 속합니다. 핵심 질문은 "우리가 올바른 것을 만들려 하는가?"입니다.  **딜리버리(Delivery)** 는 "제대로 만드는 일"입니다. 검증된 솔루션을...]]></description><link>https://www.productcampus.co.kr/post/%EB%94%94%EC%8A%A4%EC%BB%A4%EB%B2%84%EB%A6%AC-vs-%EB%94%9C%EB%A6%AC%EB%B2%84%EB%A6%AC-%EB%93%80%EC%96%BC-%ED%8A%B8%EB%9E%99</link><guid isPermaLink="false">6a7baa09f1f88bc38bdba613</guid><pubDate>Tue, 11 Aug 2026 23:03:06 GMT</pubDate><enclosure url="https://static.wixstatic.com/media/41ce11_9e50e0125b2a4d8a93bfc84f3571a446~mv2.png/v1/fit/w_1000,h_720,al_c,q_80/file.png" length="0" type="image/png"/><dc:creator>js ahn</dc:creator></item><item><title><![CDATA[MVP 제대로 이해하기: 최소 기능 제품의 함정]]></title><description><![CDATA[# MVP 제대로 이해하기: 최소 기능 제품의 함정  MVP는 프로덕트 업계에서 가장 자주 쓰이면서도 가장 자주 오해되는 개념입니다. "일단 대충 만들어서 빨리 내보내는 것"쯤으로 여기는 경우가 많죠. 하지만 이런 오해는 조악한 제품을 정당화하는 핑계가 되곤 합니다. MVP의 진짜 의미를 이해하면, 그것이 "대충"과는 전혀 다른 정교한 전략임을 알게 됩니다. 이 글에서 MVP를 제대로 정리하겠습니다.  ## MVP란 무엇인가  MVP(Minimum Viable Product, 최소 기능 제품)는 핵심 가설을 검증하기 위해 만드는, 최소한의 기능을 갖춘 제품입니다. 아이디어가 맞는지 가장 적은 노력으로 확인하기 위한 것이죠.  여기서 세 단어가 모두 중요합니다. **최소(Minimum)** 는 필요 이상으로 만들지 않는다는 뜻이고, **기능(Viable)** 은 그럼에도 실제로 가치를 제공해 검증이 가능해야 한다는 뜻이며, **제품(Product)** 은 사용자가 실제로 써볼 수...]]></description><link>https://www.productcampus.co.kr/post/mvp-%EC%A0%9C%EB%8C%80%EB%A1%9C-%EC%9D%B4%ED%95%B4%ED%95%98%EA%B8%B0-%EC%B5%9C%EC%86%8C-%EA%B8%B0%EB%8A%A5-%EC%A0%9C%ED%92%88%EC%9D%98-%ED%95%A8%EC%A0%95</link><guid isPermaLink="false">6a7ba962bc8e587d439723d7</guid><pubDate>Tue, 11 Aug 2026 23:00:05 GMT</pubDate><enclosure url="https://static.wixstatic.com/media/41ce11_aa117875dd1f453e859fd85d7c9e0aca~mv2.png/v1/fit/w_1000,h_720,al_c,q_80/file.png" length="0" type="image/png"/><dc:creator>js ahn</dc:creator></item></channel></rss>