Как построить продукт, который будет нужен рынку

Артём Дегтярёв

СЕО IT-компании Dunice

Привет! Я — Артём Дегтярёв, СЕО IT-компании Dunice. Как показывает мой опыт, многие предприниматели, особенно начинающие, совершают одну и ту же ошибку, когда заказывают разработку своего сервиса и выводят его на рынок — делают продукт ради продукта. В итоге оказывается, что рынку он не нужен.

Предлагаю вместе разобраться, как этого не допустить. Под моим чутким руководством мы пройдём весь цикл запуска продукта, проработаем проблемные места и выведем лучшие практики.

Когда компания начинает разработку проекта, у неё есть два ресурса: время и деньги. Оба — конечные. От того, как владелец бизнеса ими распорядится, зависит успех проекта — то, сколько и когда фирма получит прибыли.

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

Такой подход ведёт к следующему сценарию. Бизнес заказывает разработку своего продукта с огромным количеством функций. Допустим, это сервис по вызову такси, который показывает погоду, включает музыку под настроение и принимает оплату в биткоинах.

На разработку такого продукта уходит очень много денег и много времени — ведь, кажется, нельзя запуститься, пока не будет готово абсолютно всё. И если мы всегда предупреждаем заказчика об опасности его выбора, то не очень принципиальная IT-компания может этого не сделать — ведь чем больше работы, тем больше денег она получает.

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

Давайте разберёмся, как предотвратить такой грустный сценарий. Для примера возьмём тот же сервис заказа такси.

Суть продукта — в одном предложении

Как вы уже поняли, выписывать на листок все прикольные фишки и идти с ними к разработчикам мы не будем. А будем жёстко приоритизировать и выкидывать лишнее.

Для начала стоит сформулировать суть проекта в одном предложении. Например: это сервис заказа такси, который сравнивает цены операторов на текущий момент и предлагает самый дешёвый вариант.

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

Готова главная функция — сразу на рынок

Не стоит путать начальную версию продукта с недоделанной. Начальный продукт делает только базовый набор функций, но делает их отлично. Недоделанный — плохо справляется с основной задачей. Выкладывать неполный продукт не значит, что он будет работать неправильно. Это значит лишь то, что всё, что выложено — будет работать.

Как только разработчики справились с задачей, протестировали сервис и сдали его нам, идём запускаться. Даже если пока кажется неидеальным интерфейс, и много чего ещё хотелось бы прикрутить.

Вот, почему такой подход нам выгоден:

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

Над чем работать дальше — диктует рынок

Следовать своим представлениям об идеальном продукте — опасная идея. Конечные пользователи могут вовсе не разделять нашу идею, что оплачивать биткоинами — круто и современно. По моему опыту, абсолютное большинство сервисов, создатели которые руководствовались только своими представлениями, не попадали в рынок и проваливались.

Нам стоит прислушаться к тем, кто использует наш сервис, и выяснить, что им бы хотелось улучшить и добавить. Начнём с очевидного — прочитаем отзывы в App Store и Google Play. Ещё можно запустить небольшой опрос внутри приложения для тех, кто пользуется им больше недели — это совсем не сложно и не дорого.

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

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

Не бояться тестовых итераций

Не всегда запуск новых функций проходит удачно. Давайте представим, что мы добавили возможность выбирать разговорчивого и молчаливого водителя. Оказалось, что за неделю тестового периода никто ей так и не воспользовался.

Не опускаем руки и анализируем. Функция могла оказаться невостребованной, потому что:

• мы слишком далеко поставили её в меню, и она неочевидна,
• мы не рассказали о ней пользователям,
• она никому не нужна.

Идём тестировать наши гипотезы.

1. Переставили опцию поближе, теперь её не надо искать. Ждём неделю. Кажется, у неё появились первые пользователи.
2. Запустили на неделю рекламу нашего революционного сервиса «Выбери тип водителя». У сервиса стало на четверть больше клиентов!

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

Решать проблемы по мере поступления

Ещё в самом начале разработки у нас была проблема: что делать, если два пользователя приложения стоят рядом и одновременно заказывают одну и ту же машину.

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

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