좋은 제품에 관한 이야기 002
정답은 없으니 이건 고민의 흔적일 뿐이지만.
좋은 제품을 만들기 위해서 무엇을 해야 하는 글에서는 일단 좋은 제품을 만들자는 선언을 하기로 했는데, 무엇이 좋은 제품인지 알아야 만들 것이 아니냐 하는 생각이 들겠습니다. 이것도 하나의 문제라면, 지금 상태는 어떤데, 되어야 하는 상태가 무엇인지 정의할 수 있어야 해결책을 고민할 수 있겠지요.
어떻게 좋은 제품을 만들지는 어느 정도 확립된 규칙을 본 적은 있습니다. 확실한 것 하나는 바로 "필요한 제품을 만들자"였습니다. 크리스텐슨 교수가 'Jobs-to-be-done'이라고 부른 것일 수도 있고, IDEO 가 HCD 초창기에 'desirability'에서 시작하라고 한 것과 같을 수 있겠네요. 하지만 그럼 도대체 필요한 제품이 무엇인가? 하면 고객의 문제를 해결해 주거나, 삶을 낫게 하거나 아니면 우리 회사에서 돈을 더 벌 수 있는 여하튼 무언가 계속 쪼개질 것 같네요. 상황에 따라 다를 수 있겠죠.
보다 더 현실적으로 버그가 적은 제품을 만들자는 어떨까요? 필요한 제품이 있다고 해도, 버그 때문에 사용을 못하면 더 이상 필요한 제품이 아니겠죠. 아주 훌륭한 게임도 버그투성이면 최소한 '압도한 긍정적'인 상태가 되진 않을 것입니다. 사용성이라는 게 되게 대단한 게 아닐 수도 있다고 생각합니다, 이런 측면에서는.
이런 것들에 비추어 제품을 만드는 프로세스를 개선한다면 어떨까요? 매일 조금은 더 나은 제품의 상태로 나아갈 것이고, 우리는 매일 1% 를 개선할 수 있을 것이라고도 생각합니다. 그렇게 돌려 표현해 보면 우리의 목표는 하루하루 제품을 개선하는 것이고 그것이 제품 주도 성장의 기반이 될 것이라고 생각합니다.
다시 - 정의의 문제로. 버그는 무엇일까요? 소프트웨어 버그에서 예전에 천공판 시절에 실제 '벌레'가 들어가서 기계가 동작하지 않던 시절부터 시작되었다고 알려진, 이 버그는. 그중에서 좋은 제품을 만들기 위해 해결할 버그는? 일단은 중대한 버그라고 해보죠. 당연히 수정해야 하겠죠? 제품 사용이 불가능한 형태의 버그나. 데이터 제품의 경우 중대한 계산 오류가 있을 경우일 것입니다. 가장 빠르게 개선해야 할 지점이겠지요.
반면 당연하게도 버그에도 종류가 있는데, 조금은 작은, 사용에 불편함이 조금 남아 있는 수준의 버그도 있겠죠. 기획적인 부채에 따른 오류들도 있겠죠. 당연히 해결해야겠지만 우선순위 입장으로 내려오면 애매해집니다. 따라서 이럴 때는 이 버그, 오류를 단기간에 수정할 수 있는지에 따라서 결정해야 할 것입니다. 빠르게 처리할 수 있다면 그만큼의 임팩트가 있고, 확실한 개선사항이 될 수 있겠죠. 특히, 작은 성공이라는 측면에서 팀에게 힘이 될 것이고, 작은 수백 개의 아이디어라는 측면에서 경쟁우위가 될 수도 있을 것입니다. 쌀로 밥 짓는 소리죠?
버그 수정이 우선이라는 건, 너무 당연해서 재미가 없네요. 고객의 요구사항으로 넘어가 봅시다. 좋은 제품은 고객의 문제를 해결해 주는 것이니까요. 그러니 고객의 요구사항은 기본적으로 최우선적으로 만들어야 할 내용이 될 것입니다. 메주는 콩으로 만든다지요?
하지만 두 가지 축이 여전히 남아 있을 것 같습니다. 이 요구사항은 얼마나 중요하고, 긴급하고 또 큰지에 대한 부분과 우리는 이 요구사항을 구현하는데 얼마나 빠르게 작업할 수 있을까 하는 부분입니다. 우선은 얼마나 중요한가, 이것은 우리 제품이, 이 요구사항이 해결하고자 하는 문제의 중요도로 귀결될 것입니다. 이 요구사항을 기능으로 만들어 더함으로써 고객은 어떤 문제를 해결하고, 그것은 다시 어떤 가치로 고객에게 환원되는가?
따라서 고객의 요구사항은 우선적으로 고객의 문제로 치환되어 해석되어야 합니다. 그리고 그 문제를 정의할 때 보다 상위의 근본 원인, 해결함으로 달성하고자 하는 그들의 KPI를 고려해야 할 것입니다. 벼에서 쌀이 나는 소리를 넘어서, 고객의 매출을 올려주거나 비용을 줄여야 하는데, 그러기 위해서 그들이 필요한 당면한 개선점은 무엇인지, 혹은 그들이 풀지 못하고 있는 문제를 우리가 대신해줄 순 없는지 말이죠. (크리스텐스형, 이거 맞죠 Jobs-to-be-done?)
당연히 긴급함도 문제의 중요도에는 큰 영향을 줄 것입니다. 지금 이 문제를 해결해주지 않으면 고객은 어떤 곤란함을 겪을 것인가? 그건 우리에게 어떤 영향으로 돌아올 것인가 하는 부분이 있겠죠. Time-to-market이라는 개념과도 비슷할 것 같아요. 어느 시점에 해결해 주느냐도 우선순위를 정할 때 꼭 들어 있어야 하는 부분이겠죠. PRD 양식 대다수에 출시전략이 있는 것도 뭐 - 꼭 여기에 Fit 하지 않지만 아마 연결될 거예요. (아마에 주목합시다)
반대 측면으로 볼까요? 우리 팀, 회사로 돌아오면 결국 이 문제를 해결하는 것이 우리 제품의 가격을 올릴 수 있는가, 혹은 우리 제품을 구매할지 안 할지 결정하는 사항인지 혹은 우리 제품의 리텐션을 올리는 사항인지를 고민해 볼 필요가 있을 것입니다. 물론 이건 결과이고, 원인은 다시 고객으로 돌아가게 될 것입니다. 하지만 모든 일을 한 번에 처리할 순 없으니, 고객의 문제의 크기와 가치를 산정하고 이게 우리 회사로 돌아오는 부분을 계산해 보고 판단할 필요가 있단 말이지요.
그러니, 고객의 문제의 긴급도와 중요도가 기본적인 우선순위의 축이긴 하지만 B2B에서는 다른 사항도 고려해야 한단 말입니다. 이 요구사항의 매출의 기대 볼륨이 어떤지? 그러니까 다른 고객에게도 이 요구사항이 유효한지를 따져서, 임팩트의 크기를 계산해야 한단 것이지요.
물론, 데이터가 불충분하기에 심플한 메트릭을 사용해야 할 것입니다. 중요도 측면에서의 몇 개의 숫자 정량화, 긴급도 측면에서의 숫자 정량화 그리고 이것의 복제 가능성, 확장 가능성의 지표를 기반으로 점수를 따지게 될 것이라고 생각합니다. 대충 우와, 말도 별로 안 그럴듯한데 당최 뭘 어떻게 하라는지 구체적인 내용은 안 들어있군요.
하나만 좀 더 파보죠. 확장 가능성이라 하면, 이 고객의 추가 구매 가능 수량과, 다른 고객들이 이 기능, 요구사항을 통해 문제를 해결할 수 있다는 것을 알았을 때 추가로 구매할 것으로 기대되는 수량이지 않을까 싶습니다. 결국 Value x Volume의 계산식으로 표현할 수 있을까요? 이 단순함을 계산하기 위해 거쳐야 하는 무수한 논의에 비해서 너무 없어 보이는군요. 여기에다가 반복 매출이라는 개념, 고객 추천 여부 등등등, 고려하기 시작하면 해야 할 것이 너무나 많습니다. 그러니 가치와 가치의 범위라는 단순한 개념으로만 일단 이야기해 보죠.
다시, 가치, 공식에서 Value 라 함은 이 문제를 해결함으로 얼마나 중요한 고객의 문제를 풀어 주는가, 그리고 그 시급성이 얼마나 되는가로 봅시다. 중요함은 여러 기준이 있지만 고객 입장의 Revenue와 Cost의 크기라고 보고, 시급성은 단순하게는 올해 없던 예산을 편성하여 구매하고 싶다 수준이 제일 높은 수준이지 않을까 합니다.
반대로 가치의 범위, Volume 은 우리가 이 기능을 통하여 고객사, 혹은 고객군에게 얼마나 많은 Copy를 판매하게 될 것인지 예측해 볼 만한 수치일 수 있겠습니다. 이 고객사가 추가로 구매하거나, Cross-sell 이 되거나, 이 고객사를 leverage 하여 더 나아갈 수 있는 마켓이 있는지 등등. 물론 모두 가설적인 접근이지만 우리가 우선순위를 정할 때 생각해봄직은 하지 않을까요? 왜냐면 우리가 모든 일을 한 번에 할 순 없으니까요.
요구사항에서 급선회해서 버그로 돌아와 봅시다. 이것이 얼마나 쉬운 일인가? 얼마나 빨리 할 수 있는 일인가가는 여전히 중요합니다. 그러나 여기서도 우리가 얼마의 노력을 투입해서 어떤 가치를 창출할 것이냐를 따져봐야겠지요? 어떠한 작업이 어떤 가치를 가져올 수 있을지를 알게 된다면. 같은 노력을 들였을 때 어떤 것이 임팩트를 더 크게 가져올 지에 대한 감을 세울 수 있을 것이라고 생각합니다.
진짜 쉽지는 않은 게, 첫째로, 고객의 문제를 우리는 100% 이해하지 못하고, 고객은 스스로 무엇을 풀고자 하는 지도 잘 모를 때가 많습니다. 모든 것이 가설의 형태로 남아서, 증명하기 전에 실행해야만 하는 상황에 놓여 있을 것입니다.
둘째로는 많은 경우에 첫 Sales의 관문을 넘기 위해서 증명되지 않았을 기능도 빠르게 만들어야 하는 경우가 있겠지요. 우리가 충분히 많은 기능을 만들어둔 상황에서는 기능의 조합으로 Sales 가 달성될 수 있겠지만, 보통은 그렇지 않을 것입니다. 그러니까 우리는 존재하지 않은 고객의 요구사항을 상상해서 구현해 나아갈 때도 있을 것입니다. 음, 이걸 위해 <아이디어 불패의 법칙>이나 여러 린스타트업 등등에서 방법을 고안했지만, 결국 이 일이 - 가설 상태에서도 작업을 해야 한다는 상태가 사라지진 않을 것이라고 생각해요.
그래서 사실 가장 중요한 조건은, 어쩌면 우리가 생각할 때 이것은 고객에게 필요한가? 이것이 있다면 우리 제품은 얼마나 좋아지는가?라는 고민과 그 실행인 것 같습니다. 커피는 커피콩으로 만든다는 게 참 옳은 말이지요. 그런데, 가끔 그렇지 않은 때가 있으니 계속해서 말하는 것 같습니다. (사족. 커피를 커피콩으로 만들겠지만, 우리는 고객을 계속 생각하고 있는가, 대충 그런 말입니다)
에어비엔비 창업주가 말한 것처럼, 이 제품을, 이 요구사항을 만들었을 때, 내 이름을 붙이고 배포할 수 있을 것인가? (If you can't name on it, don't ship it) 이것이 우리가 생각하는 최선인지를. 규정하는 게 필요하지 않을까요? 때로 숫자로만은 표현하기 힘들 수 있고. 자신만의 고집이 필요할 수도 있을 거라고 생각합니다. 데이터 기반의 회사들은 그러지 말라곤 하지만, 어쩔 수 없이 없는 데이터로도 결정은 해야 하니까요. 다행히 대다수의 회사에서 제품을 만드는 사람은 혼자가 아닌지라, 함께 논의하며 이 부분을 고려해서 제품 개발의 우선순위를 잡을 수 있을 것이라고 생각합니다. 물론, 물론 아주 쉽지 않을 것입니다. 사실 더 어렵겠죠.
(좀 더 쉽게는, 이게 내 이력서에서 - 포트폴리오에서 자랑할 만한 제품인지 고민해보면 더 쉬울 거라고 생각해요)
이 조건을 통과한 요구사항이 충분히 많고, 잘 논의된다면 그것이 곧 우리의 마일스톤, 로드맵일 것이라고 생각합니다. 하지만 PMF를 찾는 B2B 상황에서 그것은 늘 작동하지 않겠죠. Sales의 속도와 변동성에 로드맵이 흔들릴 수 있고, 사실은 변해야만 하는 순간도 있을 것입니다. 심지어는 이미 만든 것을 사용하지 못할 때도 있을 것입니다.
<아이디어 불패의 법칙>에서 시장의 많은 아이디어는 90% 이상 실패한다고 말하는데요. 최종적으로 PMF를 찾기 전까지는 계속 그럴 것입니다. 그런데, 그게 의미 없는 일인가? 글쎄요. 에디슨이 야심만만하게 전구로 동작하지 않는 999가지 방법을 찾았다고 말했듯, 우리의 구현체는 성장하고 바뀌는 것이고. 따라서 그 이하의 모든 실패들은 성공의 밑거름이 될 수 있지 않을까 기대도 해봅니다. 대신 가설을 잘 설계하고, 실패해도 배움과 성장은 있어야겠죠. 여하튼!
그러니 모든 요구사항과 구현을 관리할 때, 이것이 어떨 때 성공하고, 어떨 때 이것을 실패로 볼 지. 그리고 그 실패에서 무엇을 배울지를 알아야 합니다. 다시! 순서를 바꿔봅시다. 우리가 하는 일이 이것을 통해 무엇을 증명하고 바꿀지를 규정하는 게 우선되어야 합니다.
분명하게 인정해야 할 것은 이게 안될 수도 있다고 생각하는 것은 필요합니다. 박명수 씨가 <할명수>에서 "중요한 건 꺾여도 그냥 하는 마음"이라고 했었죠. 그럼에도 하는 것. 낙관적인 생각이란, 내 행위의 가치에 부여해야 하는 것이지, 나의 결과물에 마냥 좋을 것이라고 기대하는 것은 별로입니다. 분명, 좋은 결과를 가져오기 힘들 것입니다. 베트남전의 미군 포로로 기반한 '스톡데일 패러독스'라는 개념이 있는데. 크리스마스가 오면 풀려날 거야라고 기대만 한 사람은 좋은 결과를 가져오지 못했고, 그때 잘 안될 수도 있지만. 언젠가는~이라는 마음가짐과 꾸준한 관리를 한 사람, 즉 스톡데일이 살아남았다고 하는데요.
이게 바로 여태도 팔리는 <좋은 기업을 넘어 위대한 기업으로>의 저자가 인터뷰하면서 만든 개념입니다.
"결코 성공하리라는 믿음을 잃지 않음과 동시에 눈앞에 닥친 현실 속의 가장 냉혹한 사실들을 직시해야 한다"라는 문장으로 요약될 수도 있겠는데.
따라서 우리가 무언가를 할 때, 이것은 하나의 밑받침, 밑거름이라고 생각해야 한다고 생각합니다. 제품이 잘된다는 확신보다는 우리는 더 앞으로 나갈 것이고, 지금 만든 것에 묶이지 않을 것이라고. 지금의 최선이고, 나중의 최선은 또 다를 테니까. 계속해서 바꿔나가야만 하는 것이라고 믿고 나가는 것에 확신을 가져야 한다고 생각합니다.
지금, 완벽을 기할 필요는 없을 거라고 생각합니다. 생각이 바뀔 수도 있고, 상황이 바뀔 수도 있다는 점을 분명히 인정하고, 빠르고 기민하게 대응하고. 실패를 수용하되, 비관하지 말고 다음을 노리는 것. 그게 좋은 제품을 만들기 위한 태도가 아닐까라고 생각해요. 과학자처럼, 다음 실험을 염두에 두고 계속해서 노려보는 거죠.
여전히 맥주를 보리로 만든단 이야기네요. 하지만 밀맥주도 있고, 보리로 위스키를 만들 수도 있지 않을까 싶기도 하고 그렇습니다. 보다 문제라면... 이전 글 과내용적으로 다른 게 없군요. 발전이 개인에서 일어나야 팀도, 제품도 그리고 회사도 성장할 텐데 참 큰일입니다.
초고 2023.12.11
탈고 2024.04.06
