«Плохо выявленная проблема — это лишний вес, который тянет ваш стартап или компанию вниз».
Серийный предприниматель Арсений Санташев
— Сколько миллионов рублей ваша компания потратила на разработку продуктов, которые никому не нужны? Дайте угадаю: достаточно. В эту ловушку попадают как молодые стартапы, так и крупные компании, которые думают, что создают сложные навороченные продукты, но не решают реальных проблем пользователей. Почему так происходит? В этой статье я попробую ответить.
Я хочу предложить вам посмотреть на процесс создания продукта через одну наглядную метафору — эволюцию ракетных двигателей. Она отлично иллюстрируют путь создания продукта как в небольшом стартапе, так и в крупной компании. Прототип — это то, с чего все начинают. Избыточно сложный, перегруженный деталями.
На этом этапе команда пытается решить проблему, но еще не понимает, как именно, поэтому тестирует множество разных прототипов. Большинство организаций, как правило, не придает особого значения этой ступени. Однако именно фаза прототипирования является критически важной в продуктово-операционной модели (это такая модель, которая представляет собой подход к управлению и организации бизнеса, акцентируя внимание на взаимодействии между всеми операциями и продуктами, эта модель подчеркивает важность интеграции операционных процессов с продуктовой стратегией для достижения максимальной эффективности и конкурентоспособности), потому что, чем быстрее и больше вы отгружаете прототипов, тем выше шанс на инновацию. И под «быстрее» я имею ввиду отгружать хотя бы раз в две недели.
Вторая ступень — что в центре — уже больше похожа на рабочий продукт. Но посмотрите внимательно — двигатель все еще перегружен. Слишком много трубок, проводов, дополнительных элементов. Классическая ловушка второй ступени: пытаться угодить всем пользователям одновременно, не ликвидировав определенные риски. Результат? Продукт, который вроде бы много чего умеет, но ничего по-настоящему хорошо. Он ничем не отличается от аналогов. К сожалению, большинство организаций навсегда остаются на этой ступени, в результате чего топ-менеджеры начинают фокусироваться на оптимизации процессов, чтобы противостоять возрастающим затратам на «не очень» рентабельные продукты.
Третья ступень — это то, к чему нужно стремиться: все риски выявлены, решение найдено, а поставленные задачи выполнены. Однако, чтобы перейти на эту ступень, продакт менеджеру нужно проделать огромную работу, начиная с переосмысления работы продакт менеджера: то, что у вас титул «продакт менеджер», еще не означает, что вы обладаете нужной компетенцией, и вам можно поручить задачу.
Вот 11 красных флагов продакт менеджмента, являющиеся причиной, по которой организации тратят миллионы, создавая продукты, которые никому не нужны:
1) Огромные и криво составленные «карточки» с техзаданиями для команды;
2) Менталитет «IT-студий»
3) Водопадная модель разработки;
4) Дорожные карты и диаграммы Ганта;
5) Приоритезация вместо фокуса;
6) CustDev вместо Discovery (и Delivery);
7) Отсутствие продакт дизайнера;
8) Неплатящие пользователи/клиенты диктуют свои хотелки;
9) Отсутствие единого видения и продуктовой стратегии;
10) Отсутствие оценки компетентности продакт менеджеров;
11) Отсутствие сильного СРО, продакт-лидеров команд и коучинга.
Если в вашей организации есть два или более красных флага, то скорее всего ваши проДАКТ менеджеры по факту занимаются проДЖЕКТ менеджментом и застряли на второй ступени, в бесконечной петле разработки фич, составлении дорожных карт, формировании бэклога и умасливании стэйкхолдеров, когда их первостепенная задача — это устранение четырех ключевых рисков, которые можно выявить в процессе Discovery. Заметьте, я не использую слово CustDev.
В ходе Discovery продакт менеджер выявляет реальные проблемы пользователей, работая бок о бок, в связке, а не порознь, с продакт дизайнером (не путать с дизайнером, иллюстратором или кем-нибудь еще) и техлидом, создавая множество прототипов, чтобы найти такое решение, которое а) полюбят пользователи и будут готовы за него платить; б) оно будет легкое в использовании; в) инженеры (разработчики) смогут создать; и г) оно удовлетворяет бизнес-задачи, поставленные на квартал или год.
Главный урок, который можно извлечь, заключается в следующем: задача продакт менеджера — не создать самый навороченный продукт, а решить КОНКРЕТНУЮ проблему КОНКРЕТНЫХ пользователей максимально эффективно, а вот плохо выявленная проблема — это лишний вес, который тянет ваш стартап или компанию вниз.