스타트업이 확장 가능하지 않은 일을 해야하는 이유
Do things that don't scale로 PMF 찾기
스타트업 생태계에 있는 사람 중 'Do things that don't scale'이란 말을 모르는 사람은 별로 없을 것이다. 워낙 많이 인용되어서 다들 이걸 해야 한다는 건 너무 잘 알고 있다. 그런데 '왜' 해야 하는 지에 대해서는 그다지 말하지 않는 것 같다.
Do things that don't scale을 해야하는 이유
사업 초기라 고객이 없고 리소스가 없어서 Do things that don't scale 해야하는 것이 아니다. (그것도 이유의 하나가 될 수는 있는데.. 가장 중요한 이유는 아니라고 생각함.) 그게 성장하는 가장 빠른 길이기 때문이라고 말하는 사람도 있는데, 동의는 하지만 더 중요한 게 있다고 생각한다.
내가 생각하기에 Do things that don't scale을 해야하는 이유는, 창업가와 팀이 직접 유저에 대해 생각하고 그들의 경험을 handcrafting하는 것만큼 빠르고 효과적인 방법이 없기 때문이다. 다시 말해, Do things that don't scale이 유저의 경험을 디자인할 수 있는 가장 좋은 방법이기에 그렇다.
Don't scale에서 scale로 나아가는 방법
1. 유저를 감동시킬 수 있는 경험을 디자인한다.
2. 실행한다.
2-1. 유저가 감동하고 실험이 성공했다면, 그걸 어떻게든 오퍼레이션으로 키워내면서 스케일업하는 방법도 동시에 생각해낸다.
2-2. 유저가 감동하지 않고 실험이 실패했다면, 1로 돌아가 경험을 다시 디자인한다.
2-1의 포인트
동시에 해야한다는 것. 만약 don't scale한 방법으로 성공했지만 아무도 스케일업에 대해 생각하지 않는다면 언젠가는 감당할 수 없게 된다. 반대로 스케일업 하기 위해 don't scale한 일을 멈춰버리면 성장도 같이 멈춘다. 그래서 둘 다 동시에 해야한다. (환경과 시기, 경쟁사 현황 등에 따라서 속도가 달라질 수는 있겠다.)
2-2의 포인트
1로 돌아가야 한다는 것. 고객이 감동하고 만족할만한 경험을 디자인하기 전까지는 계속 don't scale한 방식으로 가설을 검증해나가야 한다.
Appendix
아래에 인상 깊었던 내용을 정리해보았다. 30분 가량 짧은 팟캐스트이니 직접 들어보시는 것을 추천.
1.
왜 Do things that don't scale을 해야하는가? 지금만 할 수 있고 그것이 가장 효과적이기 때문
He said, “Go to your users. Get to know them. Get your customers one by one.” And I said, “But that won't scale. If we’re huge and we have millions of customers we can't meet every customer.” And he said, “That's exactly why you should do it now because this is the only time you'll ever be small enough that you can meet all our customers, get to know them, and make something directly for them.”
2.
User feedback을 맹신하는 자를 위한 caveat : 유저를 잘 pick 해야한다.
It’s essential to seek out and listen to user feedback. But the caveat is: You have to figure out which users to listen to. You're going to have different kinds of users giving you feedback—and some of it will take you in the wrong direction. So you need to exercise judgment in discerning: Will this particular user and particular feedback lead me to the mass market? Or is it an edge case?
2-1. 링크드인 케이스
모든 사람들과 이어지기를 원하는 유저들이 있었음. 하지만 링크드인은 majority 케이스가 아니라고 판단. 바쁘고, 리소스가 넘쳐나고, 스타 플레이어인 사람들은 그걸 원하지 않을 것이기 때문에. 호프만은 '자신들의 조언을 듣지 않아서 링크드인이 바보라고 말하는 열성 유저들에게서 벗어나야 했다'고 언급.
For example, at LinkedIn, we had one group of users who invented a name for themselves. They called themselves LIONs—which is LinkedIn Open Networkers—because their theory of the world was that everyone wants to directly connect to everyone else in the world—because that's the way they wanted it. But they're actually not the majority case. A lot of people who are very busy, who have access to resources, who have some celebrity status—do not want that. And if we followed their feedback, LinkedIn would not be where it is today. We had to steer away from a bunch of passionate users who told us very explicitly that we were fools for not following their advice.
3.
에어비앤비가 don't scale에서 Scalable 하게 된 여정
- 우선은 창업자 두명이서 사진 찍으러 다님
- 버티다가 너무 고통스러워서 새로운 사진작가를 고용
- 너무 고통스러워지기 전까지는 스프레드시트로 모든 걸 매니지함
- 그렇게 또 버티다가 너무 고통스러워서 인턴을 채용
- 인턴은 매뉴얼에 적혀있는대로, 사진작가에게 이메일 넣고, 호스트랑 연결하고, 사진작가에게 사진 받아서 피드백 주고, 호스트 웹사이트에 몇 시간 들여서 하나하나 업로드함. (Brain이 매일 매일 와서 "오늘은 얼마나 됐어! 새로운 사진 몇 장이나 찍었어? 물어봤다고 함)
- 그러다가 어느날 '자, 이 중에서 가장 자동화하기 쉬운 부분이 뭘까'하고 물어봤고, 거기서부터 조금씩 자동화하기 시작함
We had a saying that you would do everything by hand until it was painful. So Joe and I would photograph homes until it was painful, then we get other photographers. Then we’d manage them with spreadsheets until it was painful. Then we got an intern.
Intern : I don't think I knew how anything would grow to the level that it did. Very manually, I would email the photographer and the host and connect them.
The photographer would then send me the photos. I would go through each one giving feedback if they needed to be retouched. Then I would manually upload them to the host's website, their listing, one by one. It would take hours to upload. Multitasking was the name of the game. : And we kind of looked at this and we said OK what is the easiest thing that we can automate. Any little thing that changed was quite a shift in what I had been doing—but for the better.
4.
don't scale한 mind와 scale한 마인드는 전혀 다름.
- don't scale (designing of experience) : 직관, 고객에 대한 공감, end-to-end 경험
- scale : 매우 분석적, 운영 지향적, 기술 지향적
The designing of experience is a different part of your brain than the scaling your experience. It's a different skill set. The scaling experience is a highly analytical, operations oriented, and technology oriented problem. The designing of experience is a more intuition based human, empathetic, end-to-end experience
>> 여기서 중요한 건 언제나 "don't scale" 범주에서 경험을 디자인해야만 Scale까지 도달할 수 있다는 것. 작은 회사, 큰 회사 모두 마찬가지임. 새로운 기능을 런칭한다면 그건 또 다시 don't scale 영역에서 한명 한명의 유저에 집중하며 경험을 디자인해야함.
4-1. 에어비앤비 사례
한명의 고객을 만족시키는 경험을 디자인해서, 그걸 스케일할 수 있는 방법을 다시 생각하기
I see him at the end of the trip. I say, “How was your trip?” He says, “It was amazing.” And then I walk away. He yells at me. “Brian, one more thing.” He starts crying. He breaks down, he says, “Thank you. This is the best trip I've ever had.” I was like, “Oh my God. I guess it worked. It really moved him.” I don't think anyone ever tried to design an end-to-end experience for somebody like they're in a movie before and we did it. That became a blueprint. We said we are confident on an unscalable basis that we know how to create a trip that deeply moved somebody that’s better than anything they've ever experienced. The question is: Can we develop a technology that scales and do it 100 million times?
5.
Scale한 규모까지 커지더라도, 창업가는 언제나 우리가 타협할 수 없는 "handcrafting"이 무엇인지 생각해야함.
The reason that scaled companies have a hard time with this handcrafted process is all in the list of objections about why this won't work, why this shouldn't be integrated as part of the company. And so what you need to do as a founder is to be extremely choiceful of which handcrafted innovation you choose, and how you protect it organizationally. You need to protect it because the natural reaction of the scale organization will be to kill it.
출처 : Masters of Scale 팟캐스트 ep.1 https://mastersofscale.com/brian-chesky
