Как не стать разработкой на аутсорсе при создании 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 человек. Плюс больших команд — у нас нет конфликтов за ресурсы. В том смысле, что не возникает ситуация, когда есть хорошая идея, а делать ее некому.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

#wrike #b2b