Showing Posts From

Prd

AS-IS TO-BE로 보면 이 기획이 말이 된다

AS-IS TO-BE로 보면 이 기획이 말이 된다

AS-IS TO-BE로 보면 이 기획이 말이 된다 또 왜냐고 묻더라 회의실. 개발팀장이 물었다. "이 기능 왜 만들어요?" 기획서 12페이지. 유저 플로우 3개. 예상 효과까지 썼다. 그래도 묻는다. 왜. 숨 한번 쉬고 화이트보드 들었다. "AS-IS TO-BE로 보면요." 왼쪽에 현재. 오른쪽에 목표. 3분 만에 이해했다. 질문 끝. 이게 6년차에 배운 거다.1년 전 나는 설명을 못했다 기획서를 길게 썼다. 배경, 목적, 기대효과, 상세기능, 예외케이스. A4 20장. 2주 걸렸다. 대표님이 물었다. "한 줄로 요약하면?" 버벅댔다. "그러니까... 유저가..." 답을 못했다. 내가 뭘 기획한 건지 모르겠더라.디자이너가 물었다. "지금 화면이랑 뭐가 달라져요?" 또 버벅였다. "일단... 버튼이 추가되고..." 그게 다였다. 버튼 추가. 왜 추가하는지 설명 못했다.개발자가 말했다. "스펙이 불명확해요." 화났다. 20장이나 썼는데. 지금 생각하면 맞는 말이었다. 나도 몰랐으니까. 뭘 만드는지.선배가 알려준 프레임워크 점심 먹다가 토로했다. "기획서 써도 이해를 못 해요." 선배가 웃었다. 8년차 PM. "AS-IS TO-BE 써봤어?" 처음 들었다.선배가 노션 켰다. 기획서 첫 장. 표 하나.구분 AS-IS TO-BE현재 ... ...목표 ... ..."이것만 명확하면 돼." 그게 다였다."현재 뭐가 문제야?" "목표는 뭐야?" "어떻게 바뀌는 거야?" 세 질문. 이걸 답하면 기획이 된다고 했다. 반신반의했다. 너무 간단해서. 첫 적용, 회원가입 개선 다음 프로젝트. 회원가입 개선. 일단 AS-IS 썼다. AS-IS (현재 상태)회원가입 7단계 완료율 42% 평균 소요시간 3분 20초 이탈 지점: 본인인증(38%), 약관동의(25%) 유저 피드백: "너무 복잡해요" (CS 월 230건)구체적으로 썼다. 숫자로.TO-BE 정의했다. TO-BE (목표 상태)회원가입 3단계 완료율 목표 65% 평균 소요시간 1분 30초 소셜 로그인 우선 노출 필수 정보만 1차 수집, 나머지는 사용 중 수집변화가 명확했다. 7단계 → 3단계.이걸 기획서 첫 장에 넣었다. 페이지 수 12장 → 6장. 설명 시간 30분 → 10분. 질문 거의 없었다. 개발팀장이 말했다. "이제 이해됐어요."왜 이게 작동하는가 3개월 써보니 알았다. 사람들은 "변화"를 이해하고 싶어 한다.기획서는 보통 목표만 쓴다. "회원가입을 개선한다." 현재가 없다. 비교 불가. 얼마나 개선되는지 모른다.AS-IS TO-BE는 변화를 보여준다. 변화 = TO-BE - AS-IS 이게 기획의 가치다. 현재 7단계 → 목표 3단계 = 4단계 개선. 숫자로 보인다. 명확하다.대표님이 좋아하는 이유. "투자 대비 효과"가 보인다. 개발 2주 → 완료율 23%p 상승. ROI 계산 가능.개발자가 좋아하는 이유. "왜 만드는지" 명확하다. 현재 문제 → 해결 방향. 동기부여 된다.디자이너가 좋아하는 이유. "비포 애프터"가 명확하다. 화면 개선 방향 잡힌다. 레퍼런스 찾기 쉽다. 실전 적용 3가지 케이스 케이스 1: 검색 기능 개선 AS-IS검색 결과 없음: 43% 재검색률: 67% 이탈률: 52% 검색어 자동완성 없음 오타 보정 없음TO-BE검색 결과 없음: 목표 15% 연관 검색어 제안 오타 자동 보정 인기 검색어 노출 검색 히스토리 저장변화: 검색 실패 → 검색 성공. 개발 공수: 3주. 예상 효과: 검색 성공률 28%p 상승. 승인까지 2일.케이스 2: 결제 플로우 단순화 AS-IS결제 5단계 결제 완료율 68% 평균 소요 시간 2분 40초 이탈 지점: 배송지 입력(45%) 모바일 결제 포기율 38%TO-BE결제 3단계 결제 완료율 목표 82% 배송지 자동 불러오기 간편결제 우선 노출 원클릭 결제 옵션변화: 클릭 수 감소. 완료율 증가. 개발 공수: 4주. 예상 매출 증가: 월 1,200만원. CFO가 바로 승인했다.케이스 3: 푸시 알림 재설계 AS-IS푸시 발송: 하루 평균 8건 오픈율: 12% 설정 해제율: 주 3.2% 타이밍: 오전 10시 일괄 발송 개인화 없음TO-BE푸시 발송: 유저당 하루 최대 3건 오픈율 목표: 25% AI 기반 발송 시간 최적화 유저 행동 기반 개인화 알림 카테고리 선택 가능변화: 스팸 → 유용한 정보. 개발 공수: 2주. 예상 효과: 재방문율 15% 증가. 마케팅팀이 환호했다. AS-IS 작성할 때 팁 현재를 객관적으로 써야 한다. 주관 빼고. 숫자로.나쁜 예시 "현재 회원가입이 복잡함" 얼마나 복잡한지 모른다.좋은 예시 "현재 회원가입 7단계, 완료율 42%, 평균 3분 20초 소요" 측정 가능하다. 비교 가능하다.AS-IS 작성 체크리스트: 숫자로 표현했는가 측정 가능한가 누가 봐도 동의하는가 문제가 명확한가 데이터 출처가 있는가데이터 없으면 추정한다. "CS 문의 주 평균 50건" "유저 인터뷰 10명 중 7명 불편 호소" "경쟁사 대비 2단계 더 많음" 완벽하지 않아도 된다. 없는 것보단 낫다. TO-BE 작성할 때 팁 목표는 현실적이어야 한다.나쁜 예시 "완료율 100%" 불가능하다. 신뢰 떨어진다.좋은 예시 "완료율 42% → 65% (목표)" 달성 가능하다. 근거 있다.TO-BE 작성 체크리스트: AS-IS보다 나은가 측정 가능한가 달성 가능한가 기간이 명확한가 비용 대비 효과적인가목표 설정 근거:경쟁사 벤치마크 "네이버는 3단계, 카카오는 2단계"과거 데이터 "작년 A 기능 개선 시 15% 상승"유저 리서치 "10명 중 8명이 3단계가 적당하다고 응답"숫자에 이유를 단다. 설명이 쉬워진다 이제 어떤 질문에도 답한다."왜 만들어요?" → "AS-IS가 이래서 TO-BE로 가려고요." "얼마나 좋아져요?" → "42%에서 65%로 예상돼요." "꼭 해야 해요?" → "현재 이탈률 58%인데 개선 안 하면 더 오를 거예요." "다른 방법은 없어요?" → "이 방법이 가장 빠르고 효과적이에요. AS-IS TO-BE 비교표 보시면..." 한 방에 끝난다.설득이 쉬워졌다. 표 하나면 된다. 말 많이 안 해도 된다.회의 시간 절반 줄었다. 전: 1시간 후: 30분 질문 80% 감소. 복잡한 기획도 단순해진다 3개월 전. 앱 전면 개편 기획. 120개 화면. 기능 50개. 막막했다.AS-IS TO-BE로 쪼갰다. 화면별로. 기능별로. 유저 플로우별로.메인 화면AS-IS: 최신순 나열, 평균 체류 28초 TO-BE: 개인화 추천, 목표 체류 60초마이페이지AS-IS: 5depth, 원하는 기능 찾기 어려움 TO-BE: 2depth, 자주 쓰는 기능 상단 고정알림 센터AS-IS: 시간순 나열, 확인률 23% TO-BE: 중요도 기반 정렬, 목표 확인률 45%50개 기능 → 50개 AS-IS TO-BE.대표님이 말했다. "이제 보이네요. 왜 개편하는지." 4개월 프로젝트 승인. 개발 시작. 이해관계자 설득에 최적 마케팅팀과 싸웠다. "푸시 더 보내야죠!" 나: "오픈율 12%인데요." 마케팅: "그래도 보내야 해요!"AS-IS TO-BE 보여줬다. AS-IS하루 8건 발송 오픈율 12% 푸시 해제율 주 3.2% 3개월 후 푸시 수신 유저 0명 예상TO-BE하루 3건 발송 (선별) 오픈율 목표 25% 푸시 유지율 상승 장기 채널 확보마케팅팀 조용해졌다. "...그럼 개인화 로직은?" 협의 시작.경영진 보고도 마찬가지. 숫자 좋아한다. 변화 좋아한다. AS-IS TO-BE면 충분하다. 실무에서 쓰는 템플릿 노션에 템플릿 만들었다. ## AS-IS TO-BE 분석### AS-IS (현재 상태) - 측정 지표 1: - 측정 지표 2: - 측정 지표 3: - 주요 문제점: - 데이터 출처:### TO-BE (목표 상태) - 목표 지표 1: - 목표 지표 2: - 목표 지표 3: - 개선 방향: - 달성 기간:### GAP 분석 - 변화량: - 필요 리소스: - 예상 효과: - 리스크:### 실행 계획 - 1단계: - 2단계: - 3단계:모든 기획에 쓴다.5분이면 작성 가능하다. 처음엔 10분 걸렸다. 지금은 자동이다.팀원들도 쓰게 했다. 처음엔 귀찮아했다. 2주 후 모두 쓴다. "설명하기 편해요." 6개월 후 변화 기획서 페이지 수: 20장 → 8장. 승인 기간: 2주 → 3일. 개발 착수 지연: 40% → 5%. 회의 시간: 평균 1시간 → 30분. "스펙 불명확" 지적: 주 5회 → 주 1회.숫자로 증명됐다. AS-IS TO-BE가 작동한다.대표님이 말했다. "기획이 명확해졌어요." 최고의 칭찬. 주의할 점 AS-IS TO-BE가 만능은 아니다.안 맞는 경우:신규 서비스 (AS-IS 없음) 탐색적 프로젝트 컨셉 기획 단계이럴 땐 다른 프레임워크.흔한 실수:AS-IS를 부정적으로만 씀 TO-BE가 너무 이상적 측정 불가능한 목표 숫자 없이 감으로객관성 잃으면 의미 없다.보완 방법:유저 리서치 함께 데이터 분석 병행 프로토타입 검증 A/B 테스트 계획AS-IS TO-BE는 시작이다. 지금도 쓴다 오늘도 기획서 썼다. 첫 장. AS-IS TO-BE. 10분 걸렸다.슬랙에 공유했다. 개발팀장: "명확하네요. 이번 주 스프린트에 넣을게요." 디자이너: "화면 컨셉 잡혔어요." 마케팅: "예상 효과 공유 부탁드려요." 질문 끝.퇴근길 지하철. 주니어한테 DM 왔다. "선배님, AS-IS TO-BE 어떻게 쓰는 거예요?" 템플릿 보냈다. "한번 써봐. 세상이 달라질 거야." 6년차가 1년차한테 배운 거. 또 전달한다.기획은 복잡하지 않다. 현재 → 목표. 이게 전부다. AS-IS TO-BE로 보면, 모든 기획이 말이 된다.내일 회의. 새 프로젝트. AS-IS TO-BE 준비했다. 또 설득한다.