Эффект первого пользователя

в 9:30, , рубрики: Анализ и проектирование систем, пользователи, Программирование, метки:

При запуске нового продукта всегда наблюдал один интересный эффект, который осознал и стал учитывать только в последние пару лет:

«Эффект первого пользователя» или «Бойтесь пользователей, фидбек приносящих».

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

Редко, когда кто-то общается с потенциальными клиентами до первой версии. Кто-то — боится конкуренции, кто-то — самоуверенно считает, что «он и так все знает», кто-то — витает в облаках, кто-то — просто испытывает удовольствие от создания продукта и до пользователей ему дела нет.

В день первого публичного релиза вы получаете фидбек. Иногда — очень много фидбека, особенно если продукт бесплатный или free-to-try. И вот тут-то начинается самое интересное:

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

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

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

Лекарство? Желательно представлять направление развития продукта еще до его первого релиза. Ну и настаивать на своем, если это важно для вас. Реализовывать только тот функционал, который запланирован именно вами, а не «свалился с неба» от первого случайного человека.

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

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

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

Чтобы не быть голословным, приведу пару примеров из моей практики:

1. SEO Note — бесплатный органайзер. Изначально задумывался как органайзер для сео-шников и маркетологов. Опыта тогда было мало, поэтому вместо концентрации на определенном, достаточно узком наборе функцонала мы кинулись реализовывать все, что люди попросили.

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

2. TheDowser — продукт для исследования ключевых слов. Совершил ту же ошибку: вместо концентрации только на тех, кому нужно исследовать ключевые слова, пытался впихнуть все, что люди попросят. Ну и то, что мне казалось «нужным». В общем, пытался «угадать» пользователя.

Итог? Год потерянного времени, мизерные продажи, отсутствие таргетированной рекламы. Успешный запуск состоялся только тогда, когда новые партнеры убедили меня порезать весь функционал, кроме исследования ключевых слов. В итоге первый же публичный релиз обновленного продукта принес $70,000 (в 2004 году, кажется) за 5 дней.

Основная рекомендация: попытайтесь представить себе пользователей своего продукта еще до первого релиза и делайте только то, что им соответствует. Не пытайтесь всем угодить — все равно не получится. Лучше меньше пользователей, но на 99% довольных.

Автор: MaxPastukhov

Источник

* - обязательные к заполнению поля


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js