10 главных причин провала продуктов

Эта статья — краткая выжимка доклада Марти Кагана на конференции mind the product в 2018 году. Марти Каган — один из совладельцев компании Silicon Valley Product Group, помогающей создавать стратегии создания прорывных продуктов. Марти участвовал в разработке многих успешных продуктов в eBay, AOL, Netscape Communications и Hewlett-Packard. Он был старшим вице-президентом по управлению продуктами и дизайном в eBay, а до этого — вице-президентом в AOL и Netscape Communications, а также инженером-программистом в HPLabs.

Итак, 10 главных причин провала продуктов по версии Марти Кагана.

Обычными источниками идей новых продуктов, разработок и инициатив в компаниях являются собственники, члены совета директоров или покупатели (будь то b2c или b2b компании). Не то чтобы эти источники были плохи, но ограничиваясь ими мы упускаем огромный кладезь очень ценных возможностей, о которых нам могли бы рассказать наши инженеры. Именно они проводят с продуктом больше всего времени и именно они знают, что возможно реализовать в продукте и что, скорее всего, будет очень востребованно со стороны пользователей. Не приглашать инженеров к обсуждению новых идей и инициатив — большая ошибка.

Выбрав какую-то идею, бизнес как правило, сразу старается получить ответы на два сакральных вопроса: сколько это нам принесёт и сколько это стоит? Но правда состоит в том, что на данном этапе никто и понятия не имеет ни об одном, ни о другом. Тем не менее тратятся огромное время и ресурсы на то, чтобы это подсчитать, как будто сам по себе факт этих затрат способен сделать расчёты достовернее. Не обманывайте себя "проработкой" рисков. Вместо этого исходите из того, что у вас есть только лишь самое общее представление о том, что реализация этой идеи позволит вам в итоге заработать больше, чем вы собираетесь потратить, и вам придётся дальше двигаться с этим уровнем неопределённости, постепенно уточняя оценки, вместо того, чтобы тщетно пытаться получить точные оценки на старте.

Что касается планов (бэклога или дорожной карты, называйте как хотите), про них существуют две неудобные правды. Первая: как минимум половина того, что вы напланировали, никогда не будет претворено в жизнь. И вторая касается второй половины: даже если вам удастся её реализовть, потребуется несколько итераций для того, чтобы всё начало работать, как задумывалось изначально. Проблема с планами в том, что руководство воспринимает план как обещание, договор, и пытается заставить команду придерживаться его даже тогда, когда уже всем понятно, что план не выгорел. Ещё бы, ведь мы так много времени потратили на старте, чтобы договориться об этом плане — как же мы можем просто взять его и выкинуть? Как говорил Джеф Безос: «Будьте тверды в своих намерениях, но гибки в своих планах».

У многих компаний в описании вакансии менеджера продукта так и написано: собирать требования, описывать, документировать и так далее. Это совершенно не то, чем должен заниматься менеджер продукта. Для этого есть совершенно отдельная роль — проектные менеджеры. Работа сложная, важная, нужная. Но другая. Заставлять делать это продактов — большая ошибка. Ведь тогда они не смогут сделать того, для чего вы их на самом деле наняли — сделать вам продукт.

Когда мы нанимаем дизайнера, мы думаем о нём, как о человеке, который нам всё нарисует. Но это весьма поверхностно. В команде должен быть кто-то, кто спланирует и сконструирует сценарии пользователей, чтобы ваш продукт был удобен и понятен в использовании (а от этого в конечном счёте зависит ни много ни мало будут ли им вообще пользоваться). Графический дизайнер сможет только лишь отрисовать графику по готовому ТЗ. Но если у вас в команде нет человека, который сможет выдать ему качественное ТЗ — у вас проблема. И нет, это не менеджер продукта.

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

Все нынче знают про аджайл и работают по аджайлу. Но гибкости, которую аджайл должен подразумевать, нет и в помине. Сначала идеи, потом оценка, потом планирование, приоритизация, сбор требований, дизайн, разработка, тестирование, выкат на пользователей. Знакомо? Так вот — это не аджайл. Если ваши процессы не позволяют запустить новую итерацию ровно тогда, когда стала понятна её необходимость — скорее всего вы недостаточно гибки, чтобы преуспеть в том, чем вы занимаетесь.

Если ваш производственный процесс выстроен так, как написано в предыдущем пункте (так называемая водопадная модель), но он проектоцентричен, а не продуктоцентричен. И проблема тут в том, что можно сделать проект по всем правилам, и на выходе получить очень дорогую и абсолютно никому не нужную разработку. Путать процесс с результатом в бизнесе просто опасно.

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

Большинство компаний, с которыми мне приходилось работать, испытывают кадровый голод. Они вынуждены платить огромные зарплаты, и всё равно не могут нанять достаточно специалистов. В этих условиях работать по водопадной модели и браться за проекты с длинным горизонтом возврата инвестиций (а водопадная модель вам другого не предложит) — это прямой путь в могилу.

Меня зовут Евгений Самойлов, я занимаюсь бизнес-трекингом стартапов, зрелых бизнесов и корпоративных команд. Контакт для связи: