- Были ли у вас технические проблемы при создании стартапа?
- Вы всегда расстраиваетесь, когда вам приходится писать код для вашего стартапа?
- Ты собираешься сдаться?
Ну не надо.
Ваш случай не специфический.
Вот почему YCombinator подготовил это удивительное мышление/стратегию, чтобы сделать вас успешным основателем технического стартапа.
YCombinator (YC) — известный акселератор стартапов. Они обеспечивают начальное финансирование, наставничество и ресурсы для компаний на ранней стадии. Благодаря своей интенсивной программе YC помогает предпринимателям создавать и масштабировать свои предприятия.
Погружайтесь и процветайте…
Кто является техническим основателем?
Технический основатель — это тот, кто занимается технической/научной стороной стартапа. Их роли включают создание продукта и общение с пользователями.
На ранних стадиях стартапа роль технического основателя выглядит как роль ведущего разработчика в такой крупной компании, как Google. Вы внедряете инновации, строите и распространяете. Это также похоже на главного разработчика в проекте с открытым исходным кодом.
Вы делаете все технологические выборы.
Но есть несколько ключевых отличий:
- Это стартап, поэтому нужно учиться и делать все: фронтенд, бэкенд, DevOps, разный софт.
- Вы привыкнете создавать достаточно хороший продукт, а не идеальный. Это для того, чтобы вы могли двигаться быстро.
- Вы освоитесь с техническим долгом и неэффективными и грязными процессами.
На начальном этапе вы стремитесь к успеху. Делать все, что нужно, чтобы продукт работал.
Как строить на каждом этапе
Этап 1: Идеи
Теперь у вас есть идея.
Цель здесь состоит в том, чтобы построить прототип как можно скорее.
Что-то, что вы можете продемонстрировать пользователям. Он не должен работать полностью.
Ваш генеральный директор/соучредитель одновременно будет искать клиентов, которым можно показать прототип.
Здесь принцип построить очень быстро за считанные дни!!!
Создание прототипа за один день.
Как?
Используйте программное обеспечение для прототипирования, такое как Figma или Envision. Что-то, на что пользователи могут нажимать и взаимодействовать
Была компания, оптимально. Он был основан кем-то, кто возглавлял аналитику кампании Обамы. Они пришли в YC с другой идеей, но она не сработала, поэтому они собрали прототип за считанные дни. Их прототипом был всего лишь визуальный редактор с файлом Javascript для запуска A/B-тестов. Этого было достаточно, чтобы показать их потенциальным клиентам.
В зависимости от сложности проблемы, которую вы решаете, ваш прототип может занять больше времени.
Примером может служить компания Эшер. Они работали в дополненной реальности, поэтому им потребовалось несколько недель, чтобы получить прототип. Им нужно было заставить алгоритмы компьютерного зрения работать на мобильных телефонах.
Прототип избавляет вас от объяснения теории, которую никто не видит.
Популярные ошибки:
- Перестройка.
- Не слушая клиентов.
- Не слишком привязывайтесь к идее. Пример оптимизации
- Представление теории вместо практического прототипа.
Этап 2: этап MVP
Цель здесь — построить что-то быстро, в течение нескольких дней или недель. Месяцы также могут быть разрешены в крайних случаях, таких как AR, AI и т. д.
Вы хотите создать MVP, который получит приверженность клиентов.
Настоящая приверженность заключается в том, чтобы заставить их платить, а не в обещаниях или листах ожидания.
Ваш прототип должен выйти, пока вы создаете MVP. Это должно быть то, что приносит вам списки ожидания и обещания.
В: Является ли найм хорошей идеей на этапе MVP?
Это зависит, но в основном это плохо.
Почему?
- Это замедлит вас. Вы должны потратить некоторое время, чтобы найти правильно настроенных и правильный уровень инженеров.
- Вы будете создавать пробелы в знаниях между вами и продуктом.
Примером может служить Justin TV/Twitch, у которого было 4 соучредителя. Джастин Кан, Эммет Шир, Кайл Фогт и Майкл Сейбел. Кайл создавал потоковое видео, Эммет работал с базой данных, а Джастин работал в Интернете.
Этого им хватило для запуска, после чего наняли. Но они пошли на неудачников. Они пошли для людей, отклоненных Google. Они выбрали людей, которые могли наброситься на проект и были готовы участвовать в гонках.
Принципы этапа MVP
#1. Делайте то, что не масштабируется.
Пока не беспокойтесь о масштабировании.
Ручная регистрация, ручное редактирование базы данных для добавления пользователей и записей, сумасшедшая поддержка клиентов. Все это пока разрешено.
Просто прочитайте историю MVP от Stripe. Они вручную заполняли банковские формы запросами, сделанными на их уродливом веб-сайте с помощью своих API. Это было не масштабируемо, но позволяло им оставаться в живых достаточно долго, чтобы стать масштабируемыми.
#2 Создайте решение 90/10.
Всегда старайтесь выполнить 90% того, что вы хотите, всего за 10% работы/усилий/времени. — Пол Бучиетт, изобретатель Gmail.
Создайте что-то, что работает. Разрубите этот большой стартап до основания, затем разрубите его еще раз и постройте то, что осталось. Возможно, вам придется переписать всю кодовую базу позже. Ничего страшного.
Хорошим примером является Door dash, MVP которого был просто статическим веб-сайтом HTML/CSS. У них был номер телефона одного из основателей на сайте. Бэкэнд был формой Google. Они согласовывали заказы с документами Google. Они использовали найти моего друга на iPhone, чтобы отслеживать водителей.
Хреново но сработало.
Выбор стека технологий
#1 Сбалансируйте то, что имеет смысл для вашего продукта и технических знаний.
Выберите то, что позволит вам двигаться быстро. Не выбирайте какую-то новую модную чепуху. Я сделал это, пытаясь создать свой первый SAAS, и я обжегся.
#2 Выберите свой технический стек для скорости итерации.
Используйте сторонние библиотеки.
- Auth0 для аутентификации
- Полоса для оплаты
- React нативный для кросс-платформы
- AWS, Vercel, GCP для облака
- Webflow для целевых страниц
- Firebase или Lambda для серверной части
Вам пока не нужно создавать собственные решения для этих нужд. У стартапов заканчиваются время и деньги, потому что они пытаются построить все с нуля.
Люди жалуются на масштабируемость и затраты. Но сейчас не время беспокоиться о масштабировании. Если вас беспокоят затраты, существует множество альтернатив с открытым исходным кодом/фримиум/бесплатный уровень.
Вы даже можете написать вонючий код. У вас будет время решить ее позже.
Facebook изначально был построен на PHP, который на самом деле не масштабируется. После достаточного роста они создали транспилятор, который помог им конвертировать PHP в код C. Это решило их проблему со скоростью.
#3. Единственные технические решения, которые имеют значение, связаны с обещаниями ваших клиентов.
Эшер действительно выбросил большую часть своего кода и переписал его. Они пообещали своим клиентам поддерживать работу API и плагинов Unity Engine. Они выполнили свои обещания, не касаясь тех, что были переписаны в их коде.
Этап запуска
Цель — провести итерацию, чтобы продукт соответствовал рынку.
#1 Быстрая итерация с достоверными и программными данными
Жесткие данные — это данные, которые вы фактически отслеживаете на панели инструментов или в электронной таблице.
Мягкие данные — это данные из разговоров о вашем продукте. Это могут быть клиенты или инвесторы.
Убедитесь, что у вас есть аналитическая панель, отслеживающая достоверные данные. Сделайте приборную панель простой. Выбирайте по скорости. Просто используйте Google Analytics.
Объедините реальные и мягкие данные, чтобы узнать, почему ваши пользователи остаются или уходят.
Узнайте, какие новые проблемы возникают у ваших пользователей, и решите их в первую очередь.
Хорошим примером является WePay, который был стартапом платежных решений B2C. У них были все функции B2C, обмен сообщениями и т. д., но их пользователи ими не пользовались. Их основным пользователем тогда был GoFundMe, который также сказал им, что им нужен только платеж. Основатели увидели в этом возможность перейти к продукту API, и именно так они добились соответствия продукта рынку.
#2 Запускайте постоянно.
Segment — это решение для аналитики в классе. Они начали с только плагина Google Analytics. Они решили прислушаться к своим пользователям и начали добавлять поддержку Node, PHP, WordPress и т. д.
Они запускались каждую неделю. В итоге они вышли за 3 миллиарда долларов.
#3 Создание баланса по сравнению с исправлением.
Освойтесь с техническим долгом.
Возможно, вам придется создавать больше, чем исправлять ошибки.
Примером может служить PokemonGo, который был запущен в 2016 году, и пользователи даже не могли войти в игру. Даже это их не убило.
У них был баг. Их архитектура просто не была готова к тому количеству пользователей, которое получила игра. Как будто они подверглись DDOS-атаке. Им потребовался месяц, чтобы набрать такое же количество активных пользователей, на которое у Twitter ушло 10 лет. Это напрягло их архитектуру, но они все же преуспели.
На самом деле, в прошлом году они заработали более миллиарда долларов дохода.
На изображении ниже показаны ошибки, допущенные на этом этапе.
Как развивается роль?
Это когда вы строите для масштабируемости.
Это когда переписывание кода и оптимизация вступают в игру.
В это время техника сломается из-за спроса на нее.
Вам решать, какой будет инженерная культура.
Краткое содержание
Следите за моей работой
📰 Подпишитесь на мою [внешнюю среду] Информационную рассылку, чтобы получать мои статьи бесплатно или получать обновления, когда я публикую.
🔗 Получите членство по моей реферальной ссылке.
С докладом выступила партнер YC Group Дайана Ху. Она была техническим директором своего стартапа: Escher Reality, который был приобретен Niantic (создатели PokemonGo). Она была директором по технике.
