Разработчики становятся разработчиками по многим причинам, но всех их объединяет одно: они любят строить. Задолго до того, как они начнут зарабатывать на жизнь, разработчики напишут код для решения проблем и создадут продукты для чистого процесса построения.
В определенный момент каждый разработчик, вероятно, создал что-то, что заставило их думать, что у них есть потенциальная идея для стартапа. Затем они должны решить, хотят ли они построить что-то еще: бизнес.
В подкасте Decoded Филип Томас рассказал нам о том, как сделать этот выбор и как мало общего между строительным кодексом и построением компании. Томас — вице-президент по продуктам и инжинирингу в Zyper. До своей нынешней должности он основал сообщество разработчиков Moonlight, которое было приобретено PullRequest.
Для разработчиков, которые хотят стать основателями, Томас говорит, что ключом к успеху не обязательно будет навык, с которого вы начали. Технические основатели должны знать, когда снять шляпу разработчика, а когда надеть бизнес-шляпу.
«Если вы начинаете бизнес, вам нужно быть готовым больше не писать код в течение пары лет. Ваша ценность для компании заключается не в написании кода; ваша ценность будет исходить от управления людьми, от определения видения, от установления стандартов исполнения, от сбора денег. Ваши навыки программирования не обязательно будут тем, над чем вы будете работать в долгосрочной перспективе».— сказал Томас.
Клиенты важнее кода
Когда вы разработчик, идей пруд пруди. Так как же узнать, стоит ли развивать идею продукта в бизнесе? Вместо того, чтобы тратить время на уточнение идеи и создание кода, потратьте это время на понимание проблемы, которую вы пытаетесь решить. Томас начал Moonlight как прототип без кода, который был не более чем целевой страницей, созданной на Squarespace, что позволило ему протестировать идею с клиентами.
Это может показаться нелогичным для разработчиков, которые привыкли писать код и не решаются выпускать что-то, пока оно не станет идеальным. Но один из самых важных уроков, которые Томас усвоил при создании Moonlight, заключается в том, что решение никогда не имеет такого значения, как проблема пользователя.
«Пользователи будут использовать полностью сломанный инструмент, если он действительно решает проблему. На самом деле опасность не движется слишком медленно, она движется в неправильном направлении, потому что, если вы двигаетесь слишком медленно, это можно исправить. Но если вы движетесь в неправильном направлении, это действительно трудно исправить ».
Поиск правильного фокуса
Чтобы стать успешным основателем, Томас предлагает четыре следующих совета:
- Сделайте код товаром. Слишком много разработчиков тратят время на то, чтобы сделать свой код максимально эффективным и красивым. Однако Томас предлагает рассматривать ваш код как товар, который может написать любой, а не только вы. Это поможет вам тратить меньше времени на совершенствование кода и больше времени на пользователей.
- Уделите время программированию. Вы строите бизнес, а не просто продукт. В своем запуске Томас запланировал два дня в неделю, когда он не касался кодовой базы. «Проведите день, разговаривая с покупателями, исследуя цены, пишите электронные письма о продажах», — сказал он. «Это действительно важно для основателя, если он технический».
- Читайте, смотрите, учитесь. Есть миллионы книг, видео и сообщений в блогах, в которых даются советы по запуску. Узнайте как можно больше, чтобы избежать простых ошибок. Не забудьте вернуться к просмотру материала, который вы прочитали ранее, так как он будет иметь больше смысла, чем дальше вы продвинетесь в своем пути к запуску.
- Станьте основателем по правильным причинам. Если вы становитесь основателем только для того, чтобы разбогатеть, вы можете быть разочарованы. «Самый богатый человек, с которым я работал, был одним из первых сотрудников большой компании. Мои друзья-основатели по большей части — мои самые бедные друзья », — отмечает Томас. В течение первых нескольких лет работы вашей компании вам, возможно, придется сильно сократить зарплату, поскольку продукт не приносит почти никакой прибыли, сотрудникам нужно платить, а инфраструктуру нужно строить. Примите процесс, а не только пункт назначения.