📆 메이커의 레시피 연말 결산, 올해의 코멘트는?

메이커의 레시피 연말 결산

안녕하세요. 구독자님, 오늘도 팁스터 뉴스레터와 함께 해주셔서 감사합니다.

2024년 한 해, 메이커의 레시피는 정말 다양한 메이커와 주제별 이야기를 나눌 수 있었어요. 올해 마지막 레터에서는 발행한 주제 중 에디터들이 다시 꼭 소개하고 싶은 주제와 메이커의 코멘트를 정리해 봤어요. 이번 레터 아래에는 내년 1월 시작되는 소셜 러닝 클럽(북클럽)에 대한 상세 소개와 신청 링크가 포함되어 있으니 함께 꼭 확인해 주세요!

우선순위 설정이 중요한 이유

지난 5월 발행된 🤩 메이커의 레시피 : 우선순위 설정이 중요한 이유 편에서는 4명의 메이커를 만나봤는데요. 제한된 시간과 리소스 내에서 업무를 효율적으로 진행하고, 방향성을 수립하기 위해 우선순위 설정이 매우 중요하다 의견을 모았어요.

우선순위 설정 시 활용하는 기준도 다양했는데요. 그 중 PO 스테파네트 메이커는 우선순위의 결과 임팩트와 일정을 전반적으로 고려하는 방식을 소개했어요.

Q. 우선순위를 설정할 때 어떤 기준으로 진행하나요?

우선순위 설정은 다음과 같은 기준으로 판단하고 있어요.

얼마나 시급한지 (하거나/하지 않았을 때의 파급력이 곧바로 발생하는지)
비즈니스 임팩트 (KPI 달성 기여도, 마케팅 효과, 사용자 확보, 비용 절감 등)
얼마나 빠르게 완료할 수 있는지
일의 규모 (프로젝트 또는 개별업무를 완료하는데 걸리는 시간)

메이커가 추천한 자료 : [팬을 만드는 비즈니스 15] 우선 순위 중요성

스테파네트 PO님의 우선순위 설정 시 활용하는 기준은 2025년 우선순위를 설정하는데 도움 될 것 같아 다시 한번 보면 좋을 코멘트로 선정했는데요.

우선순위를 설정하는데 여러 가지 기법이 있어요. 가장 많이 사용하는 X축과 Y축을 바탕으로 업무를 나열하는 ‘우선순위 매트릭스 기법’부터 반드시 해야 하는 일부터 할 가치가 없는 일 순서로 나열하는 ‘MoSCoW 방법’ 등 방식과 방법론은 계속해서 발전해나가고 있죠.

다가오는 2025년에는 우리 팀에 어울리는 방식으로 새롭게 목표를 설정, 우선순위를 설정해보면 어떨까요?

💡함께 읽어보면 좋은 아티클 : 🚀 가장 유명한 10가지 우선순위 지정 기법. 워렌 버핏처럼 우선순위를 정해보자

3명의 메이커와 함께한 벤치마킹의 모든 것

지난 9월에 발행된 🎯 3명의 메이커와 함께한 벤치마킹의 모든 것 편에서는 3명의 PM, PO, 프로덕트 디자이너가 실무에서 벤치마킹을 어떻게 진행하고 활용하는지에 대한 내용을 담았어요. 메이커들은 제품을 성공적으로 출시하고 성장시키기 위해 벤치마킹을 적극적으로 활용, 도움이 될 만한 인사이트를 발견하는데요. 하지만 벤치마킹 대상이 타 프로덕트나,기업인 만큼 메이커들이 경계해야 할 점도 존재해요.

관련해, PO Dionysos님이 벤치마킹을 처음 시작하는 메이커에게 전해준 의견을 다시 한 번 살펴보고자 합니다.

Q. 벤치마킹 시 경계해야 할 점이나 유의해야 할 윤리적 기준 등 벤치마킹을 처음 시작하는 메이커들에게 해주고 싶은 조언이 있다면 무엇인가요?

벤치마킹을 통해 빠르게 성과를 내고 싶을 수 있지만, 장기적인 브랜드 신뢰와 평판을 고려하는 게 중요해요. 단기 성과보다는 벤치마킹 인사이트를 장기 전략에 통합해 지속 가능한 성장을 추구해야 해요.

벤치마킹은 다른 기업의 성공을 복제하는 게 아니라, 배움의 과정이에요. 타사의 성공 사례에서 배울 점을 찾으면서도 우리만의 철학과 비전을 유지하는 게 필수적이에요. 타사의 전략이나 기능을 그대로 모방하기보다는, 우리 제품이나 서비스에 맞는 창의적이고 독창적인 해결책을 개발하는 게 중요해요.

또한, 벤치마킹을 할 때는 그 기업이 성공한 맥락을 충분히 이해해야 해요. 다른 기업의 전략이 우리에게도 유효할지는 시장, 고객군, 비즈니스 모델 등 다양한 요소에 따라 달라질 수 있어요. 이러한 맥락을 고려한 후에 적용해야 실질적인 효과를 기대할 수 있어요.

마지막으로, 벤치마킹은 한 번으로 끝나는 게 아니라, 지속적인 학습과 조정이 필요한 과정이에요. 시장과 기술은 끊임없이 변화하므로, 벤치마킹도 정기적으로 이루어져야 하고, 필요에 따라 전략을 유연하게 조정하는 게 중요해요. 이렇게 하면, 우리만의 독창성을 유지하면서도 최신 트렌드를 반영하는 균형을 이룰 수 있어요.

프로덕트를 기획하는 메이커로 벤치마킹을 하면서 다른 기업의 전략이 우리에게도 유효할지에 대한 맥락을 이해해야 한다는 부분이 인상 깊었어요.

타사가 어떤 기능을 구축하거나 개선해서 이뤄낸 성공 사례를 보면서, 때로는 그 기능 자체가 성공의 열쇠라고 착각할 수 있다고 생각해요. 같은 도메인의 제품이라도 사용자의 연령대나 니즈가 다를 수 있고, 해당 기업이 이전부터 꾸준히 일구어 놓은 단계적인 개선이 있었기에 성공했을 수도 있는데 말이죠. 벤치마킹을 하면서 겉으로 보이는 결과뿐만 아니라 성공의 맥락까지 깊이 고려해야 한다는 점을 스스로 되새기며, 다시 한번 돌아보고 싶었어요!

💡함께 읽어보면 좋은 아티클 : 복제가 아닌 창조를 위한 서비스 벤치마킹법

유저 스토리의 핵심 구성 요소는 무엇일까?

10월에 발행된 🎯유저 스토리의 핵심 구성 요소는 무엇일까? 편에서는 세 명의 메이커들이 유저스토리 작성 노하우를 공유해 주셨습니다! 유저 스토리는 프로덕트에서 사용자가 할 수 있는 행동을 서술하는 방식으로, 개발팀과 비즈니스팀이 공동의 목표를 가지고 소통하는 데에 활용됩니다. 하지만 메이커가 사용자 관점에서 프로덕트를 바라보면서 유저 스토리를 작성하는 일이 쉽진 않죠.😣

이 과정에서 8년 차 PO 생존캠핑님이 유저 스토리 작성 시 자주 범하는 실수와 이에 대한 간단한 조언을 들려주셨었는데요, 다시 확인해볼까요?

Q. 유저 스토리 작성 시 자주 범하는 실수는 무엇인가요?

자주 범하는 실수 중 하나는 너무 광범위하거나 모호한 스토리 작성인데요. 구체적인 사용자와 상황을 상정하지 않으면 개발 과정에서 방향을 잃기 쉬워요. 또 하나는 수용(인수) 기준을 불명확하게 설정하는 거예요. 인수의 기준이 명확하지 않으면 실제로 기능이 완성되었을 때는 물론 테스트 과정 등에서도 무엇을, 어떻게 평가해야 할지 서로 헷갈리는 상황을 마주할 수 있어요.

예를 들어, "사용자는 알림을 통해 서비스 활동에 대한 업데이트를 받을 수 있다’와 "사용자는 알림을 통해 카테고리별 활동 업데이트를 받을 수 있다”에는 세부적인 상황이 다르게 기입되어 있는데요. 후자의 경우 ‘카테고리’에 따른 우선순위 구분도 가능하며, 그에 따른 인수 기준도 구체적으로 작성할 수 있어요.

유저 스토리를 작성하면서 스스로 사용자가 수행하는 Task를 너무 모호하게 작성하는 것이 아닌가 하는 고민이 있었을 때, 생존캠핑님의 답변을 보고 다시 제가 작성한 유저 스토리를 점검하게 되었어요.

”사용자는 (목적)을 위해 (액션)을 한다.” 라는 형식으로 유저 스토리를 작성하는데, 이 액션을 저도 모르게 큰 범위로 뭉뚱그려서 작성하고 있었더라고요. 그리고 세부적인 액션을 모두 인수 조건으로 작성하려다 보니 인수 조건이 과하게 광범위하고 길어졌어요.

이렇게 유저 스토리가 모호하거나 액션의 단위가 커지는 것 같다면, 가장 대표적인 유저 스토리(Epic)와 여기서 구분될 수 있는 세부적인 상황이 담긴 유저 스토리, 그리고 각 스토리가 성립되기 위해 필요한 세부적인 조건들(인수 조건)을 작성하는 식으로 단계를 쪼개보는 것도 좋은 방법이 되지 않을까 싶습니다.

💡함께 읽어보면 좋은 책 추천: <잘나가는 서비스 기획자 도그냥은 왜 PM/PO가 되었을까?>

PM을 위한 가설 설정과 검증 방법!

11월에 발행된 따끈따근한 🍳 PM을 위한 가설 설정과 검증 방법! 편에서는 세 명의 PM과 가설 설정부터 검증 방법, 결론 도출까지의 과정을 어떻게 수행하고 있는지 살펴봤습니다. 가설 설정과 검증은 우선순위 설정과 유사하게 불필요한 자원 낭비를 줄이고, 성공 가능성을 높이기 위해 수행되는 단계인데요.

그 중 프로덕트 개발의 방향성을 제시하고 효율적인 작업을 위해 데이터 기반의 가설을 설정하는 PM 감자윤 메이커의 가설 설정 기준 세 가지를 소개합니다.

Q. 가설을 설정할 때 중요하게 생각해야할 기준 세 가지는 무엇일까요?

원칙에 부합하는지 : 목표 달성을 위해 가설을 세우는 경우, 그 가설이 '진짜' 우리가 원하는 목표를 달성시킬 수 있는지 여부예요. 목표에는 단순히 수치적인 것만이 아닌 얻고 싶은 의미나 가치도 담고 있기 때문이에요. 그 의미나 가치를 원칙으로 세우고 가설이 그 원칙에 부합하는지를 확인해요.
검증 가능한 지 : 세운 가설이 실제 검증 가능한지를 확인해요. 간혹 검증이 현실적으로 어려운 가설도 있어요. 검증할 때 통제가 어려운 변수가 존재하는 환경이나 요소가 있는 경우는 특히 가설 검증이 쉽지 않은 것 같아요
근거가 있는지 : 설정한 가설이 성공할 근거가 있는지 여부를 살펴봐요. 근거란 꼭 정량적일 필요는 없다 생각해요. 레퍼런스, 인터뷰 내용 등도 좋은 근거가 될 수 있다고 봐요. 직감도 경험에 의한 좋은 근거가 될 수 있지만 이 가설을 어떻게 세웠는지 물어봤을 때, '그냥'이라는 대답은 지양해야 한다 생각해요.

가장 공감했던 부분은 검증이 가능한지를 체크해야 한다는 점입니다. 때로는 이 가설을 검증하는 과정에 다양한 변수를 고려하지 못하는 경우가 많죠. 그래서 결과에 영향을 주는 변수를 먼저 제거하거나 통제가 가능한 상황에서 확인이 가능한 가설로 변경해야만 정확한 검증이 가능합니다.

사용자는 항상 우리의 예상을 벗어난 행동을 보여주죠😅. 그러다보니 우리가 원하는 목표를 달성하기 위해 해결해야하는 문제 정의, 그 문제를 해결할 수 있는 가설을 계속해서 찾아 검증해나가는 것이 중요합니다! 

💡함께 읽어보면 좋은 아티클 : PO 업무의 핵심: 문제 정의, 가설 수립, 가설 검증

업무 과정에서 챗GPT를 활용하는 방법은?

개인적으로 작년 발행한 주제 중, 가장 흥미롭게 편집한 내용은 바로 ‘ChatGPT’ 활용방법이었어요. 다양한 업무를 진행하고 있는 메이커들이 AI를 언제, 어떤 방법으로 활용하고 있는지를 살펴보고, 구독자분들이 나는 어떻게 활용해 볼 수 있을까? 에 대한 답과 출발점을 찾으실 수 있기를 바라는 마음으로 발행했는데요.

네 명의 메이커와의 대화 중, 서비스 기획자 C님의 ‘기능에 대한 아이디어 발산 도구로 활용’에 담긴 내용을 다시 공유하려고 해요

저는 기능에 대한 아이디어를 얻을 때, 정확히는 킥오프 미팅을 진행하기 전에 주로 챗GPT를 활용하고 있어요. 처음에는 특정 기능을 구현할 때 고려해야 하는 점 등을 간단하게 물어보는 정도로 활용했는데, 최근에는 다양한 조건과 배경을 미리 알려주고 특정 역할을 부여해 답변을 얻는 방법을 적극적으로 활용하고 있어요.

예를 들어, 특정 주제에 대해 이야기를 나눌 수 있는 ‘커뮤니티’ 기능을 개발해야 하는 상황이라면 ‘커뮤니티’ 기능을 우리 서비스의 배경과 목적에 따라 어떻게 구성할 수 있을지에 대한 내용을 확인하는 방법이에요. 개인적으로는 ‘지금 사용자가 어떤 불편을 겪고 있고’ ‘구체적으로 어떤 문제를 해결하고 싶다’는 조건을 추가했을 때 더 매력적인 답변을 얻을 수 있었던 것 같아요.

게다가, 문제와 불편이라는 배경을 깔아주면 필요한 기능 등에 대한 답변을 받은 뒤 2차로 사용자라는 역할을 부여해 사용자의 입장에서의 예상 만족도를 10점 또는 5점 만점으로 매겨달라는 요청을 더할 수 있어요. 이렇게 10-20개의 기능에 대한 아이디어가 정리되면 우리 서비스를 사용해 본 사용자, 이 프로젝트를 이끌어갈 매니저 등의 역할을 부여해 평가점수를 부여해 달라는 요청도 해보고 있어요.

당시에 저도 어떻게 하면 PM의 주요 업무에 AI 서비스와 LLM을 잘 활용할 수 있을까?라는 고민을 많이 했어요.(물론 지금도..) 당장은 제가 정리한 내용이 배경과 맥락에 잘 맞는지 정도를 확인하는 정도였는데요. 뉴스레터를 준비하며 기능에 대한 아이디어를 확보하고, 이를 우리 서비스 사용자와 유사한 대상으로부터 검증하는 방법까지 보다 상세한 내용을 확인할 수 있어 좋았어요. 

💡함께 읽어보면 좋은 아티클 : ChatGPT로 프로덕트 디자인 시간 줄일 수 있을까?

스펙 문서가 필요한 이유와 활용 방법은?

제품 스펙 문서는 무엇을, 왜 만들어야 하는지에 대한 명확한 결정 내용을 정리한 문서로 참여자들이 비판적 사고를 할 수 있게 하고, 효율적인 커뮤니케이션을 도우며, 책임 소재를 분명하게 해주는 역할을 하게 되는데요! 클럽을 통해 스펙 문서에 대해 많은 실무자와 이야기를 나눌 수 있었고, 그 중요성에 대해 다시 한번 확인 후 뉴스레터를 발행하게 되었어요.

그중, 서비스 기획자 올니 님의 코멘트는 제가 저의 ‘업무 레시피 문서’ 중 스펙 문서에 따로 저장해 뒀는데요. 그 이유가 무엇인지 지금부터 다시 살펴볼게요!

Q. 스펙 문서가 필요하다고 생각하는 이유(업무 상의 이점을 중심으로)

첫 번째는, 스펙 문서를 통해 팀 구성원 모두가 개발의 필요성, 목표 그리고 개발 내용에 대해 동일한 이해를 할 수 있어요. 두 번째는, 스펙 문서를 통해 개발 가능성을 논의할 수 있어요. 이를 바탕으로 기획 리뷰 시, 기획서를 수정하거나 논의에 필요한 시간을 줄일 수 있어요. 마지막으로 스펙 문서를 바탕으로 업무를 미리 준비하기에 기획서 작성 기간 동안 시간이 낭비되지 않고, 리뷰 후에 바로 개발을 진행할 수 있어요.

Q. 스펙 문서에 주로 포함되는 내용

개발 필요성
개발 목표
개발 일정
개발 범위
대략적인 서비스 정책
대략적인 와이어 프레임, 플로우 차트
타사 레퍼런스
개발 이슈

Q. 스펙 문서 작성 팁과 활용 방법

논의에 필요한 핵심 사항들을 최대한 간결하고 명확하게 작성
스펙 문서를 바탕으로 의사결정을 하기 위해 아이디어가 적절하고 타당한지 서로 논의하며 검증
회의에 참석한 모든 구성원의 의견을 듣고 함께 논의
회의를 통해 변경되거나 확정된 사항에 대해서는 종료 전 모두에게 정리하여 공유
회의록과 수정된 스펙 문서를 공유, 기획서 리뷰가 이루어질 때까지 참고할 수 있도록 준비

규모와 상관없이 PM에게 주어진 역할 중 하나는 일이 되게 만드는 것인데요. 여기서 핵심은 내부 구성원을 설득하는 과정이에요. 아무리 좋은 기획안과 아이디어를 갖고 있다 하더라도 함께 일할 사람들을 움직이게 하지 못한다면 아무런 의미가 없기 때문인데요. 그래서 저는 기능 개발과 신규 프로젝트 진행 전, 1-2페이지 분량의 문서를 꼭 작성해 구성원들에게 공유하고 논의하는 과정을 거쳐 우리가 어떻게, 어디까지 먼저 닿을 것인지에 대한 기준을 설정한 뒤 업무를 진행하고 있어요! 

새해에도 우리는 많은 프로젝트를 진행할 가능성이 높기에, 쓰지 않았다면 어떻게 쓰면 좋을지의 관점에서 쓰고 있다면 어떻게 개선할 수 있을지의 관점에서 스펙 문서에 대한 내용을 다시 한번 확인해보면 어떨까요?

💡함께 읽어보면 좋은 아티클 : 제품 관리에 필요한 문서 작성 방법

메이커의 레시피 북클럽 1기 모집 안내

책을 읽고 요약하고 생각을 공유하는 것을 넘어, 참여하는 사람들 간의 집단지성을 활용해 책의 한계를 넘는 방법을 계속 고민했어요. 그렇게 떠올린 개념이 '소셜 러닝 클럽'인데요. 책과 연결된 확장된 지식과 정보를 다양한 형식으로 함께 수집하는 메이커의 레시피 북클럽이 25년 1월 시작됩니다!

진행 도서 : UX/UI 심리학 법칙(저자 : 존 야블론스키), 참여자 별도 구매
참여 비용 : 3주 기준, 1만원
진행 방법 : 매주 지정된 챕터까지 책을 읽고 미션 내용을 노션에 작성하고 공유

메이커의 레시피 북클럽 참여자에게는 함께 책을 읽은 사람들의 요약과 추가 아티클을 모은 노션 템플릿을 제공해요. 함께하는 분들이 모은, 책과 관련된 다양한 정보가 차곡차곡 쌓여 많은 도움을 받으실 수 있어요! 1월 첫 북클럽과 관련된 보다 자세한 내용은 아래 링크를 참고해주세요.

북클럽 1기 신청하기