제품 원칙, 어떻게 만드나요?
제품 원칙의 힘(1)
커리어의 대부분을 기능적으로 일을 잘 해내는 것에 더 많은 시간을 썼다면, 몇년전부터는 팀으로써 어떻게 일을 해내야하는지에 대해서 더 많은 고민을 하고 시간을 쓰고, 여러 방식에 대해서 여러 실험을 해오고 있다.
다양한 백그라운드, 직군의 사람들이 모여 하나의 목표에 얼라인을 맞추기 위해서 여러 시도를 해보면서 도움이 되었던 경험들을 공유하려고 한다.
책 속에만 존재하는 비전이라던가, 원칙이라던가 하는 내용들을 여러 조직 속에서 크게 체감을 하지 못했기 때문에 그 존재의 이유에 대해서는 잘 믿지 못했었다. 이전에는 그 이유가 현실이 반영이 되지 못한 이론때문이라고 생각했지만 최근 몇년간은 현실 속에서 제대로 실행하지 못했기 때문이라고 생각이 바뀌고 있다.
이론을 읽을때와 현실에 반영했을때의 차이내가 막 조인한 팀은 제품을 잘 만들어내고 싶다는 마음과 현실 상황 사이에서 많이 지쳐있던 상황이었다. 해내야 하는 일은 엄청 나게 쌓여있었고 - 여느 회사와 마찬가지로 - 리소스 상 제품 고민에 최소한의 시간도 투입하기 쉽지 않은 상황이 꽤 오랫동안 유지되고 있었기 때문이었다.
팀원들과 함께 첫번째 task를 진행할 때 팀원들이 입을 모아 최소한의 문제 없는 제품을 만들어내고 싶다고 했다. 늘 촉박한 일정 속에 대응하다보니 눈앞의 문제들을 인지한채 릴리즈하는 것이 일상이여서 기존에 릴리즈했던 스펙들에 대해 후속대응 건들이 쌓이면서 다음 tasks들에 대해 고민하고 만드는 시간이 점점 줄어드는 악순환이 반복된다는 것이었다. 참고로, 내가 속한 팀은 하나의 제품을 고민하는 모든 직군이 모여있는 목적조직이었다.
문제들의 수준과 예측가능한 발생 빈도 그리고 일정이라는 여러 변수들 사이에서 모든걸 완벽하게 해내는 것이 당연할 수도 있겠지만 모든 것이 부족한 스타트업에서는 특히 어느 수준의 합의된 기준이라는 것이 필요하다. 이런 기준들이 없으면 누군가는 문제가 많은 불량 제품이 나간다고 생각하고, 누군가는 고객반응을 위해 불완전하더라도 빠르게 릴리즈해야한다고 생각할 수 있다.
Midjourney으로 생성한 같은 단어, 다른 생각처음부터 제품 원칙을 정해야겠다고 생각한 것은 아니었고, 스프린트 운영을 어떻게 할지 논의로 시작했다. 그러다 스프린트때 진행할 tasks들의 커밋 기준이 무엇이 되어야 하냐 등의 디테일한 질문들에 대해서 각자의 생각을 이야기하면서 해당 내용들을 디테일하게 정의해볼 수록 우리는 실제로 각자 다른 생각을 하고 있다는 사실을 알게 되었다. 기존에 비슷한 단어들을 사용했기 때문에 서로 합의가 되었거나, 합의가 필요 없는 같은 생각을 하고 있다고 착각 했던 것이다.
달랐던 각자의 생각들을 나누고 합의를 하려고 하자, 상위 개념들의 전제가 필요했다. 상위 개념들을 따라올라가다가 “우리의 고객은 누구인가”, “우리의 고객에게 어떤 가치를 주고 싶나?” 등의 질문들에 다달았다. 질문들이 나왔다는 것은 해당 질문에 대해 각자 가진 의견의 유무 이전에 조직 차원에서 최소한 얼라인된 답이 없다는 것을 의미했다.
단순히 해야할 일이 많고, 촉박한 일정, 부족한 리소스 때문에 괴롭고 문제가 많은 제품을 릴리즈 하는 것이 아니라 합의되지 않은 기준들과 중요한 질문들에 대한 답이 없고 방향성이나 혹은 최소한의 구심점이 없기 때문이라는 사실을 팀원들 모두가 느끼기 시작했다. 어쩌면 해야할 일이 많고, 촉박한 일정, 부족한 리소스는 원인이 아니라 결과일수도 있겠다는 생각이 들었다.
크고 작은 합의되지 않은 질문들에 대해서는 장기적으로 시간을 가지고 논의하기로 하고, 우선 우리는 당장 처음에 언급되었던 “문제 없는 제품”에 대한 것부터 정의를 맞춰보기로 했다.
피그마잼에서 각자의 생각을 포스트잇에 남겼다.각자 평소의 생각들이 다듬어지지 않은 채로 많은 포스트잇들에 문장들이 담겼다. 다행인건, 비슷한 결들의 생각을 하고 있었다는 점이다. 약간 다르게 생각하고 있는 팀원들의 이야기는 듣고 공감하고 넘어갔다. 이제 “문제 없는 제품”이라는 정의는 디테일하게 파고들 타이밍이었다.
“어떤 문제를 말하는거예요?, 그리고 문제가 없다는 기준을 어떻게 볼까요?”
누군가에는 필요한 질문일 수도, 누군가에게는 문제가 없으면 없는거지, 추가적 정의까지 필요한가라고도 순간적으로 생각이 들었을 수도 있다.
“버그가 없는거요”
“버그의 기준이 뭐예요?”
“의도한 기획처럼 안나온거요?”
“그럼 기획에서 정의되지 않았던 내용이나, 기획에서 정의한 것처럼 나왔는데 프로덕션 상에서 진짜 이상하게 보이는건요?, 의도한 디자인처럼 안나온건요?”
파고드는 질문들을 바탕으로 각자의 생각들이 우리의 생각들로 자세하게 정리되기 시작했다.
우리가 정의하고 합의한 문제 없는 제품이란?
- 의도한 기획과 디자인처럼 모두 적용되어있다.
- 기획/디자인에서 정의되지 않았던 내용 중에 기능적으로 이슈가 있는 것은 해결한다.
- 정의된것처럼 반영이 되어있으나 심각한 사용성이 있는 경우는 보완한다.
하지만 이대로 끝나면 안되었다. 우리의 생각들이 문서로 이쁘게 정리가되고 마무리 될 것이 아니라 액션아이템까지 영향을 미칠것이므로 앞으로 일을 해 나가는데 원칙이라는 것이 어떤 의미인지 한번 더 확인할 필요가 있었다.
“이 원칙을 이제 매번 릴리즈때마다 지킬껀가요?” 라고 물었을 때 파이팅 넘치게 모두 “넵!”이라고 대답했다. 논의하고 있던 시간은 오후 3시, 하루 중 가장 에너지 레벨이 좋을 때이니 모두가 쉽게 긍정할 수 있다고 생각했다.
“그럼, 오후 3시가 아니라 새벽 3시라고 해볼게요. QA 중 인데, 다 마무리가 되었는데 정보를 담는 테이블 구석이 약간 겹쳐서 깨졌어요. 혹은 메뉴 타이틀 옆에 뱃지가 v-align이 안맞아서 약간 위로 올라가 있어요. 고치고, 다시 한번 QA하고 마무리할껀가요?”
이 질문에는 이전 질문 때보다는 현실적인 답변이 돌아왔다. “아.. 근데 해봐야죠!”
2주뒤 이 논의 뒤로 맞이한 첫번째 QA, 실제로 그런일이 일어났다.
