한국 스타트업이 이스라엘에서 배워야 할 점

간혹 이스라엘 스타트업이 다른 국가 기업보다 성공하는 이유를 다룬 서적이 눈에 띈다. 실제로 이들의 성공에는 여러 이유가 있다. 그리고 이 중 직접 시도해볼 만한 쉽고 효율적인 방법 하나를 소개하려 한다. 바로 제품 최적화 이전에 만드는 것부터 시작하라는 것이다.

한국인은 완벽함을 고집한다. 하지만 이스라엘인은 정반대다. 형식보다 기능을 선호하는 경향 때문만은 아니다(사실 조금 그렇긴 하지만). 일단 중간 결과가 충분히 괜찮은 수준이면 그 뒤의 결과가 어떻게 되든 일단 진행해보려는 경향 때문이다.

이런 다음에야 최적화를 시작한다지만 전체에 대해서가 아니라 실제 고객으로부터 온 피드백이나 데이터를 기반으로 한 문제점에 대해서만 진행한다. 문제를 일으키지 않은 부분이나 쓸데없는 부분에 대한 최적화는 진행하지 않는다는 얘기다. 물론 이 말은 이 제품의 첫 버전이 속된 말로 상당히 구릴 수도 있다는 말이기도 하다. 하지만 개발 속도와 개선 시간 면에서 보자면 빠른 속도를 낼 수 있는 것도 분명하다.

하지만 이런 모습은 한국 스타트업 대부분에선 찾아볼 수 없다. 최근 한 한국 스타트업으로부터 제품을 받아 써본 적이 있다. 거의 2년 가까운 시간을 고생한 끝에 내놓은 상용화 버전이었다. 그래서인지 디자인이나 기능 면에서 상당한 노력을 엿볼 수 있었다. 스타일리시하고 여러 피처로 가득한 제품이었다. 필자는 이 제품이 시장에 나오자마자 바로 써본 입장이지만 그럼에도 불구하고 제품 버전만 따지면 적어도 3.0이나 4.0 수준은 되는 듯했다.

다시 말해 제품의 초반 개선 과정이 완전히 내부에서만 이뤄졌을 것이란 얘기(혹은 프라이빗 베타라든지)다. 그래서인지 실제로 필자가 제품을 써봤을 때를 돌아보면 사용자 경험 면에선 오히려 아주 별로였다. 실제 사용자가 아닌 제품에 대해 잘 아는 내부 인원을 대상으로 테스트를 진행했다는 게 확실하게 드러나는 대목이었다.

결국 필자는 깔끔한 디자인에 대해선 잊어버린 채 실망에 가득차 제품을 쓰레기통에 던져버리고 말았다. 이게 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.