새로운 기능 기획 시 범위를 어떻게 합의할까?
우리는 몇 피스 퍼즐을 맞추고 있을까?
내 커리어는 서비스가 완전히 궤도에 오른 경우보다 프로덕트 마켓핏을 찾기 전 단계의 회사에서 주로 만들어졌고 현재도 그런 상태다. 성향상 초기 스테이지가 잘 맞고, 방향성이 너무 명확할 경우 매력을 못 느끼는 것 같다. 과거에는 프로덕트 디자이너로, 현재는 프로덕트 오너로 일하지만 여전히 새로운 기획의 크기나 디테일을 산정해 동료들과 합의하는 것은 어렵다. 개발 리소스는 정해져 있고, 메이커들의 디테일에 대한 바람은 크기 때문이다. 프로덕트 디자이너 시절에는 나 역시 디테일에 대한 욕심을 많이 부렸는데, 프로덕트 오너가 돼 보니 입장이 또 달라졌다.
기능은 가설 검증의 도구
가장 달라진 점은 생존을 위해 디자인과 개발 만능 주의에서 벗어나게 된 것이다. 과거에는 멋진 디테일을 가진 UX가 허허벌판에서 프로덕트 마켓핏을 빨리 찾아줄 것이라는 막연한 믿음이 있었다. 과거 제품 성장 주기에 비해 무리한 개발을 밀어붙였던 기능들이 생각난다. 디테일이 많아져 개발 기간이 자동으로 길어졌고 예상치 못한 코너 케이스도 계속 발견됐다. 유저들의 반응 역시 좋지 않았다.
좌측이면 충분한데 우측같이 만들 때 문제가 발생한다.이런 경험은 그 이후로도 몇 번 반복됐다. 유저 반응이 좋지 않은 신기능의 다음 방향이 모호해지자 자연스레 깨달은 지점이 생겼다.
스타트업, 특히 프로덕트 마켓핏을 찾기 전 초기 팀의 경우 새롭게 개발될 기능은 가설 검증 수단 그 이상 그 이하도 아니라는 것이다. 이 단계에서 디자인이나 개발 자체에 너무 심각한 의미성을 부여하지 않는 것이 중요하다. 예를 들어 콘텐츠 공유가 없는 프로덕트에 공유 기능이 처음 개발된다고 해보자. 0에서 1로 갈 때 확인해야 하는 건 공유 자체가 잘 되는 지이다. 아이콘 밑에 사람들이 얼마나 많이 공유했는지 카운트되는 숫자나, 서비스 정체성을 담은 예쁜 아이콘 디자인은 이후에 적용해도 충분하다.
디자인과 개발은 가설 확인을 위한 도구다.
디자이너 시절 나는 이 사실을 받아들이기가 무척 어려웠던 것 같다. "벤치마킹 해보면 다른 프로덕트의 공유 기능은 저렇게 고도화 됐는데, 우리 서비스는 겨우 이 정도로 만족해도 되는 걸까?" 이런 생각은 표면적으로는 서비스를 위한 것처럼 보이지만 사실 메이커의 욕심이 무의식에 반영됐을 가능성이 높다. 욕심을 다스릴 수 있는 가장 좋은 방법은 우리 서비스가 초기 스테이지임을 강하게 인식하는 것이다. 그리고 초기 스테이지에서만 할 수 있는 메이커들의 역할을 이해하고 자부심을 가지는 것이 좋다. 이 시기의 기능 개발은 마켓핏을 이미 찾은 서비스처럼 기능 개선을 위한 디테일에 자원을 투자하는 것이 아니라, 초기 가설을 기능으로 치환해 시장에 받아들여지는 것을 빠르게 살피는 훨씬 더 근본적이고 원초적인 과정에 가깝다. 메이커들에게 디테일을 타협하는 것은 쓰릴 수 있다. 하지만 목표 달성을 위한 절충 과정 역시 무척 훌륭한 디자인적 사고라고 생각한다.
우리는 몇 피스 짜리 퍼즐을 맞추려는 걸까?
신규 기능의 범위를 정할 때 떠올리기 좋은 메타포는 퍼즐이다. 가설 검증을 위한 솔루션을 퍼즐 피스의 복잡도와 비교해 보는 것이다. 너무 적은 피스일 경우 가설을 풀기 위한 최소 디테일에 못 미칠 수 있고, 너무 많을 경우 가설 검증에 자칫 과할 수 있다. 프로덕트 오너와 프로덕트 디자이너가 개발 리소스를 고려해 가설 검증에 적당한 솔루션 디테일(피스)을 사전 조율하는 시간이 있으면 효율적이다.
이처럼 솔루션에 맞는 적당한 피스의 퍼즐을 함께 떠올릴 경우 예측하기 힘든 코너 케이스를 최소화할 수 있는 장점도 존재한다. 디테일(피스)이 많은 기능은 첫 배포에서 모든 코너 케이스와 버그를 대응하기 힘들다. 이경우 처음부터 좋은 완성도를 기대하기는 쉽지 않다.
솔루션을 몇 개의 퍼즐 피스로 풀지 머릿속 상을 만들자. @aelitta인테리어 플랫폼 서비스에서 아래와 같은 문제를 풀고 있다고 가정해 보자.
문제-1) 원룸에 사는 유저들이 원룸 정보를 검색하는 것에서 어려움을 겪고 있다.
가설-1) 원룸 정보를 쉽게 얻을 수 있다면 원룸 상품 판매량이 증가할 것이다.
가설 검증을 위한 솔루션은 다양할 수 있다.
솔루션-1) 온보딩부터 유저의 거주 형태가 원룸인지, 투룸인지를 먼저 식별한 뒤 홈화면에서 관련 정보를 노출한다.
솔루션-2) 원룸 관련 정보만 볼 수 있는 새로운 탭을 오픈한다.
솔루션-3) 화면 상단에 검색박스를 두고 탭 하면 힌트 텍스트로 원룸 관련 내용을 넛지 한다.
여기서 중요한 것은 최소한의 비용으로 가설 검증에 효율적인 사용자 경험을 찾는 것이다. 생각해 보면 디테일이 많고 개발 비용이 많이 드는 사용자 경험이 항상 문제를 잘 해결하는 것은 아니다. 만약 내가 해당 문제를 직접 풀어야 하는 PO라면 큰 고민 없이 3번 솔루션을 선택했을 것이다. 가설 검증 지표는 원룸 관련 상품 판매량이 증가하는 것이다. 온보딩~메인 화면 여정을 완전히 새로 설계하는 것이나, 새로운 탭을 굳이 열지 않고도, 빠르게 검색박스를 추가하는 것만으로 전후 지표를 비교해 볼 수 있다. 만약 원룸 관련 상품 판매량이 증가한다면 가설이 유효하다 판단해 조금 더 나은 디테일로 이어나가면 된다.
이번 기획은 25피스짜리 퍼즐을 맞추는 거야.
이번 기획은 500피스짜리 퍼즐을 맞추는 거야.
이번 기획은 1000피스짜리 퍼즐을 맞추는 거야.
출발부터 500피스짜리 퍼즐을 한 방에 맞춰야 하는 기획은 거의 없을 것이다. '주문하기 버튼을 잘 찾을까?', 'SNS 공유를 잘할까?', '에디트 이후 저장을 잘할까?' 같이 심플한 기능으로 초기 가설을 검증하는 것이 좋다.
스타트업의 성공 가능성을 높일 수 있는 최선의 방법은 타석에 최대한 많이 서는 것이다. 소박한 퍼즐로 핵심이 되는 가설 검증에 성공했다면, 그만큼 다음 타석에 설 수 있는 시간 자원을 많이 확보한 셈이다. 반대로 처음부터 500, 1000피스 퍼즐을 맞추려는 것은 초심자의 헤매는 시간과 함께, 수많은 디테일도 함께 보겠다는 선언과 같다. 한 가지 뼈아픈 사실은 초기에는 그렇게까지 기능의 디테일을 챙기지 않아도 확인할 수 있는 가설이 대부분이라는 점이다. PMF를 찾기 전 초기 팀의 경우 스파게티 코드나 예쁘지 않아도 핵심 경험이 살아있는 UX를 지향해야 하는 이유이기도 하다(그런데 생각보다 각 분야 전문가들과 이러한 합의점을 찾는 게 쉽지 않다). 초기 기능들은 가설 검증이 되지 않거나 유저에게 외면받을 시 사라질 가능성이 무척 높다. 사실 이 스테이지에서 가장 좋은 것은 개발 리소스 없이 프리토타입이나 초기 지지자 인터뷰 만으로도 어느 정도 가설 검증을 할 수 있는 경우다.
피스가 많아질수록 놓치는 피스가 많아진다. @gearpatrol프로덕트 오너가 된 이후로 생긴 두려움 중 하나는 기획이 장황해지는 만큼 개발자의 코드 역시 무한히 길어진다는 것이다. 이것은 일종의 위기감 같은 것이다. 코드가 길어질수록 버그나 코너 케이스가 발생할 수 있는 확률이 높아진다. 코너 케이스를 열심히 발견하다 보면 팀 전체가 최초에 검증하고자 했던 가설을 망각할 때도 있다. 일종의 집단편향인 셈이다.
이러한 일이 몇 번 반복되면 대중을 향해 설 수 있는 타석수는 현저히 줄어들 수밖에 없다. 대부분의 스타트업은 런웨이가 정해져 있고, 무한히 타석을 부여받을 수 있는 초기 제품팀은 존재하지 않는다. 적은 생산 비용으로 고객에게 가치를 제공하는 비용 효율(Cost Efficency)은 초기 단계 팀에서는 선택이 아닌 필수다.
'새로운 기능 개발 시 범위를 어떻게 합의할까?'(끝)
