판단의 기록

me:mory 프로젝트 · 소중한 사람을 기억해주는 iOS 앱을 혼자 만들고 있습니다.① 아몬드 알레르기에서 시작한 문제 정의② 가입자 절반이 첫날 떠난 이유③ 네이버 쇼핑 API 폐지 대응기④ 유입 0, 스레드 계정을 새로 판 이유⑤ 유입 4주 성적표, 훅은 따로 있었다 (이 글) 4주 전 글에서 약속을 하나 했습니다. 스레드 계정을 새로 팠고, 4주 뒤에 그 숫자를 공개하겠다고요. 오늘이 그 4주째입니다. 결론부터 말하면, 유입은 만들어졌습니다. 가입자 19명이 35명이 됐고, 스레드 글 하나가 다운로드 10건을 만들었다는 게 앱스토어 데이터로 확정됐습니다. 그런데 유입보다 훨씬 큰 걸 발견했습니다. 새로 들어온 유저들의 한 달치 행동 데이터를 전부 뜯어봤는데, 17명 중에 제가 두 달 동안 공들여 ..

me:mory 프로젝트 — 소중한 사람을 기억해주는 iOS 앱을 혼자 만들고 있습니다.① 문제 정의② 가입자 절반이 첫날 떠난 이유③ 네이버 API가 사라진 날④ 검색 유입 0에서 시작하는 마케팅 (이 글) 출시했는데, 아무 일도 일어나지 않았다앱을 App Store에 출시하고 약 한달이 지났습니다.그동안 기능은 계속 나갔어요. 푸시, AI 챗봇, 홈 위젯, 월간 리포트까지.그런데 숫자는 이렇습니다.누적 가입자 19명 (지인 제외하면 15명)앱스토어 검색 유입 사실상 0 원인 중 하나는 좀 웃픈데요.앱 이름이 me:mory입니다. 가운데 콜론이 들어가요.이 콜론이 앱스토어 검색 색인에서 불리하게 작동해서, 정확히 이름을 아는 사람도 못 찾는 경우가 있었습니다.이름이 브랜딩은 되는데 검색은 안 되는 상태..

me:mory 프로젝트 — 소중한 사람을 기억해주는 iOS 앱을 혼자 만들고 있습니다. ① 문제 정의 ② 가입자 절반이 첫날 떠난 이유 ③ 네이버 API가 사라진 날 1. 증상 — 잘 되던 기능이 조용히 죽어 있었다제가 만드는 앱에 선물 추천 기능이 있습니다. 사용자가 담아둔 기억(예: "캠핑 의자 갖고 싶다고 했음")을 근거로 실제 상품을 추천해주는 기능이에요. 어느 날 "선물 추천이 계속 실패한다"는 제보를 받고 로그를 봤더니, 네이버 쇼핑 검색 API가 404를 뱉고 있었습니다.GET https://openapi.naver.com/v1/search/shop.json?query=캠핑의자&display=20HTTP/1.1 404 Not Found{ "errorMessage": "존재하지 않는 검색 a..

📌 me:mory 프로젝트 — 소중한 사람을 기억해주는 iOS 앱을 혼자 만들고 있습니다.① 문제 정의 ② 가입자 절반이 첫날 떠난 이유 ③ 네이버 API가 사라진 날 상황앱을 출시하고 지인들에게 링크를 돌린 지 2주가 지났습니다. 오늘 처음으로 운영 DB를 제대로 열어봤는데, 생각보다 아팠습니다.누적 가입 18명최근 7일 활성 8명첫날 이후 아무 기록이 없는 사용자 9명 (50%) 특히 7월 20일 하루에 13명이 가입했습니다(지인들에게 링크를 뿌린 날이에요). 이 코호트를 따로 떼서 보니 이랬습니다. 코호트 내 행동인원 가입 당일 이후 흔적 없음9명며칠 더 사용 (2~5일)3명2주 뒤에도 간헐적 사용1명 1차 가설 — "핵심 경험을 못 봐서 떠났다" 이 앱의 핵심 경험은 명확합니다. 약속을 저장하는..

me:mory 프로젝트 — 소중한 사람을 기억해주는 iOS 앱을 혼자 만들고 있습니다.① 문제 정의② 가입자 절반이 첫날 떠난 이유③ 네이버 API가 사라진 날 여자친구가 사온 아몬드 우유 저는 아몬드 알레르기가 있습니다. 그런데 여자친구가 그걸 모르고, 어느 날 아몬드 원액이 든 우유를 사왔어요. 저를 챙겨주려고 산 거였습니다. 그걸 먹고 며칠을 앓았습니다. 여자친구는 미안해했지만, 사실 미안해할 일이 아니었어요. 제가 언젠가 말했을 수도 있고 안 했을 수도 있는데, 어느 쪽이든 그 정보가 필요한 순간에 그 사람 머릿속에 없었을 뿐입니다. 마트에서 우유 코너 앞에 섰을 때, "얘 아몬드 안 되지" 하고 떠올릴 방법이 세상에 없었던 거죠. 그리고 그 일이 있고 나서 여자친구가 이런 말을 했습니다. "이런..

제품의 신규기획을 하다 보면 누구나 한 번쯤은 이런 순간을 만난다.내가 잘 아는 서비스, 익숙한 산업, 자주 써본 기능만 맡게 되면 좋겠지만 현실은 그렇지 않다.오히려 회사 안에서 중요한 프로젝트일수록, 그리고 새롭게 확장하는 사업일수록기획자는 종종 생소하거나 어려운 도메인을 맡게 된다. 법률, 회계, 의료, 제조, 부동산, 시설관리처럼용어부터 업무 흐름까지 낯선 영역을 처음 접하게 되면처음에는 이런 생각이 든다. “내가 이걸 제대로 기획할 수 있을까?”“도메인 지식이 부족한데 잘못 방향을 잡으면 어떡하지?”“전문가도 어려워하는 내용을 내가 정리할 수 있을까?” 나도 이런 고민을 자주 했다.그리고 지금은 한 가지를 분명히 느낀다.어려운 도메인을 맡았을 때 기획자에게 필요한 것은 ‘처음부터 다 아는 것’이..

스프린트를 운영하다 보면, 유독 간단하게 생각되는 Task 들이있다.기능 추가라고 해도 규모가 작고, 복잡한 화면 설계가 필요한 것도 아니고, 별도의 디자인 작업도 없어 보이는 그런 일들이다.이번에도 비슷했다.나는 이 작업을 보면서 “이 정도는 굳이 기획서를 쓸 필요는 없겠다”라고 판단했다.디자인도 필요 없는 task라고 생각했고, 팀에게도 간단히 설명만 한 뒤 넘어갔다.그 순간에는 꽤 효율적인 판단처럼 느껴졌다.문서를 작성하는 시간도 아낄 수 있고, 모두가 각자 필요한 부분만 이해하면 충분하다고 생각했기 때문이다.그런데 결과적으로는, 그 판단이 오히려 팀의 흐름을 끊는 원인이 되었다.AI 파트는 자신들이 맡은 작업을 기준으로 task를 진행했고, 필요한 부분을 모두 완료한 뒤 다른 파트의 지원이 필요한..

운영의 불편함에서 시작된 제품 백로그 관리 개선 회고그동안 제품을 운영하면서 가장 꾸준히 어려움을 느꼈던 영역 중 하나는 제품 백로그 관리였다.아이디어는 계속 생기고, VOC도 꾸준히 들어오고, 운영팀이나 CS를 통해 다양한 요청들이 쌓이는데, 이를 체계적으로 정리하고 추적하는 일이 생각보다 쉽지 않았다.기존에는 아래와 같은 방식으로 제품 관련 이슈들을 관리해왔다.기존 운영 방식1. PON 시트 운영아이디어 단계의 내용이나 VOC, 운영 중 발견된 문제 등을 우선 가공되지 않은 raw 형태로 기록하는 방식이었다.말 그대로 “일단 적어두는 공간”에 가까웠고, 빠르게 메모할 수 있다는 장점은 있었지만 시간이 지날수록 내용이 누적되면서 관리가 점점 어려워졌다.2. Jira 백로그 운영PON 시트에 쌓인 항목들..

프로젝트 관리의 다섯가지 중요한 역할이라는 아티클을 HBR에서 읽었다.https://hbr.org/2016/11/five-critical-roles-in-project-management Five Critical Roles in Project ManagementAn overview of who’s who.hbr.org이 글의 핵심은 “누가 어떤 책임을 맡는지 명확해야 프로젝트 목표를 달성할 수 있다”는 점이다. HBR은 프로젝트 운영에 특히 중요한 다섯 가지 역할을 제시하며, 각 역할이 분명히 구분되고 서로 연결될 때 성과가 난다고 이야기하고 있다. 1. 스폰서(Sponsor)스폰서는 프로젝트를 조직의 높은 수준에서 후원하고, 프로젝트가 흔들리지 않도록 정치적·조직적 장애물을 제거하는 사람이다. 단순한 ..

1) 배경 / 문제기존 홈에서 사용자가 뭘 못 했는지공고문 자동작성에서 어떤 불편/리스크가 있었는지근거: VOC, 사용 로그, CS, 내부 운영 이슈 등2) 목표(Outcomes) & 가설“이 기능을 넣으면 무슨 행동이 늘어나야 성공인지”예: 인기질문은 “첫 답변 도달 시간을 줄이고”, AI 리포트는 “재방문/활용도를 올린다”3) 성공지표(KPI) + 가드레일KPI는 ‘행동’ 지표로, 가드레일은 “부작용 방지”로홈화면(인기질문/AI 리포트) 예시 지표KPI홈 → 인기질문 클릭률(CTR)홈 → 첫 질문/첫 답변까지 시간(Time to first value)DAU/WAU 중 “챗 사용 전환율”(홈 방문 대비)AI 리포트 진입률, 리포트 생성 완료율가드레일이탈률/세션 길이 과도 증가(헤매는 신호)CS 증가, ..