Мультимедийные презентации

Интерактивный маркетинг

	iPhone-приложение «Детская Афиша» (разработчик: КСАН)
	«Как мышка играла в мячик» — iPad-приложение для детей от 1 до 2 лет! (разработчик: КСАН)

Все примеры интерактивного маркетинга

Рассылка «Prezentation.Ru»

Новости

Статьи

Фестивали, конкурсы

	Vimeo Festival Awards. Конкурс видео-роликов
	YourFilm Festival — 2012. Кинофестиваль Видеопортала YouTube. Победители поедут в Венецию.
	Международная конференция #1 по социальным играм в Восточной Европе Sociality Rocks!

Все конкурсы

Полезная реклама

На главную страницу  |  Прислать новость
Интерактивный маркетинг  |  Мультимедийные открытки  |  Виртуальные туры  | 

НОВОСТИ  |  Статьи  |  Интервью  |  РАССЫЛКА

Самые трудные уроки для стартапов, часть I

Версия для печати

[10.06.06]

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

Мы уже проинвестировали довольно много компаний, так что я научился выявлять такие идеи — и именно на них я и буду акцентировать внимание. К тому же я собираюсь их пронумеровать, и, может быть, со следующими стартапам мне удастся внедрить разновидность кода Хаффмана: я заставлю всех прочитать это эссе, а затем, вместо того, чтобы донимать их детальным изложением, смогу просто сказать: номер четыре!

1. Выпускайте рабочую версию как можно раньше

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

Быстрый выпуск первой версии оправдан по ряду причин. Во-первых, просто потому, что это оптимальный метод программирования, и не только для стартапов. Я утверждаю это с 1993 года и до сих пор не встречал особых тому опровержений. Множество стартапов погибло из-за того, что они слишком затягивали релизы, и ни один — благодаря тому, что выпускал продукт слишком быстро. [1]

Одно из неожиданных открытий, которое вас ждет, если вам удастся создать нечто популярное — это то, что вы не будете знать своих пользователей. У Reddit сейчас почти полмиллиона уникальных посетителей в месяц. Кто эти люди? Команда Reddit понятия об этом не имеет. И ни один web-стартап этого не знает. А поскольку вы не знаете своих пользователей, то очень рискованно пытаться угадать,что им понравится. Гораздо лучше выпустить нечто и прислушаться к их мнению.

Wufoo восприняли этот мой совет близко к сердцу и выпустили генератор форм еще до создания базы данных. Машина еще не ездит, а уже 83 тысячи человек пришли посидеть в водительском кресле и подержаться за руль. Подобный подход дал Wufoo ценную обратную связь: пользователи Linux жаловались на излишнее использование Flash, поэтому разработчики избавились от Flash, переписав программу. А вот если бы они решили выпустить все сразу, то к моменту обнаружения проблемы она была бы внедрена уже гораздо глубже.

Но даже если у вас не будет пользователей, быстрый выпуск все равно важен. Первый выпуск для стартапа — все равно что спуск корабля на воду. Если есть серьезные проблемы, например, слабая идея или взаимная неприязнь основателей — стресс выпуска первой версии их проявит. А чем раньше вы обнаружите такие проблемы — тем лучше.

И, пожалуй, самый главный аргумент за быстрый выпуск состоит в том, что он заставляет вас больше работать. Когда вы работаете над еще не выпущенным продуктом, появление проблем вызывает любопытство. Но их появление в уже выпущенном продукте вызывает сильную тревогу. Как только вы выпустите продукт, у вас появится намного больше безотлагательных задач. Мне кажется, что именно поэтому разработчики затягивают выпуск, они знают: как только он состоится — им придется работать гораздо больше. [2]

2. Продолжайте наращивать возможности

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

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

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

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

И это не только хорошая методика разработки, но и маркетинговый ход. Пользователи любят постоянно улучшающиеся сайты. Ведь на самом деле они ждут от сайта улучшений. Представьте: вы посетили очень хороший сайт, затем вернулись через два месяца, а он ни на йоту не изменился. Разве он не покажется вам никудышным? [3]

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

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

Как только продукт избавлен от вопиющих недостатков, вы начинаете к нему привыкать и постепенно отождествляете его с набором уже реализованных в нем возможностей. Например, я сомневаюсь, что кто-нибудь в Yahoo! (или Google) осознавал, насколько лучшей может быть web-почта, пока Paul Buchheit им это не продемонстрировал.

На мой взгляд, решение заключается в понимании, что все сделанное до сих пор еще далеко от того, что может быть сделано. Заставьте себя, в качестве умственного упражнения, постоянно думать над усовершенствованиями. Имеющееся, конечно, уже и так совершенно, но если бы вам пришлось что-то изменить, что бы это было? Если ваш продукт кажется вам завершенным, на то могут быть две причины: (а) он действительно завершен, или (б) вам недостает воображения. Опыт подсказывает, что вариант (б) в тысячу раз вероятнее.

Пол Грэм,
Internet.Ru

Подписка на рассылку «Prezentation.Ru»

Поиск на сайте:

Copyright © 2004-2012
Prezentation.Ru
Мультимедиа. Интернет. Будущее

е-мейл:
news@prezentation.ru