Как продавать backend-продукт внутри компании

Philipp Sanachev, backend-разработчик

Среди разработчиков есть люди, которые хотят видеть, что их продуктом пользуются. Но что делать, если продукт еще в разработке? Или разработан, но нет первых пилотных клиентов? В обоих случаях нужна обратная связь, чтобы понимать, какие возможности продукта востребованы рынком, а какие нет. А если всё это осложняется трудностью представить результаты работы для не-технарей? Ну и самое сложное — продукт нужно продать внутри компании, чтобы его начали продавать клиентам?

Зачем нужна обратная связь?

Меня зовут Филипп, и я разработчик в компании Xsolla. В компании много продуктовых команд и почти все работают по Scrum. Одной из особенностей Scrum является постоянный сбор обратной связи: команде важно, чтобы то, что они делают, было ценным и решало проблемы клиентов, на основе этой обратной связи корректируется дальнейшая работа.

Пара слов о продуктах команды

Мы делаем backend-решения для игровых разработчиков, чтобы они могли сосредоточиться на игре, а не на том, как организовать магазин в игре или работу с предметами в инвентаре игрока.

Как мы пытались показывать результаты?

В Scrum есть специальный ритуал — обзор итогов спринта (презентация итогов работы команды за период времени), который нужен для получения обратной связи. В какой-то момент команда поняла, что объяснений, о том, что было сделано, недостаточно и начала экспериментировать с вариантами, как демонстрировать результаты работы.

Берешь и рассказываешь!

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

К сожалению, с ростом компании команда не всегда может напрямую общаться с клиентами, ведь на кону могут быть репутационные риски. В таком случае обратную связь команде дают люди, которые общаются с клиентами — интеграторы и аккаунт-менеджеры. Так уж вышло, что эти люди могут не обладать достаточными техническими навыками, чтобы из 15–20 минутного объяснения и пары картинок было понятно, что было сделано и как это работает.

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

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

Давным-давно

Времени на подготовку было мало и команда решила — откроем Postman (cUrl/Fiddler) и покажем запросы. Для команды всё понятно: вот запрос, вот ответ. Ещё можно логи показать, да что данные в базе изменились.

Для команды разработки минимум временных затрат, и всё понятно.

Тем, кто общается с клиентами, оказалось непонятно, что конкретно сделала команда, как этим будут пользоваться и зачем это вообще нужно. Из-за этого обратная связь была низкого качества либо отсутствовала вовсе. Чаще всего мы слышали “Да, всё понятно”, но в реальности продукт был непонятным, а значит про него даже не упоминали возможным клиентам.

Не так давно

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

Стало намного понятнее, как продукт работает.

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

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

Сейчас

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

Не знаю, как вам, а нам понравился результат. Вышло красиво, наглядно и привлекает внимание. Одна проблема — поддерживать демостенд в актуальном состоянии дорого — новый backend- функционал хочется демонстрировать постоянно, а добавлять его на frontend бывает так же сложно, как и разрабатывать его на backend. Большой плюс в этом — разработчики качают frontend-компетенции.

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

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

Будущее

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

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

Вместо вывода

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

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