심플한 프로덕트를 만드는 법

심플한 제품을 만드는 일에 대해 정답은 당연히 없다. 하지만 심플함이 무엇인지, 그리고 문제에 접근하는 관점에 대해서는 얘기해볼 만할 것 같다.

어떤 제품이 심플한 제품인가?

"미니멀하다"고 해서 심플한 제품이 아니다. 또 복잡한 기능을 갖췄다고 해서 복잡한 제품이 아니다.

적게 갖춘 제품이 심플한 제품이 될 수는 있지만, 심플한 제품은 적게 갖춘 제품이 아니다. 심플한 제품은 제대로 갖춘 기능을 심플하게 만든 제품이다. 결국 심플함은 사용하는 사람의 관점에서 결정된다.

• 심플한 제품 != 적게 갖춘 제품
• 심플한 제품 == 제대로 갖춘 기능을 심플하게 만든 제품

또한 심플함의 이름 아래 제품의 핵심을 이루는 기능이 부족해서는 안 된다. 그건 심플한 제품이 아니라 그냥 기능이 부족한 제품이다. 적게 갖추더라도 핵심을 이루는 기능을 제대로 구현한 제품은 심플한 제품이다.

심플한 제품은 한 가지 문제를 제대로 해결한다. 드랍박스(Dropbox)는 클라우드 위에서 내 파일을 제대로 연동해준다. 2007년 스티브 잡스가 세상에 들고 나온 아이폰은 음악(iPod), 전화, 그리고 인터넷을 하나의 기기로 사용할 수 있도록 만들었다.

드랍박스와 아이폰은 결코 적게 갖춘 제품이 아니다. 심플하게 사용할 수 있는 인터페이스 이면에는 복잡하고 다양한 기능들이 모여있다. 하지만 수많은 기능과 복잡한 시스템을 쉽고 간편하게 사용할 수 있도록 만들었다. 그게 심플함이다. 단순히 적은 기능이 심플한 게 아니라.

이처럼 진정으로 심플한 제품은 적게 갖춘 제품이 아니라 제대로 갖춘 기능을 심플하게 만든 제품이다. 말하자면, 복잡함을 단순하게 풀어내는 제품이 진짜 심플한 제품이다.

적은 기능을 확실하게 구현한다.

심플한 제품을 만들기 위해서는 먼저 제품을 만들 때 명확한 절충을 해야 한다. 훌륭한 프로덕트 매니저는 무엇을 만들 것인지에 대한 좋은 절충안을 내놓는 사람이다. 100짜리 제품을 만들어야 하는 데 1년이나 걸린다면 절반으로 잘라 50짜리 제품을 6개월 안에 만들어서 내놓는 사람이다.

"Build half a product, not a half-ass product."

– Basecamp founders Jason Fried & DHH

Basecamp의 Jason Fried(제이슨 프리드)와 David Heinemeier Hansson/DHH(데이비드 하이너마이어 핸슨)은 언제나 "build half a product, not a half-ass product."라는 조언을 한다. 만들다 만 프로덕트를 내놓지 말고, 절충해서 절반만 제대로 만들라는 얘기다.

이메일 서비스를 만든다면 캘린더, 자동예약발송 기능, 2FA, 검색 기능 이런 것은 이차적인 것이다. 이런 것들을 전부 만들려다 보면 결국 퀄리티를 절충해야 한다. 모든 것을 100의 퀄리티로 정해진 시간 내에 만드는 것은 불가능하니까.

그 대신 가장 먼저 만들어야 할 것은 이메일을 보내고 받는 수신, 발신 기능이다. 수신 발신 기능을 60으로 만들고 나머지를 대강 20에 만드는 것보다, 수신 발신 기능부터 100을 만드는 것이 더 중요하다. 그리고 이렇게 만들어야 제품이 처음부터 복잡하지 않다.

또한, 제품의 본질이 무엇인지 명확하게 정의하는 것도 중요하다. 본질이 무엇인 가에 따라 지금 만드는 것이 의미 있을 수 있고, 없을 수도 있다. 또 어떤 기능을 확실하게 구현할 것인가에 대해서도 본질을 알면 명확하게 정의하기 쉬워진다. 앞서서 말한 이메일 서비스 예시에서도 만약 이메일을 "빠르게" 보내는 것이 본질이라면, 키보드 단축키를 첫 제품에 넣는 것은 의미가 있다.

에릭 리스(Eric Ries)의 린스타트업(Lean Startup)과 함께 온 MVP 열풍은 수많은 사람을 창업의 길로 이끌었고 스타트업 업계에 많은 좋은 영향을 미쳤지만, 그와 동시에 부작용도 있었다. 많은 사람이 자동차를 만드는데 스케이트보드를 만들어서 런칭하는 것이 무조건 좋은 거라 믿게 되었다는 것이다. 자동차를 만든다면 처음 만들어야 할 것은 스케이트보드가 아니라 모터 동력으로 움직이는 심플한 자동차를 만드는 것이다.

고객의 요구사항이 아니라, JTBD에 집중한다.

고객이 원하는 것을 문자 그대로 만들고 나면, 제품이 너덜너덜해지거나 복잡해진 것을 깨닫게 된다. 그 이유는 고객이 정말로 원하는 것은 만들어 달라고 했던 것의 일부분일 가능성이 크기 때문이다. 고객의 요청 사항을 들어줄 땐 언제나 보수적으로 그리고 제한적으로 접근하는 것이 맞다.

"기능 A를 만들어 주세요." 고객의 요구사항은 언제나 명확하다. 하지만 고객의 요구사항을 액면가 그대로 받아들이게 되면 아무도 쓰지 않을 (심지어는 만들어 달라고 했던 고객마저) 위험을 너무 크게 가져간다. 고객이 진짜로 원했던 것은 "기능 A"라는 포장 안에 아주 작은 부분일 수 있기 때문이다.

고객이 원하는 것을 만들어야 할 때는 이 기능이 왜 필요한지나 어떻게 생겨야 하는지 보다, 언제 필요한지 물어보는 것이 더 큰 도움이 된다. 이것이 바로 "고객은 어떤 필요를 해결하기 위해 제품을 고용한다"를 주장하는 JTBD (Jobs-to-be-done) 프레임워크를 적용하는 것이다.

예를 들어, 앱 내 사용 자당 권한을 관리할 수 있는 기능을 만들어 달라는 요청이 들어왔을 때, 왜 필요한지를 묻는 것보다 언제 필요한지 물어보면 권한 관리 기능이 필요했던 순간을 묘사하게 된다.

"우리 팀원 중 한 명이 설정을 바꾸면 나머지 사람들의 설정도 동일하게 적용된다는 사실을 모르고 설정을 바꿔서 혼란이 생긴 적이 있어요."

권한 관리 체계를 기획하고 기능을 만드는 것도 물론 고객이 가진 문제를 해결하는 방법 중 하나다. 하지만 몇 주가 걸릴 수 있는 긴 프로젝트가 될 가능성이 높다. 그 대신, 설정 변경을 시도할 때 모달을 띄워 나머지 사람들의 설정도 바뀐다는 경고메시지를 보내면? 이제 몇 주가 아니라 하루 만에 해결할 수 있다.

"좋은" 솔루션의 기준은 결국 시간의 제약을 받는다. 시간이 무제한으로 있으면 권한 관리 체계를 만들어 주는 것이 가장 좋다. 프로덕트 팀은 언제나 시간에 쫓긴다. 제한된 시간 내에 최적의 솔루션을 만들어야 하기에, JTBD에 집중하는 것이 더 효과적이다.

핵심인 것은 제대로, 핵심이 아닌 것은 가능하게만 만든다.

Shopify에서 제품을 이끄는 Alex Danco는 제품 팀의 원칙 중 하나로 "핵심은 제대로, 핵심이 아닌 것은 가능하게만 만든다"를 세웠다고 한다. 핵심이 아닌 것은 연동과 마켓플레이스(App Store)에서 Shopify ecosystem내 다른 회사가 만들도록 하는 것이다.

가령 쇼핑몰을 운영하는 사람에게 상품을 등록하고 웹사이트에 진열한 다음, 결제를 받는 것은 핵심이고, 둘러만 보다가 나간 고객에게 할인 쿠폰 메시지를 보내는 것은 (중요하지만) 핵심이 아니라고 규정하는 것이다. 그래서 할인 쿠폰 메시지를 보내는 것은 Shopify에서 가능하게만 만들고, Klaviyo와 같은 3rd party 소프트웨어 회사가 훨씬 더 잘하게 두는 것이다. (Klaviyo는 Shopify위에서 동작하는 이메일/SMS SaaS이다)

"We want to make the important stuff easy and the rest possible." And a lot of the real job of the Ecosystem here is to say, "Let's make the rest possible."

제품을 만드는 순서는 이렇게 되어야 한다. 핵심부터 제대로 만들고 핵심이 아닌 것은 가능하게만 만든 다음, 계속 개선하는 것이 맞는 방향일 것이다.

하지만 핵심부터 만드는 일은 생각보다 어렵다. 디자인을 하다 보면 보이는 세부적인 것들이 있고, 또 왠지 만들지 않으면 충분해 보이지 않게 되기 때문이다. 그래서 디자인 단계부터 핵심에 집중하는 노력을 해야 한다. 예를 들어, User flow를 그릴 때, 시각적인 요소는 나중에 생각하고 우선 글씨로 움직여보는 것이 도움이 된다.

그리고서 어떻게 만들어져야 할지 그려볼 때는 두꺼운 마커로 그려보는 것도 도움이 된다. 두꺼운 마커로 그리다 보면 자연스럽게 핵심만 그리게 된다. 디테일을 그리기에는 너무 두꺼우니까.