프로덕트를 개발하는 모든 팀의 시간은 소중합니다. 개발자도 바쁘고, 디자이너도 바쁘고, 기획자도 바쁘고, 비즈니스 담당자도, 마케터도 바쁩니다. 당장 다음 주에 릴리스할 기능을 개발하고 QA 하기도

프로덕트를 개발하는 모든 팀의 시간은 소중합니다. 개발자도 바쁘고, 디자이너도 바쁘고, 기획자도 바쁘고, 비즈니스 담당자도, 마케터도 바쁩니다. 당장 다음 주에 릴리스할 기능을 개발하고 QA 하기도 바쁩니다. 귀찮게 사용자를 직접 만나서 인터뷰를 하고, 개발자들의 귀한 시간을 뺏어서 로그를 심고 데이터 분석이니 뭐니 할 시간이 없습니다. 하지만 안심하세요! 다음에 소개하는 방법을 따르면 사용자와 데이터를 생각하지 않고도 제품을 개발할 수 있습니다. 01. 절대 사용자를 직접 만나지 마세요. 그들은 당신이 내놓은 제품이 그들이 진정 원하는 것이 아니라며 당신의 자신감을 망쳐놓을 것입니다. 02. 스펙 문서에는 기능이 ‘어떻게 작동하는지만' 쓰세요. ‘왜 이 기능을 구현해야 하더라?’라는 불편한 생각이 들면 재빨리 시간낭비를 멈추고 커피나 한 잔 뽑으러 가세요. 03. 제품의 간결함을 위해 ‘당신이 보기에' 가장 중요해 보이는 기능만 남겨두세요. 아침에 볼 일을 보다가 슬쩍 훑어본 힉의 법칙 같은 것을 기획회의에서 언급하세요. 04. MVP는 잊어버리세요. 우리는 아마존이나 트위터가 아닙니다. 가설 검증 따위를 할 시간에 최대한 빠르게, 완전하게 구현하는 데 온 리소스를 투자해야 합니다. 05. 데이터 분석가에게 수많은 리포트를 제출하게 하세요. 그리고 아무것도 반영하지 마세요. 06. 제품을 만든 후에 고객을 찾으세요. 훌륭한 제품은 많은 고객이 좋아합니다. 우선 제품을 만들고 나면 진정한 가치를 알아주는 고객들을 만날 것입니다. 07. 각자 하고 싶은 일을 하게 하세요. 제품이 다다르고자 하는 최종적인 목표를 그들이 알게 해서는 안됩니다. 만약에 중장기적인 로드맵, KPI가 있다면 몇몇 핵심 멤버끼리만 공유하는 것이 바람직합니다. 08. 경쟁사와 비슷한 스펙을 찾아서 최대한 비슷하게 만드세요. 진짜 사용자 리서치나 데이터 분석이 필요할 때가 물론 있습니다. 그럴 리소스와 리서치, 분석 역량이 부족하다 해도 , 안심하세요. 다행히 우리의 경쟁사가 그 모든 것을 하고 있습니다. 그저 좋아 보이는 제품의 기능이라면 뭐든 따라 하면 됩니다.