8 вещей, которые должен уметь любой нетехнический основатель стартапа

Одна из наиболее распространенных проблем, с которыми сталкиваются начинающие предприниматели, — это развитие проекта без технических навыков. Многие думают, что без навыков программирования не стоит и браться за собственный стартап, но это не так. Алекс Тернбулл, основатель трех стартапов, не умеет программировать, но за годы работы над проектами он накопил важный опыт, который крайне важен для нетехнических основателей. В своей блоге он поделился восемью правилами, которые помогут основателям, не являющимся программистами, взаимодействовать со своими техническими подкованными коллегами. Редакция AIN.UA приводит полный перевод его заметки.

Я основал три SaaS-стартапа. Для каждого из них я не написал ни строчки кода. Вот, что я бы хотел знать с самого начала.

«Извините, но пока среди команды основателей не будет программиста, этот разговор не двинется вперед». Пытаться привлечь инвестиции, будучи нетехническим основателем, та еще задача. В ней меня часто заворачивали вежливыми репликами «у вас нет кое-чего необходимого для успеха». Спасибо за доверие, ребят.

Несмотря на то, что у меня был продукт, я не был разработчиком. И несмотря на мои усилия, у меня не было и технически подкованного сооснователя.

В мире технологий основатели без технических навыков рискуют быть названы некомпетентными.

Я видел потенциальное отношение инвесторов, сотрудников, партнеров, консультантов и даже товарищей-основателей, у которых не было доли в моем бизнесе.

Вы не можете построить software-бизнес, если вы не можете разработать software. Бред.

Несмотря на то, что нам предстоит еще долгий путь, я чертовски горжусь тем, как далеко мы зашли с Groove. Мы сделали это с отданным на аутсорс прототипом, крутой командой и тонной разных активностей. И мной, сознательно нетехническим основателем.

Все это не попытка вызвать жалость и немного уважения к нетехническим основателям в индустрии. Уважение зарабатывают, а в отрасли есть множество групп, куда более маргинальных. Но так я в третий раз стал основателем стартапа без технических навыков и научился многому по дороге. Пройденные уроки помогли мне более эффективно работать с техническими членами команды, вносить больше ценности в продукт и становиться лучшим предпринимателем. Надеюсь, и вам удастся вынести из этого что-то полезное.

Примечание: многое из написанного — отличные навыки и для технических основателей. И многие CTO, которых я знаю действительно хороши в этих направлениях. Но мой опыт показывает, что для нетехнических основателей, которые не могут внести свою лепту в программный код, эти навыки совершенно необходимы.

Навыки, которые помогли добиться успеха нетехническому основателю

1. Исследование и подтверждение

Перед тем, как основать свой первый стартап, я начал карьеру в роли помощника моего брата — финансового консультанта. Вскоре после этого я начал впадать в ступор от того, что отсутствует инструмент, который бы автоматизировал работу по взаимодействию с клиентами. Все, включая написание фоллоу-апов, обработки лидов и их отслеживания, приходилось делать вручную. Затем я подумал, что раз у меня есть такая проблема, то возможно, что и другие страдают от этого. Поэтому я сделал в PowerPoint презентацию решения, которое себе представил.

Я позвонил финансовым консультантам своего района, спрашивая, не выделят ли они мне пять минут своего времени. Затем я спросил про их личный опыт и проблемы и понял, что десятки из них разделяют мою боль. Тогда и только тогда я решил объединиться с моим техническим сооснователем и заняться созданием продукта.

Этот процесс я повторял для всех своих стартапов. Время, затраченное на раннем этапе, возвращалось ко мне сторицей, помогая создавать решение лучше, чем без предварительной подготовки.

Вывод: без способности реализовать прототип, самый простой вариант подтвердить вашу идею — поговорить с потенциальными пользователями. Вы будете удивлены, как много людей с радостью поделятся своим временем и мнением с вами.

2. Создание визуализаций

Мне повезло привлечь в команду одного из моих лучших друзей, разработчика, который только что покинул Yahoo! Прежде чем он приступил к работе, я попытался сесть и рассказать ему о всех функциях, которые, на мой взгляд, должны быть в приложении. После пяти бессвязных минут он остановил меня: «Мы не можем разрабатывать функции по списку. Давай организуем твои мысли и изобразим их на бумаге, чтобы понять, как будет выглядеть приложение». Так я и сделал.

Я начал рисовать скетчи. Они превратились в каркас приложения. Затем, в конце концов, я разобрался с Photoshop и нарисовал мокапы приложения.

Это перекрыло пропасть между мыслями в моей голове и их пониманием со стороны моего сооснователя. Такой подход позволил сэкономить нам множество времени на правках и дополнительных итерациях в будущем.

Несмотря на то, что сейчас для создания мокапов я отбросил Photoshop и переключился на Balsamiq, это по прежнему мой любимый способ показать команде, что конкретно нам нужно сделать. Например, я могу указать на часть сайта, в которой необходимо исправить ошибку:

Или я рисую каркас целой страницы, чтобы команде было проще понять ее в моем видении.

Или, если проблема в пользовательском опыте, то я запишу поведение пользователя с помощью Jing, сервиса для записи происходящего на экране, и сразу отправлю его команде. Такой подход куда более полезен нашей команде, чем любое объяснение.

Вывод: все зависит от ваших возможностей, но помните, что показывать всегда лучше, чем рассказывать. Вооружитесь хорошими инструментами для создания мокапов и записи видео с экрана, и используйте их, чтобы показать команде, что вы хотите.

3. Давайте понятную обратную связь

Когда вы говорите, а не показываете, описывайте ваши пожелания настолько подробно, насколько это возможно.

В начале работы над моим вторым стартапом мы пытались создать страницу входа в учетную запись для пользователей и процесс двигался очень туго. «Форма должна быть больше и нам нужно меньше навигационных ссылок», — писал я в письме руководителю разработки. Если у вас есть опыт в разработке продукта, то вы недовольно трясете головой. «Без проблем», — отвечал программист и присылал слишком большое поле, где не хватало критически важных ссылок. Этот танец мы плясали днями: сперва я расплывчато просил об изменениях, затем он исполнительно присылал мои правки.

Наконец я решил, что с меня хватит. «Господи, почему мы убрали ссылку на домашнюю страницу?», — недоумевал я. «Ты же сказал, что хочешь меньше ссылок», — отвечал разработчик. Так и было.

Следующим утром у нас была длинная дискуссия, которая мне невероятно помогла. Я понял важность четкой и понятной обратной связи. В конце концов, если бы кто-то прислал мой пост из блога с замечанием «текст должен быть покороче», я бы тоже потерялся.

Теперь вместо «поменьше навигационных ссылок» я пишу: «Давай уберем ссылки на разделы «О нас», «Контакты», «Функции» и увеличим размер кнопки на 20%». Работа начала происходить значительно продуктивней.

Вывод: нет никакой объективной причины давать расплывчатую обратную связь. Это замедляет команду, порождает непонимание и вредит продукту. Выражайтесь ясно, четко и прямо.

4. Предпродажи

В первом стартапе, пока мой друг трудился над кодом, я сидел на телефоне. Я обзвонил более тысячи финансовых консультантов по всей стране, и так же, как я делал на более ранней стадии, спрашивал в чем их боль. Это дало мне невероятное понимание проблем наших клиентов, что помогло в разработке. Но это также дало мне кое-что, серьезно увеличившее наши шансы на успешный запуск.

Во время этих разговоров, услышав, что агент ненавидит писать фоллоу-апы вручную, я говорил ему: «Просто чтобы вы знали: мы разрабатываем инструмент, который автоматизирует все это. Он будет делать X, Y и Z. Когда он будет готов, я бы хотел показать его вам и получить обратную связь. Вы не против?» Такая стратегия дала нам сотни горячих лидов и десятки платящих пользователей в первые недели запуска.

Вывод: вы можете начать продавать даже до того, как у вас будет продукт на продажу. На самом деле, пока ваш продукт разрабатывается, это один из лучших вариантов использовать свое время.

5. Продажи

Я пришел к выводу, что моя работа, как нетехнического основателя, больше всего состоит в продажах.

Хотите привлечь инвестиции? Нужно связаться с инвесторами, которые видят сотни питчей каждую неделю, и убедить их, что ваша компания достойна ставки.

Хотите продать продукт? Вам надо связаться со своими пользователями и полностью понять их проблемы, надежды и страхи.

Хотите нанять лучших специалистов? Вам нужно найти талантливых кандидатов с различным опытом, понять их цели и показать им, почему ваша компания — наиболее подходящее для них место.

Хотите подписать договор с выгодным партнером? Надо поговорить с человеком, с которым вы ищете сделки, выяснить, что он хочет, и убедить его, что вы сможете помочь.

Хотите эффективно управлять? Надо быть на связи с командой и удерживать набор показателей на высоте: счастье, продуктивность, препятствия, цели и распорядок. Список можно продолжать бесконечно.

Продажи — навык, который можно изучить. Пара моих любимых книг, которые помогли мне, это «СПИН-продажи» Нила Рекхэма и «Да!» Ноа Голдстайна, Стива Мартина и Роберта Чалдини.

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

Вывод: главная работа нетехнического основателя — развивать бизнес через привлечение новых клиентов, найм и управление. Развивайте навык взаимодействия с людьми благодаря регулярной практике.

6. Чирлидинг

В каждом из трех моих стартапов мне приходилось натыкаться на людей, которые говорили мне, что я ничего не понимаю, ведь я не разработчик. Честно говоря, скептики — проблема, с которой сталкиваются все основатели. Они приносят больше всего неприятностей, когда бьют по проблеме, которая действительно есть. Например, когда говорят, что вы не разработчик.

Я научился быть своим собственным чирлидером, чтобы мотивировать себя пробиваться через стену скептицизма и ФОКУСироваться на вещах, которые важны. А затем я научился быть чирлидером для всех остальных.

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

Пример чирлидерства для пользователей — письмо, которое я отправил пользователю, когда наш сервис оказался временно недоступен.

Тема: Апдейт по статусу Groove

Привет, Алекс!

Хотел поделится коротким апдейтом о работе нашей команды над решением проблемы с сервером, которая возникала этим утром. Мы стремимся наладить работу Groove на 100%.

По состоянию на 15:00, мы успешно перезапустили шесть из семи серверов, которые пострадали от ошибки Amazon/Engine YARD:

• Начисление оплаты работает на 100%
• Отправка и получение email работают на 100%
• Сервер с чатом поддержки все еще не работает. Мы стараемся востановить его и рассчитываем, что чат заработает в течение часа.
• Функция обновлений Groove в реальном времени, которая находится на том же сервере, что и чат, также не работает. Мы ожидаем вернуть ее в течение часа. Тем временем, обновление страницы обновит письма и все изменения.

Спасибо, что остаетесь с нами, пока мы работаем над восстановлением Groove, и примите мои извинения за сегодняшнюю неисправность.

Я пришлю свежий апдейт, как только чат и обновления приложения снова заработают.

Как всегда, вы можете написать мне напрямую на почту [email protected] с любыми вопросами или пожеланиями.

Алекс,
СЕО Groove

Если делиться с командой каждой маленькой победой, это может повысить их моральный дух и мотивацию.

Так как я не могу ринуться исправлять баги на сервере, поддержка коллектива и пользователей — лучшее, что я могу привнести в такой ситуации.

Вывод: ваша работа — быть собственным чирлидером и поддерживать свою команду и пользователей. Это будет держать вас в здравом уме, мотивацию команды на должном уровне, а ваши пользователи будут счастливы и лояльны.

7. Умейте работать с инструментами разработчиков

Как и каждый из нас, разработчики используют инструменты, которые помогают им выполнять им работу лучше и проще. Чтобы не отвлекать людей от рабочего процесса и не тормозить разработку продукта, мне пришлось научиться пользоваться этими инструментами.

Каждая команда будет использовать разные инструменты. Вне зависимости от предпочтений вашего коллектива, если вы знаете как с ними работать, это поможет всей команде.

Когда я нахожу небольшой баг, я не шлю письмо, отвлекая разработчика от работы. Я пишу подробную пользовательскую историю и отправляю ее в Pivotal Tracker, который направляет мой фидбек в рабочий процесс разработчиков без лишнего отвлечения.

Чтобы научиться работать с большинством инструментов, не требуется много времени (например, у Pivotal Tracker есть отличные видеоинструкции), но это усилие станет одним из серьезных факторов успеха вашей команды.

Вывод: не пытайтесь заставить команду разработчиков пользоваться вашими инструментами. Они, вероятно, созданы не для программирования. Вместо этого, упростите процесс взаимодействия и сделайте жизнь вашей команды проще, научившись обращаться с их инструментарием.

8. Делайте «все остальное»

Я научился бывать в тысяче ролей. Нам нужно создать таблицу и найти контакты для повышения вовлечения нашего блога? Это моя работа. Нужно найти подходящее приложение, чтобы делиться скриншотами разных версий продукта? Уже ищу. Разработчику необходимо, чтобы я связался с поддержкой Pivotal Tracker и выяснил, почему у нас не синхронизируются обновления? Письмо уже ушло!

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

Вывод: эго здесь не место. Ваша работа — делать абсолютно все, на что нерационально тратить время разработчиков. Иначе вы рискуете ростом вашей компании.