Как не стать разработкой на аутсорсе при создании b2b-продуктов

Сделали статью из доклада Дмитрия Меликова (Atlassian, менеджер продукта Jira) на конференции ProductSense в марте 2018 года. На тот момент Дмитрий работал в Wrike и рассказал, как держать баланс между кастомизациями под клиента и рыночной привлекательностью продуктов для бизнеса.

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

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

Расскажу, как этот баланс мы стараемся держать во Wrike.

Wrike — это облачный сервис для управления проектами и командной работы, который соединяет в себе функции Slack, Trello, Jira, Confluence и классической почты.

Нашими продуктами пользуются компании для организации совместной работы, ведения документации, визуализации Roadmap и так далее. Платят за каждого пользователя помесячно. Сейчас это более 19 тысяч компаний и 2 млн пользователей (данные на 2019 год).

У нас сквозная структура целеполагания — от стратегии до конкретных фичей. Мы следуем методологии Objectives and Key Results: ставим цели на год вперед для компании и продукта, а потом декомпозируем их до конкретных задач на уровне продуктовых команд.

Еще мы используем фреймворк Jobs to be done: год назад провели большое исследование — получилось около 12 историй, пользуемся ими до сих пор.

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

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

Стараемся прислушиваться к рынку и проверять гипотезы. Не всегда получается валидировать через А/В-тесты: на нашем количестве пользователей нужно достаточно долго ждать, чтобы результаты были статистически значимыми.

Продуктово-аналитическая команда помогает принимать решения на основании данных об использовании продукта. Но самое главное — мы стараемся получать с рынка фидбек. Для этого у нас есть три канала:

• Customer Support и Customer Success — большая команда постоянно собирает пожелания клиентов, структурирует и рассказывает, кому, что и почему нужно сейчас на рынке.
• Комьюнити — есть форум, где все клиенты могут общаться, выдвигать идеи и голосовать за них.
• Продажи — сейлз-консультанты постоянно общаются с клиентами и транслируют нам их пожелания.

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

Штаб-квартира Wrike — в Калифорнии, есть офисы в Сан-Хосе, Сан-Диего, Дублине, Токио, Мельбурне; офисы разработки — в Праге, Санкт-Петербурге и Воронеже. Соответственно, есть клиенты в США, Европе и СНГ.

Здорово, что можно съездить пообщаться с клиентом в офисе Airbnb в Сан-Франциско. Но во время пользовательского интервью клиент говорит: «Есть фичи, которые нам срочно нужны. Мы обсудили с советом директоров: если вы их не сделаете, мы уйдем на другой продукт».

С одной стороны, это действительно самый большой клиент. Если он уйдет сейчас, то все скажут: «Это из-за решения, которое принял менеджер продукта». Какие есть варианты в этой ситуации?

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

Клиент говорит: «Сделайте, иначе уйдем», а вы им: «Нет», а они вам: «Ладно, расходимся». Уходите довольным — суперпродакт, который сказал «нет». А потом клиент на самом деле уходит от вас, хотя все началось с пользовательского интервью.

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

Получается, что все три варианта — плохие решения. Давайте посмотрим, как можно выйти из этой ситуации с минимальными потерями.

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

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

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

Теперь поговорим о том, какие проблемы могут появиться на кастдеве.

Бывает, что клиенту просто не нравится продукт. Если вопрос ставится жестко: «Не сделаете — уходим», — скорее всего, клиент уйдет в любом случае. Тогда тратить силы на дополнительную разработку бессмысленно.

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

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

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

Сейлзы, особенно новички, могут недопонимать продукт или продавать с мыслью, что потом его «доделают».

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

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

Но что если предложить CEO смотреть отчет в мобильном приложении? Может, ему так будет удобнее, а он и не знает, что у нас есть приложение. И ведь это просто workaround, а не дополнительная разработка.

Так тоже бывает, просто помогите разобраться.

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

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

• Предложить альтернативу. Самое простое — выслушать и предложить workaround, и, может быть, предложить отложить это на потом: «Попробуйте приложение, поработайте с ним месяц. Если окажется неудобно, сделаем выгрузку в PDF». Вы сможете выиграть время — зачастую через месяц срочная фича уже никому не нужна.
• Презентовать Roadmap. Хороший Roadmap решает ключевые проблемы рынка хотя бы в перспективе. Если вы уловите суть проблемы клиента и сможете состыковать ее с проблемой рынка, то продадите ему свой Roadmap, объяснив, когда будет нужная фича.

Есть и более дорогие способы:

• Пообещать рассказывать об обновлениях. Такой способ подходит, если клиента смущает недостаточно внимательное отношение к его проблемам. От продакта это требует больших трудозатрат, потому что предполагает регулярные созвоны и выстраивание отношений. Если пообещаете рассказывать о движении по плану всем, то через полгода будете постоянно «висеть» на созвонах. Не злоупотребляйте.
• Привлекать разработку, взять фичу в беклог — самое нежелательное решение. Я имею в виду вариант, когда вы берете какие-то небольшие фичи в работу. Если вы подпишетесь под этим, постарайтесь придерживаться двух правил.

Во-первых, берите то, что нужно не только конкретному клиенту, но и всему рынку. Постарайтесь мыслить стратегически.

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

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

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

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

В обратном случае — если молча проигнорируете просьбу или забудете об обещании — вы рискуете испортить отношения с клиентом.

• Собирайте фидбек клиентов всеми возможными способами. Будьте готовы к тому, что в b2b клиенты считают нормальным просить о доработках, и иногда просьбы о доработках выглядят как шантаж.
• Ищите причину, по которой клиент просит сделать доработку. Старайтесь понять, какую проблему клиент хочет решить.
• Когда сформулируете проблему клиента, сможете успокоить его — предложить альтернативные решения или рассказать, когда будет это решение, с помощью Roadmap.
• Будьте аккуратнее с обещаниями: это касается и обещаний регулярного фидбека по планам, и обещаний взять новую фичу в беклог или подвинуть приоритет у запланированной.
• Если все-таки пообещали — выполняйте или работайте с ожиданиями клиента.

Посмотрите полное выступление Дмитрия Меликова на конференции ProductSense.

Благодарим за подготовку статьи редактора Асю Челован.

#wrike #b2b