어떻게 완벽할 것인가 : MVP가 하울의 성이 되지 않게 하려면

최근 인상 깊은 영상을 봤습니다.
약 28조라는 엄청난 금액에 어도비에 인수된, 디자인 툴 회사 ‘피그마’ 창업자인 딜런의 인터뷰입니다.

저희도 제품 기획이나 디자인을 할 때 피그마를 많이 쓰는데요.
매우 편리하고 직관적이고 훌륭한 제품이라고 생각합니다.
어떤 제품을 만드는 것 자체도 쉽지 않은데, 제품을 만들 수 있는 툴을 이렇게 잘 만든다는 건 얼마나 쉽지 않은 일일까?
피그마를 쓰면서 이 정도의 제품력을 갖기까지 얼마나 많은 노력을 했을까라는 생각을 자주 합니다.

이처럼 탄탄한 제품으로 성공 궤도에 오른 창업자의 인터뷰이기에
얼마나 제품을 완벽하게 만들기 위해 노력했는지에 대한 이야기를 기대했습니다만,
그는 이렇게 말했습니다. “Perfection is enemy, always.”
완벽주의는 항상 경계해야 하며, 제품을 시장에 내놓을 때
우리를 가장 어렵게 하는 것은 우리가 완벽한 제품을 내놓지 못한다는 것입니다.

그 이야기를 들으니 최근 저의 고민이 생각났습니다.
지난주 저는 2주간의 비디어스 스프린트 후 QA를 진행했는데요.
QA는 Quality Assurance의 약자로 품질 보증이라는 뜻을 갖고 있습니다.
프로젝트 목적에 대한 이해를 바탕으로 서비스 품질을 보증하여 비즈니스 리스크를 감소시키고
사용자에게 최대 서비스 가치 제공을 목표로 하는 활동으로 정의되고 있습니다.

QA를 하다 보면 QA 담당자로서, 프로덕트 매니저로서 그리고 창업자로서
저마다 마음속에서 소리 없는 아우성을 칠 때가 있습니다…
이 기능을 테스트하다 보면, 저 기능도 있으면 좋을 것 같고, 기존에 연관된 부분도 이번에 같이 개선하면 좋겠고.. 와 같은 욕심이 조금씩 생깁니다.

하지만 원하는 것을 만들기 위해 시간을 많이 쏟게 되면
시장의 니즈를 확인하고 고객과 만날 수 있는 좋은 타이밍을 놓치게 될 수도 있습니다.

A라는 가설을 테스트하려고 A를 만들었는데,
A를 만들었더니 A1이 필요할 것 같고 그래서 A1까지는 만들기로 해서 만들고 나면
A2도 필요해 보이고 그러다 보면 A10을 만들고 있게 됩니다.
우리의 실험은 A1으로도 충분한데 생각이 A10까지 가게 되면
A1이 부족한 것처럼 느껴진다는 것이 완벽의 함정입니다.

게다가 저는 위에 말씀드린 것처럼 여러 롤을 수행하고 있다 보니
제품에 대한 기준이 롤마다 달라서 어떤 기준을 상정할지 매번 고민이 되는데요.
차라리 하나의 목적을 가지고 해내야 하는 입장이면 의견을 관철하기까지 내달리기만 하면 되는데
그 반대에 입장에 있는 사람도 똑같은 저이다 보니
어느 한쪽의 요구가 100% 충족될 수 없고 어딘가 사이 지점에서 서로 타협을 하게 되는데
그 선이 모호해지기도 하고 어느 한쪽도 빠짐없이 모두 중요하다는 생각이 들 때는
장기적인 제품의 관점보다 그 당시 상황에 따라 판단하게 되기도 하는 것 같습니다.

이럴 때는 프로젝트의 목적을 상기합니다.
우리의 가설을 테스트하는데 부족함이 없다면
저는 그게 곧 완벽이라고 생각하고,
그 외 부분은 오히려 빠르게 테스트를 하고 피드백을 통해 보완할 영역이라고 생각하게 되었습니다.

그리고 또 떠올립니다.
완벽한 제품을 내놓아야 한다는 생각으로 제품 출시가 계속 미뤄졌던 지난날들과,
우리가 생각하는 제품의 완벽함이 사업의 성패와 직결되지 않는다는 사실을요.

그래서 이번 스프린트는
제가 생각하기에 기존 비디어스 구조를 온전히 유지하는 완벽한 구조로 편입되지 않더라도
우리가 꼭 실험해 보고 싶은 가설을 테스트하기 위한 기능만을 만들어서
시장 검증을 하고자 했습니다.

우리만의 완벽을 정의하고
그 완벽을 어떤 부분에서 달성할지 선택과 집중을 한다면
완벽의 함정에 빠지지 않고 빠르게 앞으로 나아갈 수 있으리라 생각합니다.

---

---