Як стати власним технічним співзасновником - і чому це варто вашого часу

Примітка : цей блог натхненний моїм нещодавнім інтерв’ю в подкасті з Квінсі Ларсоном із FreeCodeCamp, де ми говоримо про це протягом останніх 15 хвилин.

Шукаєте технічного співзасновника? Я теж був. Протягом багатьох років. Це була важка подорож, тому що головна “мудрість” полягає в тому, що вам потрібно вийти і знайти технічного співзасновника, оскільки вони були у всіх успішних стартапів (до речі, неправда). Але що відбувається, коли ви знаходитесь у кінці злітно-посадкової смуги, і ваш вибір - навчитися кодувати або кинути?

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

Ну звичайно.

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

Мій досвід роботи як нетехнічного (сольного) засновника

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

  1. Я витратив масу часу, переглядаючи форуми, LinkedIn та списки контактів, шукаючи людей, які відповідають мінімальним критеріям
  2. Я витратив багато часу, не маючи змоги перевірити багато, багато тестувати, багато прогресувати, тому що мені не було чого перевірити, перевірити чи прогресувати, крім добре відточеного кроку
  3. Я познайомився з багатьма людьми, і більшість з них не цікавилися підприємництвом або не мали необхідної трудової етики (вона ж мазохістська смуга)
  4. Я познайомився з багатьма людьми, яким було цікаво, але при всіх неправильних мотиваціях (швидко збагатитися, слава, слава ...)
  5. Я зустрів кількох людей, які мали правильні мотивації та (наскільки я міг зрозуміти) правильні навички, але які не мали ментальності, щоб протистояти жорстокості запуску
  6. Я зустрів дуже мало людей, які мали досвід запуску та мали навички, але жоден з них не був захоплений моїми поняттями (статистична неминучість)

Я невпевнено знав про програмне забезпечення, хоча хотів створити технологічну компанію. Отже, ось мої помилки з того часу:

  1. Я не мав уявлення про основні, основні аспекти програмного забезпечення та його дизайн
  2. Я сильно недооцінив складність (не знав, скільки я не знав)
  3. Я дуже недооцінював задіяний час
  4. Я сильно переоцінив людей, до яких я звертався, щоб бути співзасновниками техніки
  5. Я суттєво (але не свідомо) завищив свою роль у початковий період - «пересування» та «розвиток бізнесу» були моїми навичками, і я не розумів, що деякі найуспішніші стартап-компанії витрачали на ці речі третину свого часу, і більшу частину свого часу створюють продукт і відповідають потребам клієнтів

Близько 4 років я казав собі: « Мені не потрібно вчитися кодувати. Мої таланти краще використовувати деінде ”. Звучить знайомо?  

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

Я зробив усі ці речі і наблизився до своїх цілей. Але це зайняло занадто багато часу. Звичайно, прогрес завжди повільний, звичайно, повільніший, ніж хотілося б. Але ми лише гальмуємо себе далі, не об’єктивно дивлячись на ситуацію. Навіть коли у мене були співзасновники (які врешті-решт кинули, оскільки було занадто важко або змінились життєві обставини), я виявив, що управління їх робочою етикою, очікуваннями та настроями забирало багато мого часу та сил. Це нормально - але на це ніхто не бюджетує.

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

Озираючись назад, це коштувало мені 4 років і досить великих грошей. І в кінці цього єдиним способом почати спочатку було повторити ці витрати часу, зусиль та грошей, виконуючи те саме - складаючи план, а потім відчайдушно шукаючи технічного співзасновника.

Ось ми знову ...

Проста математика часу

У 2014 році я прочитав блог Сема Альтмана, президента YCombinator. У ньому Сем говорить деякі найглибші істини, якими я колись нехтував. Ось твіт, який я викопав для розваги.

Перші два-три рази, коли я читав його твір, я наводив справді обґрунтовані аргументовані аргументи, чому це не стосується мене. Я помилився, і це коштувало мені грошей, але гірше, це коштувало мені багато часу (я повернув гроші).

В основному він стверджує, що швидше ( набагато швидше ) навчитися програмувати достатньо для побудови свого прототипу, ніж знайти надійного, надійного співзасновника, який добре підходить і піде на відстань. Не просто швидше, але ймовірність прогресу значно вища.

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

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

Аналогія датування

У старшій школі я пам’ятаю, як мені говорили, що якщо ти відчайдушно хочеш когось любити, ти будеш діяти так, щоб компрометувати себе - свої стандарти, свої цінності та свої найкращі інтереси. Ви погодитесь на людей, поведінку та ситуації, які не підходять вам.

Подібно до того, як шукати співзасновників. Із часом, а мій страх і відчай зростали, я виявив, що йду на компроміс - знижуючи свої стандарти. Переговори проти себе. Виправдання інших. Поселення.

З часом я приймав невдалі рішення і погані компроміси. На щастя, жодне з цих невдалих рішень не призвело до реальних співзасновницьких стосунків.

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

Технічні речі не закінчуються на момент запуску

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

Я важко дізнався, як моя потреба в технічній допомозі зростала після запуску. Я думав, що важкі двори збираються запускати. Хлопче, я помилився. Речі ламаються. Виникають помилки. Функції працюють не так, як очікувалося. Користувачі мають сильні погляди на речі. Ітерація - це спосіб досягнення відповідності товарному ринку. І це має бути швидко, добре скоординовано та систематично. Дані допомагають, і багато цінних даних надходить після запуску!

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

Отже, що ви збираєтеся робити, коли через 4 тижні після запуску речі ламаються, користувачі повідомляють про несподівані помилки, а сервер виходить з ладу або магазин додатків змінив якусь політику? Ви витрачаєте більше грошей. І благайте розробників поспішати. Тим часом ти робиш все можливе, щоб знайти користувачів, представити, продати тощо.

Ви витрачаєте свій час на речі, безумовно, і вони важливі. Але якщо вибрати вибір між виправленням помилки / додаванням функцій, на які вимагають ваші користувачі, та розгортанням вашого бізнес-плану потенційним насінницьким фондом, найкращим використанням вашого часу є продукт, а не висота реклами. І ви не можете цього зробити, бо не знаєте як. Отже, ви докладаєте зусиль до речей другого порядку, тому що не можете докладати зусиль для речей першочергового значення .

Розвиток технічної емпатії

Як я вже згадував у подкасті, я був (прикро) одним із тих людей, які наполягали на тому, що "це простий, швидкий прототип". Мені абсолютно, цілком, прикро, не вистачало жодної концепції того, що таке процес розробки.

Квінсі, засновник freeCodeCamp і той, хто керує подкастом, дуже добре це підсумував:

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

Уявіть, якщо хтось, хто не здогадується про вашу роботу, приходить до вас і наполягає на тому, що щось, що займає тиждень, має зайняти 2 дні - чи не хочете ви постукати їх по голові і просто з відразою відвернутися?

Мене серйозно бентежить усі часи, коли я це робив (наполягайте, що це простий додаток, а не стукати когось по голові).

Гірше того, чому вони сприймають мене серйозно? Чи справді я виявив їм повагу та відданість, хоча б намагаючись трохи навчитися їх ремеслу? З їхньої точки зору, я ховався за своїми вміннями та розумним виправданням, що кодування - " не найкраще використання мого часу ".

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

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

Як каже Сем Альтман:

"Коли такі люди кажуть:" Я зроблю все, що потрібно, щоб зробити цей бізнес успішним "(що вони майже завжди кажуть), я кажу щось на кшталт" Чому б не навчитися зламати? "

Чому б не справді. Робіть все, що потрібно. Особливо, якщо це допомагає вашому стартапу «не вмерти».

Техніка - це не все-все-все-все

Жодної миті я не думаю, що кодування є відповіддю на все. Якщо ви серед тих, у кого є зацікавлений і цілком надійний технічний співзасновник, однокласник, колега, брат чи сестра тощо, то так, це не найкраще використання вашого часу - чому? Тому що у вас є чудовий ресурс у цієї іншої людини. Тоді навчання кодуванню дублює набори навичок.

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

пріоритет = ймовірність результату за дану одиницю часу

Тому:

Знайдіть співзасновника через 6 місяців і починайте будувати на 7-му місяці: 50% ймовірність

Вивчіть достатньо коду за 6 місяців і починайте збирати з 7-го місяця: 90%

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

То чому зворотне не так очевидно?

Дайте собі довіру

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

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

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

А що тепер?

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

Я не чудовий програміст. Я не думаю, що мені потрібно (можливо, через 5 років я перегляну цю думку). Але я знаю достатньо, щоб створити власні прототипи та зрозуміти, що пов’язано зі створенням життєздатного продукту. І я знаю достатньо, щоб прийняти дзвінок щодо того, які біти передати на аутсорсинг, як описати те, що я хочу, не взяти на прогулянку, оцінити результат і об’єднатися з іншими хакерами, щоб отримати результати. Можливо, я ніколи не буду професійним розробником, і це чудово. Не про це йдеться.

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

Все це менш ніж за 12 місяців. Подумай над цим. Можливо, це найкраще використовувати свій час, якщо ви хочете стати засновником.

Постскриптум для студентів freeCodeCamp

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

Маючи це на увазі, якщо ви хочете інвестувати зі мною 3 години, щоб знайти ваш найкоротший шлях до навчання кодуванню (особливо, якщо ви хочете запустити), тоді перейдіть на сайт мого курсу та скористайтеся там формою реєстрації (не спливаюче вікно!). Якщо ви додасте до повідомлення слова “FREE MY TIME”, я дізнаюся, що ви читач freeCodeCamp, і я надішлю вам промо-код, тому що, як і ви, freeCodeCamp дав мені надійний старт.

Перегляньте відновлений підкаст freeCodeCamp, де Квінсі та Еббі використовують свій неймовірний досвід як викладачі, щоб зібрати вміст, який допоможе вам у вашій подорожі. Нещодавно я був у 53-му епізоді, і деякі речі в цій публікації висвітлені там більш докладно. Ви також можете отримати доступ до подкасту в iTunes, Stitcher та Spotify або безпосередньо з цієї сторінки.

Зі мною можна зв’язатись у Twitter: @ZubinPratap