Робіть речі, які не масштабуються!

Переклад статті Пола Грема "Do Things that Don't Scale" (українською)

28.05.2020

Чому масштабний запуск продукту практично не працює? Як шукати перших клієнтів стартапа і чи варто це робити? Чи потрібно прагнути завоювати світ на ранній стадії стартапу? Ми підготували український переклад відомого есе Пола Грема «Do Things that Do not Scale», яке присвячене помилкам засновників стартапів на початковому етапі.

Тим, хто прийшов в Y Combinator ми найчастіше радимо не думати про масштабування. Багато майбутніх засновників компаній вважають, що стартапи або відразу стають успішними, або не домагаються успіху ніколи. Потрібно створити новий продукт, запропонувати його на ринку, а далі все як обіцяв Емерсон: якщо вам вдалося вдосконалити мишоловку, то люди самі знайдуть дорогу до вашого будинку. А якщо не знайдуть, значить, ринку для вашої продукції не існує. [1]

Насправді стартап злітає, якщо засновники змушують його злетіти. Винятки бувають, але дуже рідко. Зазвичай «розганяти» компанію доводиться самостійно — зовсім як машину до появи електричного стартера. Для запуску двигуна в ті часи доводилося крутити залізну рукоятку. Коли завівся, тоді все в порядку, але якщо хочеш їхати — спочатку покрути!

Клієнти

Перш за все вам доведеться шукати клієнтів. Через це проходять практично всі стартапи. Не можна сидіти і чекати приходу користувачів — вони не прийдуть. Потрібно самому піти і привести їх.

З усіх стартапів, які ми фінансували, одним з найуспішніших стала компанія Stripe, і ця проблема стояла перед нею на повний зріст. Взагалі-то, якщо хтось і міг спокійно сидіти і чекати клієнтів, то це якраз Stripe, проте в Y Combinator вони прославилися саме агресивним залученням користувачів на початковому етапі.

Стартапи, які роблять щось для таких же стартапів, мають великий резерв потенційних користувачів в інших компаніях, які ми фінансували. Ніхто не користувався цією можливістю краще Stripe. У себе в Y Combinator ми називаємо їх підхід «установкою по методу братів Коллісон» (творців сервісу). Більш скромні фаундери спочатку запитають у користувача, чи не хоче той спробувати їх бета-версію, і якщо відповідь ствердна — вишлють посилання. Але тільки не брати Коллісон. Коллісон не бажали просто сидіти і чекати. Ледь хтось погоджувався спробувати Stripe, вони тут же говорили: «Дуже добре, давайте сюди ноутбук» — і відразу робили всі налаштування.

На мій погляд, є дві причини, за якими засновники стартапів не хочуть самостійно шукати користувачів. По-перше, поєднання сором'язливості і ліні. Їм більше подобається сидіти вдома і писати код, ніж розмовляти з незнайомими людьми, більшість з яких, швидше за все, відповість відмовою. Однак для успіху нової компанії принаймні один з її засновників (зазвичай це генеральний директор) повинен приділяти багато часу продажу та маркетингу. [2]

Друга причина криється в тому, що досягнення спочатку здаються мізерними. Новачки вважають, що успішні, знамениті стартапи починали зовсім не так. Помилка таких людей полягає в недооцінці сукупних темпів зростання. Ми рекомендуємо кожному стартапу вимірювати щотижневий темп зростання . Якщо у вас є 100 користувачів, то для тижневого зростання на 10% до початку наступного тижня доведеться знайти ще десять клієнтів. І хоча 110 не набагато більше 100, якщо вдасться підтримувати зростання на рівні 10% в тиждень, то дуже скоро цифри вас приємно здивують. Через рік у вас буде вже 14 000 користувачів, а через 2 роки — 2 мільйони.

Звичайно, коли лік одномоментно залучених користувачів піде на тисячі, доведеться діяти по-іншому, та й темпи зростання в якийсь момент знизяться. Однак якщо попит є, то зазвичай можна почати з пошуку клієнтів «в ручному режимі», а потім поступово його автоматизувати. [3]

Класичний приклад такого підходу — компанія Airbnb. Такі майданчики (так званий marketplace) дуже важко запускати, тому спочатку потрібні буквально героїчні зусилля. У випадку з Airbnb ці зусилля пішли на поквартирний обхід будинків в Нью-Йорку в пошуках нових користувачів і на допомогу вже існуючим клієнтам в поліпшенні їх пропозицій по оренді житла. Згадуючи співпрацю Y Combinator з хлопцями з Airbnb, ніяк не можу уявити собі їх без валіз на коліщатках, тому що на нашій традиційний вівторковій вечері вони завжди заявлялися з чергового відрядження прямо з літака.

Крихкість

Сьогодні Airbnb виглядає незламною громадою, проте спочатку положення компанії було дуже хитким. Саме той місяць, витрачений на обхід і особисте спілкування з потенційними клієнтами, і відділив успіх від невдачі.

Така нестійкість на початку шляху — зовсім не відмінна риса Airbnb. Майже всі стартапи на першому етапі вкрай нестабільні, і з цим пов'язане одне з найголовніших помилок їх недосвідчених творців і інвесторів (а також журналістів і «знавців» на форумах). Вони несвідомо судять про стартапи, які перебувають в зародковому стані, за мірками сталих компаній. Це все одно що, дивлячись на новонародженого немовляти, говорити: «Навряд чи це крихітне створення зможе хоч чогось домогтися».

Не страшно, якщо журналісти і «всезнайки» відмовляться всерйоз сприймати ваш стартап. Вони завжди помиляються. Не страшно, якщо ваш стартап не надихнув інвесторів — вони змінять свою думку, коли побачать зростання компанії. Найстрашніше — це якщо ви самі перестанете в нього вірити. Мені часто доводиться підбадьорювати людей, які не бачать перспектив свого власного дітища. Цією помилки не уникнув навіть Білл Гейтс, який заснував Microsoft, а потім (нехай і ненадовго) повернувся в Гарвард. Цього ні за що не сталося б, якби він тоді хоч віддалено уявляв, на що перетвориться його компанія. [4]

На ранній стадії стартапу варто питати не «чи завоює ця компанія світ?», а «наскільки зможе вирости компанія, якщо засновники все зроблять правильно?». Правильні дії часто виглядають трудомісткими і непослідовними. Навряд чи в Microsoft можна було вгледіти щось особливе, коли двоє хлопців в Альбукерке писали інтерпретатори мови Basic для декількох тисяч, як тоді говорили, «ентузіастів-аматорів». Однак сьогодні можна стверджувати: це був оптимальний шлях до домінування на ринку програмного забезпечення для персональних комп'ютерів. Ще я точно знаю, що коли засновники Airbnb Брайан Ческі і Джо Гебб «професійно» фотографували квартири своїх перших клієнтів, вони зовсім не передбачали прийдешній успіх, а просто намагалися утримати компанію на плаву. Проте зараз також очевидно,

Як самостійно знаходити користувачів? Якщо ви розробляєте щось для вирішення власних проблем , то залишається лише знайти схожих на вас людей, що зазвичай не викликає труднощів. В іншому випадку доведеться цілеспрямовано шукати найбільш перспективне джерело поповнення призначеної для користувача бази. Зазвичай для цього потрібно залучити первісну групу клієнтів, запустивши продукт або послугу більш-менш безадресно, а потім подивитися, хто проявляє до них найбільший інтерес, і постаратися залучити побільше таких клієнтів. Наприклад, засновник Pinterest Бен Зільберман звернув увагу, що серед перших користувачів його соціальної мережі багато тих, хто цікавиться дизайном. У пошуках нових клієнтів він відправився на конференцію блогерів, які пишуть про дизайн, і цей хід виявився успішним. [5]

За́хват

Вам доведеться докласти великих зусиль не тільки щоб залучити користувачів, але і щоб вони залишилися задоволені. Поки була можливість (а була вона напрочуд довго), компанія Wufoo посилала кожному новому користувачеві написаного від руки листа з подякою. Перші користувачі повинні відчувати, що реєстрація на сайті вашої компанії — одне з найбільш правильних рішень в їх житті. Ви ж, в свою чергу, повинні поламати голову: чим би ще їх порадувати?

Чому нам доводиться вчити цьому стартапи? Чому творці самі цього не розуміють? По-моєму, з трьох причин.

По-перше, багато хто з них за освітою інженери, яких не готують до роботи з клієнтами. Їх вчать створювати надійні і елегантні речі, а не догоджати користувачеві немов якийсь продавець. Як би не парадоксально, але таке небажання технічних фахівців няньчитися з клієнтами якоюсь мірою пов'язано з традиціями їх професії — адже раніше інженер мав куди менше впливу і відповідав тільки за свою вузьку область розробки, а не за продукт в цілому. У команді бурчати дозволено інженеру Скотті, але аж ніяк не капітану Кірку (прим.: персонажі серіалу "Star Trek: Enterprise").

Друга причина, чому в стартапи не приділяють належної уваги окремим клієнтам, — це боязнь того, що такий підхід не масштабується. Коли стартап знаходиться в зародковому стані і засновники починають про це хвилюватися, я нагадую, що в даний момент їм все одно нічого втрачати. Так, якщо зараз дуже постаратися, щоб поточні користувачі були всім задоволені, то в один прекрасний день їх стане дуже багато, і сил на кожного вже не вистачить. Бажаю вам побільше таких «проблем». Ось і спробуйте цього досягти. До речі, якщо вийде, ви переконаєтеся: задоволеність клієнтів масштабується куди краще, ніж вам здавалося. Частково тому, що майже завжди знайдеться спосіб домогтися масштабування всупереч початковим прогнозами; а якоюсь мірою тому, що вона вже стане частиною вашої корпоративної культури.

Я жодного разу не бачив, щоб стартап зайшов в глухий кут через те, що занадто сильно прагнув порадувати найперших користувачів.

Втім, напевно, головний бар'єр, який не дозволяє стартапам зрозуміти важливість турботи про користувача, — це відсутність у власників досвіду такого ставлення до них самих. Їх стандарти обслуговування часто запозичені у компаній, клієнтами яких були колись вони самі. Як правило, це великі корпорації. Голова компанії Apple Тім Кук не пише від руки лист з подякою, коли ви купите у нього ноутбук. Він просто не може, а ось ви — можете. В цьому одна з переваг маленької компанії. Ви можете забезпечити рівень обслуговування, який не надасть жодна велика корпорація. [6]

Коли ви зрозумієте, що існуючі умовності не перепона для вдосконалення користувацького досвіду, приємно буде поміркувати про те, що ще таке ви можете зробити для своїх клієнтів, щоб вони залишилися повністю задоволені спілкуванням з вашою компанією.

Досвід

Я шукав спосіб краще пояснити, до яких крайнощів необхідно доходити в турботі про користувачів. Виявилося, що це вже зробив Стів Джобс, коли назвав Mac «прекрасним до божевілля». «До божевілля» — не просто синонім слова «дуже». Стів розумів це буквально: як необхідність зосередитися на якості виконання до такої міри, що в звичайному житті це вважалося б патологією.

Таким підходом відрізнялися всі найуспішніші стартапи, які ми фінансували, що навряд чи здивує засновників нових компаній. Однак новачки не розуміють, що означає те саме «прекрасний до божевілля» для стартапу на самому старті. Коли Стів Джобс вперше вимовив ці слова, Apple вже була визнаною компанією. Він мав на увазі, що дизайн і виготовлення комп'ютерів Mac (в тому числі їх документація та навіть упаковка — така була ступінь його одержимості) повинні бути «прекрасні до божевілля». Такий підхід інженеру зрозуміти нескладно: це та ж сама вимога «створювати надійні і елегантні речі» — просто в більш категоричній формі.

Засновникам же компаній буває складно зрозуміти, що це означає, якщо повернутися до першої пари місяців життя стартапу (мабуть, зараз це нелегко далося б і самому Стіву). «Прекрасним до божевілля» повинен бути не продукт, а досвід користувача. Продукт — лише один з компонентів цього досвіду. Звичайно, для великої компанії продукція має домінуюче значення. Однак ви можете і повинні забезпечити користувачам «прекрасний до божевілля» досвід роботи з сирим і недоробленим продуктом, компенсуючи недоліки увагою до клієнта.

Напевно, це можливо. Але чи потрібно? Безумовно! Активна взаємодія з першими користувачами — не просто один із способів зростання. Для більшості успішних стартапів це найважливіший елемент зворотного зв'язку, яка виллється в продукт високої якості. «Удосконалення мишоловки» — це ітеративний процес. Навіть якщо піти по шляху найбільш успішних стартапів і зробити продукт, який потрібен вам самому, з першого разу ідеальним він не вийде. Краще взагалі не прагнути до досконалості на початковому етапі (якщо, звичайно, не працюєш в області, де ціна помилки дуже висока). При розробці програмного забезпечення найефективніше викотити продукт користувачам як тільки від нього буде хоч якийсь зиск, а потім подивитися, що саме з ним будуть робити. Перфекціонізм часто служить виправданням для зволікань, але пам'ятайте,[7]

Найкращу зворотний зв'язок дають саме перші користувачі. Коли компанія розростеться і доведеться збирати фокус-групи, ви будете мріяти про можливість поспостерігати за тими, хто користується вашим продуктом у себе вдома або в офісі також, як ви це робили з першої жменькою клієнтів.

Багаття

Іноді, правильний трюк який не масштабується — це свідоме фокусування на дуже вузькому ринку. Це схоже на багаття: спочатку розводиш маленький вогник і даєш йому розгорітися, а потім вже можна підкинути полін.

Саме так діяли засновники Facebook. Спочатку його зробили тільки для студентів Гарвардського університету. Потенційних клієнтів було всього кілька тисяч, зате всі вони вважали, що мережа створена саме для них, так що критичну масу початкових користувачів вдалося набрати дуже швидко. Навіть коли Facebook вийшов за межі Гарварда, мережа ще довго призначалася лише для студентів кількох коледжів. В інтерв'ю для нашої «Школи стартапів» Марк Цукерберг розповів мені, як багато часу пішло на збір даних про розклади занять в кожному коледжі, зате для студентів, які цим займалися сайт відразу став рідною домівкою.

Якщо стартап є marketplace-майданчик, то він майже завжди починає із одного з вузьких сегментів обраного ринку. Втім, цей підхід може спрацювати і для інших стартапів. Завжди є сенс пошукати сегмент, в якому вийде швидко набрати критичну масу користувачів[8]

Більшість стартапів, які використовують стратегію «розведення багаття», роблять це несвідомо. Вони створюють якийсь продукт для себе і своїх друзів, які і виявляються першими активними користувачами. Вже пізніше вони раптом розуміють, що можуть запропонувати його більш широкому колу. Дана стратегія прекрасно працює навіть коли реалізується несвідомо. Небезпека тут полягає в тому, що якщо дієш несвідомо, можна просто втратити якусь частину системи. Наприклад, буває, що продукт робиться не для себе і друзів, або розробка ведеться в корпоративному середовищі, і тоді друзі не стають першими активними користувачами. В цьому випадку у вас більше не буде ідеального початкового ринку, який вам передадуть на блюді.

В B2B моделі кращі активні користувачі виходять, як правило, з інших стартапів. Вони більш відкриті для нового — частково просто за своєю природою, а якоюсь мірою тому, що знаходяться в самому початку шляху і ще не визначилися з пріоритетами. Крім того, в разі успіху стартапи починають швидко рости, і ваша компанія — разом з ними. Одна з багатьох неочевидних переваг моделі Y Combinator (і зокрема перетворення Y Combinator у великий проект) проявилося в тому, що у стартапів в області B2B сьогодні є готовий ринок збуту з сотень інших стартапів.

Meraki

Для hardware-стартапів є спосіб забути про масштабування, який ми називаємо «трюк Meraki». З самою компанією Meraki ми не працювали, але її заснували аспіранти одного із засновників Y Combinator Роберта Морріса, так що ми в курсі всіх подій. Вони починали з самостійної збірки маршрутизаторів — ось вже де і правда варто забути про масштабування.

Hardware-стартапи часто стикаються з перешкодою, незнайомою розробникам ПЗ. Вартість мінімального замовлення для запуску заводської серії становить, як правило, кілька сотень тисяч доларів. Виникає замкнуте коло: без продукту не буде зростання, а без зростання не залучиш коштів на виробництво продукту. Раніше hardware-стартапи повністю залежали від інвесторів, тому їм потрібно володіти серйозними навиками переконання. З появою краудфандингу (а точніше системи попередніх замовлень) ситуація змінилася, проте я все одно рекомендую при можливості використовувати трюк Meraki. Саме так діяла компанія Pebble, розробник «розумних» годинників. Її працівники зібрали перші кілька сотень виробів самостійно. Якби не пройшла компанія цей етап, їй навряд чи вдалося б продати годинників на 10 мільйонів доларів після виходу на Kickstarter.

Так само як і гіпертрофована увага до перших клієнтам, самостійне виготовлення продукції — дуже важливий етап для hardware-стартапів. Самостійно займаючись виробництвом, можна швидше модифікувати конструкцію, ніж розміщуючи замовлення десь ще. При цьому ти також швидше отримуєш зворотну дію, котра просто недоступна при інших обставинах. Ерік Міджіковскі з Pebble якось згадав, що зрозумів, «наскільки важливо знайти хороші шурупи». Ну хто б міг подумати?

Консалтинг

Іноді ми рекомендуємо B2B-стартапам піти на крайній крок: вибрати одного користувача і займатися розробкою конкретно для нього, як ніби ви виступаєте консультантом для цього конкретного клієнта. Перший користувач стає для продукту свого роду «прес-формою». Потрібно вносити зміни до тих пір, поки ваш продукт не буде повністю відповідати його потребам, в результаті ви зазвичай виявляєте, що іншим користувачам це також потрібно. Навіть якщо цих клієнтів мало, в сусідньому сегменті ринку їх напевно знайдеться більше. Поки є хоч один користувач з реальною потребою, яку ви можете якось задовольнити, у вас є точка опори — адже ви робите щось потрібне. А більшого стартапу для початку і не потрібно. [9]

Консалтинг — це класичний приклад роботи без масштабування. Однак (як і з іншими варіантами роздачі подарунків) спокійно займатися цією діяльністю можна тільки до тих пір, поки вам за неї не платять. Саме тут багато перетинають межу дозволеного. Поки ви продуктова компанія, яка просто проявляє додаткову увагу до клієнта, він буде тільки вдячний, навіть якщо якісь проблеми не вирішуються повністю. А ось коли за той же увагу клієнт починає платити на погодинній основі, він чекає, що ви зробите все, що він хоче.

Ще один варіант консалтингу, що дозволяє отримати спочатку байдужих до продукту клієнтів, — це працювати з власним ПЗ «від їх імені». Ми застосовували цей підхід з Viaweb. Торгові компанії, яким ми пропонували спробувати наш сервіс створення інтернет-магазинів, нерідко відмовляли, проте не заперечували, якщо це зробимо ми самі. Ми погоджувалися, оскільки були готові на все заради користувачів. Звичайно, в той момент ми відчували себе «слабаками»: адже замість великих стратегічних партнерств для створення Інтернет-магазинів доводилося торгувати валізами, ручками і чоловічими сорочками. Однак зараз зрозуміло, що курс був обраний вірно, адже ми зрозуміли, що відчуває клієнт, працюючи з нашим сервісом. Іноді зворотний зв'язок з'являлася практично миттєво: працюючи над сайтом якогось магазину, я раптом розумів, якої функції нам не вистачає. Тоді я швидко дописував цю функцію і повертався до роботи над сайтом.

Вручну

Є і більш екстремальний варіант: коли ви не працюєте зі своїм сервісом, а просто стаєте ним. Якщо користувачів у вас небагато, то деякі завдання можна виконувати вручну, а автоматизувати пізніше. Це дозволить швидше запустити проект, а коли прийде час автоматизації, ви вже будете точно знати, що треба робити, адже після ручної роботи потрібна інформація збережеться в «м'язової пам'яті».

Коли виконуються вручну елементи виглядають для користувача як частина програмного забезпечення, робота починає нагадувати розіграш. Наприклад, при «миттєвому» наданні своїм першим користувачам рахунків для прийому онлайн-платежів з банківських карт засновники компанії Stripe просто реєстрували їм ці рахунки вручну.

Деякі стартапи могли б на першому етапі працювати повністю в ручному режимі. Якщо у вас є потенційний клієнт з проблемою, яку необхідно вирішити, і ви здатні розв'язати цю проблему вручну, то беріться за справу і працюйте, поки є така можливість, а потім поступово автоматизуйте проходження «вузьких місць». Звичайно, вирішувати проблеми без автоматизації страшнувато, але куди страшніше більш поширений випадок, коли автоматизація є, але проблем вона не вирішує.

Запуск

Є один тактичний прийом, який не працює майже ніколи, — це Масштабний Запуск Проекту. Деякі творці стартапів, здається, думають, що компанія більше схожа не на літак, а на артилерійський снаряд. Вони вважають, що великого успіху можна досягти, тільки запустивши проект з досить високою початковою швидкістю. Такі люди прагнуть оголосити про старт одночасно в восьми різних місцях, причому не раніше певної дати. Так, і неодмінно у вівторок, адже вони десь читали, що кращий день для запуску проекту — це саме вівторок.

Неважко зрозуміти, що запуск не має ніякого значення. Візьміть кілька успішних стартапів — ви пам'ятаєте, як вони запускалися? У запуску одна задача — залучити першу групу користувачів. Ваш успіх через кілька місяців залежить скоріше від уміння задовольнити потреби цих користувачів, ніж від їх кількості. [10]

Чому ж творці стартапів надають таке значення запуску? Це пояснюється поєднанням соліпсизму і ліні. Такі люди вважають свій продукт настільки чудовим, що кожен, хто почує про нього, негайно вирішить поповнити ряди клієнтів. Крім того, їм здається, що куди простіше залучати користувачів, просто оголосивши про своє існування, ніж шукати їх по одному. Але навіть якщо ваш сервіс і правда чудовий, користувачі все одно будуть накопичуватися поступово. Частково тому, що інноваційні продукти спочатку виглядають незвично, але в основному від того, що у людей є й інші турботи.

Партнерські відносини теж зазвичай не працюють. Вони не працюють для стартапів взагалі, і особливо як засіб забезпечення зростання. Серед новачків гуляє поширена помилка, що партнерство з великою компанією стане для них великим проривом. Однак через шість місяців всі як один говорять, що працювати довелося куди більше очікуваного, а ефекту практично ніякого. [11]

Недостатньо лише здійснити на початку щось видатне. Спочатку потрібно докласти видатні зусилля. Будь-яка стратегія, яка при пошуку клієнтів спирається не на зусилля, а на масштабний запуск або великого партнера, вкрай сумнівна сама по собі.

Вектор

Оскільки на старті завжди потрібно трудомістка робота без можливості масштабування, ідеї стартапів більше немає сенсу розглядати як скалярні величини. Ідею краще представляти як парне поєднання: продукт, який планується створити, і робота (що потрібна для запуску стартапу), але яка не масштабується.

Було б корисно розглядати ідеї саме так, оскільки, маючи два компонента, можна шукати творчі рішення не тільки для першого, а й для другого. Втім, в більшості випадків другий компонент є незмінним: пошук клієнтів «в ручному режимі» і забезпечення їм неперевершеного користувацького досвіду. Головна перевага уявлення стартапу в вигляді вектора — це можливість нагадати їх творцям, що напружено працювати над відразу в двох вимірах. [12]

При найкращому сценарії обидві компонента такого вектора внесуть свій вклад в формування «ДНК» компанії. Робота без ефекту масштабування, яку необхідно провести на початковому етапі, — це не просто «неминуче зло», вона назавжди змінить компанію на краще. Якщо ви активно залучаєте користувачів, поки компанія невелика, то і коли вона розростеться, ви напевно будете діяти також активно. Самостійно виробляючи власне обладнання або працюючи зі своїм програмним забезпеченням, ви придбаєте знання, яким більше ніде не навчишся. І головне: якщо вам довелося попрацювати, щоб перші кілька користувачів були задоволені, то ви будете так само працювати, коли їх стане багато.

 

Примітки

[1] В дійсності Емерсон навіть не згадував про мишоловки. Він писав: «Якщо у людини є гарне зерно, деревина, дошки або свині для продажу або він краще, ніж інші, вміє робити стільці, ножі, тиглі або церковні органи, то ви знайдете широку, добре втоптану дорогу до його дому, навіть якщо він живе в глухому лісі».

[2] Спасибі Сему Альтману за пораду висловити цю думку безпосередньо. До речі, майте на увазі, що перекласти продажу на найманого фахівця не вийде. Спочатку ними необхідно займатися самому, а ось пізніше можна вже знайти кого-то на заміну.

[3] Цей прийом працює, тому що в міру розширення вашої компанії її розмір сприяє подальшому зростанню. Як писав Патрік Коллісон: «У якийсь момент відчуття від роботи в Stripe істотно змінилися. Компанія немов перетворилася з валуна, який ми тягнемо вгору, в залізничний вагон, який сам котиться з гори ».

[4] Поряд з іншими, більш очевидними перевагами, співпраця з фондом Y Combinator допомагає засновникам компаній вірно оцінити свої амбіції — адже ми добре знаємо, як виглядали багато успішних стартапи на самому початку шляху.

[5] Якщо для вашого продукту важко зібрати навіть невелику групу користувачів, за якими можна спостерігати (наприклад, ви розробляєте корпоративне ПО), і у вас немає в цій області потрібних зв'язків, то доведеться покладатися на «холодні дзвінки» і просити представити вас за потрібний людям. Втім, чи варто взагалі витрачати на таку ідею час?

[6] Гаррі Тан звернув увагу на цікаву пастку, в яку на початковому етапі потрапляють засновники стартапів. Їм так хочеться здаватися більшими, що вони копіюють навіть недоліки великих компаній, в тому числі байдужість до окремих користувачів. Це здається їм більш «професійним». Насправді краще прийняти той факт, що ви маленька компанія і використовувати всі пов'язані з цим переваги.

[7] Ваші уявлення про користувачів просто не можуть бути абсолютно точні, так як їхні потреби часто змінюються у відповідь на створений вами продукт. Запропонуйте їм персональний комп'ютер, і їм раптом захочеться запускати на ньому електронні таблиці, які хтось вигадав, отримавши ваш комп'ютер.

[8] Якщо в одному сегменті можна швидко залучити клієнтів, а в іншому вище платоспроможність, то краще зупинитися на першому. Ці люди напевно стануть першими активними користувачами, які посприяють розвитку продукту, при цьому вам не доведеться докладати надзусиль, щоб забезпечити продажу. Не страшно, що у них менше грошей, адже на початковому етапі для підтримки запланованих темпів зростання потрібно не так вже й багато.

[9] Так, можливо і таке, що створений вами продукт виявиться корисним рівно для одного користувача. Втім, як правило, такі випадки очевидні навіть для новачків. Тому, якщо у вас немає повної впевненості, що потенційний клієнт всього один, то хвилюватися не варто.

[10] Залежність між масштабністю запуску і успіхом проекту буває навіть зворотного. Всі запуски, які пам'ятаю особисто я, обернулися грандіозними провалами, наприклад, Segway або Google Wave. Найсильніше лякає якраз приклад Google Wave, адже ідея, на мій погляд, була чудова, але помпезний запуск здорово посприяв її провалу.

[11] Google перетворилася на велику компанію, спираючись на Yahoo, однак це не було партнерством. Компанія Yahoo була клієнтом Google.

[12] Це також нагадає творцям стартапів, що ідея, в якій другий компонент не використовується, тобто який не передбачає ніяких дій для запуску (наприклад, тому що знайти користувачів «в ручному режимі» неможливо), швидше за все, погана ідея. Принаймні, саме для них.

 

Спасибі Сему Альтману (Sam Altman), Полу Букхайту (Paul Buchheit), Патріку Коллісон (Patrick Collison), Кевіну Хейлі (Kevin Hale), Стівену Леві (Steven Levy), Джесіці Лівінгстон (Jessica Livingston), Джефф Ролстон (Geoff Ralston) і Гаррі Тану (Garry Tan) за ознайомлення з чорновим варіантом цього есе.

Оригінальна стаття "Do Things That Don't Scale":
http://paulgraham.com/ds.html


Якщо вам сподобалась стаття — поділіться з друзями:  


Коментарі: