Джефф Миллер, разработчик, автор кулинарного социального стартапа Punchfork, решил поделиться списком типичных отвлекающих факторов для тех, кто начинает работу над собственным стартапом. Редакция AIN.UA представляет его публикацию в переводе на русский язык.

Основное отличие между запуском совершенно нового стартапа и работой над проектом, которому уже исполнилось пару лет, – это качество, с которым вы выбираете свои цели и тратите свое время. Каждый день начинается с тысячи потенциальных “открытых дверей”: какую из этих “дверей” вы изберете, чтобы добиться наибольшего продвижения в своем проекте и поставленных задачах? Выбор точной цели и направления состоит в том, чтобы сфокусироваться на чем-то одном и пренебречь остальными “возможностями”. Такой навык – один из критически важных в работе над стартапом.

По мере того, как проект становится зрелым, на мой взгляд вполне нормально пересматривать свои навыки в умении фокусироваться на конкретной задаче и ради нее игнорировать всё остальное, на что тратится время в текущем моменте. Умение фокусироваться определяется очень многими вещами и факторами. Может, вам стоит сосредоточиться на том, сколько на ваш сайт приходит пользователей, какой фидбек вы получаете, какая доля рынка. Или же вы найдете для себя определенный набор ролевых моделей, которые помогут в таргетировании проекта. Или же вы сосредоточитесь на метриках проекта и их оптимизации.

Если учесть опыт прошедших 6 месяцев в работе над собственным стартапом, я могу сказать, что просто в шоке от того, как ужасно я распоряжался собственным временем у умением избрать цель для фокусирования. Я каждый день тратил кучу времени на то, что никакой пользы не приносит моему бизнесу и моему проекту. Мне казалось, что всё круто продвигалось в краткосрочных проектах (продолжительностью в 1-2 недели), и что отвлекающие факторы там не вредили мне, а наоборот делали процесс легким и веселым; но тут я обнаружил, что потерял уйму времени на всё в целом. Я просто не был в достаточной мере сфокусированным. Оглядываясь назад, я могу выделить ряд отвлекающих факторов – своего рода “убийц времени” для нового проекта.

Вот ряд таких вещей, действий и событий, на которые я теперь ни за что на свете не стал бы тратить свое время:

1. Доступ только по приглашениям

Инвайты – традиционная стратегия веб-проектов для того, чтобы привлечь внимание, подогреть пользовательский интерес и управиться с масштабами аудитории при запуске проекта. В моем случае, запуск доступа только по инвайтам привел к тому, что ряд пользователей были недовольны тем, что слишком долго “висят” в списке ожидания. Теперь это покажется странным, что я так долго умышленно задерживал их в списке ожидания, но в то время я думал, что чем дольше пользователь ждет своего инвайта, рассылая приглашения другим, тем выше “вирусный” эффект. Кроме того, разработка и внедрение всех компонентов системы, работающей только по инвайтам, забрали у меня немало времени в общем графике разработки проекта.

2. Измерение трафика в реальном времени

В работе над своим проектом я прошел через стадию, когда использовал GoSquared (а до того – Chartbeat), чтобы отслеживать аудиторию пользователей моего веб-приложения в режиме реального времени. Я мог ежесекундно видеть, сколько пользователей приходит на мой сайт, из каких они стран и регионов, какие страницы они просматривают и т.д. Целая куча подробных метрик крутились перед моими глазами. И конечно же, я тратил свое время, просматривая показатели в Панели администратора по 10 раз в день, чтобы убедиться, что трафик растет и т.д. Теперь я попросту игнорирую статистику в реальном времени и просто пользуюсь Google Analytics для слежения за общим трендом и просмотра показателей в разрезе определенного периода, а не за каждую минуту или за каждый час.

3. Панель администратора для работы с пользователями

Еще одна бессмысленная штуковина, которую я “наворотил” в собственном проекте, – это классная подробная Панель администратора, с помощью которой я мог просмотреть данные по всем зарегистрированным пользователям, откуда они приходят, какие профили в социальных сетях привязаны к их учетным записям, как согласованы эти данные с их биографическими данными и т.д. Например, если некий Фред зарегистрировался в моем приложении при помощи своего профиля в Facebook, я мог также увидеть его профиль в LinkedIn, ленту его сообщений в Twitter, его фото и личные данные. Изначально предполагалось, что такая панель администрирования поможет выбрать наиболее активных и влиятельных пользователей, чтобы наладить с ними взаимодействие; но на это у меня вечно не хватало времени. А после того, как число пользователей перевалило за пару тысяч, работать с такой панелью стало просто нереально.

4. Эксперименты с рекламой на ранней стадии работы проекта

Я так спешил монетизировать проект, что утыкал рекламными ссылками всю главную страницу еще тогда, когда у меня было всего пару тысяч уникальных пользователей в сутки. Не пойму, почему я удивился, что только пару десятков человек кликнули на текстовые рекламные блоки и ссылки. Это был для меня толковый урок насчет того, что значит низкий показатель CTR. Стоит сначала наладить поток аудитории и привлекать по-настоящему большое количество пользователей, прежде чем всерьез браться за монетизацию (так вы, кстати, и толковых рекламодателей сможете привлечь).

5. Amazon и ее партнерские ссылки

Еще один эксперимент в плане монетизации проекта, который не стоило делать и тратить на него свое время, – это ни на чем не основанная уверенность, что посетители моего сайта захотят купить кулинарные путеводители и книги рецептов, пока будут просматривать мой сайт. Построение системы реферальных ссылок на страницах сайта тоже угробило пару дней моего времени: мне понадобилось изучить особенность работы с Amazon Affiliate API, переписать код, чтобы кулинарные книги и ссылки на них были привязаны к рецептам на страницах сайта и т.д. А в итоге уровень прибылей составил не более $1 в день. Еще никто из тех, кто работает над собственными стартапами, насколько мне известно, не смог заработать серьезных денег на партнерке от Amazon.

6. TechCrunch

Этот ваш TechCrunch – классная площадка, чтобы тебя заметили инвесторы и сообщество разработчиков, но на собственном опыте я убедился, что реальной практической ценности от этого нет ни грамма (ну может, есть толк в плане SEO). Жаль, что я потратил столько умственных усилий и времени, чтобы выяснить, как бы мне так сделать свое приложение и сайт, чтобы обязательно обо мне написали в TC. И когда я наконец-то этой цели добился, то трафик со статьи в TechCrunch оказался ошеломляюще низким. Мне бы стоило сконцентрироваться не на техноблогах, а на ресурсах, которые куда интереснее и понятнее для широкой аудитории – вроде тех же LifeHacker и kottke.org; это бы принесло мне в сто раз больше новых пользователей, чем публикация в TC.

7. Партнерские проекты со сторонними ресурсами

Как-то раз я потратил недели две на то, чтобы написать кастомный прототип на базе своего API в рамках потенциального партнерского проекта с участием одной сторонней компании. Это партнерство в итоге так ничем и не кончилось: мы даже не запустили тот проект. Ничего особо странного в этой нет: иногда надо поиграться, рискнуть, попытаться выгадать что-то на пути к реализации большого проекта и достижению своей цели. Но 2 недели личного времени разработчика – довольно большая ценность на ранней стадии развития стартапа. Мне надо было бы сказать “Нет, спасибо, я конечно ваше предложение ценю, но откажусь” – и потратить лучше эти 2 недели на дальнейшую “полировку” своего собственного продукта, а не на запуск совместного продукта с партнером.

8. Предложения пойти попить кофе и “пересечься по важному вопросу / интересному предложению”

Может, это прозвучит странно, но я никак не ожидал, что предложения “быстро встретиться и обсудить за чашкой кофе” могут быть таким мощным “убийцей” моего личного времени. Такой звонок и такая встреча как правило никогда не соответствуют ожиданиям: встреча длится дольше, чем “пару минут”, в итоге вы на нее ухлопали весь день, продуктивность ваша упала раза в два, потому что вам понадобится еще потом фокусироваться и возвращаться обратно к работе (особенно это непросто, если вы на полдороги бросили писать код, а потом его надо писать дальше). Важно сосредоточиться только на тех встречах, которые по-настоящему могут добавить ценности вашему проекту или завязать ценное знакомство со специалистом, которого вы планируете привлечь к работе над стартапом, вместо того, чтобы знакомиться с кучей народа, который только и делает, что “полощет” вам мозги исключительно в собственных целях.

9. Сторонние проекты

Сторонние проекты – “еда на вынос” для кодеров. На мой взгляд, сторонний проект нужен разработчику, чтобы поработать над ним немного то тут, то там, в разной обстановке и в разное время, чтобы “не перегореть” на основной работе и переключить внимание. Но увы, был период, когда я просто набрал кучу сайд-проектов, которые “сожгли” всё мое время, и я просто забросил основной свой стартап. Пожалуй, попасть в эту ловушку – легче легкого, когда ваша компания – новая, но ей не пару дней от роду, а уже прошел какой-то срок с момента запуска. Лучше просто всё остальное отодвинуть на задний план, а сосредоточиться на своем основном проекте.

10. Работа над проектом дома

Первый  год я провел, работая над своим стартапом в режиме home-office. После этого я просто взял и арендовал стол в коворкинге в деловой части Пало-Альто. Уровень продуктивности в работе в условиях офисного пространства легко вырос в 2-3 раза по сравнению с тем временем, когда я работал дома. Не могу толком объяснить, в чем тут дело, но уверен, что дома есть своего рода психологический барьер и отвлекающие моменты, которые мешают мне целиком концентрироваться на проекте, когда я работаю в домашних условиях. Если бы однажды я начал работать над проектом в офисе с самого начала, то вполне вероятно, что продвинулся бы куда дальше за эти 6 месяцев.

Конечно, критиковать с высоты прожитого легко, но полагаю, что большинство этих ошибок – типичны для стартап-предпринимателей. Если избежать этих “убийц времени”, то можно добиться большей результативности: все эти ошибки отвлекали меня от реализации единственно эффективной стратегии – четкого развития продукта по итерациям, получения отзывов и работы с аудиторией и дальнейшей работы над тем, чтобы сделать продукт по-настоящему классным.

Источник: TalkFast