Собственный продукт как фиксация компетенции
В развитии крупных компаний-аутсорсеров наступает момент, когда они уже обросли опытом и компетенциями и хочется куда-то все эти «накопления» инвестировать. Логическим направлением становится создание собственных продуктов. У такого выбора есть три причины:
экономия денег и времени заказчика при старте новых проектов;
получение конкурентного преимущества при работе с клиентами и участии в отборах;
удовольствие команды от создания тиражируемого интеллектуального продукта, а не просто работы на конкретного заказчика с его особенностями.
Многие пытаются это сделать, но когда закапываются в разработке, понимают насколько это дорого.
В этой статье я покажу, как мы решили разрабатывать внутренний продукт, по какому направлению пошли и что это дало.
Два варианта разработки собственного продукта
У продуктовой разработки есть два основных пути – подхода.
Дорогой и часто тупиковый
Это распространённый способ, при котором руководителю кажется что придумана клёвая идея и ее надо срочно делать. Все силы сразу бросаются на разработку и в целом цепочка выглядит так: «идея → разработка → готовый продукт → поиск покупателя → доход?”. Мы и сами так делали. Например, у нас был телеграм-бот для мониторинга сайтов и управления внутренними порталами — Агент700, несколько разработок по веб-аналитике и так далее.
Хорошо, если у компании хватило ресурсов и энтузиазма дойти хотя бы до третьего этапа, а часто средства заканчиваются еще на втором, т.к. разработка параллельно с постановкой и проверкой гипотез — это долго, дорого и плохо окупаемо. А часто и идея оказывается мертвой.
Верный вариант — продуктовый подход
Суть продуктового подхода в том, что сначала ДО программирования нужно проверить и предельно дешево подтвердить свою гипотезу, и только потом начать дорогую и сложную разработку. Этот второй вариант, как оказалось, работает)
Если коротко, цепочка в таком случае выглядит так: «придумать идею→ проверить что существует спрос → продать → начать разрабатывать → снова продать → и так далее».
10 шагов на пути к разработке
Мы пошли вторым путем и на примере реального продукта, я покажу, как это сделали и к каким результатам пришли.
Идея
Разрабатывая решения для работы в B2B-сегменте для наших заказчиков и сталкиваясь с повторяющимся набором требований, мы пришли к мысли: «Почему бы не сделать такой продукт, который покроет 90% потребностей клиентов с ходу – без доработок». Мы уже знали основные боли клиентов, которые он мог решить:
отсутствие онлайн-каталога оптового предприятия со сложной структурой;
база клиентов со структурой холдингов, точек доставки и контактных лиц, работа с которой не оцифрована;
проблема трудоемкого ручного формирования заказа (речь идет именно об огромных «оптовых» заказах, соответственно это сотни строк таблиц без картинок);
отсутствие прозрачности во время выполнения заявок;
дефицит времени у менеджеров на поиск новых клиентов и допродажи старым.
Так и появилась идея создать собственную B2B-платформу, которая бы экономила клиенту и нам первые несколько сотен часов разработки.
CustDev
Чтобы наше решение соответствовало реальным потребностям бизнеса вначале нужно было провести интервью среди целевой аудитории. Но сперва описать целевой сегмент нашей разработки. На подбор и проверку ушло несколько месяцев. В итоге, формулировка выглядела так: «Производитель оборудования, приборов или инструментов с развитой сетью дилеров со штатом менеджеров по работе с дилерами от 5 до 50 сотрудников и задачами оптимизации скорости выполнения оптовых заказов.»
Чтобы проводить интервью, нужно было где-то взять респондентов. Что использовали мы:
базу «старых» лидов (25+ подходящих) – им всем предложили пройти опрос и многие согласились;
новые лиды, которые спрашивали b2b-кабинеты – мы начинали разговор как раз с интервью;
лиды уже с посадки, первые несколько штук – также строили разговор через интервью.
Перед «проблемными интервью» подготовили список вопросов:
о сегменте:
количество позиций номенклатуры;
количество оптовых партнеров (клиентов);
количество менеджеров (операторов);
количество заказов от 1 партнера в месяц;
основные проблемы на взгляд респондента;
о текущем процессе работы с оптовыми клиентами:
подбор номенклатуры по запросу клиента;
выставление коммерческих предложений;
расчет цен на основании персональной скидки клиента;
выставление счетов по заказу;
передача заказа в отгрузку;
коммуникация по текущему статусу заказа;
выставление ТТН и других документов по отгрузкам;
наличие проблемы хотя бы с одним из пунктов;
о способах решения следующих проблем:
рост оборота с текущих партнеров (среднего чека);
рост числа партнеров;
аналитика: остатки, прогноз закупок;
маркетинг: привлечение новых партнеров и продвижение товаров среди партнеров;
логистика (доставка, уведомления, возврат);
документооборот (ттн / счета / акты / что еще?);
поддержка пользователей и интеграторов (документация по товарам, инструкция по установке и настройке, и т.д.).
Проведя десяток опросов, получили пул сценариев и функций, которые могли бы быть реализованы в нашем продукте.
Анализ конкурентов
У нас был опыт, с нуля писать мы не собирались и понимали, что ниша отнюдь не пуста. Мы составили список конкурентных решений, исследовали их, выделили сильные и слабые стороны, чтобы понимать, как мы можем отстроиться — чем привлечь потенциальных клиентов.
Список решений для анализа выглядел так:
Dealer365;
Agora B2B;
Compo B2B;
KORUS | B2B-портал;
Formix - B2B-platform
Сотбит: B2B кабинет.
При изучении обращали внимание на следующие параметры:
скорость внедрения;
тарифные планы;
функциональные возможности;
интеграция;
кастомизация и доработки;
техподдержка;
брендирование;
количество проектов в портфолио.
Что вошло в MVP
По итогу проведенных аналитических работ получился список требований, которым должна была соответствовать наша B2B-платформа.
Критерии:
скорость работы: НЕ медленнее чем у «среднего» интернет-магазина, в противном случае продуктом просто не будут пользоваться;
скорость развертывания: 1 неделя на установку и настройку;
вариативность: поддержка разных источников данных (разные типы цен / типы скидок / статусы заказов и так далее у разных клиентов);
отчуждаемость кода: можно доработать конкретному клиенту новую функцию;
скорость разработки и введения новых людей в команду;
относительно низкие накладные расходы (наши) -- облака, сервера подписок, и так далее.
Первый релиз MVP по нашему мнению должен был выглядеть так:
умеет выгружать на сайт контрагентов из 1С;
умеет присваивать им персональную цену / скидку;
встраивается в каталог / корзину и выводит персональные цены;
формирует заказ по персональным ценам контрагента.
Moodboard
Подготовили moodboard с подборкой интересных решений.
Frontend
Было много итераций. На выходе получили «демонстрационный стенд»; на нем проверяли гипотезу, его показывали клиентам, и на нем же сделали первую продажу.
В демо версии можно было показать, что происходит при нажатии тех или иных кнопок, как выглядят конкретные разделы, как происходит оформление заказа и так далее.
Создание демо минимальными силами для дальнейших демонстраций и продаж — это важная часть продуктового подхода или разработки через CustDev.
Проработка CJM для построения стратегии комплексного маркетинга
Для привлечения и удержания клиентов, проработали карту путей соприкосновения пользователей с нашим продуктом. На ее основании составили план продвижения.
Сегмент проверен, MVP есть, продвигаем
О продвижении коротко. Стратегия была построена на симбиозе долгосрочных и краткосрочных инструментов:
SEO-продвижение и контент-маркетинг для роста органического трафика и получения бесплатных лидов в будущем;
продвижение с помощью контекстной рекламы, для быстрого получения лидов. Их же хотели использовать и для получения обратной связи от потенциальных клиентов и внесения важных правок в демонстрационный стенд.
Для более точного позиционирования в продвижении выделили два целевых сегмента — тех, кому:
Нужно срочно и «под ключ».
Требуется индивидуальная разработка.
Стратегия сработала. Мы получили как рост органического трафика, так и рост числа заявок.
Обработка заявок
Поток лидов помог нам не только получить реальные заказы (об этом позже), но и понять:
как лучше позиционировать свой продукт;
какие функциональные возможности стоит добавить, а какие отправить в бэклог.
Здесь становится заметно преимущество выбранного подхода разработки — мы лишь вносили правки в верстку и посадку и не привлекали разработчиков (сколько часов → денег было сэкономлено! ).
А что же мы тогда продавали? Мы продавали решение проблемы клиента с помощью нашего продукта.
Во время созвонов, мы демонстрировали потенциальным клиентам верстку и их это устраивало! Для них важнее было увидеть, что наш продукт своим функционалом сможет быстро закрыть их потребности.
Первые сделки
В итоге сегментирование в маркетинговой стратегии сработало верно и мы получили заказы на следующие виды работ :
Готовый продукт с заявленным функционалом + внедрение + интеграция с 1С и CRM .
Всё, что входит в первый вариант ( мы его называем «под ключ») + доработки под индивидуальный запрос клиента.
Наконец, разрабатываем backend и интеграции
И только теперь, после получения оплаты, к работе начали подключаться разработчики.
И снова о плюсах выбранного подхода — мы знали какие именно задачи ставить разработчикам и что должны получить на выходе, т.к. все моменты были оговорены на предварительных созвонах и в итоговой смете.
Желаемый результат (в первом приближении) разработчики могли увидеть и «потыкать» на демо-стенде. Это ускоряло и упрощало процесс разработки.
В итоге нам удалось пройти всю цепочку от идеи до готового собственного продукта и нигде не споткнуться.
Внедрение получилось выполнить в срок незначительно превышающий заявленные 2 недели. Считаем этот опыт положительным. Клиент уже пользуется платформой — получает онлайн-заказы от оптовых покупателей.
А в чем смысл?
Клиент в короткие сроки получил инструмент, который позволил ему:
автоматизировать работу с B2B-партнерами;
освободить менеджеров от рутины и перенаправить их работу на поиск новых клиентов и допродажи старым.
Мы получили ядро, которое можно продавать как готовый продукт (на создание которого, благодаря следованию методике Customer Development, потрачено минимум ресурсов разработчиков), плюс предлагать доработки за дополнительную плату.
Мы видим, что продукт востребован, знаем как его правильно позиционировать и продавать.
Выводы
Продуктовый подход действительно работает! Он помогает правильно выявить боли потенциальных клиентов и получить продукт максимально их закрывающий. Нам же как разработчику, он позволяет сэкономить часы специалистов, а значит и финансовые ресурсы.
