В этой статье: почему про него мало говорят на конференциях, особенности продуктового менеджмента в b2b, процессы и люди в b2b-командах.
Кому не подходит вариант статьи, то есть стрим: ссылка на youtube.
Вступление
Т: Меня зовут Тигран, я автор канала Black product owner, занимаюсь продуктовым B2C менеджментом.
М: Меня зовут Михаил, я веду каналы Продуктовошная и Про удобство. Занимаюсь B2B менеджментом всю свою сознательную рабочую жизнь - с 2007 года. Сейчас занимаюсь менеджментом платформы Клевер, которая автоматизирует процессы в строительстве. До этого занимался продуктами для госсектора, крупного B2B, торговых компаний. В общем, у меня разносторонний опыт.
О B2B и B2C
Т: Сегодня наша основная тема будет посвящена B2B в целом. На самом деле, мы в моем канале уже набросали ряд вопросов. Я предлагаю последовательно по ним пойти. Почему-то про B2B мало говорят. Как ты думаешь, почему это так?М: Надо начать с того, что такое B2B. Это когда мы создаем продукт для каких-то юридических лиц. Юридические лица могут быть разного размера: микропредприятия, средний бизнес, малый бизнес и крупный бизнес. Когда создается продукт для малого бизнеса и микропредприятий, они схожи с B2C. Это что-то вроде 1C, Битрикс и т.д. Когда создается продукт для среднего или крупного бизнеса, начинается много кастомизации.Такой B2B называют кровавый enterprise. Про него действительно мало говорят на конференциях.Во-первых, компании, которые создают такие продукты, не на слуху у пользователя. Значит, на конференцию меньше придет людей. Это не значит что B2B - это скучные процессы. Они просто другие.
Т: Получается основное отличие в том, что данный продукт B2B менее массовый?
М: Если говорить, почему на конференциях мало рассказывают, то просто потому, что ты зовешь ребят, про которых мало, кто знает. Это не так интересно, как B2C. Потому что, когда ты приходишь на какую-то конференцию послушать про какой-то продукт, ты можешь поставить себя на место пользователя и лучше понять, о чем говорят.
Т: Применить опыт на себе.
М: Когда рассказывают про проблемы сотрудников, которые делопроизводством занимаются, то применить на себя их могут только те слушатели, которые занимаются делопроизводством, остальные меньше проект прочувствуют. В этом вся суть. Как по мне, лучше было бы звать ребят из тех продуктов, про которые больше всего известно.
Т: Это логично, чем шире аудитория, тем как бы понятно что провоцировать легче.
Особенности продуктового менеджмента в кровавом enterprise
Ты уже как-то сказал, есть различие между продуктами для мелких юрлиц, которые больше похоже на B2C, и крупными B2B. Расскажи поподробнее про этот кровавый enterprise.
М: Возвращаясь к шагу про массовый сегмент, он не такой же большой, как сегмент физических лиц. Например, аудитория у СRM меньше, чем у Вконтакте в сотни раз. Но все равно это крупная аудитория, на которой можно количественно проверять разные гипотезы.
В кровавом enterprise аудитория существенно ниже. Количественное тестирование гипотез встречается очень редко. Например, если аудитория твоего продукта равна 10, ты выполнишь 10 внедрений за год и закроешь все показатели по продажам, и это будет шикарно, но на 10 клиентах много гипотез не потестируешь. Поэтому количественные метрики в этом рынке не распространены.
Поговорим про мотивацию пользователей. Допустим мы внедряем CRM в микропредприятие. В такой ситуации на его выбор могут повлиять 2-3 человека. У ИП и юр.лиц мотивация выбора продукта близка к мотивации обычного человека.
Например, Тигран как обычный человек увидел рекламу ноушена или кто-то тебе сказал Notion и думаешь: “О классно, хорошо бы попробовать!” Тигран попробовал, ему понравилось, и теперь он организует там работу.
Здесь у тебя работает личная мотивация: тебе понравилось, тебя триггернуло. У пользователей, которые будут пользоваться твоим продуктом внутри крупной компании, такой мотивации нет. Т.е. ты заходишь там на ЛПР продаешь ему годами сырой продукт. Потом сделка состоялась, пользователям спускают сверху продукт. Они пользуются, кто-то плюется, кто-то не плюется. Это совсем другой подход к мотивации. Твой продукт могут не принять не потому, что он плох, а потому, что до этого они привыкли к другим продуктам.
Снизу вверх или сверху вниз? Разбираем кейсы.
Т: Получается, что когда мы говорим об одном продукте в микроорганизации- это “снизу вверх”: увидел, взял, внедрил, а в больших корпорациях - “сверху вниз”, когда начальник пришел и сказал: “Вот новый стандарт. Будем работать так”. А как же, например, кейс Slack, которые будто пытаются протаскиваться именно снизу вверх. Есть ли еще такие примеры или это Slack - исключение из правил?
М: На самом деле, даже по Slack’у я бы поспорил ,что он всегда внедряется “снизу вверх”. Куча организаций, где его внедряют так: приходит CPO и говорит: “Ребята, я прекрасно понимаю, что вы тут в телеграммах переписываетесь, но есть Slack. Он удобен корпорации, с помощью него можно хорошо управлять, админить. Давайте перейдем в Slack”. И вот регламент - пользуемся слаком. Наверное, на первых порах, это было “снизу вверх”, но есть куча примеров, когда он внедряется “сверху вниз”.
Другие продукты тоже могут внедряться “снизу вверх”, но здесь возникает вопрос. Slack подходит и под маленькие команды. Но допустим мы берем и внедряем продукт, который автоматизирует какой-то жизненный бизнес-процесс организации, например Jira - система управления проектами. В любом случае, компания чем-то до этого пользовалась. Тогда сверху будут запускать этот продукт. Может быть, была инициатива снизу, но все равно решение примут наверху, потому что в крупных организациях очень сложно через низ провести продукт, за который ты потом хочешь получать деньги. Через низ можно провести лишь бесплатное.
Т: Но деньги ты за это не будешь получать.
М: Да, т.е. кому-то все равно надо продать это, если снизу вверх у тебя получается продавать, то это прекрасно, но это очень считанное количество продуктов, которые для маленьких организаций тоже подходят. Если говорить про продукты чисто для enterprise, например, Газпрома - кикие-нибудь системы, которые показывают информацию о нефтедобыче. Снизу вверх это не будет внедряться, потому что человек просто не сталкивается с этим в обычной жизни. Этот продукт просто возьмут и предложат продажники, либо кто-то увидел его в другой организации. Откуда-то этот маховик пойдет, но, как правило, не от сотрудников.
Влияние продакта на продукт, нюансы B2B
Т: Я не работал в B2B, только в B2C и внутренними продуктами. Они похожи, потому что они созданы для внутренних заказчиков. Что ты можешь рассказать про эту сферу?
М: Если говорить именно про управление продуктом, то, на мой взгляд, в B2B у продакта гораздо больше рычагов влияния на продукт и гораздо больший вес взаимодействия с пользователем.
Я не видел enterprise продукты, где он был бы отделен от разработки: там и discovery, и delivery, и продажи, и внедрение. Сфер, в которые продакт должен быть погружен, будет больше чем у продуктов в B2C. Общался с продактами, которые в банке отвечают лишь за то, как будет работать раздел справочной информации: как он будет выполнять запрос пользователей, как они могут достигать свою задачу через справку. Как правило, в B2B задачи более комплексные. Тебе надо и с пользователей снять срез какой-то информации, проконтролировать чтобы это было доставлено до продажников, потом проконтролировать внедрение, понимать обратную связь.
Когда ты создаешь проект для B2C, врубаться в продукт гораздо проще, потому что ты можешь его примерить на себя, ты можешь им попользоваться. В B2B не так. Например, я сейчас работаю над продуктом, который автоматизирует этап строительства крупных организаций, занимающихся линейным строительством дорог и мостов. Я не строил ни дороги, ни мосты, но надо врубиться в процесс: как это происходит, какие сущетствуют этапы. И это интересно.
Что еще интересно? Интересно то, что клиенты - не совсем пользователи. В B2B есть такая классификация. Клиент - тот кто заплатит денежки, т.е. сама организация, а внутри него будут пользователи. Вес тех, кто платит деньги, выше, чем в B2C. В B2C тебе один человек платит деньги, если их там миллионы, то один отвалился - не беда. Беда - когда массово отвалятся. В B2B бывает так, что один клиент отвалился, высокий кусок годовой выручки пропал, и ты должен с этим что-то делать. Это все бывает тяжело, но в целом это другие вызовы.
Системный аналитик и продакт в B2B - одно и то же?
Т: Ты сказал про применимость к себе. Это очень крутая вещь, я сталкивался с этим в бизнес анализе. Раньше была такая роль - системный аналитик. Насколько это применимо сейчас? Продакт B2B и системный аналитик - это рядом или нет?
М: Это рядом в зависимости от стадии, на которой сейчас находится продукт. Продакт может выполнять роль системного аналитика, если у бизнеса нет денег на отдельного системного аналитика.
В целом, системного аналитика и бизнес аналитика в enterprise B2B обычно отдельно выделяют. Есть тот, кто бизнес-процессы изучает и описывает, а есть тот, кто бизнес-процессы переводит на язык разработки. Этим и занимается системный аналитик - думает как преобразовать в систему полученные в ходе анализа знания, Эта роль не пропала, она раньше была и она есть сейчас, вполне себе востребована, таких ребят много.
Как устроена B2B команда
Т: Мы уже начали затрагивать блок, связанный с процессами и людьми в B2B командах. Кто еще есть в команде и как она устреона? Может ли там быть agile или там скорее жесткий waterfall?
Я знаком с ребятами, которые в интеграторе работают и пилят CRM-ки по заказу по контракту. Многие контракты задерживаются, и уже вот пилятся два года вместо одного года. Расскажи мне, как это.
М: Начну с ролей, которыея редко встречал в командах, которые занимаются enterprise продуктами: почти не встречал проверку гипотез роста. Сложно тестировать гипотезы роста, когда хорошо, если есть 10 клиентов за год. Обычно про гипотезы рассказывают на конференциях: ее надо за неделю-две проверить, чтобы за месяц ты напроверял пачку гипотез и ты вырос по каждой на 2%. В B2B у enterprise я такого ни разу не видел. Команды роста бывают, но там одна гипотеза может расстянуться на недели, месяца и полугодия. Например, такая гипотеза: если мы с нашим продуктом пойдем не через директора, а через технического директора, то конверсия будет выше. Но тебе, чтобы до этих технических директоров добраться, на каждого надо неделю-две потратить. В итоге выходит долго.
Если касаться других ролей, то в B2B командах: есть
Бизнес аналитик
Системный аналитик.
Техническая команда. Здесь от B2C отличий больших нет. Может быть бэк, front, full-stack команда.
Команда внедрения. В B2C обычно такого не бывает. Это те люди, которые обучают, внедряют процессы, контролируют, пошел продукт в процесс или нет и т.п. Продать продукт - это одна история. Сделать так, чтобы продукт стал применяться - другая. В B2B есть менеджер по внедрению, который говорит: “Наш продукт в ваши процессы внедрился на 5, 10, 20%” и вот когда продукт внедрится на 100%, с твоего продукта соскочить уже очень тяжело.
Менеджер продукта.
Менеджер проекта. Он отвечает за объединение бизнесовой, технической и продуктовой команд.
Мы применяем Agile и Kanban процессы внутри проектов. Скорость выпуска релизов у нас сейчас раз в месяц. В этой части совсем не водопад. В заказной разработке часто бывает водопадная модель, но в продуктовой я давно не видел водопадной. В предыдущей команде работали по скраму.
В B2B я редко видел борд по метрикам продукта. На продуктовых конференциях рассказывают про LTV, оттоки, retention. В enterprise сегменте борд будет посвящен воронкам продаж.
Применение waterfall и agile в B2B продукте
Т: Расскажи немного про продукт, чтобы мы все поняли как возможно осуществлять kanban, agile и другие подходы в твоем продукте, как это вообще происходит?
М: В B2B enterprise время разработки MVP не маленькое. Бывает надо год, чтобы сделать первую версию, которую можно пытаться продавать. Такой MVP требует большой бюджет, большую команду и понятный фронт работы. Эта часть схожа с водопадами, т.е. тут не будет спринтов. Через две недели у тебя не выйдет первая версия продукта. Она может идти почти как по водопадной модели. Такой продукт вообще можно заказать у внешней команды, если состыковаться по тому, что мы на выходе хотим получить.
Те ребята, которые пилят CRM два года, могут сделать первую версию какого-нибудь продукта для сегмента крупного бизнеса, а дальше его можно внутренней командой развивать. Такие подходы тоже бывают, т.е. срок выпуска MVP похож на водопадную модель. Дальше, когда ты начале его продавать, у тебя появляется обратная связь и тут можно организовывать процесс по agile. Ты видишь обратную связь, можешь приоритизировать то, что у тебя поступает в бэклог, и дальше по приоритетам выпускать релизы.
Основной момент - это именно первая версия, и она может долго выпускаться. В таком случае возможно по водопадной модели более эффективно работать.
Т: Есть ли в вашей команде архитектор?
М: Мы создаем платформу, которая состоит из нескольких продуктов. В целевом видении их 16, сейчас - меньше. Есть ряд сервисов, которые мы выносим за продуктовые контуры на уровень платформы. Есть архитектор, который за эту архитектуру отвечает: какие у нас сервисы идут за продукт и другие продукты будут их использовать. Например, ролевая модель или какая-нибудь единая точка входа в каждый продукт. Когда пользуешься Google, ты видишь меню с квадратиками, при нажатии на которое открываются все сервисы гугл. Мы делаем что-то похожее, но для строительства: нажимаешь на меню с квадратиками, там выпадут твои продукты и за них отвечает архитектор.
Также есть директор по продуктам.
Т: Ты называешь продуктами микросервисы?
М: Они не совсем микро. Каждый из них стоит какое-то количество миллионов, если продавать по отдельности, но в совокупности их 16 - экосистема из продуктов. На уровне платформы, мы еще ряд микросервисов выносим, чтобы в каждом их не повторять и не заниматься их разработкой и курированием.
Проджект-менеджеры в B2B
Т: Есть ли в подчинение у продакта проджект-менеджер, под конкретные этапы развития продукта, интеграции с внешними системами и прочих штук?
М: За всех не скажу. Там, где я сейчас работаю нет. Там, где я работал ранее, были. Это зависит от потребностей и бюджета. Вообще, что такое проджект-менеджер? Это человек, который может по определенному заданию, имея определенный ресурс в виде людей и бюджета к определенному сроку привести нужный результат. Его задача - сделать что-то в ограниченноевремя, сдать и потом идти делать другой проект.
Если для интеграции с какими-то другими системами есть понятный фронт, есть под это ресурсы и понятен срок, можно привлечь проджект-менеджера. Зависит от уровня развития организации,если она уже готова к тому, чтобы в это вкладываться, то можно конечно.
Цена ошибки в B2B
Т: Техподдержка, организация и уровень ответственности, скорее всего, относится к особенностям B2C от B2B? У тебя, если часть простоя в B2C сервисе, люди переживут, а в B2B часть простоя может стоить всех контрактов, которые у тебя есть.
М: Да, когда-то давно при обсуждении внедрения Клиент требовал от директора компании гарантировать своей квартирой, что сервис не упадет и не будет простоя aka “За базар отвечаешь?” Такого уровня был этот разговор. У людей была система, которая принимала заявки на доставку продукции. Если эти заявки не дойдут до места, которое отгружает, то бизнес теряет миллионы. И если ты пишешь, что система может быть недоступна 1 час в месяц - этот один час может случится именно в тот момент, когда много миллионов не донесли до производства. Тогда это проблема.
В B2B, в плане взаимодействияклиентов и поддержки, более обостренные чувства. Надо быть более чутким в этой части. Например, если один клиент в B2C обиделся и поставил двоечку в оценках, ее могут и не заметить. В B2B, если твой ключевой клиент обиделся, т.к. продукт не сработал, как ожидалось, это может стоить всего бизнеса, потому что он завтра своим друзьям бизнесменам расскажет, какой у тебя плохой продукт, и все: на этом ты свою деятельность закончишь.
Как сократить цикл сделки в B2B
Т: Вопрос от Андрея: ”Как сократить цикл сделки в B2B?” Давай представим, что сейчас мы с тобой на продуктовой конференции, ты вышел на сцену, много сидит продактов B2B, и ты им должен что-то рассказать.
М: Цикл сделки очень сложно сократить. Это, кстати, к вопросу, какие вопросы волнуют продактов.
Продакта естественно волнуют продажи. Т.к. это enterprise - штучная история, то цикл сделки может быть в несколько лет: начали продавать, пришли кому-то презентовали, а купят у тебя через несколько лет, если купят вообще. Что здесь могло бы помочь?
Во-первых, договариваться заранее с клиентом о каких-то целях. Когда ты приходишь продавать, то что-то резюмируешь после демонстрации либо после цикла демонстраций. В этом резюмировании надо согласовать цель. Например: “Ребята, давайте пилотный доступ предоставим, но после него вы либо покупаете, либо даете точный список того, чего вам не хватает, чтобы начать эксплуатировать”. Если они на это готовы, то это можно уже юридически фиксировать. Если они на это не готовы, то возникает вопрос к их намерениям. Длинный цикл сделки возникает из-за того, что организацию сманили посмотреть ваш продукт, они повелись на это, уделили время, возможно, им было скучно, а вы им пытаетесь продавать, но им особо это не нужно.
Второй момент, почему может растянутся - люди поменялись. Т.е. ты несколько месяцев показывал одному, потом он уволился, пришел другой, который вообще не в курсе. Надо показать и ему. Здесь хорошо бы, чтобы какая-то группа, на стороне заказчика знала о твоих активностях, чтобы при смене лидера группы остальные могли ему это донести. Т.е. искать помощников внутри организации, которые будут напоминать про продукт.
Ну и третий момент это - приятно напоминать о себе. У таких с большей вероятностью купят, чем у тех кто пропал, потом через год вспомнил: “Блин, ребята, мы же там план продаж не закрыли. Вот тут у нас был еще теплый клиент”. К нему возвращаются, а он уже все забыл, и ты уже все забыл и т.д.”
Инертность в B2B сделках
Каких-то волшебных средств здесь нет. Для меня лично не проблема была продуктпоменятьНапример, раньше писал свои заметки в EverNote, потом перешел на Notion. Могу еще куда-то перейти. Для организации, которая внедряет продукт, который автоматизирует ее ключевые бизнес процессы, инертность огромная.
Во-первых, для того, чтобы внедрить, надо много времени и энергии. Существует параллельный ввод информации: кто-то продолжает на бумагу записывать, кто-то уже в системе. Допустим внедрили вашего конкурента. Потом ты приходишь такой весь красивый с другим продуктом: у него потребительские функции шире, ценник другой, и говоришь: “А давайте попробуем!” Ты должен быть намного, намного лучше, чтобы тобою заменили того конкурента, потому что они уже помучались с ним, когдавнедряли. Инертность большая, и, чтобы им от него отказаться, надо прямо бронебойные преимущества иметь. Это тоже может на цикл повлиять. Например, им потенциально интересно, но, понимая к каким последствиям это приведет, эти последствия, более сильно горят чем то, насколько твой продукт перевешивает продукт конкурента.
Риск-менеджмент
Т: Недавно слышал, что стоимость работы с риском должна быть 25% от стоимости потерь. Мне кажется, тут можно выработать подход, при котором, если ты можешь, внедрив это, сэкономить им или заработать, тогда больше шансов, что человек ответит “Да,я пойду на это”. В противном случае, зачем ему это.
М: Тут у того человека, который примет решение, должна быть очень сильная заинтересованность в том, чтобы этот продукт внедрился. Тогда цикл сделки будет уменьшаться. Можно и серыми схемами, если пошире посмотреть на вопрос, добиться сокращения цикла сделки. Но не будем про серые схемы..
Как выявлять потребность клиентов
Т: Александра спрашивала про понимание истинной боли бизнес-потребности клиента из “хочу чтобы вы сделали вот это” в “у нас болит Х, для решения бизнес задачи придумайте, что сделать”. Мне кажтеся, существует заказчик решения, который приходит к интегратору и говорит: “У меня есть бизнес-процесс, сделай вот так”. А ты говоришь: “Я сто миллионов раз так делал, так не работает, давайте по-другому”. Как перейти к “давайте я вам решу проблему, опишите еесаму, а не решение”.
М: В B2B продуктах частенько приходит некое решение, в B2C наверняка тоже самое приходит, просто там взвешивают это иначе.
Например, в одной организации утверждали некий документ, нажимали утвердить. Система спрашивала, уверен ли пользователь, что хочет утвердить. Ты нажимаешь да, и он утверждает. Люди на автомате нажимали “Да” и утверждали то, что не надо было утверждать.
Приходит запрос в поддержку: “Ребята, сделайте так, чтобы система спрашивала второй раз, готов ли он утвердить”. Проблема же была в том, что они не могли откатывать утвержденный документ, чтобы что-то в нем поменять, т.е. истинную мотивацию здесь не понимаешь.
Почему-то часто пользователи присылают то, как они видят решения своей проблемы. Они его описывают через интерфейс. Нужно же узнавать мотив пользователя: зачем ему это нужно, почему для него это важно. Продакты часто задают вопросы, их этому учат, а в техподдержке не всегда, поэтому по-хорошему нужно просто сделать шейринг знаний внутри команды.
Я когда решал такую проблему, провел внутри команды митап про то, как элементы проблемного интервью применять к своей деятельности. Например, рассказал про то, как продажники могут применять, когда продают. Им задают вопрос: “А может ли ваша система Х”. Они говорят либо да, либо нет и идут дальше, не спрашивая: “А почему вы спросили про это, почему для вас это важно?” Через это “почему” можно прийти к ценным вещам. Также обычно саппорт не спрашивает об этом. Например, их просят, могут ли они увеличить количество символов, которые входят в это поле. Почему их волнует количество символов? А там оказывается, что у нас вообще поле не такое.
Людей, которые взаимодействуют с клиентами, нужно учить выявлять истинную потребность.
Т: Для решения задачи нужно проводить интервью, за основу, как чек-лист можно брать problem-statement canvas. Например, у меня в B2C бизнесе работает 150 человек. Мы продаем образовательные курсы, клиентов в районе 2000. Я пользуюсь распространенными системами, которыми вы все пользуетесь: Slack, Telegram, Bitrix, поддержки банков и т.д. Если сравнивать поддержку Битрикса с B2C, то это просто невозможно. Ты пишешь и там люди иногда не понимают, что ты хочешь. А эта штука кажется обязательна для внедрения, а ты не можешь взять и позвонить своему менеджеру.
Еще я пользуюсь несколькими банками, и там сейчас мода на роботов, которые подсовывают библиотеки ответов. Иногда ты не можешь с живым человеком связаться. В B2C это еще может быть как то оправдано экономией, но в B2B это прям боль.
Переход из B2B в B2C
Т: Возможен ли переход из B2B в B2C
М: Я не переходил. Я был в B2B, в B2B2C, но это все равно что B2B. Когда я менял работу, я приходил на собеседования в компании, в которых были B2C продукты.и\Технологически ты можешь быть подкован, но страдает факт и наработанность в области продуктовых метрик т.к. в B2B в таком виде, в котором их любят оценивать в B2C их нет: ни retention, ни LTV, unit-экономика абсолютно другая. У меня вот unit-экономика - на продукт 10 клиентов за год и хорошо. В B2С совсем другая история, связанная с метриками, принятием решений на основе данных. Поэтому если у тебя была хорошая позиция в B2B, перейти на такую же в B2C сложнее, чем в своей среде с B2B на B2B. Возможно перейти с понижением позиции и там учиться, если есть большое желание в B2C.
Скиллы, необходимые в B2B
Т: Можно сказать, что в B2B намного круче прокачаны коммуникационные скиллы. Например, если ты плохо общаешься с клиентами, партнерами, не умеешь подстраиваться, то ты будешь просто неуспешным менеджером продукта или здесь это не совсем уместно?
М: Скорее всего, уместно. Тебе надо понять своего клиента в любом случае. Если у тебя пользователь - это организация, то тебе нужно понять процесс. Чтобы понять процесс нужно не с одним человеком внутри компании пообщаться, а также пообщаться так, чтобы они тебя поняли и чтобы ты их понял. Это большая задача менеджера продукта - настроить коммуникацию с клиентами. Особенно она получает большой вес, когда ты на старте. В B2B очень тяжело делать первые продажи, когда у тебя нет имени, когда ты не можешь разместить рекламу в Яндексе. То есть ты можешь её разместить, но к тебе не придет Газпром и не купит твой продукт по рекламе в Яндексе. “Сейчас трафика нагоним, посмотрим конверсию” - такое не работает и лэндинг хороший тебе не поможет, т.е. нужно идти продавать, изучать процессы.
Это целая история - как найти первых клиентов, поэтому в B2B первые проекты очень часто рождаются из каких-то проектных историй. Например, мы занимались разработкой на заказ, одна компания что-то заказала, мы для неё сделали и поняли, что это можно тиражировать. Идем во вторую, предлагаем ей нашу компетенцию, но уже за другие деньги и так далее тиражируем. Либо изнутри, когда было IT подразделение внутри компании, кто-то пилил внутренний софт, потом отделились, ушли и унесли с собой компетенцию. А позже сделали этот софт для продажи, понимая процессы. Извне тяжело прийти, когда ты процесс не понял, поэтому уровень общения с клиентом и ключевыми пользователями очень важен.
Про риски в B2B, проектный треугольник и эпичные факапы
Т: Скажи пару слов про риски в B2B и управлении проектным треугольником
М: Проектный треугольник - это срок, ресурсы и функциональность, т.е. если надо увеличить функциональность, то надо увеличить либо срок, либо ресурсы, либо и то и другое. Одно влияет на другое. Я, наверное, уже зацепил вопрос про то, что MVP дорого делать, про риски - что ты можешь не добежать до конца. Вложишь деньги в продукт, начинаешь его внедрять, понимаешь, что надо доработать Х, но на это не хватает денег, и в таком виде он никому не нужен. Не добежать до конца легко, при этом, чтобы проверить добежишь или нет нужны деньги, потому что с прототипом из картонки ты в B2B не пойдешь.
Т: Вы говорите про agile. Какой размер вашей команды? Используете ли вы сейвы или иной фреймворк масштабирования agile?
М: Фреймворк масштабирования не используем. Размер команды около 10 человек, это именно продуктовая команда не платформенная, платформенная - 50 человек.
Т: Расскажи какой-нибудь эпичный факап. Который тебя чему-то научил или не научил, а просто произошёл.
М: Были разные факапы, но прямо эпичного не было. Был факап, касающийся периода сделки. Один раз мы продавали продукт 8 лет в B2G (госсектор). Он очень похож на корпоративный сектор, но там принятие решений после госзакупки происходит. И в итоге мы проиграли госзакупку. 8 лет и 0 рублей.
PS спасибо за ваше время, если понравилось, то подписывайтесь на канал https://t.me/blackproduct там регулярно появляются новые стрим с C-level гостями.
2PS поделитесь в комментариях, как вам формат? что нужно улучшить? какие еще темы осветить?
Спасибо!
