📍 06.22 (월) - 휴식
- 사실 데이터 드리븐 마지막날인데, 오전부터 집중이 잘 안되었다.
- 책상에 앉아있긴 했지만 뭔가 정신이 없었다.
- 오후에는 안마원에 가서 그동안의 피로를 풀었다.
📍 06.23 (화) - 마지막 최종 주차 시작
- 이 부트캠프 안에서 팀장을 해본 적이 없어서, 이번엔 팀장 역할을 해보고 싶다고 팀원분들께 말씀드렸다. 다행히 다들 OK 해주셨다.
- MVP 때 발표를 자원했던 것처럼, '안 해본 역할을 해보자'는 마음이었다. 팀을 끌고 가는 경험 자체가 PM으로서 남는 거라 생각했다.
- 다 같이 발제문을 다시 읽었다. H님이 "어떤 이야기를 해야 할지" 아젠다를 미리 정리해 와주셔서 회의가 매끄러웠다.
- 회의가 짧고 뾰족해지려면 결국 "오늘 뭘 정할지"가 먼저 잡혀 있어야 한다는 걸 다시 느꼈다.
- 그라운드 룰을 정하면서 "검은 마음"이라는 재밌는 규칙을 하나 만들었다. 반대 의견이나 조심스러운 말을 꺼낼 때 "저 검은 마음 있어요"라고 외치는 건데, 귀엽지만 기분 나쁘지 않게 솔직한 의견을 낼 수 있는 장치라 너무 좋았다.
- 의견 충돌은 피할 게 아니라 잘 꺼내는 게 중요한데, 그 허들을 낮추는 게 이런 작은 규칙이라는 게 인상 깊었다.
- 오그라운드 룰(회의록 작성, 티켓 정/부 R&R, 슬랙 채널 분리)과 큰 서비스 방향(0 to 1 / 결제 X / 웹 / 커머스 핵심)을 정리했다.
팀원들의 강점·보완점과 프로젝트 기대사항을 적었다. - 적어보니 우리 팀은 데이터·논리·문서는 두텁고 디자인이 전원 약점이었다. 강점은 살리고 약점은 디자인 튜터님 상담으로 메우자는 그림이 보였다.
- 각자 아이디어를 발표했다. 나는 미리 생각해둔 아이디어가 있어서 그걸 제출했다. 「너에게 닿기를」 — 말 못 하고 넘어간 고마움·칭찬을, 익명+문구 가이드+소액 선물로 전하게 돕는 서비스. 표현의 허들을 낮추고, 그 마음을 선물(커머스)로 잇는 게 핵심이다.
📍 06.24 (수) - 주제를 정하고, 팀원들과 협력하기
오늘은 최종 프로젝트 주제를 확정한 날이자, 팀장으로서 “결정 이후 사람들을 어떻게 함께 같이 갈 것인가”를 처음으로 체감한 날이었다.
오늘 한 일
1. 개발 튜터님 미팅 — 로그/데이터 방향 정리
최종 프로젝트의 로그 수집과 데이터 분석 방향에 대해 개발 튜터님과 이야기했다.
- 우선 분석 툴은 PostHog를 활용하기로 했다.
- PostHog는 이벤트를 자동 수집할 수 있어, GA4처럼 사전에 심어둔 이벤트만 확인해야 하는 한계를 줄일 수 있다는 점이 컸다. 또한 세션 리플레이를 통해 UT에서 놓칠 수 있는 사용자 행동을 보완할 수 있다는 점도 장점이었다.
- A/B 테스트는 지금 바로 설계하기보다, 핵심 KPI가 확정된 뒤 실험이 필요한 지점을 기준으로 결정하기로 했다.
- 처음부터 변수명과 이벤트 구조를 너무 빡빡하게 설계하려 하기보다, 먼저 우리가 보고 싶은 사용자 행동과 지표를 사람의 언어로 명확히 정의하는 것이 중요하다는 뜻으로 이해했다.
- 아이디어 검증 — 시장 리서치
- 「너에게 닿기를」 아이디어와 팀원들이 제안한 제철코어, 취미 온보딩 아이디어를 함께 시장 관점에서 검토했다.
- 중요한 것은 경쟁사가 있는지 없는지가 아니라, 우리가 어떤 문제를 더 좁고 선명하게 정의할 수 있는지였다.
3. 주제 확정 회의 (2차, 19:00~20:50)
저녁 7시부터 8시 50분까지 2차 주제 확정 회의를 진행했다.
후보는 총 4개였다.
- 칭찬쪽지
- 제철코어
- 취미 온보딩
- 알약 테스트
논의 끝에 「너에게 닿기를」을 기반으로 한 관계 표현 서비스로 방향을 정했다.
다만 단순히 “칭찬을 주고받는 서비스”로 정의하지는 않기로 했다.
오히려 이 서비스는 “카톡보다는 무겁고, 손편지보다는 가벼운 방식으로 관계 안의 마음을 표현하는 서비스”에 가깝다고 정리했다.
회의 중에 이 아이디어의 원래 출발점도 다시 꺼냈다.
서운한 마음을 안전하게 전하고, 관계가 갑자기 끊어지는 일을 줄이고 싶었다.
이 이야기를 공유하자 팀원들이 서비스의 방향을 더 잘 이해하는 느낌이 들었다.
결국 기능보다 중요한 것은 “우리가 어떤 관계 문제를 풀고 싶은가”였다.
4. 내일 회의 준비 — 방향성, 문제 정의, MVP 범위
내일 3차 회의를 위해 회의 진행 시나리오를 미리 정리했다.
아젠다는 크게 3가지로 잡았다.
- 서비스 방향성 정리
- 문제 정의 구체화
- MVP 범위 결정
회의록 템플릿도 미리 만들어두었다.
또, 팀장이 모든 일을 떠안지 않도록 티켓을 정/부 담당으로 나누는 구조도 설계했다.
오늘 해보니 팀장은 회의만 진행하는 사람이 아니었다.
리서치, 문서화, 일정 관리, 사람 챙기기까지 계속 신경 써야 했다. 그래서 내일부터는 역할을 더 명확히 나누고, 내가 모든 것을 들고 가지 않는 구조를 만들어야겠다고 느꼈다.
오늘 가장 크게 배운 것은 주제 선정 자체보다, 사람을 대하는 방식이었다.
회의 중에는 최대한 팀원들의 말을 많이 들어보려고 했다. 그 과정에서 두 가지를 체감했다.
- 날카롭게 빈틈을 짚는 사람에게는, 먼저 인정해야 한다
회의 중 톡 쏘듯 아이디어의 약점을 지적하는 팀원이 있었다.
처음에는 방어하고 싶었지만, 오히려 이렇게 답했다.
“그 문제 저도 알고 있었어요. 짚어주셔서 감사해요. 이게 우리가 풀어야 할 부분이 맞아요.”
그렇게 말하자 상대의 말투가 조금 누그러졌다.
방어하지 않고 먼저 인정하는 것이 오히려 논의를 더 부드럽게 만든다는 것을 배웠다.
빈틈을 지적하는 사람은 회의를 어렵게 만드는 사람이 아니라, 우리가 놓친 리스크를 먼저 보여주는 사람일 수도 있다. 중요한 것은 그 지적을 공격으로 받지 않고, 논의 가능한 문제로 바꾸는 것이었다.
- 아이디어가 채택되지 않은 사람에게는, 결정 이후의 경청이 필요하다
본인의 아이디어가 최종 선택되지 않은 팀원도 있었다.
이때 바로 다음 안건으로 넘어가기보다, 따로 시간을 주고 이야기를 들으려고 했다.
그리고 이렇게 말했다.
“원하는 방향이 있다면, 그걸 지금 주제 안에서 같이 풀어보면 좋겠어요.”
그랬더니 상대의 마음이 조금 풀리는 것처럼 느껴졌다.
결정을 잘 내리는 것도 중요하지만, 그 결정에서 밀려난 사람이 존중받았다고 느끼게 만드는 것도 중요했다.
팀장의 일은 정답을 고르는 것에서 끝나지 않는다. 사람들이 그 결정에 함께 올라탈 수 있게 만드는 것까지가 팀장의 역할이었다.
내일 적용할 것
오늘은 회의 준비, 리서치, 튜터 미팅, 팀원 케어, 문서화까지 하면서 내가 너무 많은 일을 들고 있다는 걸 느꼈다.
그래서 내일은 티켓을 정/부 담당으로 나누고, 내가 모든 일을 직접 처리하지 않는 구조를 만들 예정이다.
팀장이 일을 많이 하는 것이 중요한 게 아니라, 팀이 같이 움직일 수 있게 구조를 만드는 것이 중요하다.
📍 06.25 (목) - 서비스 방향성을 정하지 못했지만 많이 배웠다.
오늘은 주제를 확정하지 못했다.
그런데 오히려 그래서 더 많이 배운 날이었다.
14:30부터 장시간 회의를 했다. 처음 목표는 칭찬쪽지 서비스의 문제정의, 타깃, MVP 범위를 확정하는 것이었다. 하지만 논의가 진행될수록 “이게 진짜 풀 문제인가?”라는 질문으로 돌아갔다.
결국 주제는 확정하지 못했고, 칭찬쪽지와 건강기록 사이에서 다음날 다시 결정하기로 했다.
대신 오늘은 좋아 보이는 아이디어와 검증 가능한 문제는 다르다는 걸 배웠다.
- 컨디션 : 좋음
1. 오늘 한 일
1) 칭찬쪽지 문제정의와 MVP를 확정하려 했다
어제 정한 대로 방향성에 대해 정하려고 했다.
논의한 순서는 대략 이랬다.
칭찬/감사로 갈 것인가, 서운함까지 포함할 것인가
→ 문제정의는 무엇인가
→ 1차 타깃은 누구인가
→ 어떤 상황에서 쓰게 할 것인가
→ MVP 범위는 어디까지인가일단 1차는 칭찬·감사 중심으로 보고, 서운함·부정 감정·우울은 v2로 미루자는 방향까지는 나왔다.
하지만 문제정의에 대한 공감대는 약했다.
계속 걸린 질문은 이거였다.
칭찬을 보내는 서비스가 카톡과 무엇이 다른가?
이 서비스가 진짜 해결하는 문제는 무엇인가?
칭찬을 받으면 기분 좋다는 건 제품으로 검증 가능한 문제인가?칭찬쪽지는 좋은 방향처럼 보였지만, 막상 문제정의로 들어가면 추상적이었다.
좋은 말이 오가면 좋다는 건 맞다. 그런데 그걸 제품이 어떻게 만들고, 어떤 지표로 검증할 수 있는지는 아직 선명하지 않았다
2. 후보 주제 비교 — 여행동행 / 건강기록 / 칭찬쪽지
여행동행
처음에는 나도 여행동행이 재밌겠다고 생각했다. 그래서 동의했고, 관련 서비스도 찾아봤다. 하지만 파보니 이번 프로젝트에서는 어렵다는 판단이 들었다.
여행동행의 핵심은 매칭이 아니라 신뢰였다.
이 사람이 같이 여행 가도 되는 사람인가?
이 사람을 믿고 만날 수 있는가?
이 사람과 일정·취향·안전 문제가 맞는가?이 신뢰는 단기간에 만들기 어렵다. 후기, 평판, 검증 데이터가 쌓여야 한다.
그런데 우리 운영 기간은 짧다.
내가 강하게 짚은 부분은 이것이었다.
매칭 서비스는 오픈 시점에 최소한의 매칭 풀이 있어야 데이터가 시작된다.
여행동행이라면 최소 몇 쌍의 매칭을 책임지고 만들어야 하는데,
운영 기간 2주 안에 신뢰 데이터까지 쌓는 것은 어렵다.그래서 여행동행은 “재밌지만 이번 프로젝트에서는 어렵다”로 정리됐다.
건강기록:
건강기록은 페인이 명확했다.
컨디션이 들쭉날쭉한데 왜 그런지 모르고, 수면·식사·생리·운동 같은 데이터를 기록하면 패턴을 찾을 수 있다는 방향이었다.
나는 개인적으로 이 주제가 좋았다.
문제가 비교적 명확하고, 정량 데이터로 볼 수 있는 여지가 있었기 때문이다.
하지만 팀원들은 중요한 우려를 짚었다.
기록해야 할 변수가 너무 많다.
유저가 꾸준히 기록할까?
기록하고 끝이면 서비스 가치가 약하지 않나?
건강 기록에 진심인 사람이 얼마나 될까?건강기록은 페인은 명확했지만, 기록 리텐션과 변수 통제가 큰 과제였다. (사실 아직도 어떤 변수를 말하는지 모르겠다.)
칭찬쪽지:
칭찬쪽지는 변수는 상대적으로 적고 빠르게 만들 수 있어 보였다.
하지만 문제정의가 정성적이고 추상적이었다.
계속 걸린 지점은 세 가지였다.
카톡과 무엇이 다른가?
리텐션을 어떻게 만들 것인가?
칭찬이 오가는 것을 제품의 성과라고 볼 수 있는가?결국 오늘은 칭찬쪽지와 건강기록 중 하나를 확정하지 못했고, 다음날 결정하기로 했다.
2. 오늘의 배움
1) SNS형 서비스는 문제정의가 쉽게 흐려진다
칭찬쪽지가 계속 막힌 이유를 정리하다가 알게 됐다.
이 서비스는 자칫하면 문제 해결 서비스가 아니라 “칭찬이 오가는 공간”이 된다.
물론 칭찬하고 싶고, 칭찬받고 싶은 니즈는 있다.
하지만 그 니즈가 너무 당연해서 오히려 문제정의가 흐려졌다.
칭찬받으면 기분 좋다.
좋은 말을 들으면 힘이 된다.
사람들은 인정받고 싶어 한다.여기까지는 누구나 동의한다.
그런데 제품은 여기서 한 단계 더 들어가야 한다.
그래서 사용자가 지금 못 하고 있는 행동은 무엇인가?
그 행동을 막는 허들은 무엇인가?
우리는 그 허들을 어떤 기능으로 낮출 것인가?
그 결과를 어떤 지표로 확인할 것인가?이 질문에 답하지 못하면 “좋은 서비스 같음”에서 멈춘다.
내 생각은 그게 그렇게 중요할까.. ? 이 쪽지에서 뭘 검증해야할까..? 이렇게 파고드니 매우 복잡했지만, 인스타그램을 떠올리니 이해가 쉬웠다.
초기 인스타그램은 “허접한 사진을 예쁘게 보정해 공유한다”는 해결안이 있었다.
사용자가 사진을 올리고 공유하면 되는 구조였다.
칭찬쪽지는 “칭찬이 오가면 좋다”까지만 있으면, 결국 유저 수·게시물 수·인터랙션 수가 지표가 된다.
하지만 아직까지 그건 문제 해결이라고 느껴지지는 않았다.
👉 정성적 가치가 있다고 해서 바로 제품 문제가 되는 것은 아니다. 제품 문제로 만들려면 사용자의 막힌 행동과 그 행동을 측정할 지표가 필요하다.
2) 정성은 정량으로 번역되어야 검증할 수 있다
오늘 계속 나온 질문은 이거였다.
칭찬이라는 정성적 가치를 어떻게 정량으로 볼 것인가?칭찬은 좋다. 감사는 좋다. 응원도 좋다.
하지만 MVP에서는 “좋다”를 검증할 수 없다. 검증하려면 행동으로 바꿔야 한다.
예를 들어 “칭찬할 용기”라는 가치를 잡는다면, 제품에서는 이렇게 번역해야 한다.
사용자가 카드 작성을 시작했는가?
문구 가이드를 선택했는가?
메시지를 끝까지 작성했는가?
링크를 생성했는가?
실제로 공유했는가?
수신자가 열람했는가?즉, 정성적 가치는 행동 지표로 바뀌어야 한다.
컬리의 비전을 예로 들었다.
“좋은 걸 쉽게 먹게 한다”는 말 자체는 정성적이다. 하지만 제품에서는 객단가, 재구매율, 장바구니 전환율 같은 지표로 번역할 수 있다.
칭찬쪽지도 마찬가지다.
칭찬을 주고받는 따뜻한 공간이렇게 말하면 좋지만 검증하기 어렵다.
칭찬하고 싶은 사람이 실제로 메시지를 작성하고 발송한다👉 비전은 정성적으로 말할 수 있지만, MVP는 행동 지표로 검증해야 한다.
3. 프로젝트 아이디어에 대한 문제는 다 뾰족했다. 하지만 내가 그 문제를 해결하고자 하는 당사자가 아니면 문제라고 느끼지 못한다.
우리가 프로젝트를 정하면서 제일 큰 문제가, '이거 내가 공감가지 않는 프로젝트인데?'였다. 6명이 모두 다 공감하는 문제와 방향성을 정할수가 없었다.
여기서 내가 느낀 것은, 분명히 문제 정의는 잘 했다. 하지만 공감이 안 되는 건 내가 당사자가 아니어서일 수 있다.
건강기록도 누군가에게는 아주 뾰족한 문제다.
칭찬쪽지도 누군가에게는 정말 필요한 문제일 수 있다.
여행동행도 신뢰 문제를 깊게 겪은 사람에게는 분명한 문제다.
그러면 팀이 해야 할 일은 “모두가 100% 공감하는 주제”를 찾는 게 아니다.
그건 거의 불가능하다.
대신 봐야 할 것은 이거다.
이 문제를 가진 사용자가 실제로 있는가?
그 사용자가 지금 못 하고 있는 행동은 무엇인가?
우리가 짧은 기간 안에 그 행동을 바꿔볼 수 있는가?
그 변화를 데이터로 볼 수 있는가?그러면 팀이 해야 할 일은 “모두가 100% 공감하는 문제”를 찾는 것이 아니라, 적어도 한두 명에게 뾰족한 문제가 있고, 우리가 그 문제를 검증 가능한 방식으로 풀 수 있는지 판단하는 것이다.
👉 문제정의를 모두에게 설득하려고만 하지 말고, 해결 가능성과 데이터 검증 가능성으로 판단해야 한다.
3. 팀장으로서 배운 것
1. 팀원들이 원하는 방향으로 정해보자.
솔직히 말하면, 칭찬쪽지는 내가 진심으로 밀고 싶었던 아이디어는 아니었다.
정말 생각나는 게 없어서 낸 아이디어에 가까웠다...
그래서 그 아이디어가 채택됐을 때 조금 놀랐다.
오히려 내가 하고싶었던 것은 다른 팀원의 건강기록 아이디어였다.
그런데 팀원들은 칭찬 서비스를 더 하고 싶어 했다.
신기하게도 나는 그 상황이 크게 아쉽지는 않았다. 약간의 아쉬움은 있었지만, “그러려니” 하고 넘겼다.
나는 내 아이디어가 채택되는 것보다, 팀이 빠르게 합의해서 실제로 만들고 결과를 보는 것이 더 중요했다.
👉 완벽히 마음에 드는 주제가 아니어도, 팀이 움직일 수 있는 방향이라면 그 안에서 문제를 더 선명하게 만들면 된다고 생각했다.
5. “왜 이해를 못 해요?”가 아니라 같이 정리해주는 것
오늘 가장 뿌듯했던 일은 한 팀원과 생각을 같이 정리한 것이다.
그 팀원은 칭찬쪽지를 이해하고 싶어 했다.
여기서 “그냥 진행하면 되지, 왜 이해를 못 하지?”라고 밀어붙일 수도 있었다.
하지만 그러지 않았다. 대신 메모장에 줄글로 함께 써 내려가면서, 그 사람이 계속 같은 지점에서 맴도는 이유를 같이 짚었다.
또 “칭찬이라는 정성 데이터를 어떻게 정량으로 바꿀 수 있냐”는 질문에는 컬리의 예시를 들었다.
비전은 원래 정성적이지만, 제품에서는 반드시 정량 지표로 번역해야 한다고 설명했다.
설득하려고 한 게 아니라, 같이 생각을 정리하려고 했다.
👉 팀원이 이해하지 못하는 것은 반대가 아니라 정리가 덜 된 신호일 수 있다. 답을 강요하기보다 생각의 흐름을 정리해줄 수 있어야 한다.
4. 앞으로 가져갈 기준
내일은 주제를 반드시 결정해야 한다.
오늘의 논의를 바탕으로, 나는 아래 기준을 가져가려고 한다.
1. 문제정의가 얼마나 뾰족한가
2. 사용자의 막힌 행동이 명확한가
3. 짧은 기간 안에 만들 수 있는가
4. 데이터 기반 의사결정이 가능한가
5. v1 이후 개선 방향을 만들 수 있는가칭찬쪽지를 계속한다면, “칭찬은 좋다”가 아니라 발신자가 왜 보내지 못하는가로 좁혀야 한다.
건강기록을 선택한다면, “건강을 기록하자”가 아니라 무엇을 입력하면 어떤 패턴을 보여줄 수 있는가로 좁혀야 한다.
어떤 주제를 고르든, 핵심은 하나이다.
👉 좋아 보이는 아이디어가 아니라, 사용자의 행동을 만들고 그 행동을 데이터로 검증할 수 있는 아이디어를 선택해야 한다.
📍 06.26 (금) - 프로젝트 주제 확정하고 반차 냈다.
- 컨디션: 최악 어제 밤 12시까지 팀원과 이야기 하고, 막히는 지점을 풀어주었다. 뿌듯했지만 그 과정에서 너무 무리를 했는지 두통이 정말 심했다.
전날까지 우리는 칭찬쪽지와 건강기록 사이에서 계속 흔들리고 있었다.
칭찬쪽지는 빠르게 만들 수 있고 확산 가능성이 있었지만, 문제정의가 추상적이었다.
건강기록은 페인이 명확했지만, 변수와 기록 리텐션이 부담이었다.
오늘 회의에서는 결국 칭찬쪽지 방향으로 잠정 결정되었다.
아직 완전히 확정된 것은 아니지만, 주제 선정 폼은 칭찬쪽지로 제출했다.
오늘 회의에서 정리된 것
1. 칭찬 서비스의 타깃이 좁혀졌다
처음에는 칭찬·감사·응원이라는 감정 자체가 너무 넓었다.
누구에게 보내는지, 어떤 상황에서 쓰는지, 왜 기존 방식으로는 부족한지가 흐릿했다.
오늘 회의에서는 타깃을 친구·가족 대상 C2C 서비스로 좁혔다.
직장은 제외했다.
직장 내 칭찬은 조직문화, 평가, 권력관계가 섞이기 때문에 개인 간 서비스로 풀기 어렵다고 봤다.
애인도 제외했다.
연인 관계는 이미 비트윈, 써먼 같은 강한 맥락의 서비스가 있고, 표현 방식도 친구·가족과 다르다.
결국 1차 타깃은 친구·가족처럼 애정은 있지만, 막상 칭찬이나 감사를 직접 표현하기엔 어색한 관계로 정리됐다.
👉 타깃을 좁히자 “칭찬이 좋다”가 아니라 “가까운 사람에게 좋은 말을 전하기 어색하다”는 문제로 조금 더 선명해졌다.
2. 핵심 문제정의가 한 문장에 가까워졌다
오늘 회의에서 가장 중요한 문장은 이거였다.
카톡보다 특별하고, 손편지보다 가벼운 채널이 비어 있다.전날까지 내가 계속 걸렸던 지점은 “칭찬쪽지가 카톡이랑 뭐가 다르지?”였다.
그런데 오늘 회의에서는 차별점을 기능보다 맥락과 채널의 위치로 잡았다.
카톡은 너무 일상적이다.
갑자기 진지한 칭찬이나 감사를 보내면 어색하거나 성의 없어 보일 수 있다.
손편지는 너무 무겁다.
특별한 날이 아니면 부담스럽고, 받는 사람에게도 답장 부담을 줄 수 있다.
그 사이에 있는 가벼운 전용 채널이 비어 있다는 문제정의는, 이전보다 훨씬 납득하기 쉬웠다.
3. C2C + 레퍼럴 구조로 방향이 잡혔다
오늘 회의에서는 B2B가 아니라 C2C로 방향을 잡았다.
B2B 사례는 칭찬 수요를 설명하는 근거로 쓸 수 있다.
예를 들어 아기고래 같은 사내 칭찬 문화 서비스는 “칭찬을 구조적으로 쉽게 만들면 사람들이 실제로 사용한다”는 참고 사례가 된다.
하지만 우리가 만들 서비스는 조직이 도입하는 서비스가 아니라, 개인이 자발적으로 쓰고 주변으로 퍼지는 C2C 서비스다.
특히 오늘 회의에서는 받은 사람이 다시 카드를 만들거나, 자신의 링크를 공유하면서 퍼지는 레퍼럴 구조를 중요하게 봤다.
전날 내가 걱정했던 리텐션 문제와도 연결된다.
칭찬쪽지는 매일 쓰는 서비스가 되기 어렵다.
그렇다면 리텐션만 볼 것이 아니라, 받은 경험이 다시 발신 행동으로 이어지는지를 봐야 한다.
👉 이 서비스는 매일 방문하게 만드는 서비스라기보다, 한 번 받은 사람이 다시 누군가에게 보내게 만드는 확산 구조를 봐야 한다.
오늘 내가 배운 것
1. 내가 없을 때도 진행되려면, 기준이 공유되어 있어야 한다
오늘 오후 나는 회의에 없었다.
그런데 회의록을 보니 전날 우리가 오래 토론했던 기준들이 오늘 논의에도 이어지고 있었다.
데이터로 검증 가능한가
빠르게 개발할 수 있는가
확장 가능성이 있는가전날에는 결론이 안 났지만, 그때 만든 기준이 오늘의 결정에 영향을 준 것 같다.
- 반대하던 사람을 납득시킨 건 “기능”이 아니라 “맥락”이었다
H님은 전날까지 칭찬쪽지를 잘 납득하지 못했다.
“칭찬하고 싶다”, “칭찬받고 싶다”가 문제정의로는 약하다고 느꼈다.
그런데 오늘은 아기고래 사례를 보면서 납득했다고 한다.
왜일까 생각해봤다.
아기고래가 보여준 건 단순히 “칭찬 기능”이 아니다.
칭찬이 어색한 조직 안에서, 칭찬을 더 쉽게 할 수 있는 구조와 맥락을 만든 사례였다.
즉, H님이 납득한 건 기능이 아니라 맥락이었다.
칭찬쪽지가 막혔던 이유도 같다. “칭찬을 보낸다”는 기능만으로는 약하다.
하지만 “카톡으로는 어색하고, 손편지로는 무거운 마음을 보낼 중간 채널”이라고 보면 조금 선명해진다.
다음주에 해야할 것
사실 회의록을 잘 써달라고 여러번 강조 했지만 회의록을 읽어보니 결론이 나지 않은 부분들이 많아서 다음주에 정해야할게 많아 보인다 ㅎㅎ
📍 06.29 (월) - 본격적인 업무 시작!..
- 컨디션: 피곤, 어제 밤 12에 집에 와서 .. 너무 놀았따.. ㅎ
오늘은 PRD 방향을 본격적으로 정리한 날이었다.
오전 9시 40분부터 저녁 7시 이후까지, 배경·문제정의·타깃·KPI·설문·유저플로우를 계속 오가며 논의했다.
처음에는 “칭찬/감사 서비스를 만든다”는 방향은 있었지만, 그 안에서도 계속 헷갈리는 지점이 있었다.
우리가 검증하려는 건 칭찬을 받고 싶은 수요인가?
아니면 칭찬을 보내고 싶은 사람이 실제로 보내지 못하는 허들인가?오늘 가장 크게 정리된 것은 이 부분이었다.
칭찬을 받고 싶은 수요는 배경 근거다.
하지만 MVP에서 검증해야 할 것은 그 수요 자체가 아니라, 칭찬·감사·응원을 표현하고 싶은 사람이 실제로 메시지를 작성하고 발송할 수 있는가다.
오늘 한 일
1. 배경·문제정의·타깃·KPI를 팀 전체와 다시 맞췄다
오전 회의에서는 이전 리서치와 회의 내용을 바탕으로 PRD의 큰 방향을 팀원들과 다시 확인했다.
현재 우리가 보고 있는 배경은 이렇다.
사람들은 가까운 관계 안에서 칭찬·감사·응원을 받고 싶어 한다.
하지만 실제 관계 안에서는 이런 긍정적 표현이 충분히 오가지 않는다.
처음에는 커뮤니티 리서치에서 “칭찬받고 싶다”는 반응이 많이 보였기 때문에, 수신자 중심으로 가야 하는 것처럼 보이기도 했다.
하지만 C님이 중요한 지점을 짚었다.
커뮤니티 글은 구조상 “받고 싶다”는 글이 많이 보일 수밖에 있다.
누군가에게 칭찬하고 싶다는 마음을 커뮤니티에 올리지는 않기 때문이다.
나는 이 부분에서 논리적 비약이 있다고 느꼈다.
칭찬을 받고 싶은 수요가 있다 → 그러므로 발신자 중심 서비스가 필요하다
이 연결은 바로 성립하지 않는다.
중간에 “왜 실제 관계 안에서 칭찬·감사·응원이 충분히 오가지 않는가”가 들어가야 했다.
결국 오늘 정리한 문제 구조는 이렇다.
수요: 사람들은 칭찬·인정·응원을 받고 싶어 한다.
문제: 그런데 실제 관계 안에서는 긍정적 표현이 충분히 오가지 않는다.
가설: 공급이 적은 이유는 발신자가 마음은 있어도 표현하기 어렵기 때문이다.
검증: 발신자가 왜 못 보내는지 설문과 MVP 행동 데이터로 확인한다.
MVP: 그 허들을 낮추는 카드/문구/링크 발송 흐름을 만든다.
이 정리가 오늘 가장 중요했다.
2. 핵심 KPI를 발송 완료율로 정했다
문제정의가 발신자의 표현 허들로 정리되면서 KPI도 같이 정리됐다.
나는 원래 무엇을 하든 KPI를 먼저 잡아야 한다고 생각한다.
KPI가 있어야 우리가 무엇을 보고 싶은지, 어떤 행동을 만들고 싶은지, MVP 범위를 어디까지 둘지 판단할 수 있기 때문이다.
오늘 회의에서도 발신자 중심인지, 수신자 중심인지에 따라 KPI가 완전히 달라졌다.
수신자 중심이라면 링크 생성률, 답장 확인률, 보관함 생성률 같은 지표가 중요해질 수 있다.
하지만 현재 문제정의가 “표현하고 싶지만 보내지 못한다”에 가깝다면, 핵심은 실제로 발송까지 가는지다.
그래서 핵심 KPI는 칭찬 메시지 발송 완료율로 잡았다.
보조 지표로는 이런 것들을 볼 수 있다.
- 작성 완료율
- 링크 생성률
- 공유 클릭률
- 수신 열람률
- 메시지 내용의 질
특히 메시지 내용의 질도 이야기했다.
단순히 “고마워” 한 마디만 적어도 발송 완료로 볼 것인지, 우리가 기대하는 칭찬·감사·응원의 밀도가 있는지를 어떻게 볼 것인지가 남았다.
아직 정답은 없지만, 글자 수나 특정 표현 포함 여부처럼 보조적으로 볼 수 있는 방법을 더 고민해야 한다.
3. PRD 작성 역할을 다시 나눴다
처음에는 6명이 같이 PRD와 기능명세서를 모두 붙잡을 뻔했다.
하지만 나는 그 방식이 비효율적이라고 느꼈다.
6명이 동시에 같은 문서를 보는 것은 생각보다 속도가 나지 않는다.
회사에서도 6명이 동시에 한 문장씩 PRD를 쓰지는 않는다.
방향을 잡는 사람, 조사하는 사람, 플로우를 보는 사람, 리뷰하는 사람이 나뉘어야 한다.
그래서 역할을 크게 나눴다.
- PRD v1 — 배경, 문제정의, 타깃, KPI
- 유저플로우 — 작성/전달/수신 흐름
- 칭찬 욕구·표현 허들 단계 조사
나는 PRD 쪽을 봐야 마음이 놓일 것 같았다.
사실 이미 많이 맡고 있었지만, 이 부분을 놓으면 전체 방향이 흐려질 것 같았다.
C님과 Y님은 PRD 작성에 함께 들어가고, H·Y·D님은 칭찬 욕구와 표현 허들 단계를 조사하는 식으로 정리했다.
유저플로우는 PRD와 조사 결과가 어느 정도 나온 뒤 함께 다시 보기로 했다.
4. PRD 작성 회의에서 역할을 더 줄였다
14:30 회의에서는 PRD 작성 방식을 다시 조정했다.
처음에는 PRD 작성에 여러 명이 붙어 있었지만, 실제로는 중심을 잡는 사람이 필요했다.
그래서 PRD는 채영님이 중심을 잡고 쓰고, 나는 큰 뼈대의 유저플로우를 그리기로 했다.
Y님은 발신자의 표현 허들을 낮추기 위한 데스크 리서치를 맡았다.
예를 들면 이전 과제에서 독서 환경 개선 리서치를 했던 것처럼, 사용자가 특정 행동을 못 하는 이유와 그 허들을 낮추는 방식을 찾는 작업이다.
이때 내가 정리한 흐름은 이랬다.
1. 칭찬받고 싶다는 수요는 확인되었다.
2. 그런데 그 수요가 충족되는 공간이 왜 카톡이나 롤링페이퍼가 아니라 우리 서비스여야 하는지 설명해야 한다.
3. 결국 핵심은 칭찬과 감사가 실제 관계 안에서 오가도록, 발신자의 허들을 낮추는 것이다.
이 세 번째 지점 때문에 Y님의 리서치가 필요했다.
“칭찬받고 싶다”는 근거만으로는 부족하고, “왜 실제로 보내지 못하는가”를 더 봐야 했기 때문이다.
5. 설문조사의 목적을 다시 정의했다
15:35 회의에서는 설문조사 방향을 논의했다.
여기서 다시 한 번 핵심이 정리됐다.
이번 MVP에서 검증할 것은 “칭찬을 받으면 기쁜가”가 아니다.
칭찬받으면 기쁜 건 거의 모두가 동의하는 전제에 가깝다.
우리가 확인해야 할 것은 이거다.
칭찬·감사·응원을 표현하고 싶은 사람이 왜 실제로 보내지 못하는가?
공급이 적은 이유는 아직 모른다.
가능한 가설은 여러 가지다.
카톡으로 보내기엔 갑자기 진지해서 어색하다.
무슨 말을 써야 할지 모른다.
상대가 부담스러워할까 봐 걱정된다.
보낼 명분이나 타이밍이 애매하다.
손편지는 너무 무겁고 준비 부담이 크다.
그런 감정을 표현할 전용 채널이 있는지 모른다.그래서 설문은 단순히 “칭찬받고 싶나요?”를 묻는 것이 아니라, 최근에 고마움·칭찬·응원을 전하고 싶었지만 못 보낸 경험과 그 이유를 물어야 한다.
오늘 정리한 설문 방향은 이렇다.
- 칭찬/인정/응원을 받고 싶은 니즈 확인
- 타인에게 칭찬/감사/응원을 전할 의향 확인
- 최근 실제로 전하고 싶었지만 못 보낸 경험 확인
- 못 보낸 이유 확인
- 카드/문구/링크 서비스 사용 의향 확인
- 어떤 기능이 허들을 낮출 수 있는지 확인
설문은 궁금한 걸 묻는 문서가 아니라, PRD의 가설을 검증하기 위한 도구여야 한다.
6. 유저플로우 초안을 공유했다
저녁 회의에서는 내가 러프하게 생각한 유저플로우를 공유했다.
현재 플로우는 발신자 중심으로 설계했다.
랜딩
→ 온보딩/홈
→ 카드 만들기
→ 관계/마음/상황 선택
→ 문구 가이드
→ 카드 작성
→ 익명/실명 선택
→ 카드 미리보기
→ 로그인
→ 공유 준비
→ 링크 복사/공유
→ 수신자 열람
→ 반응
→ 나도 카드 만들기
내가 중요하게 본 부분은 두 가지였다.
첫째, AI 문장 생성보다 선택지 기반 문구 가이드가 더 현실적일 수 있다.
사용자가 관계, 마음, 상황을 선택하면 그에 맞는 문구 예시를 주고, 사용자가 수정해서 보내는 방식이다.
이 방식은 개발 부담을 낮추면서도 발신자의 작성 허들을 줄일 수 있다.
둘째, 로그인은 처음부터 시키지 않는다.
카드를 어느 정도 작성하고 미리보기까지 본 뒤, 링크 생성 직전에 로그인시키는 방향이 낫다고 봤다.
처음부터 로그인시키면 이탈이 생길 수 있다.
반대로 다 작성한 뒤라면 사용자는 이미 투자한 시간이 있어 로그인 허들을 더 넘을 가능성이 있다.
7. 기술적 리스크도 함께 봤다
저녁 회의에서는 카카오 로그인, 실명 저장, 익명/실명 선택, 알림톡 가능성도 논의했다.
익명/실명은 겉으로 보기엔 간단한 선택지처럼 보이지만, 실제로는 생각할 게 많다.
실명을 어디서 가져올 것인가?
소셜 로그인으로 충분한가?
본인 인증이 필요한가?
익명/실명 선택을 나중에 바꿀 수 있는가?
이전 메시지는 변경 전 기준으로 보여줄 것인가?
DB에는 어떤 값을 저장할 것인가?알림톡도 마찬가지였다.
카톡 링크 공유가 카톡 맥락에 종속되는 단점이 있으니, 서비스에서 직접 알림톡이나 문자를 보내는 방안도 나왔다.
하지만 상대방 번호가 필요하고, 동의 절차도 있어 현실적으로 어려울 수 있다는 결론이 나왔다.
결국 알림톡은 당장 어렵고, 카카오 로그인 시 실명 저장 가능 여부는 튜터님께 확인하기로 했다.
오늘 가장 크게 배운 것
1. 수요와 문제는 다르다
오늘 가장 많이 붙잡은 건 이 차이다.
수요: 사람들이 칭찬을 받고 싶어 한다.
문제: 그런데 실제 관계 안에서 칭찬·감사·응원이 충분히 오가지 않는다.
가설: 발신자가 표현하고 싶은 마음은 있어도 보내기 어렵기 때문이다.
수요가 있다고 바로 제품 문제가 되는 것은 아니다.
수요와 문제 사이에는 “왜 지금 해결되지 않고 있는가”가 있어야 한다.
오늘 나는 이 연결이 약하면 PRD 전체가 흔들린다는 걸 느꼈다.
👉 리서치가 보여주는 것은 수요일 수 있지만, PRD가 정의해야 하는 것은 제품이 개입할 문제다.
2. KPI를 먼저 잡으면 논의가 정리된다
오늘도 결국 KPI 이야기를 하면서 많은 것이 정리됐다.
발신자 중심이면 발송 완료율이 핵심이다.
수신자 중심이면 링크 생성률, 답장 확인률, 보관함 생성률 같은 지표가 중요해질 수 있다.
즉, KPI는 단순한 숫자가 아니라 우리가 어떤 행동을 핵심으로 보는지 드러낸다.
오늘 내가 계속 KPI를 물었던 이유도 그 때문이었다.
우리가 보고 싶은 행동이 무엇인지 정해야
문제정의도, MVP 범위도, 기능도 정할 수 있다.
👉 KPI는 마지막에 붙이는 측정 항목이 아니라, 문제정의와 MVP 범위를 정리하는 기준이다.
3. MVP는 가장 작은 검증 단위여야 한다
오늘 회의에서 “칭찬 동기가 아예 약한 사람까지 설득할 것인가”라는 이야기가 나왔다.
결론은 아니다.
그건 MVP 범위를 넘어선다.
우리는 먼저 표현하고 싶은 마음은 있지만 실행하지 못하는 사람을 봐야 한다.
아예 칭찬할 마음이 없는 사람을 설득하는 것은 훨씬 큰 문제다.
그래서 1차 타깃은 이렇게 정리됐다.
칭찬·감사·응원을 표현하고 싶은 마음은 있으나,
카톡의 어색함, 문구 작성 어려움, 상대 반응 부담, 타이밍/명분 부족 등으로 실행하지 못한 사람
👉 MVP는 가장 어려운 사용자를 설득하는 것이 아니라, 가장 작게 검증 가능한 사용자 행동을 먼저 보는 것이다.
4. 기능은 문제정의와 같은 방향을 봐야 한다
오늘 사물함, 보관함, 답장, 익명/실명, 알림톡 등 여러 기능이 나왔다.
그런데 기능을 볼 때마다 다시 물어야 했다.
이 기능은 발신자의 표현 허들을 낮추는가?
아니면 수신자의 보관 경험을 강화하는가?
우리가 이번 MVP에서 검증하려는 행동과 연결되는가?
예를 들어 사물함은 재미있지만, 수신자의 보관 경험에 더 가깝다.
이번 MVP가 발신자의 작성·발송 행동을 검증하는 것이라면 우선순위는 낮아질 수 있다.
반대로 관계/상황 선택, 문구 가이드, 미리보기, 링크 공유는 발신 허들을 직접 낮출 수 있다.
👉 좋은 기능이어도 이번 MVP의 핵심 행동과 연결되지 않으면 우선순위를 낮춰야 한다.
오늘의 아쉬움
오늘은 논의가 많이 진전됐지만, 중간중간 같은 지점으로 계속 돌아갔다.
특히 발신자 중심인지, 수신자 중심인지가 계속 흔들렸다.
이건 단순히 말이 안 맞아서가 아니라, 문제정의와 기능 방향이 서로 영향을 주기 때문이었다.
수신자가 링크를 공유하는 방식은 구조상 깔끔하다.
하지만 그 방식이 되면 PRD의 중심이 “발신자의 표현 허들”에서 “수신자가 칭찬을 요청하는 경험”으로 바뀔 수 있다.
그래서 설문 결과를 보고 다시 판단하기로 했다.
오늘 완전히 확정된 것과 아직 열어둔 것을 구분한 건 잘한 일이지만, PRD 본문에서는 더 명확한 한 줄이 필요하다.
내일 가져갈 것
- PRD에서는 “칭찬받고 싶은 수요”와 “칭찬을 보내지 못하는 문제” 사이의 연결을 더 명확히 써야 한다.
- 설문 결과를 통해 발신 허들의 원인을 확인하고, 기능 우선순위에 반영해야 한다.
- MVP 기능은 발신자의 작성·발송 행동을 만드는 기능 중심으로 정리해야 한다.
- 수신자 요청 링크 구조를 넣을지 말지는 설문 결과와 유저플로우를 보고 결정해야 한다.
- 익명/실명, 보관함, 답장, 알림톡은 기능이 아니라 범위와 리스크 관점에서 다시 봐야 한다.
- PRD, 설문, 유저플로우, KPI가 모두 같은 가설을 향하도록 맞춰야 한다.
오늘의 결론
오늘은 PRD를 많이 쓴 날이라기보다, PRD가 무엇을 검증해야 하는지 정한 날이었다.
칭찬·감사·응원을 받고 싶은 수요는 있다.
하지만 우리가 MVP에서 검증할 것은 그 감정 자체가 아니다.
👉 이번 MVP의 핵심은 “좋은 말을 받고 싶은가”가 아니라, “좋은 말을 전하고 싶은 사람이 실제로 작성하고 발송할 수 있는가”이다. 수요를 행동 가설로 바꾸는 것, 그리고 그 행동을 KPI와 설문으로 연결하는 것이 오늘의 가장 큰 배움이었다.
