UNIS 스프린트 메이커로그 02. 가설 설정 이렇게 하시면 안 됩니다.

(11.8.에 업로드했던 메이커로그를 EGL 클럽 내부 메이커로그로 설정해서 재업로드합니다!)

스프린트에서 가장 중요하지만 어려운 단계인 가설 설정과 가설 검증 지표 수립 단계에 대한 메이커로그입니다.

*참고 : 아래 메이커로그를 같이 보고 이 글을 보시면 더욱 좋습니다

저는 작년에 UNIS 3기에서 창업팀 '쏙쏙'으로 활동을 했습니다.

오랜만에 쏙쏙팀원들에게 스프린트 진행 당시 느꼈던 정말 유의해야 할 사항이 뭐냐고 물어봤는데요. 아래의 답변을 얻었습니다.

"가설을 명확히 세우고 스프린트를 진행해라! 통제변수는 반드시 통제해라"

위와 같은 답변이 나온 이유는, 쏙쏙팀에서 스프린트를 진행할 때 가설이 명확하게 세워지지 않고 검증할 지표가 명확하게 구분되지 않은 채로 프로토타입을 완성했던 실수를 했기 때문입니다. 지금 스프린트를 진행 중인 UNIS 4기 창업팀분들께 도움이 되었으면 하는 마음으로 우리가 했던 실수와 헤맸던 점들을 다시 회고해보려 합니다.

쏙쏙팀에서 당시 스프린트를 진행할 때에는 냉장고에 보관 중인 음식물 관리를 도와주는 앱서비스를 주제로 진행을 했습니다. 서비스에 대해 간략히 소개하자면, 아래와 같은 기능들을 담은 서비스였습니다.

• 냉장고에 남은 음식물 정보(음식 종류, 상온/냉장/냉동 중 보관형태, 음식의 양, 유통기한/소비기한 정보 등)를 앱 내에 등록해두고, 유통기한 임박한 음식물들의 푸시알림을 보내주는 기능 - 음식이 상하기 전에 미리 확인하고 챙겨먹도록, 그래서 폐기하는 음식을 줄일 수 있도록 도와줌

• 남은 식재료들을 선택해, 해당 재료들이 들어가는 요리 레시피를 검색해볼 수 있는 기능 - 레시피를 따라 재료를 활용해 요리를 해먹을 수 있게 도와줌

• 등록해둔 음식물 중에 유통기한이 지나기 전에 먹어서 해결한 음식의 양과 먹지 못하고 폐기한 양을 체크해주고, 주/월 단위로 내가 폐기한 음식물 총량과 폐기하지 않고 구출해낸 음식물 총량을 계산해 탄소발자국 저감에 기여한 정도를 리포트 형태로 보여주는 기능

1. 장기목표와 HMW, 가설이 연결되게 설정되지 않았다.

1일차 활동에서 세웠던 장기목표는 이랬습니다.

• 이 세상의 모든 냉장고에서 버려지는 식재료가 없게 한다.

가정(소비자)/가게(생산자) 냉장고 모두를 가리킴

효율적인 식재료 관리, 잉여 식재료 감소, 식재료 활용 순환

HMW(How Might We)는 논의 끝에 아래 2가지로 좁혀졌는데

1. 어떻게 하면 이용자들에게 음식폐기물 절감 기여 정도를 수치화/시각화해서 보여주고 음식폐기물 절감에 지속적으로 참여하도록 유도할까?

2. 어떻게 최초 등록 시 어떻게 냉장고 안의 음식들을 빠르게 등록하게 만들까?

2번의 경우 지금 우리 팀이 보유한 기술로는 구현이 어렵다고 판단해서, 그래도 스토리보드로 아이디어를 짜볼 수 있을 것으로 보이는 1번을 최종 채택해 스프린트를 진행했습니다.

솔루션 형태를 다음과 같이 결정했고

평균 음식물 쓰레기 양과 실제배출량의 차이를 음식물쓰레기 감소 측정 지표로 사용

가설은 다음과 같이 세웠습니다.

평균 음식물 쓰레기 양과 실제배출량의 차이를 음식물쓰레기 감소 측정 지표로 사용해서 시각적으로 보여주면 앱을 더 오랫동안 사용할 동기를 부여하는 데에 도움이 된다.

하지만 결과적으로는, 여기서 설정한 HMW와 가설 자체가 장기목표와 직접적으로 얼라인되기보다는 너무 문제해결을 위해 빙 돌아가는 형태의 솔루션가설 같다는 피드백을 들었습니다.

[음식폐기물 절감 정도를 수치화/시각화해서 보여주는 것]이 -> [음식물을 줄이는 데 동참]하도록 유도하기에는 직접적인 솔루션이 아니라는 겁니다. 추후에 외부에서 받은 피드백과 내부에서 나눈 논의 중에는, 오히려 냉장고에 보관 중인 음식물들을 이용자들끼리 서로 공유하는 커뮤니티 기능이 서로 동기부여를 촉진하는 데 직접적인 영향을 주는 솔루션형태일 수 있다는 이야기도 있었습니다.

2. 테스트 범위가 너무 광범위해서 프로토타입을 설계할때 검증할 변수 외에 다른 변수들이 통제되지 않았다.

유저테스트 과정은 A/B테스트 형태로 진행했습니다. 서로 다른 두 개 버전의 프로토타입을 만들어 고객들에게 보여드리고 각각 사용해보게 한 뒤(Figma 프로토타입 프리뷰 화면을 보여드렸습니다. 버튼을 누르면 화면이 넘어가는 정도의 인터랙션만 구동했습니다), 두 버전 중 어떤 것을 더 선호하는지, 각각 사용의 편의성 측면에서 10점 만점에 몇 점으로 평가하는지를 조사했습니다. (다만 인터뷰한 고객이 5명이었기 때문에 양적으로 일반화하기에는 턱없이 부족한 모수임은 감안하고 진행했습니다.)

솔루션 적용이 통제된 A버전, 솔루션이 적용된 B버전 총 두 가지 버전의 프로토타입을 준비하기로 했습니다.

A버전 : 리포트 메뉴 기능 그대로 . 음식물 쓰레기 양을 보여주는 것은 그대로. 통계수치만 보여주고 시각화 X. 평균과의 차이를 보여주지 X.

B버전 : 음식물쓰레기 양을 시각화 O . 평균과의 차이 보여주기 O

그러나 실제로 구현한 프로토타입에서는, 검증하기로 한 음식물 쓰레기 양을 시각화하는 부분 외에 다른 영역도 A버전과 B버전에서 차이를 줬습니다. 이 같은 실수를 한 배경에는, B버전이 더 월등하게 사용성이 좋다는 평가를 이끌어내기 위해 B버전의 전반적인 퀄리티를 더 높여야 할 것 같다는 생각 때문이었습니다.

• 검증하기로 한 영역은 빨간색 표시된 영역 - <이번 주 음식쓰레기 배출량>을 보여주는 영역이었습니다. 그러므로 이 영역만 제외하고 나머지 영역은 화면구성을 모두 동일하게 했어야 변수가 엄격히 통제된 환경에서 검증을 할 수 있었던 것이죠.

• 초록색 표시한 영역인 <이번 주 버린 음식물>을 보여주는 비주얼도 A와 B를 다르게 디자인했습니다. (디자인할 때 의도부터가 B버전을 더 마음에 들게 느끼도록 만들겠다는 의도가 다분했습니다...)

• 파란색 표시한 영역인 <현재 음식쓰레기 배출량을 유지할 때 탄소 절감 효과>를 보여주는 영역의 경우는 -> 나무 한 그루만큼의 탄소가 절감된다는 것이 와닿지 않는다는 고객의 피드백이 있기도 했습니다. 전반적으로는 음식물을 줄여야 겠다는 동기부여가 되는 효과가 있다는 긍정적인 피드백이 있었지만, 너무 당연한 사실을 검증하는 것 같다는 느낌도 들었습니다.

또 우리 팀의 경우 스프린트에 돌입하기 전 별도로 완성되어 있는 화면 프로토타입이 전혀 없었습니다. 그래서 스프린트를 진행하며, 가설에서 검증하는 부분 외에도 서비스 기능 전반에 대한 프로토타입을 모두 만들었습니다. 그러나 추후 유저테스트하는 과정에서 오히려 테스트하는 범위가 너무 광범위해지는 문제가 있었습니다. 인터뷰를 할 때, 검증하기로 한 음식폐기물 시각화 화면에 대해서만 테스트를 하는 게 아니라 레시피 조회나 음식물 등록 화면에 대한 사용성까지 같이 물어보고 평가를 받게 됐습니다. 이렇게 인터뷰를 진행하니, 검증하기로 한 부분에만 집중해서 평가를 받고 검증여부를 판단하기가 어려운 상황이 됐습니다.

나중에 기획자 팀원이 말하길 "어차피 숲은 없으니 숲을 다 보려고 하지 말고 나무 하나만 잘 집중해서 보는 게 중요한 것 같다"고 했습니다.

3. 가설 검증을 판단하는 기준은 어떻게 세워야 하지?

유저테스트를 진행해서 고객분들의 평가점수와 선호도는 파악을 했는데, 문제는 그래서 가설이 검증되었는지 기각되었는지를 어떻게 판단해야 할지였습니다.

우리는 가설 검증 지표를 이렇게 세웠는데요.

• 솔루션이 적용된 버전과 적용되지 않은 버전 각각의 만족도 비교

1~10점 척도 (*0점 : 다운로드도 받지 않을 것임 ~ 10점 : 장기적으로 1년 내내 사용할 의향 있음)

A버전(솔루션 적용X) 평점 / B버전(솔루션 적용O) 평점

두 가지 버전의 차이가 B버전의 평점이 A버전의 평점보다 30% 높을 것이다.(B-A)

결과는 이랬습니다.

→ 가설 검증 지표를 달성하지 못했다.

B버전 선택 3명 > A버전 선택 1명, 둘 다 차이 없음 1명

B버전 평점 평균 6.6 - A버전 평점 평균 6.0 = 평점 차 +0.6 (+10%) => 30% 이상 차이나지 않았음

B버전과 A버전 평점을 동일하게 준 인터뷰이 3명 (각각 6점, 7점, 8점씩 줌)

⇒ 음식물 쓰레기 배출량을 시각화해서 보여주는 것만으로는 앱의 장기적인 사용을 유도하기 어렵다. (더 강력한 동기부여 요인이 필요하다!)

다만 이 30% 차이라는 것도 임의적인 수치 설정이었습니다.

우리가 설정한 가설 검증 지표에 따르면 가설은 기각되는 것으로 결론이 나긴 했지만,

실제 인터뷰 과정에서 고객보이스를 들어보고 체감한 바로는 B버전에 대해 확연하게 차이를 느끼고 더 긍정적인 피드백을 줬다고 체감된 부분도 있었기 때문에

가설 검증 지표를 맞게 설정한 것인가에 대한 의문도 계속 있었습니다.

그리고 가설이 기각되었다고 스프린트가 실패한 것은 아닙니다.
가설은 입증되지 않았지만 서비스 자체의 취지에 대해서는 긍정적인 호응을 얻었고, 고객 인터뷰를 통해 주요 기능들을 구체화할 인사이트도 얻었고, 원래 목표했던 사용자의 이용 지속을 유도하고 동기부여하는 목적 달성을 위한 또다른 검증해볼 만한 솔루션 형태로 리워드, 커뮤니티, 체크리스트 기능 등이 가능성이 있겠다는 힌트를 얻었습니다.

쏙쏙팀의 CTO님은 가설 기각을 쓰라리게 인정하고 스프린트 결과를 회고하던 때를 회상하며 "서비스의 가치를 증명하기 위해 긍정적인 결과를 찾아다니던 태도를 버려라,

부정적인 결과가 나오면 기뻐해라"라고 덧붙이기도 했습니다.

정리하자면, 우리는 체계적인 사용자의 니즈 탐색, 가설 검증에만 집중하는 것 = 고려할 요인의 중요도/우선순위 설정 을 잘 못했습니다.

• 팀이 중시하는 가치(친환경)와 =/= 실제 사용자들이 중시하는 가치(기능 조작의 편리성)가 달랐습니다. 공급자중심이 아닌 사용자중심의 접근하는 것이 필요했습니다. => 다음 스프린트에는 사용자의 니즈 탐색을 더 체계적으로 해서 보완해야 겠다는 인사이트를 얻었습니다.

• 설정한 가설 검증에만 집중하는 게 어려웠습니다. 외부의 복합적인 요인들을 함께 고려하면서 전체적으로 조망하는 접근을 했습니다. => 스토리보드 및 프로토타입 작업과 테스트를 진행할 때 가설 검증에만 집중해서 접근해야 겠다는 깨달음을 얻었습니다.

+덧붙임 : 참고하면 좋은 자료

• 가설 검증 지표 관련 참고하면 좋은 자료

오늘 아티클 하나를 통해 NPS(순고객 추천 지수, Net Promoter Score)라는 개념이 있다는 것을 알게 되었는데요. 1~10점 척도로 지속적인 사용 의향이 있는지 질문해보고 그 답의 수치를 분석할 때에도 정해진 공식이 있다는 걸 알게 됐습니다.

아래는 위 글에서 일부 인용해 가져온 내용입니다.

NPS는 단 하나의 문항으로 고객 충성도를 측정하는 방법으로, 고객 경험을 측정하고 비즈니스 성장을 예측하기 위한 것입니다. '이 프로덕트를 친구나 동료에게 추천할 가능성은 얼마나 됩니까?' 같은 단순한 질문을 사용하고, 사용자는 '전혀 가능성이 없음'에서 '매우 가능성이 있음' 사이의 0~10등급 척도 중에서 선택합니다.

이때 0~6점으로 응답하면 비추천자, 7~8점으로 응답하면 수동적 중립자, 9~10점으로 응답하면 추천자로 분류한다고 합니다.

표준 NPS 공식은 추천자(9~10점 응답자) 비율에서 비추천자(0~6점 응답자) 비율을 빼는 것입니다. 예를 들어 응답자 80%가 찬성이가 10%가 반대라면 NPS는 70이 됩니다.

이 공식을 미리 알았다면 스프린트에서 가설 검증 지표를 보다 체계적으로 설정할 수 있었을 텐데! 우리 팀의 경우 임의로 8점 이상 응답하면 적극 사용 의향이 있다고 판단하는 식으로 검증을 진행했던 기억이 있습니다.

• 솔루션 개발 우선순위 결정 관련 참고하면 좋은 자료

개발 우선순위 결정도 어려운 단계였던 것 같습니다. 지금 다시 의사결정 과정을 보니, 위와 같은 프레임워크를 참고하면 보다 근거와 체계를 가지고 의사결정을 할 수 있을 것 같습니다.

사진은 스프린트 1일차에 HMW를 논의했던 과정인데요.

분명히 노란색 표시한 항목들을 주요하게 고려했던 것 같고, 이슈가 가장 많은 순으로 고려하면 <레시피 제공 서비스 차별화>와 <주 기능 결정> 항목이 최종 후보여야 했는데

최종 결정된 HMW는 노란색 표시되어 있지도 않은 <효과 측정과 가시화> 영역이었네요. (왜...?)

아무리 프레임워크와 기준을 잘 따라가려고 노력해도 최선의 의사결정을 내리는 건 언제나 어려운 일인 것 같습니다.

결국 스프린트 진행하면서 겪는 어려움은 1) 팀 내에서 최대한 많이 논의하면서 2) 다른 팀과도 상황을 공유하고 피드백을 받으면서 3) 인터뷰에서 고객분들 피드백도 적극적으로 받으면서 같이 해결해나가는 것밖에 방법이 없는 것 같습니다.

마지막으로 UNIS 3기에서 스프린트에 참여했던 알럼나이분들의 조언을 덧붙입니다.

"아이디어를 많이 내보면서 팀원들과 같이 구체화하는 과정이 중요하다. 무엇보다 현실성 !! 스프린트 때 베타 테스트나 잠재 사용자 인터뷰를 간단하게라도 하는만큼 그 이후에 실제로 제품 개발이나 제작에 바로 착수할 수 있도록 현실적인 선에서 구체화하는 게 중요하다. 예를 들어 너무 많은 서비스를 한 앱에 담으려고 하기보다는 우선 메인 서비스 하나를 중심으로 스프린트를 진행하고 나왔던 여러 아이디어는 추후 개발하며 추가하는 식으로 진행해라"

"무조건 주어진대로 따라가기보다는 팀의 효율을 높일 수 있는 방향으로 적절히 수정하면서 스프린트 방법론을 활용해라"

"신속하게 방향을 정하고, 방향을 정했으면 쭉 밀고나가라. 스프린트가 단기간 진행되는만큼 가설을 세우면 일단 인터뷰까지는 밀고나가보라"

UNIS 4기 창업팀분들, 모쪼록 스프린트 과정 파이팅하시기 바랍니다!