Planning
글 7편
-
북극성 지표도 A/B 테스트 기준도 매출 하나로는 안 된다
방향은 북극성 지표, 새는 곳은 AARRR, 인과는 A/B 테스트가 묻는다
결론부터 검증 단계의 세 개념은 서로 다른 질문에 답한다. 셋을 한 줄에 놓고 “어느 게 더 좋은 지표인가”를 물으면 헷갈린다. 북극성 지표 — 제품이 맞는 방향으로 가고 있나 AARRR — 사용자가 어느 단계에서 빠져나가나 A/B 테스트 — 이 변화가 그 지표를 움직였나 그리고 ...
-
유저 스토리는 문서가 아니라서 인수 조건이 필요하다
PRD 는 릴리스 하나를, 스토리는 작업 증분을, Given-When-Then 은 완료 기준을 적는다
결론부터 명세에 쓰는 세 용어는 적는 단위가 다르다. 그래서 하나가 다른 하나를 대체하지 않는다. PRD — 릴리스 하나에 대한 문서다. 무엇을 왜 만드는지 적고, 어떻게 만드는지는 비운다 유저 스토리 — 작업을 나눈 증분이다. 카드 한 장, 대화, 확인으로 이루어지고 문서가 아니...
-
RICE 1위가 MoSCoW 에서는 Won't 가 될 수 있다
점수로 줄 세우기와 이번 범위 합의는 다른 질문이고, 순위는 Confidence 한 칸에 뒤집힌다
결론부터 RICE 와 MoSCoW 는 둘 다 우선순위 기법으로 묶이지만 답하는 질문이 다르다. RICE — 후보들 중 무엇이 일한 시간 대비 효과가 큰가. 후보를 한 줄로 세운다 MoSCoW — 정해진 기간 안에 무엇을 반드시 내고 무엇을 이번에 빼나. 이번 범위를 자른다 그래서 ...
-
유저 플로우와 와이어프레임에 안 그려지는 규칙이 정책서다
쿠폰 적용 하나를 화면 사이, 화면 안, 규칙 세 장으로 나누면 마름모 안의 질문이 남는다
결론부터 1편에서 해법 설계 단계로 묶은 문서 가운데 셋을 이 글에서 다룬다. 셋은 같은 기능을 서로 다른 질문으로 자른다. 유저 플로우 — 화면 사이: 사용자가 작업을 끝내기까지 어떤 단계와 분기를 거치나 와이어프레임 — 화면 안: 한 화면에 무엇을 어디에 놓나 정책서 — 화면과...
-
페르소나는 지어내는 게 아니고, JTBD 는 기능 목록이 아니다
밀크셰이크를 산 출근길 손님은 나이가 아니라 상황으로 설명됐다
결론부터 1편에서 페르소나와 JTBD 를 문제 정의 단계에 함께 놓았다. 둘 다 “사용자를 이해한다”는 말로 묶이지만 묻는 것이 다르다. 페르소나 — 누구를 위해 설계하나. 조사에서 공통 패턴을 모아 만든 대표 원형이다 JTBD(Jobs to Be Done) — 어떤 상황에서 어떤...
-
역기획이 남기는 것은 적용안이 아니라 가설이다
같은 쿠폰 화면을 보고 벤치마킹은 무엇을 가져올지, 역기획은 왜 그렇게 정했는지 묻는다
결론부터 역기획은 출시된 서비스에서 출발해 기획 의도와 정책, 흐름을 거꾸로 추정하는 공부법이다. 끝에 남는 것은 정답이 아니라 바깥에서는 검증할 수 없는 가설이다. 산출물 — 화면 흐름도, 정책 추정 목록, 의도·지표 가설 세 가지 확인 가능성 — 흐름도는 눌러 보면 재현되고, ...
-
서비스 기획 용어 17개는 쓰이는 단계로 나누면 안 헷갈린다
같은 PO 가 한 문서에서는 PM 의 작은 일부이고, 다른 문서에서는 미니 CEO 다
결론부터 서비스 기획 용어가 헷갈리는 이유는 다른 단계에서 쓰는 말을 한 줄에 놓고 비교하기 때문이다. 그래서 17개를 역할과 네 단계로 나눴다. 역할 — 누가 결정하나: 서비스 기획자, PM, PO 문제 정의 — 무엇이 문제인가: 역기획, 페르소나, JTBD 해법 설계 — 어떻게...