기획안의 '해피 패스'
협업툴 마림바이야기#07
#협업툴 #해피패스 #시작시나리오 #마림바 #비대면 #대기업내스타트업
보고 후 남은 정리를 하는 도중, 존에게는 큰 걱정꺼리가 생겼다.
협업툴을 만드려는 기획안은 그가 이전에 만들어왔던 기획안들에 비해 너무 큰 것 같았다. 이를 기능으로만 쪼개면 수십개의 기능이 함께 거쳐가는 시나리오가 나올 가능성이 있었다. 최초부터 스위트로 만든다는 계획도 개발 공수를 생각하면 쉽지 않은 내용이었다.
'큰 기획안을 만들면, 시작부터 일이 꼬일 수 있다'
그는 과거 린스타트업과 애자일 방식으로 제품을 만들 때 프로젝트 시작 시기에 늘 해피 패스라는 것을 정의했다. 해피패스는 중요 사용자가 처음부터 끝까지 제품을 활용하여 문제를 해결하는 가장 단순한 흐름을 이야기 한다.
경험적으로 모바일 화면 6~7개 정도, 웹 화면 기준 2~3개 정도를 선택하면 해피패스의 적당한 크기가 되었다. 이를 프로토타입으로 만들어 잠재 사용자를 만나 1시간의 인터뷰 시간 동안 검증 시 사용성에 대해 검증하고 피드백을 받는 것이 일반적이었다.
타겟 사용자를 명확히 하고 시나리오를 단순히 한 뒤 검증해야, 검증을 하고 있는 사용자들에게도 풍부하게 현실과 엮인 피드백을 받을 수 있다.
'실시간 협업 화이트 보드 + 비디오 컨퍼런스 + 태스크 매니지먼트' 의 컨셉은 그간의 경험에 비하면 해피패스로 생각하기에 일의 양이 너무 컸다. 대략 고민해도 웹 화면 기준 10개 이상이 나와야 시나리오를 커버할 수 있었다.
심지어 개발하기도 어렵다. 가까운 개발자 한 명은 '특히 화이트 보드는 짧은 시간에 구현하기 어려운 기술이다.' 라고 조언했다.
풀고 싶은 문제에 대한 솔루션을 크게 정의한다는 것은 결국 팀 전체가 빨리 움직일 수 없다는 것을 의미한다. 구현이 늘어지고, 사용자 검증의 인터뷰 주기가 느려질 수 있다라는 것과 맞물린다.
하지만 이를 무턱대고 쪼갤 수도 없다. 협업툴은 획기적인 아이디어가 아닌 이상 작게 시나리오를 쓰는 순간, 기존 세상에 존재하는 제품 기능들의 부분집합이 되어 버린다. 그리고, 작은 시나리오를 구현하여 사용자에게 검증하는 순간 다른 툴과 무엇이 다르냐고 해버릴 가능성이 많다.
매년 30개 정도의 새로운 툴이 나오는 협업툴 시장에서는 획기적인 아이디어를 만든다는 것 자체가 정말 어려운 일이다. 때문에, 고유의 아이디어를 가지고 있다는 가정하에서 해피패스의 시나리오는 사용자에게 가치가 있을 최소 단위가 되는 것이 가장 좋다.
'과연 문제를 풀때의 가치를 온전히 남겨두면서 일하는 단위로 쪼갤 수 있을까?'
이 생각은 제품에 대한 시나리오를 검증하는 시나리오 검증 단계 시점에서 더 많은 고민으로 이어진다.
이 일을 시작한지 벌써 1주일이 지나갔다.
