올바른 가설 정의와 스토리 기반 기획

제품 기획

제품을 사용하는 유저의 변화를 가져올 목적(Objective)을 확인하고, 이를 정량적 목표(Key Result)화하여 그 목적을 성취하는 데에 가장 적합한 행동(제품과업)을 설계하는 것

→ 제품을 통해 유저와 기업의 문제를 해결해 나가는 과정을 설계하는 것

 

기획의 핵심은 문제를 잘 정의하고 그 문제를 해결해 나가는 과정을 잘 빌드업하는 것이다.

 

제품의 스펙을 설정하는 것만이 기획이 아니고 제품의 목적/목표 설계 및 검증하는 과정까지 포함된 것이 기획이다.

 

 

가정 : 확실하지 않은 사실을 그 반대 증거가 제시될 때까지 진실한 것으로 인정함.
가설 : 어떤 사실을 설명하거나 어떤 이론 체계를 연역하기 위하여 설정한 가정.


ex) 
가정 : 회원가입이 전환되지 않는 이유는 00 때문일 것이다.
→ 가설 : 머니 충전을 유도하는 랜딩페이지의 문구를 기존의 "머니 적립율" 키워드가 반영된 문구에서 "특정 상품 구매 시 혜택" 키워드로 변경하면, 회원가입 전환율이 10% 이상 증가할 것이다.

가정 : 특정 사용자 그룹(노인)이 하이라이트 색상표시 A로 인해 정보를 찾기 힘들어하고 있을 것이다.
→ 가설 : 검색 결과의 하이라이트 색상표시를 기존의 A에서 B로 변경하여 표기하면 검색 이용률이 5% 증가할 것이다.


가정을 가설화해서, 그것을 검증해나가서, 실체화하는 것들이 제품 기획이다.

반응형

 

 

 

가설을 세울 때 흔히 하는 실수

- 목표와 기회영역(제약조건)을 충분히 고민하지 않고 가설부터 세우는 것.

 

 

 

 

잘못된 가설정의 예시

- 비즈니스 문제 : 당사 오프라인 가맹점 매출 온라인 대비 50% 이하

- 비즈니스 목표 : 오프라인 가맹점 매출 전월대비 30% 증대

 

솔루션(가설)

1) 서비스 내 오프라인 결제 기능을 반영하면 매출이 오를 것이다.

 

→ 유저의 문제와 비즈니스의 문제의 연계가 되지 않고 매출=결제 라는 기능 중심의 해결방안 고려함

→ 비즈니스 목표는 "매출"이지만, 오프라인 결제 기능을 사용해야만 하는 가설로 제약하여, 고객의 문제와 문제해결을 할 수 있는 기회영역에 대한 부분이 간과됨

→ 결제 기능을 상용화하더라도 결제 기능을 사용해야 하는 당위성과 해당 기능의 인지에 어려움이 있어 목표 달성에 어려움이 있을 수 있음

 

 

 

 

올바른 가설정의 예시

- 비즈니스 문제 : 당사 오프라인 가맹점 매출 온라인 대비 50% 이하

- 비즈니스 목표 : 오프라인 가맹점 매출 전월대비 30% 증대

 

유저의 문제

: 오프라인 가맹점 내 서비스 이용 정보 취득이 용이하지 않음

→ 1)정보 취득을 용이하게 한 이후, 2)오프라인 가맹점 매출 증대 문제 해결 

→ 고객의 정보취득이 지불의지까지 연결되는지 확인

 

실험 목표 : 전주대비 기존 오프라인 가맹점 조회율 30% 증대 (조회율과 매출의 상관관계는 모니터링할 필요 있음)

 

기회영역(제약조건)

- 앱/웹 내 리스팅 메뉴를 활용 : App, Web, 서버 개발 리소스 필요

- 앱/웹 내 검색 메뉴를 활용 : App, Web, 서버 개발 리소스 필요

- Push를 활용 : 서버 개발 리소스 필요

- 가맹점 영업을 통한 오프라인 가맹점 확보 필요

 

솔루션(가설)

1) 사용자는 가맹점 조회 메뉴 내 [가까운 곳]이라는 필터를 활용해 근처의 오프라인 가맹점을 실시간으로 파악할 수 있다.

2) 사용자는 실시간 Push를 통해 내 위치 근처의 오프라인 가맹점 중 프로모션 진행 중인 가맹점 정보만 실시간으로 전달받을 수 있다.

3) 사용자는 검색 화면 내 추천 검색어를 통해 가맹점 정보를 실시간으로 파악할 수 있다.

 

 

일차적으로 오프라인 가맹점 정보에 대한 인지는 높지만, 매출로의 전환이 이루어지지 않는다면 다른 접근이 필요할 것이다. 

하지만, 잘못된 가설정의 예시처럼 결제 기능을 먼저 추가하기 전에, 사전에 파악해야 할 부분을 먼저 가설로 정리할 필요가 있다.

728x90

 

 

 

 

가설 검증

A/B 테스트

두 가지 이상의 시안 중 최적안을 선정하기 위해 시험하는 방법

 

일반적으로 웹페이지나 앱 개선 시 사용자 인터페이스를 최적화하기 위해 사용

 

결과만 알 수 있으므로, 정성적인 이유에 대한 파악은 별도 유저리서치 등의 방법을 활용해야 함.

 

 

 

 

스토리기반 기획

기능 중심의 요구사항이 아닌 사용자 가치에 초점을 맞춘, 사용자의 온전한 이용 시나리오를 기초로 하는 제품 요구사항 정의방식

 

 

기능 중심 정의 예시

송금 관련 기능 정의
- 수신자 선택 기능 : 리스트 조회, Exact 검색
- 금액 입력 기능 : 금액 입력 텍스트 박스(10자리 이내 입력 가능)
- 송금 버튼 : 수신자 및 금액 입력이 입력되면 버튼 클릭 가능(수신자 및 금액 미입력 시 송금 불가 팝업)

 

 

시나리오 중심 정의 예시

송금 관련 스토리
- 이용자는 00 서비스 내에서 본인이 원하는 수신대상을 선택하여, 본인이 원하는 금액 입력 후 송금할 수 있다.

인수조건
- 수신자 선택은 리스트와 검색으로 제공 가능
- 금액 입력은 10자리 이내에서만 가능
- 버튼은 수신자 선택 및 금액 입력이 완료되었을 경우 활성화될 것

*인수조건 : 제품개발을 위해 제품관리자가 요구사항을 전달할 때, 해당 요구사항에 대한 제품개발의 기준이 되는 조건

 

 

 

 

스토리 작성 시 유의사항

1. 가급적 작은 단위로 작성

ex) 사용자는 뱅킹 시스템을 활용할 수 있다 (x) → 사용자는 메인 화면에서 송금메뉴를 선택할 수 있다. (o)

 

2. 가급적 "화면"을 보면서 인수조건을 확인할 수 있는 단위로 작성

ex) 금액 정보는 00 시스템으로 전송된다. (x) → 수신자는 문자를 통해 뱅킹완료된 금액 정보를 확인할 수 있다. (o)

 

3. 스토리의 인수조건은 가급적 상세하게 기재한다.

 

4. Sprint 범위에 구현이 가능한 수준의 스토리를 Epic 단위로 매핑한다.

 

 

 

 

스토리 생애주기

: 스토리 작성 → 스토리 과업 작성 → 스토리 개발완료 → 테스트 케이스 작성 및 수행 → 스토리 인수 → 품질검증 → 배포