제품팀이 실패율을 줄이기 위해 읽어야 할 한 권의 책

인스파이어드: 빌드 트랩에서 벗어난 진짜 제품팀 이야기

혹시 ‘왜’가 아닌 ‘무엇을 만들까?‘에만 집중하는 팀에 계신가요?

스타트업 필드에서 가장 많이 들었던 말은 이 솔루션이 '진짜 문제를 해결하는가?'입니다. 매일 수많은 서비스와 기능이 홍수처럼 쏟아지지만, 사용자에게 ‘딱 필요한 해결책’을 제시하지 못하면 금세 잊히고 맙니다. 마티 케이건의 '인스파이어드'는 그런 고민에 정면으로 맞서는 책입니다.

이 책을 읽고 나면, 내가 몸담고 있는 제품팀이 어떤 방식으로 일해야 실패를 줄이고, 진짜 가치를 만들어낼 수 있는지 분명히 알게 됩니다. 특히 PO(Product Owner)와 UX 디자이너 관점에서, ‘우리가 정말 해결해야 하는 문제는 무엇인가?’라는 질문을 끊임없이 던지게 해 준다는 점이 매력적입니다.

사용자에게 딱 필요한 해결책은 기능 추가가 아닐지도?

실패율을 줄이는 제품팀

실패가 없는 팀은 없습니다. 다만, 하지 않아도 될 실패를 줄이는 팀은 있습니다.

책에서는 제품팀이 실패하는 가장 큰 이유는 “잘못된 문제를 해결하려고 했기 때문”이라고 합니다. PM이나 PO, 혹은 UX 디자이너가 아이디어를 제시할 때, 그 아이디어가 정말 사용자에게 필요한 것인지에 대한 논의 전에 개발 비용이나 구현 방법을 따지는 경우가 많습니다.

결과적으로, 공들여 만든 기능이 외면받는 현상이 반복됩니다. 이 책은 이러한 문제를 극복하기 위해 아래 네 가지 리스크를 매 단계에서 확인하라고 조언합니다.

가치(Value)

사용성(Usability)

실현 가능성(Feasibility)

비즈니스 실행 가능성(Business Viability)

즉, 사용자가 정말 쓸 것인가? 사용할 수 있을 만큼 직관적인가? 엔지니어링 측면에서 구현이 가능한가? 우리 회사 비즈니스와 어긋나지 않는가?라는 질문에 대해 일찍부터 답을 찾으라는 것이죠.

네 가지 질문을 끝없이 던지는 팀

디스커버리와 딜리버리

이 과정을 ‘디스커버리(Discovery)’와 ‘딜리버리(Delivery)’로 구분해 접근하는 것도 중요합니다. 디스커버리 단계에서는 빠른 프로토타이핑과 사용자 피드백, A/B 테스트 등을 통해 가설을 검증하고, 딜리버리 단계에서는 검증된 솔루션을 빠르고 정확하게 개발해 시장에 내놓습니다. 그 결과, 팀의 실패율이 자연스럽게 낮아지고, 진짜로 가치 있는 솔루션만 남게 된다는 것이죠.

제가 실무에서 만난 여러 좋은 제품 팀이 있지만, 한 가지 공통점이 있습니다. 바로 팀 전체가 사용자 스토리를 깊이 이해하고, 문제 정의 초기부터 참여해 함께 해결책을 찾는다는 점입니다. 이처럼 각 역할이 책임을 갖고 움직이는 구조가, 제품팀의 실패율을 획기적으로 낮춘다는 점이 인스파이어드가 주는 핵심 교훈입니다.

빌드 트랩에서 벗어나기

제가 제품팀 리더일 때입니다. 호기롭게 '이 기능 하나만 있으면 리텐션이 급격히 오를 것'이라는 의견을 내고 팀이 아이디어를 빠르게 개발해 시장에 낸 적이 있습니다. 물론, 시장 조사나 유저 인터뷰를 안 한 건 아니지만, 스스로 그 아이디어를 너무 맹신했습니다.

유능한 개발자, 디자이너 동료 분들은 긴 시간 야근까지 해가면서 뚝딱 솔루션을 만들어냈습니다. 그러나 출시 후 데이터를 보니, 활성화율이 극히 낮았습니다. 고객 인터뷰를 진행해 보니, 정작 그 기능 자체를 원하는 사람이 거의 없었던 것이죠. 부끄럽지만 빌드 트랩(Build Trap)의 전형적인 예를 제가 저질렀던 셈입니다.

제품 담당자는 지나친 에고를 버려야만 합니다.

인스파이어드에서는 이런 실패를 피하려면, 먼저 가설을 세우고, 빠르게 검증하는 작업이 필수라고 말합니다. 이건 분명 사용자들이 좋아할 것이라는 자신감만으로 시작하면, 비용과 시간을 낭비할 가능성이 매우 높아지는 것이죠.

좋은 문제 정의가 최우선

현재 제가 UX 컨설팅을 할 때 빼놓지 않고 강조하는 점은, '구현보다 문제 정의'입니다. 사용자의 목소리에 귀 기울여 겪고 있는 문제의 본질을 파악하는 것이 우선이라는 점이죠. 한 번은 디자인 리더 시절, 고객센터에서 반복적으로 들어오는 불편 사항이 있었습니다. 그런데 기능 추가가 아니라 오히려 프로세스를 축소하면 되는 문제였습니다. 디자인 시안 없이 개발팀과 테이블 미팅만으로 문제가 해결된 셈이죠. 이 경험을 통해, 사용자 만족도를 높이는 것이 꼭 새로운 기능 개발을 뜻하지 않는다는 점을 체감했습니다.

권한의 중요성

마티 케이건은 제품팀이 힘을 발휘하려면, '스스로 문제를 찾고 해결할 수 있는 권한'이 주어져야 한다고 말합니다. 엔지니어는 기술적 가능성을 적극적으로 탐색하고, 디자이너는 사용자 인터뷰와 프로토타입을 주도합니다. PO나 PM은 이들이 제대로 협업할 수 있도록 문제 우선순위를 제시하고, 리스크를 체크하는 역할을 맡습니다.

훌륭한 팀

인스파이어드에서 말하는 훌륭한 팀은, 각 직군이 자기 전문 분야에서 최고의 역량을 발휘하며 동시에 협업하는 팀입니다. 이런 팀 문화가 정착되는 것은 사실 쉽지 않습니다. 불필요한 승인 절차나 문서 작업이 아닌 실질적인 제품 가치와 사용자 경험에 더 많은 시간을 쓰는 팀만 도달할 수 있는 지점입니다.

실패에 대하여

실패를 허용하지 않는 문화에서는, 팀원들이 새로운 시도를 꺼리게 됩니다. 그러나 책에서는 좋은 리더는 해결책이 아닌 문제를 던져준다라고 말합니다. 즉, 팀원들이 자유롭게 시도하고 실패할 수 있는 환경을 만들어주어야, 진짜 혁신이 일어난다는 것이죠. 저 역시 리더가 디자이너에게 ‘어떻게’가 아닌 ‘왜’를 고민하게 하는 경우에, 더 사용자 친화적인 결과물이 나오는 것을 종종 경험했습니다.

'어떻게'가 아닌 '왜'를 고민하게 만드는 리더

나가며

인스파이어드는 ‘무엇을 만들까?’가 아닌 ‘왜 만들어야 하는가?’를 묻는 책입니다. 제품팀, PO, UX 담당자라면 누구나 한 번쯤 겪었을 법한 빌드 트랩과 실패 사례를 생생하게 짚어주며, 이를 극복하는 방법을 구체적으로 제시합니다. 저 역시 중심이 흔들릴 때마다 이 책을 자주 꺼내 읽습니다. 그리고 좋은 디자인은 결국 좋은 문제 정의라는 생각을 공고히 합니다.

만약 여러분이 참여한 어제 미팅에서, '왜 만들어야 하는지'라는 질문이 먼저 나온다면, 우선은 행운이라는 말씀을 전하고 싶습니다. 디지털 제품을 만드는 올바른 철학이 담긴 책 '인스파이어드'를 아직 접해보지 않았다면 꼭 추천드리고 싶습니다.

---

'제품팀이 실패하지 않기 위해 꼭 읽어야 할 한 권의 책' (끝)

인스파이어드 - 예스24