이스라엘 스타트업들이 다른 나라의 스타트업들에 비해 성공하는 이유를 다룬 많은 서적들이 있는데요, 실제로 이들의 성공에는 여러 이유가 존재합니다. 그리고 여기, 당신도 시도해볼만한 쉽고 효율적인 방법 하나를 소개 드려보겠습니다. 바로 제품의 최적화 이전에 만들기부터 시작하라는 것이죠.
한국인들은 완벽함을 고집합니다. 이스라엘인들은 정반대죠. 형식보다 기능을 선호하는 경향 때문만은 아니고(사실 약간 그렇긴 하지만), 일단 중간결과가 ‘충분히 괜찮은’ 정도면, 그 뒤의 결과가 어떻게 되던 일단 더 진행해보려는 경향 때문입니다. 그리고 그 뒤에서야 최적화가 시작된다지만, 여기서는 전체 부분에 대해서가 아닌 실제 고객으로부터 온 피드백 또는 데이터를 기반으로 잡힌 문제점에 대해서만 진행하지요. 문제를 일으키지 않는 부분이라던가, 쓸데없는 부분에 대한 최적화는 진행하지 않는다는 말입니다. 물론 이 말은 제품의 첫 버전이 매우 구릴 수 있다는 말이기도 하지만요. 하지만 개발속도와 개선시간 면에서 보자면 매우 신속한 속도를 낼 수 있습니다.
그런데 이런 모습은 대부분의 한국 스타트업들에게선 찾아볼 수 없지요. 최근에 한국의 한 스타트업으로부터 제품을 받아 써본 적이 있었는데요, 거의 2년에 가까운 시간을 고생한 끝에 내놓은, 상용화 버전이었습니다. 과연 디자인이라던가 기능 면에서 많은 노력을 엿볼 수 있었죠. 스타일리쉬하고 여러 피쳐로 가득한 제품이었어요. 비록 저의 경우엔 이 제품이 시장에 나오자마자 바로 구해 써보는 입장이라지만, 그럼에도 불구하고 제품의 버전은 적어도 3 또는 4 정도는 되어보였습니다. 무슨 말이냐면, 제품의 초반 개선과정이 완전히 내부적으로만 이뤄졌을 거란 말이고(또는 프라이빗 베타라던가요), 그래서인지 실제 제가 제품을 사용했을 때를 돌아보자면, 사용자 경험 면에서는 아주 별로였답니다. 실제 유저가 아닌, 제품에 대해 잘 아는 내부 인원들을 대상으로 테스트를 진행했다는게 명확히 드러나는 시점이었죠. 결국 저는 깔끔히 폴리싱된 디자인에 대해선 깜빡 잊어버린 채, 실망에 가득찬채로 제품을 쓰레기통에 던져버리고 말았습니다. 이게 2년간의 노력에 의한 결과라 믿기 어려울 정도였죠. 주말동안 유저 테스트를 진행하여 나올법한 수준이었습니다. 얼마나 시간 낭비입니까!
저는 개발자가 완벽하지 않은 제품을 내놓는다해서 비난하지 않습니다. 오히려 빠르게 시장에 내놓을 수 있어야한다 보죠. 이 팀의 경우엔, 실제 유저(= 저)와 전혀 상관 없는 부분을 개선하는데 많은 시간을 할애했다는 점이 문제였습니다. 가령 파워커넥터 같은 것을 고려하는데 많은 시간을 할애했을 거라 보는데요, 퀵 스타트 가이드라던가 튜토리얼을 짤 시간보다도 훨씬 더 많은 시간을 여기에 썼을 것이라 예상됩니다. 쉽게 피해갈 수 있는 실수였죠. 차라리 최초 버전을 빠르게 내고, 남은 시간을 이용해 유저에게 중요한 부분만 집어 최적화하는데 썼다면 좋았을텐데 말입니다. 개발자 자신들이 느끼는 중요한(또는 재밌는) 부분말고요.
당신의 스타트업에 있어 가장 큰 적은 창업자 당신입니다. 시장이라던가 경쟁자, 기타 다른 사유를 무시하고도 이미 회사를 성공시킬 수 있는 조건을 모두 갖추고 있을 지도 모르죠. 따라서 실패를 했다면 당신이 무언가를 잘못 행했거나, 올바른 선택지를 골라 실행하지 못했기 때문일겁니다. 허나 대부분의 경우엔 올바른 선택지가 무엇인가를 알기 불가능하죠. 허나 제품 면에서 볼때 만큼은, 일단 만들고 시장에 내어 피드백을 받는 것만큼 쉬운 방법이 없습니다. 그렇지 않을까요?
이스라엘인들은 제품을 빠르게, 그리고 일찍 내는데 소질이 있습니다. 이들의 이야기를 들어보면 유저의 피드백으로 인해 원래 바라보던 비전이 아주 다른 방향으로 바뀌었던 경험을 찾아볼 수 있지요. 빠르게 출시했다는건 빠르게 바꿀 수 있다는 말이기도하고, 또 중요한 것에만 집중해 유저의 관심을 모을 수도 있단 뜻입니다. 누군가에겐 완벽해보이지 않는 방법이겠지만, 실제 유저라면 그들이 생각하는 문제를 해결해주는 모습에서 호감을 가지게 될 것이죠.
최적화보다는 더 잘만드는데 집중해야할 또다른 이유가 하나 더 있습니다. 최적화라는건 (제품 개발과정을) 질질 끌기에 아주 편한 방법이기 때문이죠. 런칭은 무서운 일입니다. 유저 피드백이 끔찍할 수도 있고요. 인간은 심리적으로 나쁜 피드백을 피하려는 경향이 있고, 이를 위한 손쉬운 방법이 바로 스스로(또는 팀)에게 이 제품은 아직 최적화가 더 필요하다고 말하는 방법이죠. 실제로는 유저 피드백을 받을 시간을 미루게 되는 것 뿐인데 말입니다.
=====
Why you should be a little more Israeli-like
Many books have been written on how successful Israeli startups are compared to startups in other countries. There are lots of reasons that makes Israelis so successful in the startup game. Here’s one thing you can do like an Israeli that both easy and efficient: Make something before you start to optimize it.
Koreans are obsessed with perfection. Israelis are the polar opposites. It’s not just the preference of function over form (although it’s a little bit of that, too). It’s more the fact that once something is “good enough”, the Israeli tendency is to go forward with it, whatever the consequences. The optimization will then begin, but it will focus on optimizing the parts that matter, based on customer feedback or actual data; not need to fix things that are not broken, and no need to optimize parts that are irrelevant. Of course, that often means that the first version that is released to public users, really sucks. But it comes out quickly, and is quickly revised until it’s better.
That’s not what I see with most Korean startups. As an example, I recently got a product from a young Korean startup. It’s a commercial product that was released after almost two years of very hard development work; you could see a lot of effort was placed in product design and functionality ? the product was stylish and feature-rich. This must have been version 3 or 4 of the hardware, despite the fact that I bought it as soon as it was released to the public; that means the initial product iterations were completely internal (or “private betas”).
However, as soon as I started using it, I suffered from the most horrible user experience possible. It was obvious that the product wasn’t tested on real users but used internally in the lab by team members who knew what they were doing. I immediately forgot about the polished design and twice I almost tossed the pretty device to the trash in frustration. I couldn’t believe this was the result of two years of work: it looked like someone has spent no more than a short weekend on the user on-boarding process. What a waste!
I don’t blame the developers for releasing a non-perfect product to the market; on the contrary: I think they should have released it sooner; the problem that I see, is that the team spent dozens of months working and improving the product, but they did that in ways that didn’t matter to the end user (me). You could see that things like the power connector were given many hours of thought ? probably ten times the amount of hours spent on the quickstart guide and the initial tutorial. And it could have been easily avoided: they just needed to release an initial version earlier, and use the rest of the time to optimize the parts that were important for the users, instead of putting time and energy into what the development team itself thought was important (and lets face it, what was probably more fun for them to do).
The biggest enemy to your startup is yourself; you probably already have all that you need to make your startup a success, regardless of the market, the competition and other factors. When you fail, it will be because you did the wrong thing or because you didn’t execute the right choice. In most cases, there is no way to know what the right choice is ? but on product features, there’s one easy way to find out: build it, release it, get user feedback. Easy, isn’t it?
Israelis are great at releasing early and quickly, and I hear many stories from Israeli startup founders about how user feedback took them to a very different direction than they original envisioned; by releasing early they can change direction quickly, or focus on what is important and gain critical traction. It may look imperfect to some, but the real users of the product will like it since you are solving a real problem of theirs.
There’s another reason why making is better than optimizing. Optimization is a convenient way to procrastinate. Launch is scary; user feedback can be negative. Psychologically we try to avoid it and an easy way to avoid it is to convince ourselves (and our team) that we need one more optimization, one last improvement. What we are really doing is delaying getting feedback from actual users
한국인들은 완벽함을 고집합니다. 이스라엘인들은 정반대죠. 형식보다 기능을 선호하는 경향 때문만은 아니고(사실 약간 그렇긴 하지만), 일단 중간결과가 ‘충분히 괜찮은’ 정도면, 그 뒤의 결과가 어떻게 되던 일단 더 진행해보려는 경향 때문입니다. 그리고 그 뒤에서야 최적화가 시작된다지만, 여기서는 전체 부분에 대해서가 아닌 실제 고객으로부터 온 피드백 또는 데이터를 기반으로 잡힌 문제점에 대해서만 진행하지요. 문제를 일으키지 않는 부분이라던가, 쓸데없는 부분에 대한 최적화는 진행하지 않는다는 말입니다. 물론 이 말은 제품의 첫 버전이 매우 구릴 수 있다는 말이기도 하지만요. 하지만 개발속도와 개선시간 면에서 보자면 매우 신속한 속도를 낼 수 있습니다.
그런데 이런 모습은 대부분의 한국 스타트업들에게선 찾아볼 수 없지요. 최근에 한국의 한 스타트업으로부터 제품을 받아 써본 적이 있었는데요, 거의 2년에 가까운 시간을 고생한 끝에 내놓은, 상용화 버전이었습니다. 과연 디자인이라던가 기능 면에서 많은 노력을 엿볼 수 있었죠. 스타일리쉬하고 여러 피쳐로 가득한 제품이었어요. 비록 저의 경우엔 이 제품이 시장에 나오자마자 바로 구해 써보는 입장이라지만, 그럼에도 불구하고 제품의 버전은 적어도 3 또는 4 정도는 되어보였습니다. 무슨 말이냐면, 제품의 초반 개선과정이 완전히 내부적으로만 이뤄졌을 거란 말이고(또는 프라이빗 베타라던가요), 그래서인지 실제 제가 제품을 사용했을 때를 돌아보자면, 사용자 경험 면에서는 아주 별로였답니다. 실제 유저가 아닌, 제품에 대해 잘 아는 내부 인원들을 대상으로 테스트를 진행했다는게 명확히 드러나는 시점이었죠. 결국 저는 깔끔히 폴리싱된 디자인에 대해선 깜빡 잊어버린 채, 실망에 가득찬채로 제품을 쓰레기통에 던져버리고 말았습니다. 이게 2년간의 노력에 의한 결과라 믿기 어려울 정도였죠. 주말동안 유저 테스트를 진행하여 나올법한 수준이었습니다. 얼마나 시간 낭비입니까!
저는 개발자가 완벽하지 않은 제품을 내놓는다해서 비난하지 않습니다. 오히려 빠르게 시장에 내놓을 수 있어야한다 보죠. 이 팀의 경우엔, 실제 유저(= 저)와 전혀 상관 없는 부분을 개선하는데 많은 시간을 할애했다는 점이 문제였습니다. 가령 파워커넥터 같은 것을 고려하는데 많은 시간을 할애했을 거라 보는데요, 퀵 스타트 가이드라던가 튜토리얼을 짤 시간보다도 훨씬 더 많은 시간을 여기에 썼을 것이라 예상됩니다. 쉽게 피해갈 수 있는 실수였죠. 차라리 최초 버전을 빠르게 내고, 남은 시간을 이용해 유저에게 중요한 부분만 집어 최적화하는데 썼다면 좋았을텐데 말입니다. 개발자 자신들이 느끼는 중요한(또는 재밌는) 부분말고요.
당신의 스타트업에 있어 가장 큰 적은 창업자 당신입니다. 시장이라던가 경쟁자, 기타 다른 사유를 무시하고도 이미 회사를 성공시킬 수 있는 조건을 모두 갖추고 있을 지도 모르죠. 따라서 실패를 했다면 당신이 무언가를 잘못 행했거나, 올바른 선택지를 골라 실행하지 못했기 때문일겁니다. 허나 대부분의 경우엔 올바른 선택지가 무엇인가를 알기 불가능하죠. 허나 제품 면에서 볼때 만큼은, 일단 만들고 시장에 내어 피드백을 받는 것만큼 쉬운 방법이 없습니다. 그렇지 않을까요?
이스라엘인들은 제품을 빠르게, 그리고 일찍 내는데 소질이 있습니다. 이들의 이야기를 들어보면 유저의 피드백으로 인해 원래 바라보던 비전이 아주 다른 방향으로 바뀌었던 경험을 찾아볼 수 있지요. 빠르게 출시했다는건 빠르게 바꿀 수 있다는 말이기도하고, 또 중요한 것에만 집중해 유저의 관심을 모을 수도 있단 뜻입니다. 누군가에겐 완벽해보이지 않는 방법이겠지만, 실제 유저라면 그들이 생각하는 문제를 해결해주는 모습에서 호감을 가지게 될 것이죠.
최적화보다는 더 잘만드는데 집중해야할 또다른 이유가 하나 더 있습니다. 최적화라는건 (제품 개발과정을) 질질 끌기에 아주 편한 방법이기 때문이죠. 런칭은 무서운 일입니다. 유저 피드백이 끔찍할 수도 있고요. 인간은 심리적으로 나쁜 피드백을 피하려는 경향이 있고, 이를 위한 손쉬운 방법이 바로 스스로(또는 팀)에게 이 제품은 아직 최적화가 더 필요하다고 말하는 방법이죠. 실제로는 유저 피드백을 받을 시간을 미루게 되는 것 뿐인데 말입니다.
=====
Why you should be a little more Israeli-like
Many books have been written on how successful Israeli startups are compared to startups in other countries. There are lots of reasons that makes Israelis so successful in the startup game. Here’s one thing you can do like an Israeli that both easy and efficient: Make something before you start to optimize it.
Koreans are obsessed with perfection. Israelis are the polar opposites. It’s not just the preference of function over form (although it’s a little bit of that, too). It’s more the fact that once something is “good enough”, the Israeli tendency is to go forward with it, whatever the consequences. The optimization will then begin, but it will focus on optimizing the parts that matter, based on customer feedback or actual data; not need to fix things that are not broken, and no need to optimize parts that are irrelevant. Of course, that often means that the first version that is released to public users, really sucks. But it comes out quickly, and is quickly revised until it’s better.
That’s not what I see with most Korean startups. As an example, I recently got a product from a young Korean startup. It’s a commercial product that was released after almost two years of very hard development work; you could see a lot of effort was placed in product design and functionality ? the product was stylish and feature-rich. This must have been version 3 or 4 of the hardware, despite the fact that I bought it as soon as it was released to the public; that means the initial product iterations were completely internal (or “private betas”).
However, as soon as I started using it, I suffered from the most horrible user experience possible. It was obvious that the product wasn’t tested on real users but used internally in the lab by team members who knew what they were doing. I immediately forgot about the polished design and twice I almost tossed the pretty device to the trash in frustration. I couldn’t believe this was the result of two years of work: it looked like someone has spent no more than a short weekend on the user on-boarding process. What a waste!
I don’t blame the developers for releasing a non-perfect product to the market; on the contrary: I think they should have released it sooner; the problem that I see, is that the team spent dozens of months working and improving the product, but they did that in ways that didn’t matter to the end user (me). You could see that things like the power connector were given many hours of thought ? probably ten times the amount of hours spent on the quickstart guide and the initial tutorial. And it could have been easily avoided: they just needed to release an initial version earlier, and use the rest of the time to optimize the parts that were important for the users, instead of putting time and energy into what the development team itself thought was important (and lets face it, what was probably more fun for them to do).
The biggest enemy to your startup is yourself; you probably already have all that you need to make your startup a success, regardless of the market, the competition and other factors. When you fail, it will be because you did the wrong thing or because you didn’t execute the right choice. In most cases, there is no way to know what the right choice is ? but on product features, there’s one easy way to find out: build it, release it, get user feedback. Easy, isn’t it?
Israelis are great at releasing early and quickly, and I hear many stories from Israeli startup founders about how user feedback took them to a very different direction than they original envisioned; by releasing early they can change direction quickly, or focus on what is important and gain critical traction. It may look imperfect to some, but the real users of the product will like it since you are solving a real problem of theirs.
There’s another reason why making is better than optimizing. Optimization is a convenient way to procrastinate. Launch is scary; user feedback can be negative. Psychologically we try to avoid it and an easy way to avoid it is to convince ourselves (and our team) that we need one more optimization, one last improvement. What we are really doing is delaying getting feedback from actual users
관련뉴스
