Velocity vs. Quality

‍

이 글의 목적은 아직 PMF를 찾지 못한 초기 제품팀이 속도와 품질 사이에서 어디에 우선순위를 두고 의사결정을 해야 하는지에 대한 접근과 사고방식에 관해 설명합니다.

초기 제품팀이 지향해야 하는 문화에서 가장 중요한 것은 학습에 집중하는 것입니다. (The Lean Startup,  "Build, Measure, Learn Feedback loop").
우리는 실험을 통해 학습합니다. 따라서 제품팀의 구성원들이 이미 알고 있는 가치와 경험을 기반하여 서비스를 제공하기보다는 새로운 가치와 문제를 발견하는 데 더 많은 시간을 할애하여야 합니다.

초기 제품팀의 목표는 빠른 반복을 통해 학습 속도를 극대화하는 동시에 명확한 임팩트를 달성하는 것입니다. 비즈니스를 영위하는 기업으로서 지표를 전진시키는 것들에 대해 가능한 한 많은 리소스를 확보해야 합니다. 초기 제품팀의 경우 좋은 품질 기준에 대해 논의하기보단, 제한된 리소스로 학습에 집중하는 것이 PMF를 찾는 저비용 고효율적인 방법이라고 생각합니다. 이 기간 동안엔 학습된 데이터를 통해 제품이 올바른 방향으로 나아가기 위한 방법에 대한 큰 그림을 깊이 있게 살펴보는 것이 더 중요합니다.

다만, 팀에서 학습 속도를 극대화하는 것에만 노력하고 있다면 팀 내 몇몇 구성원은 제품 품질에 대한 깊은 우려를 하고 있을 수 있습니다. 하지만 PMF를 확인하려면 이러한 우려를 덜어주어야 합니다. PMF를 찾고 Scalability를 구축하는 것은 생각보다 긴 게임으로 초기 단계에서의 최고의 품질이 의미하는 것이 무엇인지 팀 내 생각을 일치시켜야 합니다. 그리고 이를 위해서는 명확한 목표가 있는 실험이 필요합니다. 고정된 양의 리소스를 고려한다면 단기적인 제품 품질을 개선하는 것은 제한하고 학습을 최대화해야 합니다.

만약 초기 단계에서 포괄적인 제품 품질에 너무 집중하면 팀원들이 고객 가치를 위한 활동보다는 주관적인 품질 욕심을 채우는 쪽으로 리소스를 사용할 것입니다. 이렇게 된다면 고객에게 배울 수 있는 리소스는 더욱 빼앗길 것이고, 느려진 학습 속도는 문제 해결을 증명하거나 또는 지표를 개선하지 못해 전반적으로 나이브하게 제품 방향을 결정하게되고 의미있는 활동은 못하게되는 팀이 되는 악순환을 만들 수 있기 때문입니다.

그렇기에, 초기 제품팀에서의 제품 개발 문화는 학습을 위한 활동에 집중하는 것이 매우매우 중요합니다. 제품팀이 학습을 통해 핵심 가설에 대한 고객 가치를 증명(PMF = CAC < LTV or Retention rate)했다면, 이후 각 퍼널을 높이기 위한 활동으로 제품 품질을 구축할 수 있습니다. 이러한 접근 방식은 자금이 마르는 동안 의미 없는 제품만 만드는 것을 막고, 구축해야 할 것을 구축할 수 있는 더 나은 기회를 제공합니다.

결국 제품 품질은 보기 좋은 컴포넌트의 연결이 아닌, 핵심 가설의 퍼널 전환율을 견고히 하는 것으로 생각할 수 있습니다.
‍

MVP(Minimum Viable Product)

‍
초기 제품팀에서 기대하는 품질을 줄이고, 시장 반응을 확인하기 위해 MVP라는 이름으로 서비스를 먼저 출시합니다.
여기서 많은 팀들이 오해하는 것이 MVP 의미를 목표로 하는 제품에서 시간에 쫓겨 품질을 낮추어(=Feature를 줄여서) 제품을 출시한다는 것입니다. 제가 생각하는 MVP의 진정한 의미는 minimum feature product가 아니라, minimum funnel product로 핵심 가설을 검증하기 위한 최소 단위 funnel을 구축하는 것을 의미한다고 생각합니다. 이를 이해할 수 있는 방법으로는 아래 유명한 그림이 있습니다.

‍

만약 우리가 생각하는 고객 문제 해결의 extra mile이 자동차인 경우, 이를 시장에 전달하기 위해서 자동차의 일부를 하나씩 개발해서는 안 됩니다. 결국 자동차가 출시되는 시점은 너무 늦을 것이고, 출시한 뒤에도 대부분을 사람들이 자동차를 원하는지조차 확신할 수 없습니다. 대신에, 우리가 자동차가 extra mile이라고 생각한 가설을 검증하기 위해, 스케이트보드나 자전거와 같이 고객 문제를 해결시키는 작은 버전을 만들어 고객 문제 해결의 extra mile이 자동차가 맞는지 확인해야 합니다.
‍
또 하나는 결국 우리는 extra mile을 달성해야 한다는(자동차) 것을 잊으면 안됩니다. 처음 출시한 초기 스케이트보드를 최적화하지 않는 것입니다. 학습을 검증하기 위해 필요 이상의 시간을 스케이트보드에서 보낼 필요가 전혀 없습니다! (유명한 말이죠.  ✨Don't optimize the skateboard)

우리의 목표는 MVP(스케이트보드)를 만드는 것이 아니라 Extra mile(자동차)를 만드는 것임을 계속 명심해야 합니다. 이를 위해 우리는 스케이트보드를 버리고 자동차를 만들기 시작할 때를 알고 스케이트보드를 최적화하지 않도록 해야 합니다.

이러한 원칙은 규모있는 실험에서도 동일하게 적용되며, 스페이스X는 이러한 문화를 가지고 있는 회사 중 하나입니다.

At SpaceX speed was maximized by using a destructive testing strategy instead of an analytical development strategy. Analysis was used to size systems, we would then build the minimum viable version and test it to limit to confirm or refute the analysis and then build the next iteration. This repeats through the first production generation of the system. Something else we did that may be unique is a fast-follow generation strategy. In other words, one team would be assigned to design a new system (like the Starlink satellite) and they would proceed as fast as possible toward flying a first generation design. ~2-6 months after that initial team is underway on their development process, a second team starts work on a clean sheet design for the next generation of the system. This slight phase shift means the second team is learning in near real time from the first team and incorporating those lessons into their development without being held to any of the assumptions or design decisions of the first team. This fast follow system really helped to limit anchoring around sunk cost. If you wait too long and produce too many of your first version, you are probably getting married to a design that is far from ideal. By already having a second version in the works, the pathfinder team can produce a few scrappy articles of the thing that gets the job done and produces a lot of important findings, knowing it will quickly be retired by the gen 2 system. from SpaceX

👀 Existential focus

초기 제품팀은 상대적으로 적은 결과로 큰 변화를 일으킬 수 있는 Goldilocks 기간에 있다는 것입니다.(The Goldilocks Zone of Startups: Why “Just Right” Is Not In The Middle by nfx). 현재 제품을 사용하는 사용자는 수십 명 또는 수천 명에 불과할 것이고, 수십만 또는 수백만 명의 고객이 확보되면 실험을 실행하는 것이 훨씬 더 어려워질 것입니다. 엔지니어링 리소스가 규모 문제를 해결하는 것에 사용되고 훨씬 더 많은 구성원이 생길 것이기 때문입니다. 그렇기에 초기 제품팀은 제품 품질에 대한 백로그가 너무 많아 학습 기회를 놓치는 것을 방지하고, 핵심 가설에 대한 대한 집중력을 잃지 않도록 노력해야 한다는 것입니다. 감각적(시각, 촉각 등) 제품 품질에 집중하는 것은 대부분의 사람들의 기본적인 성향입니다. 특히 제조업, SI/솔루션 산업에서는 반복된 학습을 통해 고객 문제를 해결하여 성장하는 것이 어려울 수 있고, 아이디어만 가지고 IT 서비스에 처음 진입한 대표님, 교수님들 또한 정말 중요한 것을 이해하는데 많은 시간이 걸립니다. (IT 서비스 업종은 항상 서비스를 만드는 것이지, 기술을 만드는 것이 아니라는 것을 명심해야 합니다.) 따라서 적절하지 못한 품질 책임이 제품팀의 방향성을 어디로 떨어뜨릴 수 있는지, 그리고 제품을 대하는 자세가 어떻게 형성되어야 하는지에 대한 주의가 더 필요합니다.

어느 회사의 예로 대표와 매니저는 작고 지루한 것(시각적 디자인 요소와 어디서 본 좋아보이는 제품 컨셉)들에 집중했고, 그리고 이러한 것들을 구축하는데 얼마나 많은 시간이 들었는지를 과소평가했습니다. 팀은 불필요한 기능을 개선하고, 구축하는 데 너무 집중하게 되어 핵심 가설을 증명하는 제품을 보지 못했다는 사실을 몰랐습니다. 개발팀은 이러한 과정에서 동기부여를 잃고 이탈을 했습니다. 일반적으로 기업을 죽이는 것은 처음부터 존재해서는 안 되는 것들을 개선하는 것입니다. 한정된 리소스를 잘못된 것을 최적화하는 데 사용되기 때문입니다. Don't optimize the skateboard

‍

Velocity and Quality

✨Velocity is the speed at which we learn from our members and ship features that improve their experience

제품을 릴리즈하지 않는 IT 스타트업은 사라지게 됩니다. 제가 들었던 말 중에 속도의 중요성을 깨달은 말이 'IT 서비스업의 성장 속도는 릴리즈 속도다'라는 말입니다. IT 서비스가 성공하려면 고객 문제를 해결하고(PMF), 확장성(Scalability)을 갖추는 것입니다. 그리고 이 과정에서 핵심은 위에서 말한 '빠른 반복을 통해 학습 속도를 극대화하는 동시에 명확한 임팩트를 달성'인데, 빠른 반복=빠른 개발=빠른 릴리즈를 의미합니다. 물론, 개발을 통한 학습만 있는 것은 아니지만 여기서 다루는 IT 서비스는 Product driven growth를 한다는 가정하에 릴리즈 속도가 결국 우리의 조직의 성장 속도라고 볼 수 있습니다.

이제 팀은 성장하기 위해서 빠른 반복(릴리즈)를 목표로 할 것 입니다. 그렇다면. QA 담당자는 경악을 하겠죠.. 꼼꼼한 QA = 물리적 리소스 = 속도의 제한으로 성장 욕심이 있는 매니저가 QA에게 일을 설렁하라고 얘기할 수 없기에(그래선 안됩니다) QA와 좋은 관계를 유지하며 속도와 품질 사이의 밸런스를 맞추어주어야 합니다.
그래서 QA 담당자 또는 제품팀내 메이커들과 제품 품질에 대한 기준을 설정하기 위해 아래 항목을 참고할 수 있습니다.

품질의 기본적인 속성은(MIT의 품질 정의)에서 참고하였습니다.

1. 미학적 관점 (시각적 디자인)
2. 제품 / 특징/ 성능
3. 사용자 기반 접근
4. 엔지니어링 기반
5. 가치 기반

품질을 위해서는 위처럼 다양한 속성을 이해한 접근이 필요하지만, 회사의 단계에 따라 현재 중요한 품질 기준이 다를 수 있습니다.
예를 들어 초기 단계의 회사에서의 품질 기준을 설명한 그림입니다.

Culture

사람들은 제한된 원칙이 있을 때 훨씬 더 많은 창의성을 발휘한다고 합니다. 즉, 제품팀 내 메이커들에게 핵심 가설을 설명하고 이를 달성하기 위한 원칙(=품질 기준 등)을 설명한다면 완전히 이해하지는 못하더라도 메이커들은 고객이 제한된 원칙 또는 리소스 내에 최고의 경험을 쌓을 수 있도록 노력해 줄 것입니다. 만약 그렇지 않다면, 해당 구성원이 정말 스타트업에 어울리는지, 우리 조직 문화에 어울리는지 확인을 해봐야 합니다. 제품 성장을 통해 자아실현을 하는 것에 Alignment가 맞춰져 있는지 확인이 어렵다면 전체를 위해 빠르게 조치를 취하는 것이 좋을 것입니다.

초기 제품팀의 조직문화의 중요성에 대해서는 밤새도록 얘기해도 부족하지만, 가장 큰 것은 대표 또는 제품 매니저가 고객의 모든 것을 이해할 수 없고, 정답을 갖고있는 것이 아닙니다. 그렇기 때문에 속도와 품질의 밸런스를 맞추며 정답을 찾아가는 것이 가장 중요한 활동인데 이를 개인이 주도하는 것이 아닌, 팀이 주도해야만 큰 효과를 발휘합니다.

조직내에 이러한 문화가 동작한다면 아래의 사례처럼 메이커들 간의 주도적인 문제 해결의 모습을 보게될 것입니다. 왜냐하면 모두의 목표는 학습을 위한 제품 개발(명확한 목표 정렬)에 있기 때문입니다.

‍

‍

마지막으로 비즈니스 세계에서 유명한 은유인 Bikeshedding을 소개하며 마치겠습니다.

Bikeshedding = 중요한 안건을 미뤄둔 채 덜 중요한 일에 대해 깊이 의논하고 시간을 보내는 것.

초기 제품팀이 중요한 것은 핵심 가설 검증(PMF)입니다.