Lean과 Quick은 다르다.

스펙아웃과 빠른 검증의 관계

최근에 제품을 만드는 PM 친구랑 이야기를 나누다가 든 생각들을 글로 적어보려고 한다.

친구의 주된 요지는 이와 같다. 자신은 사용자를 위해 열심히 이런 기능, 저런 기능을 하려고 하는데 기한이 정해져있는 프로젝트이다보니 개발자와 논의 과정에서 점점 스펙 아웃이 진행된다는 것이다. 빠지는 이유는 구현의 난이도, 오픈 기한을 맞추기 위해서라고 한다.

그러다보니 제품은 다른 경쟁 제품 대비해서 차별화된 부분은 사라지고 그냥 그런 제품이 되는 것 같아서 현타가 온다고 했다.

물론 빠르게 제품을 우선 런칭하는 것도 중요하지만 시장에 그런 제품을 정해진 시간 내에 만드는 것이 어떤 의미가 있을까에 대해서 생각해보게 되었다.

흔히 스타트업은 빠른 실행을 추구하는 조직으로 린한 검증을 추구하는 것이 당연하다. 하지만 일을 하다보면 이런 린한 개발과 이 스펙은 빼고 빨리 배포해서 결과보죠라고 하면서 스펙을 아웃하는 것을 동일시하게 하는 경우가 종종 발생한다.

그래서 나라면 비록 오픈 기한이 정해져있는 프로젝트더라도 먼저 우리가 이 오픈을 통해서 무엇을 검증하거나 얻고 싶은지를 파악하고 싶을 것 같다.

고객에 대해서 이러한 행위를 할 것이라는 가설이 있다면 이 스펙 아웃의 기준이 이 가설을 검증하는데 꼭 필요한 기능인지를 기준으로 판단해야하지 개발기한의 문제로 이를 아웃시켜서는 안된다고 생각한다. 오히려 이게 정말 필요하다면 검증에 필요없는 기능을 빼서 기한을 맞추는 형태로 나아가야한다고 생각한다.

물론 이런 가설이 아니라 "매출"을 올리는 것이 핵심이라고 한다면 기준은 조금 달라질 수 있다. 오픈만 하면 우리는 얼마만의 매출을 얻을 것이지만 이 기능을 얻음으로서 우리는 더 명확하게 경쟁사의 파이를 가져올 수 있다는 것을 검증해서 스펙 아웃을 판단하는 것이 맞지 않을까?

나조차도 이렇게 일을 하게 된지는 일을 한지 한 3년 정도 지나서였던 것 같다. 바쁘다는 핑계로, 가벼운 의사결정이라는 이유로 쉽게 결정했는데 막상 오픈하고 나니 이 제품의 뾰족함이 사라지고 단순히 오픈 횟수만 늘리면서 후회했었던 적이 많았다.

정리해보면, 우리가 제품을 개발하고 시장에 출시하는 궁극적인 목적은 사용자에게 가치를 제공하고, 기업의 장기적인 성공을 위한 기반을 마련하는 것이다. 

따라서, 제품의 핵심 가치와 사용자의 필요를 충족시키는 기능에 집중하면서도, 시간과 자원의 제약을 명확한 기준으로 의사결정하는 팀을 만드는 것이 중요하다.