Почему некоторые проблемы не решаются в казалось бы клиентоориентированных компаниях?

Горячо любимый мной Т-Банк на днях прислал уведомление и предложение забронировать гостиницу в Перми - мол у вас же билеты куплены! Все бы ничего, да только лечу я из Перми. Видимо, при разработке и тестирования фичи забыли учесть, что можно летать не только из Москвы, но и в Москву. Я вспомнил, что уже была подобная история в том же сервисе Город Т-Банка, когда мне прислали напоминание о концерте по Московскому времени. Вот была бы история, если бы я из-за них опоздал :)

В Miro пользователи жаловались на проблемы навигации по доске мышкой. Все это знали, и вся команда каждый день пользовалась своим продуктом (догфудинг на 100%), но шли годы, а опыт никак не улучшался. Просто вся команда сидела на Макбуках и пользовалась тачпадами. А Enterprise клиенты сидели на Windows с мышками.

Недавно консультировал одну компанию, организовали интервью с клиентами, уже начали делать предварительные выводы, когда кто-то вспомнил, что из-за наличия у компании физических магазинов, поведение клиентов в Москве и на Урале может очень сильно отличаться. И в этот раз чуть не пострадали москвичи :)

В чем мораль? Развивая клиентоцентричность, не забывайте о разнообразии клиентов. И я сейчас не об ориентации :)

Такие вот уроки продакта

Все прочитали статьи про закрытие Amazon'ом своего #AI стартапа - магазинов "Взял и иди"? Лет 6 назад Амазон открыл магазины, где берешь товар с полок и идешь по своим делам дальше. Деньги спишутся автоматом. Сейчас Амазон объявил о закрытии проекта.

У этой новости два интересных момента:

1. Кроме ИИ на этом проекте работало еще 1000 индусов, которые вручную по камерам распознавали кто и что купил. Многие пишут не "кроме ИИ", а "вместо ИИ". Конечно же не вместо. Зачем тут индусы? Допустим, модель работает с точностью 90% (цифра для примера), но - что делать с оставшимися 10%? В модели рекомендаций моно забить, но тут транзакции! Вот люди и подчищали хвосты за ИИ. Не будем тут даже вспоминать про дообучение модели и контроль качества. Мораль в том, что ИИ не является чудо-средством. Это надо понимать и учиться работать с ограничениями, которые могу сломать всю бизнес-модель.

2. История хорошо демонстрирует, как на волне хайпа новых технологий создаются повышенные ожидания. Бум стартапов, миллиардные оценки, громкие запуски... Потом хайп спадает, большинство стартапов закрывается... Но еще через какое-то время из оброненных ранее ростков прорастает что-то полезное. Меньшего масштаба, чем ожидалось на старте, но зато действительно рабочее. Существует так называемый цикл хайпа новых технологий Гартнера. Можно легко нагуглить текущий статус по вашей отрасли. Для примера приложил кривую гартнера по технологиям ИИ на 2023 год. Где там Chat GPT? :)

   Канал Growth anti-hacking

   

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

Давайте разберемся.

Пойдем от обратного. Множество ролей в компании отвечают или растят какие-то метрики. Менеджеры по продажам - выручку, саппорт - время реакции и удовлетворенность обслуживанием, инженеры - uptime и SLI, маркетологи - контакты. Они все продакты? Пожалуй что нет :)

Есть ли еще критерии, которым должен удовлетворять продакт менеджер? Минимальный набор, это:

• Присутствует объект управления - продукт (а, например, не процесс).

• Используются продуктовые подходы для управления продуктом.

• Критерии успеха - а вот тут уже появляются метрики, как самое частое обоснование бизнес ценности и способ измерения прогресса.

Может ли быть "продакт менеджер без метрики, по которой может рассказать о своих личных результатах"? В долгосроке скорее нет, но в моменте - легко! Например, при работе над стратегией продукта, или разработке продукта до его вывода на рынок.

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

Канал Growth anti-hacking

RAG или Finetuning?

В AI сообществе сложилась определенная классификация подходов к решению задач с помощью LLM. Вот хорошая статья про это. Мне была полезна такая классификация, возможно, будет полезна и вам. Позволю себе краткое саммари статьи.

Итак, есть два подхода.

RAG - Retrieval-Augmented Generation. Берут "generic" LLM, обученную на большом массиве данных и дополняют решение поиском по базе знаний, специфичной для вашего домена. Подходит, например, если делаете систему помощи для работы с внутренней базой знаний компании.

Finetuning. Снова берут уже обученную на большом датасете LLM и дообучают ее на меньшем наборе данных, специфичном для домена. Подходит, например, если делаете болталку на специфичные темы.

Простой набор вопросов, который поможет выбрать путь:

Выбирай RAG, когда: 

- требуется доступ к внешним источникам данных

- необходимо минимизировать галлюцинации модели

- нет большого набора данных для тюнинга модели

- специфичные данные меняются во времени

- необходима возможность анализировать источники и причины ответов системы

Выбирай Finetuning, когда:

- требуется модификация поведения или стиля ответов модели

- есть большой набор данных для тюнинга модели

- доменные данные статичны

- нет необходимости анализировать источники и причины ответов системы

Канал Чуть больше продакта

Каким продуктам можно иметь слабый UX?

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

Но UX продукта вызывает много вопросов. Скажу даже так - если бы не приходилось продираться через этот UX-ад, то многие свои задачи я бы решил намного раньше.

Пара примеров:

1. линкую одну Jira issue к другой, в поле поиска issue все время пытаюсь вставить ссылку на таску, а не название таски - не прокатывает. Приходится тупо редактировать ссылку и оставлять от нее только код issue. Тогда все находится.

   

2. для перехода в режим редактирования доски есть кнопка прямо на странице доски, но для редактирования проекта надо в верхнем меню найти раздел Jira Administration и там заново искать нужный проект.

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

Получается, такая стратегия вполне себе рабочая. Ведь идут годы, а UX остается убогим. Возможно, я такой один, но обработать вставку ссылки вместо короткого названия - не звучит как инициатива размера XL.

То есть, это просто не является частью стратегии продукта и компании. Значит, им можно и так. Но это не значит, что всем можно :)

Канал Чуть больше продакта

Как размер организации влияет на стиль выполнения задач продактом? Посмотрим на примере.

Задача - продуктовое исследование.

Маленький стартап. Сам подбираешь способ исследования, по неполным событиям подбираешь респондентов, делаешь анкеты и составляешь вопросы и потом делаешь выводы. Каждый элемент исследования сделан не идеально, зато быстро. Но не факт, что все 100% корректно.

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

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

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

Телеграм канал Чуть больше продакта

Компетенции технического продакт менеджера

Обсуждали как-то с коллегами как при найме проверять компетенции технических продакт менеджеров. Кажется, очевидный ответ - это продакт менеджер, но который еще понимает в разработку, архитектуру, и системный анализ. Так?

Ну а как это проверить? Может, проверить что знает эту "технину", на уровне джун-разработчика? А еще надо чтобы что-то про структуры и хранение данных понимал, может, и SQL немного проверим?

Но такой подход приведет к тому, что наймем продакт менеджера, который может "hello world" написать. Ну, или логи прочитать. Но это ли нам нужно?

На самом деле нет. Если нам нужен технический продакт менеджер, надо проверять его умение работать с той же архитектурой на синьорном уровне. Но не как архитектор. А с другой стороны, с продуктовой: продумать не функциональные требования: латенси, доступность, масштабирование, гибкость и расширяемость, спроектировать доменную модель (но не в таблицах в базе данных с типами полей - путь это делают инженеры!). И, самое главное, четко связать все это с потребностями бизнеса - то есть не пытаться делать все сразу идеально, а найти баланс между текущими потребностями бизнеса и стоимостью разработки. Дать команде разработки четкие цели, которые приведут к реальным бизнес результатам.

Технический продакт должен уметь разговаривать с инженерами, понимать их и челленджить. Но он не должен просто делать какую-то часть их работы. Так мы наймем "недоразработчика".

Телеграм канал Чуть больше продакта

В конце прошлого года Microsoft неожиданно сделала заявку на дизрапт рынка поисковиков. Chat GPT создал волну хайпа, а компания быстро заявила о планах по внедрению технологии в свои продукты. Казалось, наконец кто-то скинет Goolge с пьедестала поисковиков. Да, Google явно отстал в этой технологической гонке.

Однако, если верить статистике, то за год доля Google на рынке даже несколько выросла.

Так что же, не будет никакого изменения продуктовой категории? Не будет революции?

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

Но при этом слухи о смерти Google оказались преувеличенными. Любая технология еще должна пройти определенный путь до внедрения в массовые реальные продукты. А здесь вовсе не обязательно быть первым. Каналы продаж и аудитория - устойчивые конкурентные преимущества.

Microsoft не была первым на рынке корпоративных мессенджеров, но быстро обошла Slack, когда выпустила Teams. Все благодаря доступу к аудитории - пока Slack привлекал инноваторов и с трудом боролся за ранних последователей, Microsoft легко пришел и забрал основную массу клиентов. Забавно, но сейчас Microsoft может оказаться в противоположной ситуации - компания подогрела рынок и вывела тестовые продукты, но сможет ли она воспользоваться всеми плодами грядущей революции?

Телеграм канал Чуть больше продакта