Джефф Миллер, разработчик, автор кулинарного социального стартапа 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