스토리 매핑: 빠르게 배우기 위해 계획하라
User Story Mapping
이 글은 Jeff Patton의 User Story Mapping: Discover the Whole Story, Build the Right Product 내용을 번역, 의역 및 재구성한 글입니다.
스토리 논의의 제일 첫 번째 논의사항은 기회를 구조화하는 것입니다.
Your first story discussion is for framing the opportunity.
아이디어를 기회로 만들어야 한다.
어떠한 사업적 아이디어가 떠올랐을 때, 대부분은 그 아이디어를 제품화시키기 위해 기능 백로그를 먼저 만들곤 한다. 하지만 그러한 사업적 아이디어는 너무나도 광범위하고 큰 생각(big idea)이다.
광범위하고 거대한 생각은 필연적으로 추상적인 상태로 인식되기 마련이며, 추상적인 상태로 실행되면 어떤 함의조차 갖기 힘들다. 사업적 아이디어가 떠올랐을 때 제일 먼저 해야할 것인 그 아이디어가 무엇인지에 대해 분석이 선행되어야 하며, 그 사업적 아이디어를 실행한 후에 무엇을 얻는지에 대해 알아봐야 한다.
필요한 질문은 다음과 같다.
다루고자 하는 사업적 아이디어는 무엇인가?
누가 고객이 되는가? - 구매를 고려할 수 있는 사람 혹은 이해관계자는 누구인가?
누가 사용자가 되는가? - 실질적으로 제품을 사용할 사람 혹은 이해관계자는 누구인가?
왜 구매하거나 사용하는가? - 어떤 문제가 그들을 고통스럽게 하며, 혹은 어떤 것이 그들에게 큰 효용을 제공하는가?
우리는 왜 이 제품을 만드는가? - 이 제품을 만들고 나면, 이 제품은 어떠한 방식으로 우리를 도와줄 것인가?
즉, 이 과정은 머리 속에서 떠올린 사업적 아이디어를 구체적으로 실행 가능한 ‘기회’로 만들어 나가는 과정이다.
문제가 실제로 존재하는지 확인해야 한다.
우리가 풀고자 하는 문제가 실제로 존재하는지부터 확인하세요.
Validate that the problems you’re solving really exist.
직관에 의해 도출되는, 대부분의 사업적 아이디어는 필연적으로 가설이다. 사업의 성공 여부는 사업이 진짜 성공하는지 확인하는 수밖에 없다. 하지만 현실에서 가장 큰 문제는, 사업이 진짜 성공하는지 확인하기 위해서 계획 없이 무모하게 뛰어든다는 점이다.
사업의 성공 여부는 실제 사업 실행에 의해 검증되지만, 그 검증에 있어서 리스크(risk)는 계획과 분석을 통해 최소화할 수 있다. 이 리스크 최소화의 가장 첫 단계는 ‘고객 개발 파트너(customer development partner) 발굴’이다. 실제 고객과 사용자와 만나 이야기하면서, 실제로 기회가 생각한 대로 존재하는지 확인해나가는 것이다.
여기서 중요한 점은, 고객에 대해 더 많이 알아갈수록, 기회는 형태는 엄청나게 변화할 것이란 것이다. 다시 말하면, 고객의 맥락과 문제들에 대해 구체적으로 알아나가면서 그 기회의 형태는 점점 뚜렷하고 다양하게 펼쳐진다.
일반적인 그저 그런 사업가라면, 사업 아이디어를 떠올린 직후 기능 백로그를 왕창 기록하여 제품을 만들고, 고객에게 제품에 대한 평가를 요청한다. 이미 수많은 자원과 시간이 낭비된 채로 말이다.
하지만 똑똑한 사업가는 그렇게 하지 않는다. 사업 아이디어를 떠올리면 그 사업 아이디어를 검증하고 구체화하기 위해 고객에게 먼저 다가가 고객을 이해하고, 기회를 더 뚜렷하게 만드는 것을 목표로 삼는다.
‘제품을 만드는 행위’는 필연적으로 마지막으로 해야하는 것이 된다.
왜 지속적으로 학습해야 하는가?
최소 기능 범위 제품을 만들 때 집중하는 것은 다음과 같다.
(1) 사람들이 충분히 기뻐할 만큼
(2) 최소한의 범위로 개발하는 것
하지만 1번에는 심오한 의미가 뒤에 있다. ‘충분히 기뻐한다’라는 것은, 단순히 1회성으로 끝나는 것이 아니라, ‘구매 결정 뿐만 아니라, 구매 이후에도 필요할 때 찾아서 사용할 만큼’의 용의를 가져야 함을 의미한다.
그렇기 때문에 우리는 고객들의 삶과 맥락에 대해 깊이 이해해야 하며, 제품이 어떤 스토리를 가져야 그들의 삶에 밀접하게 들어가 의미를 가질 수 있는지 결정할 수 있다.
스토리 매핑을 통한 학습
우리는 제품을 실제로 출시하기 전에, 어떤 로드맵을 가지고 제품을 단계적으로 출시할지 계획하기 위해 출시 계획을 위한 스토리맵을 제작한다. 여기서 주의할 점은, 제품 출시 계획이 한번 정해졌다고 해서 완전히 고정되는 것이 아니란 점이다. 우리는 지속적으로 학습해나가며 기능과 스토리의 우선순위를 조정해나간다.
위의 이미지처럼, 출시 후에도 지속적으로 출시 계획이 조정된다. 즉, 여기서 중요한 것은 지속적인 고객 조사를 통해 ‘학습’하고, 스토리맵이 살아움직이듯 조정된다는 점이다.
스프린트 내용이 정해지면 해당 스프린트의 스토리/활동을 한켠에 분류하여 태스크를 정리한다.
프로토타입(=최소 기능 제품)을 만들 때 주의할 점
MVP의 나쁜 예와 좋은 예, https://appetiser.com.au/blog/minimum-viable-product-example/프로토타입이라고 해서, 옛날 게임 데모 체험판처럼 중간에 흐름을 끊어버리면 안 된다. 시간이 좀 걸리더라도, 고객이 가지고 있는 문제를 유의미하게 풀며 효용을 제공할 수 있어야 한다. 기능 자체가 불완전하여 효용을 제공하지 못 한다면, 그 제품 혹은 사업의 자체의 실패라기보다 제품 만드는 과정의 실패에 가깝다.
우리의 제품 사업의 목표는 ‘만드는 것’이 목표가 아니다. ‘우리가 제대로 된 것을 만들고, 사업 아이디어를 확인하고 배우는것’이 목표임을 잊지 말아야 한다.
