product development что это
Да кто вообще такой этот продуктовый разработчик?
Сегодня в названиях вакансий всё чаще появляются приставки «продуктовый» — дизайнер, аналитик, разработчик… Компании, придерживающиеся продуктового подхода, ожидают от кандидатов определённого образа мышления, хороших технических скиллов бывает недостаточно. Меня зовут Михаил Мазеин, я тот самый продуктовый разработчик в ManyChat, занимаюсь бекэндом и участвую в процессе найма. Давайте расскажу, как это выглядит изнутри.
Помните известную байку про двух программистов-одногруппников? Один из них был троечником, второй — заядлым отличником. Троечник сделал небольшой прототип, за несколько месяцев открыл компанию, вышел на рынок. А отличник работал над очень продуманной и красивой архитектурой. В итоге через два года у троечника была компания и ниша на рынке, а отличник пришёл к нему на собеседование. История ироничная, но под капотом лежит довольно много правдивых фактов.
@innubis
Продуктовая разработка и MVP
Для начала давайте обсудим, чем продуктовая разработка отличается от проектной. Приведу пример — у проектной разработки путь такой же, как при ремонте квартиры: заказали дизайн-проект, пришли рабочие, реализовали всё по нему — готово. Схема рабочая и стара как мир. Но продукт — меняющаяся и живая сущность: в квартире вам могут разонравиться обои, потом нужно будет переделать гостиную под комнату для детей, вы заведёте кота и так далее. Поэтому подход «сначала делаем немного, потом смотрим, что с этим будет на рынке, затем доделываем» выгоднее экономически: меньше time to market, больше шанс не делать полгода работу, которая никому не будет нужна. Работа над продуктом – это бесконечный процесс, когда вы его улучшаете через небольшие итерации при помощи небольших проектов.
Создавая продукт мы чаще всего работаем по принципу проверки гипотезы на прототипе (MVP), который отдаём реальным юзерам. MVP — это минимально рабочий продукт, который даёт возможность продакту что-то протестировать, а разработчику — реализовать функционал минимальным количеством ресурсов, чтобы не аффектить архитектуру (ладно, не аффектить архитектуру слишком сильно). Это на тот случай, если гипотеза не оправдает ожиданий, и код будет выпилен, чтобы не поддерживать. Да, хоронить проекты никто не любит, но MVP тут как раз и помогает — сократить боль от невыполненных проектов. То есть прототип электромобиля — это не шасси или самокат с габаритной моделью, а «Запорожец» на аккумуляторе. Кондиционер и прочее повесим после.
Баланс между техникой и продуктом
Итак, я разговариваю на эльфийском, постоянно сыплю какими-то непонятными гипотезами, метриками и идеями, не давая спокойно пилить код. Хуже, я регулярно мешаю работать, прося что-то перестать делать, а что-то вообще выкинуть из прода. То есть веду себя как типичный продакт — какой-то опасный гиперобщительный чувак, попивающий смузи. При этом я же разработчик.
Опасная пересоциализация в образе ПР — это оттого, что идёт постоянное общение: с пользователями, коллегами, представителями бизнеса. Но нам необязательно это делать в таком же активном режиме, как это делают продакт-менеджеры, устраивая созвоны. Можно почитать тикеты в саппорте, посмотреть форум, ознакомиться с feature requests, попросить аналитика прислать какие-нибудь исследования — главное, это попытаться понять, какие именно проблемы решают при помощи вашего продукта другие люди и какие у них есть потребности.
Продуктовый разработчик находится посередине между программистом и продакт-менеджером, соединяя в себе лучшее от двух ролей, он озабочен технологиями и пользовательским опытом в равной мере. Ему нужно понимать продукт настолько, чтобы с технической точки зрения помогать продактам достигать целей и предлагать варианты, как проверить гипотезу минимальными средствами. Например, вместо того, чтобы делать сложную валидацию формы сбора номеров телефонов, можно начать с простой валидации длины и символов в номере, постепенно улучшая по фидбеку пользователей и добавляя дополнительные этапы валидации, включая определение страны и региона через внешние библиотеки/апи, добавляя в следующих итерациях определение оператора, обслуживающего номер телефона.
Не бойтесь быстрых экспериментов для проверки реакции. Сутки на фичу — и вот уже люди пишут, что и как нужно. А вы понимаете, как вашу архитектуру и вашу кодовую базу нужно будет поменять для того, чтобы в дальнейшем это было проще расширяемо и поддерживаемо. Так что ПР — это своего рода учёный, который через цепочку опытов открывает что-то новое.
Что мерить, если не длину кода
ПР ориентируется на продукт в глазах пользователя. Чем больше ценности у продукта — тем лучше работает ПР. Если говорить конкретно о ManyChat, то продуктовый разработчик — это человек, который начинает думать не только о том, как писать код, но и о том, какую ценность его код несёт.
Каждый раз, когда ты пишешь какую-то строчку кода, ты принимаешь решение о том, как твой пользователь воспользуется этим функционалом, который ты только что написал. И поэтому стоит думать в этот момент о том, будет такой кейс или не будет такого кейса, если будет, то сколько людей из сотен тысяч им воспользуются, стоит ли один пользователь из миллиона поддержки этого функционала в будущем и так далее.
Когда у нас продакт-менеджер приносит фичу, продуктовый разработчик вполне может почелленджить его на предмет, действительно ли эту гипотезу нужно делать. И когда они оба находят точки синхронизации, то это идёт в реализацию. После этого, когда видно, как заработал продукт, все вместе смотрят на фидбек и проблемы и находят решения.
Функция разработчика меняется с обеспечительной в духе «Напишите нам тут ещё кода» на стратегическую. То есть решения начинают приниматься там, где быстрее их реализовать. Чтобы стать ПР, на самом деле достаточно болеть за свой продукт или компанию и разбираться в деньгах. Полезно будет изучить, как бизнес монетизирует создаваемую ценность в софте, разобраться в ключевых метриках: что для вашего продукта и бизнеса важно (MAU, DAU, другие показатели), как эти метрики влияют, на чём сейчас фокусируется бизнес для того, чтобы стать успешнее. Стоит следить за трендами рынка, где позиционируется бизнес, погружаться в бизнес-контекст, но при этом не забывать о технической составляющей. Моя задача, как продуктового разработчика, объяснять бизнесу, как всё работает и находить компромисс, в том числе, чтобы закладывать время на архитектурные улучшения и поддержку, чтобы не копить техдолг.
Для разработчика в момент, когда он перестаёт решать какие-то конкретные узкие задачи, и начинает мыслить категориями бизнеса, — профессиональный и, наверное, в том числе, материальный рост. Не стоит забывать, что бизнес платит не за количество строк, а за решение проблем пользователей. А пользователи платят за это бизнесу.
С чего начать
Если желания самостоятельно выходить из зоны «я пишу код по задаче, и всё хорошо» нет — то не надо, кому-то важнее уровень определённости и ближе проектная разработка. Если человек не вылезает за пределы спеки и не спрашивает, как лучше писать фичу, — скорее всего, не в его характере мыслить «за ту сторону». А тем, кому хочется расширить кругозор и быстро видеть результат работы, я могу посоветовать следующее:
Почитать
Эрик Рис — «Бизнес с нуля. Метод Lean Startup для быстрого тестирования идей и выбора бизнес-модели»
Экономичный стартап — это целый подход, который позволяет разрабатывать действительно нужные для пользователя продукты. Из названия может сложиться впечатление, что подход применим только к стартапам. Но сам автор утверждает, что это нет так: стартап для него — это любой проект, даже если он реализуется внутри крупной компании. На примерах историй различных бизнесов книга рассказывает о важности быстрого тестирования гипотез на реальных пользователях, сборе обратной связи, её анализе и последующих корректировках. В этой книге автор определяет такие понятия, как MVP, гипотеза роста, гипотеза ценности, прыжок веры и многое другое.
Cindy Alvarez — «Lean Customer Development»
Если вы уже готовы пообщаться с пользователями и провести свой первый CustDev, но не знаете, с чего стоит начать, это книга может вам помочь. Здесь вы легко сможете найти информацию о том, как правильно выбирать пользователей для интервью, как правильно проводить интервью, чтобы найти настоящую боль пользователя, почему полезно показать даже минимально жизнеспособный макет, чтобы получить первый фидбек и проверить свою гипотезу.
Майк Кон — «Пользовательские истории. Гибкая разработка программного обеспечения»
В этой книге подробно описан процесс подготовки требований к разработке на основании исследования пользователей продукта и выявления пользовательских историй — коротких и понятных кейсов, которые принесут ценность для конечного юзера продукта. Если вы решите прочитать книгу, то найдете практические методы сбора историй; как действовать в тех ситуациях, когда нет возможности непосредственно пообщаться с пользователями; объяснения, что делает истории хорошими или плохими и многое другое, что поможет эффективно применять данный подход для постановки задач и планирования.
7 этапов разработки (NPD) New Product Development
Разработка нового продукта – это процесс, позволяющий пройти от этапа идеи до этапа реализации и запуска. В ходе разработки продумывается идея, анализируется ее успешность, проводится оценка и подбираются пути реализации. Дальше начинается технический процесс. Мы определили 7 этапов разработки, которые позволяют вывести новый продукт на рынок.
Что такое New Product Development?
New Product Development – это концепция, подразумевающая вывод нового продукта на рынок при помощи основных рыночных принципов. Иными словами, это процесс превращения потребностей рынка в идеи, которые реализуются при помощи готового продукта.
Как это работает? Генерируется новый продукт, который может быть полезен на рынке. Проводится аналитика и рождаются идеи. Они проверяются и создается концепция. Например, компания может создать сервис, полезный для их клиентов. Он уникален, или является лучшей версией уже существующих продуктов.
В итоге происходит разработка продукта, который размещается, скажем, на сайте компании. И это уже востребованный сервис, а сайт становится популярным и полезным, благодаря чему компания растет и получает прибыль.
Разработка нового продукта имеет множество задач. Среди них – сделать выход эффективным, быстрым и менее затратным, ориентированным на рынок и потребности, экономически обоснованным. Для бизнеса последний пункт – наиболее важен, но и другие факторы нужно учитывать.
Разработка продукта помогает компании повысить уровень конкурентоспособности, особенно на фоне технологического роста и изменений, улучшить взаимодействие с клиентами и масштабироваться.
Этапы New Product Development
Вывод нового продукта на рынок – это длительный процесс, но главное, он имеет четкую структуру. Условно разработка продукта разделяется на 7 основных этапов.
Этап 1: Генерация идеи
Идея – это один из главных этапов в разработке любого продукта. И начинается он с оценки рынка и целевой аудитории.
Создание идеи – ключевой фактор, но при этом, довольно динамичный. Нередко генерируется большое количество идей, они проверяются, анализируются, и даже начинают тестироваться. Но уже в ходе работ возникают новые улучшенные идеи, позволяющие сделать новый продукт еще лучше.
Акцент внимания на проблемах и задачах клиентов
Разработка нового продукта при помощи пользователей – это возможность быстро сгенерировать идею и создать продукт с высоким уровнем востребованности на рынке. Суть его заключается в том, чтобы сделать сразу то, что необходимо пользователям. Нередко маркетологи и аналитики берут идеи именно от пользователей, так как это помогает значительно снизить расходы на разработку и ускорить процесс запуска.
Поэтому на этот этап выделяется немало времени, а также большая группа специалистов, которые сразу должны видеть, как будет проходить маркетинг продукта, как его будут в дальнейшем предлагать пользователям и как он поможет принести компании выгоду.
Этап 2: Проверка идеи
Недостаточно только создать хорошую идею, важно ее проанализировать и на этом этапе понять ее жизнеспособность. Анализ продукта помогает заведомо понять, будет ли он востребован.
Проверка идеи экономит в дальнейшем массу времени и средств, так как помогает не просто оценить перспективы востребованности продукта, но и собрать более точные данные. Например, статистику, понять финансовые расходы на реализацию и рассчитать ориентировочные доходы.
Что такое SWOT-анализ и зачем он нужен при проверке идеи
SWOT-анализ – это метод исследования сильных и слабых сторон с целью определить перспективы нового продукта. Он позволяет понять все возможности, потенциальные угрозы и риски, связанные с конкурентами, изменением рынка или другими факторами.
Главная задача SWOT-анализа – убедиться в эффективности идеи, понять, реально ли ее осуществить и какими силами это можно сделать. Благодаря этому методу, маркетинг продукта выходит на новый уровень. Есть ряд рекомендаций, позволяющих проанализировать данные как можно точнее:
Этап 3: Разработка концепции и тестирование
Каждый новый продукт должен нести смысл и быть полезен. В этом заключается концепция. Но прежде ее нужно проверить, действительно ли она соответствует потребностям рынка, и будет ли такой продукт востребован. Кроме того, концепция включает формирование общей картины. Она отвечает на два главных вопроса: что нужно для успешного запуска нового продукта, и как это можно сделать. Также необходимо протестировать ее, чтобы избежать ошибок.
Количественная оценка соотношения «прибыль / боль»
Важно понять, какие потребности есть у потенциальных клиентов, и что им можно предложить, чтобы получить из этого прибыль. Любое лекарство создается для того, чтобы снять боль. Разработчики или владельцы такого лекарства получают прибыль.
Оргструктуры, дружелюбные к новым продуктам, наш опыт
Меня зовут Дмитрий Черноморец, занимаюсь разработкой новых продуктов в Humathèq.
Мы помогаем нашим клиентам из разных отраслей создавать новые продукты, модернизировать существующие: находим новые продуктовые идеи, разрабатываем концепции продуктов, работаем над промышленным дизайном, создаём конструкторско-технологическую документацию, помогаем ставить продукты на производство, выводить на рынок.
Права на разработанные продукты принадлежат нашим клиентам.
Проблема, с которой мы встречаемся – организационные структуры многих клиентов не дружелюбны к новым продуктам, в результате новые продукты либо не выходят в релиз, погибая на стадии постановки на производство, либо запускаются в искажённом виде и умирают на рынке.
Когда мы помогаем «протаскивать» продукты через все стадии рождения, на преодоление внутрикорпоративных сопротивлений тратится очень много времени и энергии.
При этом когда клиент это делает по образу и подобию нашей работы, ничего не получается.
Мы всегда работаем в открытую, у нас нет желания привязать клиентов к себе, чтобы они без нас не могли создавать и запускать новые продукты, мы рады, когда вместе с продуктами клиенты получают трансфер NPD-технологий.
NPD (New Product Development) / Разработка нового продукта – устоявшийся термин, используемый для обозначения полного цикла создания и запуска нового продукта на рынок, от рождения идеи до начала коммерциализации продукта.
NPD включает следующие процессы: генерацию идей нового продукта; разработку концепции нового продукта; разработку бизнес-модели нового продукта; тестирование продукта на всех стадиях разработки; создание промышленного дизайна нового продукта; инженерное проектирование; постановку продукта на производство; вывод продукта на рынок.
С одной стороны, имея множество кейсов «протаскивая» новых продукты через компании клиентов мы сформировали понимание того, что же ингибирует (тормозит) NPD-процессы.
С другой – мы постоянно изучаем опыт наиболее успешных компаний в новых продуктах и инновациях, до ковида у нас было много производственного туризма в компании Европы, США, Китая, Южной Кореи.
1. Сложные непрозрачные структуры с непонятными коммуникациями, размытой ответственностью.
Непонятно, кто как и на каком этапе участвует в создании новых продуктов, кто за что отвечает, что делать, если возникает конфликт между отделами.
Создание и запуск нового продукта превращается в «Санта Барбару».
2. Отсутствие мотивации на новые продукты.
В новых продуктах заинтересованы многие, но только на уровне риторики.
Фактически, новые продукты органически нужны собственникам бизнеса и еще нескольким пассионарным сотрудникам.
Продавцы, маркетологи, конструкторы, технологи хотят новых продуктов только на словах.
3. Нет продукт-менеджеров, сотрудников, отвечающих за создание новых продуктов, обновление существующих, инновации, «пушеров» NPD-процессов.
Это основное, остальное вторично.
Главный принцип – разделяй и властвуй (не мешай все в кучу).
Компания разделяется на бизнес-единицы (бизнес-юниты) по принципу – каждая бизнес-единица может в любой момент выделиться из компании и стать самостоятельным бизнесом.
Здесь ключевое не про выделится, а про бизнес-модель, которая позволяет зарабатывать, как внутри корпорации, так и за её пределами.
Полученные бизнес-единицы на уровне юридической конструкции бизнеса могут быть отделами, департаментами, дивизионами или выделяться в отдельные юридические лица.
Иногда выделение бизнес-единиц в отдельные юридические лица выгодно с т.з. налогооблажения и мотивации сотрудников, но это уже другая история.
Если интересен этот момент, спрашивайте в комментариях, поделюсь.
Самый важный момент достичь между бизнес-единицами отношений «заказчик — исполнитель» вместо «коллега — коллега».
Практика показывает, что первое эффективнее второго, это настоящий капитализм.
Ещё одно важное требование – вся бизнес-модель должна крутиться вокруг клиентов и пользователей, как планеты вокруг Солнца (планеты – бизнес-единицы, Солнце – клиенты и пользователи).
Клиенты – те, кто платит деньги, пользователи, те – кто взаимодействует с продуктом.
Давайте представим, что каждая компания – это минимально самодостаточный бизнес-организм, который в сотрудничестве с другими компаниями способен создавать, тиражировать и продавать продукты.
Все начинается с продуктовых компаний, они исследуют клиентов и пользователей, выявляют их проблемы и боли, ищут идеи их решения, в результате разрабатывают концепции новых продуктов.
Концепция нового продукта включает в себя дизайн, техническую архитектуру, маркетинговую и экономическую модели, прототипы начальных уровней.
Продуктовые компании обращаются к R&D-компаниям за разработкой на основе продуктовых концепций конструкторской документации, опытных образцов (лабораторных прототипов).
Заказчиком разработки конструкторской документации являются продуктовые компании, они ставят задачи, принимают результаты, оплачивают услуги R&D-компаний.
Продуктовые компании выбирают R&D-компании, руководствуясь их профессионализмом, репутацией, ценовой политикой.
Продуктовые компании – заказчики, R&D-компании – исполнители, их связывает договор с взаимными обязательствами и ответственностью.
Происходит классический обмен денег заказчика на результаты труда исполнителя.
Договор также предусматривает ответственность сторон в виде штрафов на случай невыполнения своих обязательств сторонами.
Как показывает практика, это намного эффективнее, нежели классические отношения между отделами компании, их сотрудниками, т.к. в компании по факту нет ни выбора исполнителя, ни ответственности.
После того, как у продуктовой компании появляется конструкторская документация, она обращается к производственным OEM-компаниям для постановки продуктов на производство и последующего тиражирования в соответствии с потенциальным спросом.
Здесь продуктовая компания снова заказчик, производственная OEM-компания – исполнитель, их связывает договор контрактного производства.
Есть взаимные обязательства, где стороны друг перед другом несут настоящие обязательства и настоящую ответственность.
Уверен, вы часто видели на упаковках разных товарах фразу: «произведено одной компанией по заказу другой компании» — это, как раз тот самый случай.
Итак, пока происходит постановка продукта на производство, а точнее на финальной стадии процесса, продуктовая компания начинает выводить продукт на рынок, передавая его различного рода торговым компаниям (ритейлерам, дилерам, дистрибьюторам) или через маркетплейсы.
Опять же, связывая себя с ними договорными обязательствами и взаимной ответственностью.
В итоге продуктовые цепочки могут состоять из компактных продуктовых компаний, аутсорсинговых R&D-компаний, а также OEM-производителей, давая рынку действительно сильные продуты.
Теперь давайте перенесем эту логику на корпорацию, в которой перечисленные компании будут бизнес-единицами, а отношения между ними будут идентичны отдельным бизнесам.
В результате получаем эффективно работающую организационную структуру, прозрачную, высокомотивированную, саморазвивающуюся.
Продуктовые БЕ (бизнес-единицы) инициируют создание новых продуктов, разрабатывают продуктовые концепции, управляют жизненным циклом своих продуктов.
Каждая продуктовая бизнес-единица управляет однородной группой продуктов, фактически являясь внутренним владельцем интеллектуальной собственности на продукты.
R&D БЕ ведут разработку продуктов на основе заданий продуктовых бизнес-единиц (не проявляя самодеятельности в постоновке задач) и сдают результаты своего труда внутреннему заказчику (продуктовой БЕ).
R&D БЕ могут, как показано на примере, быть 2х типов: работающих на коротких дистанциях, когда задача разработки носит высокодетерминированный характер, работающих на перспективу, когда сегодня разрабатывается инновационная технология, которая ляжет в основу будущих продуктов перспективы 3-5-10 лет.
Производственные БЕ выполяют тиражирование продуктов в соответствии с конструкторской документацией, принадлежащих продуктовым бизнес-единицам на условиях внутриконтрактного производства.
Сбытовые БЕ продвегают и продают продукты в регионах присутствия.
За успех продуктов полностью отвечают продуктовые БЕ.
За последние 5 лет мы помогли нескольким клиентам (приборостроение, металлургия, робототехника, продукты питания, фармацевтика) построить такие структуры, в результате получили прорыв эффективности: компании сами стали генерировать новые продукты, быстро разрабатывать, производить и тестировать прототипы, ставить на производство, запускать на рынок.
Организационный консалтинг, это не наш бизнес, здесь мы скорее помогаем нашим наиболее лояльным клиентам, поэтому таких проектов не сотня, их менее десяти, при этом, согласитесь, у нашей выборки есть признаки репрезентативности.
Краткое пособие для продукт-менеджеров: 59 принципов разработки новых продуктов от Humathèq
Компания, в которой я работаю (Humathèq) занимается разработкой новых продуктов. Мы помогаем нашим клиентам анализировать их продуктовые портфели (ассортимент), находить идеи новых продуктов, разрабатываем концепции и прототипы новых продуктов, делаем инжиниринг продуктов их постановку на производство и помогаем выводить разработанные продукты на рынок.
Работаем мы в самых разных отраслях: приборостроение, машиностроение, IT, продукты питания, услуги (сервисы), мебель, двери, интерьерные продукты, строительные материалы и конструкции.
Чуть позже я напишу статью о том, как устроен наш бизнес изнутри и, как мы умудряемся успешно решать задачи в самых разных продуктовых областях.
Ладно, небольшой спойлер: под каждый продукт мы формируем команду разработчиков, где обязательно присутствуют эксперты из отрасли, в которой мы выполняем соответствующий R&D-проект, причём разработчики могут быть из любой страны мира. Кстати, из опыта, самые классные продукты получаются, когда работает максимально интернациональная команда.
Итак, для того, чтобы у вас сформировалось более полное впечатление о нашем бизнесе, в конце статьи я дам несколько интересных ссылок на VC.RU.
А сейчас переходим к обещанным в заголовке принципам, которые мы с коллегами сформулировали пару лет тому назад и исповедуем до сих пор:
1. Что такое сильный и слабый продукты: СИЛЬНЫЙ продукт – это продукт, который продаёт себя сам и тем самым обогащает своего создателя и владельца. СЛАБЫЙ продукт – это продукт, который не решает проблемы и боли клиентов и пользователей, а, следовательно, за него не готовы платить. В результате слабый продукт, это продукт, который не продаётся, и генерирует убытки.
2. Несмотря на то, что речь идёт о B-to-B (а не о B-to-C) продуктах – они не создаются для компаний, корпораций, организаций и т.д. Они создаются для конкретных людей, которые в этих компаниях, корпорациях, организациях принимают решения и пользуются этими продуктами, решая свои профессиональные и личные проблемы.
3. Кроме клиентов, ещё существуют пользователи, потребители, дистрибьюторы, которые имеют свои интересы и проблемы, отличающиеся от интересов и проблем пользователей.
4. Продукты создаются для решения проблем, а не для того, чтобы “поиграться в технологии” и реализовать свои знания и умения. Если продукт не решает проблемы – он никому не нужен, и за него никто не будет платить деньги.
5. Люди на первое место ставят личные проблемы, далее следуют – профессиональные. При этом в целях политкорректности декларируют обратное.
6. Конечной целью создания продукта – является прибыль, при этом на работу мы ходим, чтобы зарабатывать деньги. Да, удовольствие от работы – это приятный бонус, но деньги на первом месте, иначе мы потерям нюх и разорим компанию своими порывами немонетизируемой самореализации.
7. Чаще всего создание универсального продукта (продукта для всех) заканчивается провалом. Напротив, чем точнее целишься в однородные группы клиентов / пользователей, тем вероятность успеха становится выше согласно геометрической прогрессии.
8. Сильный продукт нуждается в инновациях, инновации решают проблему конкуренции и низкой маржинальности. Фактически, современная компания должна стать фабрикой инноваций.
9. Продукты быстро устаревают, их копируют, поэтому продукты нужно постоянно развивать, подпитывая улучшающими инновациями, вовремя списывать и выводить новые, построенные на прорывных инновациях.
10. Сильные продукты создаются не талантливыми или назначенными одиночками, а увлечёнными мультикомпетентными командами во главе с продукт-менеджерами, которые в свою очередь отвечают за успех продуктов.
11. Чтобы продукт хорошо продавался, он должен решать не только проблемы пользователя, но и клиента и дистрибьютора (если он есть в цепи поставок).
12. Сильный продукт должен быть одновременно функциональным, эмоциональным, выгодным (для клиента, пользователя, дистрибьютора), уникальным и безопасным.
13. Лучше, чтобы продукт выполнял одну или две функции, но на грани перфекционизма, нежели, чтобы продукт был многофункциональным, но при этом, ни одна из функций не выполнялась полностью.
14. При анализе продукта сравнения нужно проводить не с конкурентами, а с ожиданиями клиентов, пользователей, дистрибьюторов.
15. Продукт не будет продаваться, если клиенты, пользователи и дистрибьюторы ничего о нем не будут знать, поэтому новый продукт особенно нуждается в маркетинговой поддержке.
16. Говоря об экономике продукта необходимо постоянно анализировать его маржинальность, прибыль, которую генерирует продукт, а также рентабельность R&D. Поэтому процесс R&D должен быть быстрым и дешёвым и лучше всего осуществляться за деньги клиентов.
17.Стоимость продукта может быть всегда выше, если это повышение находится в нечувствительном для клиента диапазоне (закон эластичности спроса), или если растёт ценность продукта.
18. Важно своевременно принимать решения об окончании продаж и производства продукта. Продукт должен завершать свою “карьеру” чемпионом.
19. Продукт должен быть для компании технологичным, т.е. компания должна иметь возможность быстро его воспроизводить и видоизменять, в т.ч. обладать нужными технологическими компетенциями. Работа с подрядчиками и поставщиками технологий не терпит дилетантства.
20. Продукт всегда можно сделать лучше, вопрос в доступности технологий и экономической целесообразности улучшений.
21. Невозможно разработать сильный продукт, если ты ничего не знаешь о клиенте, пользователе, дистрибьюторе. При этом общение с клиентами, пользователями, дистрибьюторами – это не больно, это иногда и приятно (если правильно выстроить коммуникацию).
22. В основе концепции нового продукта находятся гипотезы, которые требуют подтверждения, для этого в первую очередь и нужны маркетинговые исследования. Т.е. проводя исследования, мы не собираем и так понятную информацию, а подтверждаем или опровергаем ранее сформированные гипотезы.
23. Шансы создания по-настоящему сильного продукта многократно увеличиваются, если к процессу разработки приглашаются клиенты, пользователи, дистрибьюторы, внешние эксперты, понимающие проблемы тех, для кого разрабатывается продукт, а также владеющие технологиями.
24. Говоря о проблемах клиентов, пользователей и дистрибьюторов важно понимать, что же такое проблема. В нашем понимании, проблема – это дискомфорт, который испытывает человек при недоступных способах от него избавиться. Также важно принимать во внимание такое явление как боль. Боль – это проблема высшей степени актуальности, где клиент готов заплатить любые деньги за её решение. Поэтому успешный продукт должен решать проблемы, а суперпродукт – избавлять от болей.
26. Продукт-менеджер и его команда не должны брезговать созданием прототипов, особенно если речь идёт о прототипах нулевого уровня. На этом этапе дизайнеры-визуализаторы не нужны.
27. Процесс разработки – это итерационный процесс, где, выполняя первую итерацию, психологически нужно быть готовым ко второй, третьей, четвертой и т.д.
28. В ходе одной из итераций продуктовая команда может прийти к выводу, что продукт “не взлетит”. И здесь нужно набраться мужества, чтобы отказаться от продукта.
29. Прежде чем продукт станет продуктом, он требует тестирования, начиная со стадии прототипа нулевого уровня, завершая тестированием первого образца. В принципе, тестирование происходит на всём протяжении жизненного цикла продукта, что необходимо для его постоянного совершенствования и поддержания актуальности.
30. Люди не любят и не читают инструкции, вернее читают, но тогда, когда уже что-то пошло ни так, т.е. тогда, когда они испытали отрицательные эмоции от пользования продуктом. Если во время тестирования пользователь не может самостоятельно разобраться с продуктом, продукт нуждается в доработке.
31. Продукт-менеджер должен очень хорошо понимать специфику R&D-процессов, в обратном случае он не может эффективно управлять как своей командой разработчиков, так и аутсорсинговой.
32. Стоимость разработки определяется некомпетентностью заказчика, поэтому нежелание погружаться работу подрядчика стоит очень дорого.
33. Отсутствие компетенций в компании не является ограничением для создания продукта, сегодня компетенции можно очень быстро наращивать через процессы обучения и рынок труда.
34. Agile делает разработку быстрее и эффективнее, но главное не заигрываться и не превращать здравый смысл, заложенный в agile в религию.
35. Сильная команда разработчиков (включая руководителя) и возможность быстрых замен, если что-то пошло не так – важное условие успешного завершения R&D-проекта в срок.
36. Разработчики должны в первую очередь быть замотивированы на сроки и качество выполняемых задач. Кроме денег разработчику важен внутренний рейтинг и референс-лист, который в будущем будет определять, в каких проектах он будет задействован. При этом самым важным мотиватором разработчиков является увлечённость проектом. Здесь задача продукт-менеджера влюбить разработчиков в задачу, тогда он получит максимальный эффект.
37. Планирование и контроль – это наше все!
38. Самый лучший тестировщик – это пользователь.
39. Любые разработки необходимо бюджетировать, также необходимо контролировать следование бюджетным ограничениям, в обратном случае может получиться так, что R&D-инвестиции отбить не получится, не говоря уже о «заработать».
40. С MVP (Minimum Viable Product, минимально жизнеспособный продукт) нужно быть очень аккуратным. Часто “играя” в MVP компании выбрасывают на рынок настолько сырые продукты, что они даже не способны «оторваться от земли».
41. Маркетинг нового продукта очень отличается от поддерживающего маркетинга. В первом случае нам необходимо вывести продукт “на орбиту”, т.е. обеспечить продукту “вертикальный взлёт”, во втором – корректировать “движение продукта по орбите”, перемещать “на орбиты большего радиуса”.
42. Думая о монетизации продукта, важно не останавливаться на одном способе монетизации. Например, если вашим продуктом является музыкальный инструмент, то на его упаковке может быть размещена рекомендация определённых расходных материалов и аксессуаров (разумеется, за деньги).
43. Сильный продукт-менеджер кроме всего прочего должен быть сильным маркетологом. В принципе все участники продуктовой команды должны понимать, как функционирует рынок, каким законам он подчиняется, какие доступны маркетинговые инструменты и технологии и как они работают.
45. Маркетинговая активность должна приводить к высокому охвату клиентов и пользователей, развитию бренда и лояльности клиентов, при этом не менее 75% маркетинговых усилий должны быть направлены на рост продаж.
46. Бренд – это инструмент, который решает две задачи: помогает склонять клиента и пользователя к выбору вашего продукта и помогает продавать дороже. Бренд по-настоящему состоялся, когда он превратился в имя нарицательное и его пишут с маленькой буквы.
47. В маркетинге нового продукта отлично работает правило Парето. У продуктовой команды часто возникает желание показать все, что они умеют, при этом важно сосредоточится на небольшом числе наиболее эффективных каналов и отработать их предельно результативно.
48. В 21 веке у большинства компаний существует соблазн сосредоточиться исключительно на on-line инструментах, игнорируя off-line, что в свою очередь делает олдскульные каналы менее конкурентными и достаточно эффективными. Одним словом, нужно совмещать on-line и off-line активность, не игнорируя что-то одно, а балансируя между реальным и виртуальным.
49. Маркетинговая активность – это дорогое удовольствие, а неэффективная маркетинговая активность – это расточительно, а, следовательно, короткий путь к банкротству. Поэтому, принимая решение о том, стоит ли реализовать ту либо иную активность – задайте себе вопрос: как это поможет нам больше зарабатывать. Если никак, то не тратим ресурсы.
50. Самый большой маркетинговый грех – это когда продукт-команда судит о клиентах, пользователях и дистрибьюторах по себе.
51. Планируя развитие бизнеса, продуктового направления, компания должна отталкиваться от желаемых будущих результатов (стратегических целей), а не от текущего состояния бизнеса.
52. Компания должна стремиться к изменению ситуации на рынке (революционный подход) вместо приспособления к сложившейся рыночной ситуации (защитный подход).
53. Бизнес должен стремиться к созданию новых пространств для конкуренции (новых сегментов, новых продуктов, новых бизнес-моделей ) вместо поиска своего места и своих продуктов в существующей структуре рынка.
54. Компания должна стремиться к прорывным инновациям, а не делать ставку на постоянные улучшающие изменения существующих продуктов, хотя второе тоже необходимо.
55. Планируя развитие, продукт-менеджеры, руководители направлений должны сочетать линейные модели прогнозирования с креативными подходами к определению целевого будущего.
56. Компания должна стремиться к смелому соединению новых ресурсов и использованию нетрадиционных источников знаний.
57. Бизнесу стоит предугадывать неартикулируемые проблемы, боли и потребности клиентов, пользователей, интеграторов и дистрибьюторов, там больше свобод для инноваций, чем в артикулируемых.
58. Бизнес-модели рождаются в ходе экспериментального и предпринимательского подхода, а не книжных теорий.
И, как я обещал, в конце немного интересных ссылок:
Короткое видео о 10 лайфхаках генерации новых идей:
А теперь с этим живите 🙂
Дмитрий, наткнулась на статью, увидела себя на фото, аж проностальгировала))
Чувствую, сейчас наверное напишу «много букаф», но благодаря вашим курсам по разработке продуктов у меня недавно снова случился «прорывной» продукт))
В нашем ассортименте он самый дорогой, я жутко стрессовала, как на просевшем рынке мы его продадим, а он взял и продал сам себя. Это моя любимая аксима, что продукт должен продавать себя сам, вижу и Ваша тоже.
Этот мой продуктище уже купила «Натура Сиберика», с колес так сказать. А это, на секундочку, лидер отрасли, «толкались локтями», чтоб первыми его получить. Мне теперь разрешают творить, что хочу))) от слова «творчество». И вообще в компании считают творческой натурой, а я ж работяга)) и прожженый продажник с нотками маркетолога))
Вы мне своевременно вправили мозги, научили мыслить по-другому))) хоть я и ленилась делать домашние задания (сорри, до сих пор стыдно), но эффект, как видите, налицо.
Ага, вот еще цифры (самой стал любопытен момент окупаемости), примерная прибыль от первой продажи первой партии этого продукта в 2.8 раз выше стоимости обучения у вас (на тот момент). И это просто 1 продукт из примерно 10 моих последних, и только первая «пробная» партия))) Так что, мной, как учеником, точно можете гордиться))