Иногда наши рефлексы, вызванные инстинктом самосохранения, могут привести к летальному исходу. Например, когда переходишь дорогу в России, надо посмотреть сначала налево, а потом направо. А в Англии наоборот: сначала направо, затем налево. Если забыть о левостороннем движении — можно попасть под машину.
При переходе от проектного бизнеса (например, веб-студии или компании аутсорсинговой разработки) к продуктовому (разработка и вывод на рынок собственного решения) — происходит то же самое. Сложно избежать привычного подхода к бизнесу. Директор Акселератора ФРИИ Дмитрий Калаев рассказал о шести привычках проектного бизнеса, которые мешают продуктовому расти, а в самых тяжелых случаях — убивают стартап.
В проектном бизнесе к вам приходит клиент, чтобы решить конкретную задачу, и часто эта задача возникает только в его бизнесе. Клиент составляет техническое задание, и за его выполнение вам платят. Например, у вас веб-студия или компания аутсорсинговой разработки: вы продаете свою экспертизу и человеко-часы. Причем, возможно, у вас есть отдел, который аутсорсит разработку для американского стартапа или компании. В случае успеха стартапа у отдела возникает ощущение сопричастности, но по факту он все равно выступает для этой американской компании в роли подрядчика и не принимает бизнес-решения.
Если сравнить проектный бизнес с продуктовым — одни и те же паттерны поведения не всегда ведут к одинаковым последствиям для разных типов бизнеса.
Для проектного бизнеса ведение одновременно многих проектов — это выгодно. У вас есть десяток заказчиков: один из них задерживает оплату, другой меняет подрядчика. Это могло бы стать причиной кассового разрыва, но за счет того, что у вас есть другие клиенты, вы не провисаете. Это диверсифицирует компанию по отраслям и помогает при спадах.
Для продуктового бизнеса расфокусировка — это смерть. Вы «размазываете» ресурсы внутри одной компании на десяток маленьких продуктов — одновременно делаете slack, trello и подобие facebook на консьюмерском рынке. В конечном счете вы создаете продукт «все в одном» и не решаете конкретную проблему клиента. То есть — не показываете результат, увеличиваете риски и проигрываете компаниям-конкурентам, где вся команда работает на создание понятного и простого продукта с ограниченной функциональностью.
Поэтому в продуктовом бизнесе на старте нужно фокусироваться на одном сегменте. И двигаться в соседний сегмент — только когда есть понимание, что ваша компания стала лидером в своем сегменте и уверенно доносит ценность, а процесс продаж уже выстроен.
В проектном бизнесе вы продаете свою экспертизу клиенту, у которого есть деньги. Если он ставит адекватную задачу и готов за нее заплатить, а ваша компания может ее решить, — это ваш клиент. Исключение — если у проектного бизнеса заказов в избытке, и он может позволить себе не брать заказы менее интересных клиентов.
В продуктовом бизнесе нужно научиться выбирать «своих» клиентов — фокусироваться на определенном узком сегменте, достаточном для быстрого развития. И один из навыков, который должен быть сильно развит в продуктовом — это умение отказывать «не своим» клиентам.
Если продукт не готов для продажи потенциальному клиенту, и требуется значительная доработка или создание нового продукта — не стоит сразу бросать все и идти делать под него продукт. Лучше положить этот запрос клиента в «копилку». И когда у вас накопится какое-то количество клиентов с запросом по подобному продукту, можно начать думать, стоит ли его делать для этой ниши.
Задача основателя продуктового бизнеса — найти массовый рынок, где клиентов, которым подходит наш продукт, на порядки больше. А не переделывать продукт под каждый запрос нового клиента.
По большому счету проектному бизнесу достаточно отгрузить software-продукт клиенту, а отстройка процессов, маркетинг и продажи именно этого продукта — уже лежат на стороне клиента.
В продуктовом бизнесе недостаточно просто составить ТЗ и согласовать с заказчиком результат. Во-первых, необходимы компетенции в продакт-менеджменте, чтобы экспериментировать с разными версиями продуктов, изощряясь тратить на это минимальные ресурсы, — чтобы в итоге создать продукт, нужный клиенту.
Во-вторых, когда продукт готов, у основателей появляется ощущение, что дальнейшие продажи и маркетинг — произойдут сами собой. Или же они воспринимаются как одна из наименьших частей бизнеса: на вывод продукта на рынок в бюджете компании заложено либо 0, либо не более 10-20% от цены разработки. Основатели думают: «Мы сделали классный продукт, дальше он распространится и продаст себя сам».
На самом деле, вывод на рынок обычно стоит больше разработки готового продукта — потому что в эту стоимость помимо затрат на маркетинг заложены серьезные компетенции в маркетинге и продажах. Знать свой продукт лучше всех — недостаточно для того, чтобы сделать из него лучший бизнес. Продукт — это не то, что программисты разработали и протестировали, а вы выпустили, продукт — это то, что стал покупать клиент. От окончания разработки до покупки продукта клиентом происходит еще очень много работы, которая в проектном бизнесе просто отсутствует. Поэтому чтобы стать лучшим в сегменте бизнесом, также надо иметь лучшие компетенции по продажам и маркетингу, и это стоит дополнительных денег.
В проектном бизнесе часто возникает история «мы делаем все, что попросил клиент» — он голосует деньгами, поэтому и имеет право заказывать нужные ему функции и сценарии работы с продуктом. Здесь происходит следующее: клиент отправил техническое задание, он платит за реализацию, компания над ним работает, выполняет и таким образом повышает свою ценность для других клиентов, в том числе потенциальных.
В продуктовом бизнесе такой рефлекс тоже нередко срабатывает: если клиент просит и готов заплатить, компания идет отрабатывать запрос. Но в случае с продуктовым бизнесом не стоит забывать про roadmap, стратегию развития, и какой продукт делает ваша компания. Работа с фичами здесь строится так же, как и с типами клиентов: вы смотрите, насколько запланированные функции вписываются в развитие продукта — они усложняют или упрощают работу вашей основной клиентской базе? Например, у вас уже есть 500 клиентов, и 501-й хочет, чтобы появилась красная кнопка «Купить». Но это значит, что красная кнопка появится не только у него, но и у других 500 клиентов, которые уже пользовались продуктом. И не факт, что они будут счастливы. Поэтому надо уметь балансировать: помнить о юнит-экономике и клиентах, которых вы считаете целевыми. Это значит, что функции всегда проходят процесс оценки: пойдут они в плюс или в минус вашему продукту для всей целевой аудитории, как повлияют на общую маржинальность бизнеса.
Есть и еще одна веская причина поспорить с клиентом — наработанная экспертиза. В продуктовом бизнесе зачастую вы становитесь большим экспертом в бизнесе заказчика, чем он сам: у вас появляются сотни и тысячи клиентов с одинаковой ситуацией. Поэтому вы приносите клиенту не только набор функций, но и экспертизу по решению задач, которые у него есть. Поэтому вы также знаете, какие требования клиента удовлетворять не надо — они не ведут к результату.
В проектных бизнесах же не всегда есть возможность глубоко проникнуть в бизнес-процессы и начать переносить экспертизу из одного клиента в другого, чтобы можно было смело сказать клиенту, какие функции делать не надо, потому что они не принесут результата с точки зрения бизнес-целей. Субъективное мнение необходимо подкреплять аргументами и кейсами.
Когда я спрашиваю у коллег, вышедших из проектного бизнеса, как они могут зарабатывать больше, они всегда говорят: «Мы добавим фичи». Для проектного бизнеса работает правило «больше фич = больше денег». При этом если компания делает что-то по техническому заданию клиента как подрядчик, она не может отследить, как добавленные функции влияют на прибыльность клиента. Работа с клиентом заканчивается на этапе сдачи-приемки: когда продукт запущен, багов нет, и клиента все устраивает.
Бывает, что это правило работает и в продуктовом бизнесе. Допустим, компания сделала продукт, который составляет рабочий календарь сотрудников в ритейле в зависимости от загрузки. Решая задачу «как можно больше зарабатывать на клиенте», скорее всего, основатель решит добавить больше интеграций, ускорить процесс расчета и т.п. Если все эти фичи будут дополнительно оплачиваться — схема работает.
Но на самом деле, вопрос «как клиент может платить больше» — не про фичи, а про ценность: если мы с этим продуктом приходим к магазину с 5-ю сотрудниками, выгода от него будет на порядок меньше, чем для магазина с 50-ю сотрудниками. Вопрос ценности регулируется не количеством функций, а тем, как ваш клиент использует их в своей деятельности: может ли он на них зарабатывать больше или сокращать какие-то издержки благодаря им. Продуктовый бизнес — не про фичи, а про результат для клиента.
Кроме того, для продуктового бизнеса бывает и противоположная зависимость: «больше фич = меньше денег». В некоторых случаях фичи наоборот ухудшают продажи: одна из известных компаний сначала добавила на сайт возможность покупать билеты на самолет, потом — бронировать отели. И после добавления последней фичи компания потеряла выручку: конверсия упала в 2 раза, а чек не вырос. Поэтому важно хорошо подумать, какой функционал покажет результат, и как функции влияют на деньги. Процесс разработки в продуктовом бизнесе завязан не на приемке заказчиком, а на том, уменьшается или увеличивается количество денег на счете вашей компании с новой функцией.
В проектном бизнесе компании могут взять за работу аванс, разбить оплату по этапам или получить всю сумму по итогам работы — им часто выгодно начать отгружать услуги бесплатно.
В случае с продуктовым бизнесом иметь готовый продукт сразу — вообще не обязательно. Еще до разработки продукта можно проверить, готов ли клиент платить за него: так вы получите подтверждение того, что продукт для клиента что-то значит. Но стоит помнить о том, что обещания перед клиентом должны быть выполнены.
Любая отгрузка продукта бесплатно не отвечает на вопрос, получает ли результат клиент. Только система «деньги вперед» показывает, насколько клиент заинтересован в вашем продукте.
«Так вышло, что я имею опыт работы по обе стороны баррикад: и в проектном бизнесе, и в продуктовом. С 2004 года — являюсь директором digital-агентства JetStyle, где несколько раз пытался создать внутренние продукты, удачно развивать которые не получалось — основной бизнес съедал еще не родившиеся.
В проектном бизнесе ответственность за конечный результат лежит не на исполнителе, а на заказчике. Исполнитель может быть сколь угодно ответственным: мы, например, не сторонники подхода «брать любые деньги, если их дают» и «делать все, что просит клиент» просто потому, что наш профиль клиента — «длинный клиент». Для такого клиента важно демонстрировать эффективность комбинации из его и наших специалистов — это здорово роднит наш подход с продуктовым. Несмотря на это, на нас, действительно, всегда лежит только фрагмент ответственности: мы можем заниматься реализацией UX, но не можем отвечать за конечную пользовательскую ценность, «подводные» клиентские процессы. Мы просто делаем свою работу хорошо, но именно клиент решает — что сейчас самое главное, на что направлять деньги и усилия. Если задача поставлена клиентом грамотно — для нас, как для проектного бизнеса, это безопасно и дает предсказуемо хороший результат.
Хороший проектный менеджер в заказной разработке — это человек, который переформулирует запрос заказчика в термины прикладных целей и потом реализует проект. Его главная забота — чтобы клиент получал предсказуемый эффект в контуре его цели.
Как только начинаешь работать в продукте, сразу оказываешься в «Зоне смерти». Это такая стратегема в Сунь-цзы, когда мосты сожжены. Не очень важно, есть ли у вас на первом этапе инвестиции, или вы делаете «старт на свои» — вы оказываетесь перед внезапным осознанием, что из всего спектра возможностей выбирать вам и только вам. Задача хорошего менеджера продукта — уметь всеми силами сохранять концентрацию на главном клиентском процессе. Для этого ему нужно очень хорошо знать, за что именно ему платят клиенты, и четко видеть, какой у него ключевой клиентский процесс. Соблазн в каждый момент времени «прикрутить» к продукту еще одну маленькую штуковину — ПОЛЕЗНУЮ! — очень велик. Об этом будут просить инвесторы, совет директоров, партнеры, клиенты и друзья. Сделать неверный выбор — страшно, но если ваше дерево продукта вместо одного ствола превратится в куст — вы обречены. Такое не масштабируется.
В проектном и продуктовом бизнесах также могут быть разные подходы к расчету эффективности. Например, digital-тусовка использует термин «перформанс маркетинг» там, где в области самостоятельных технологических предприятий принято говорить о «юнит-экономике». Это очень похожие подходы, но разница в деталях приводит к очень разным стратегиям и действиям. Перформанс маркетинг, по большому счету, сводится к количеству лидов и стоимости привлечения. Драйвером выступают люди, продающие конкретный инструментарий — ux, таргетированная реклама или еще что-то. Важно то, что с помощью такого подхода удобно находить нишу, в которой ваш инструмент эффективен, и объяснять клиенту, как его заказывать и в чем считать эффект.
Юнит-экономика добавляет к перформанс-маркетингу вторую часть уравнения — сколько и с помощью какого процесса мы заработали на клиенте, которого привели. Digital это не слишком интересует ровно потому, что эта часть — ответственность клиента. Но когда начинаешь решать эту задачу в контексте юнит-экономики, резко меняется и набор инструментов, и подход к их проверке, и вообще вся стратегия.
Это очень сложно почувствовать на практике, пока вы на стороне разработчика. Но однажды врубившись, вы всегда будете пользоваться этим подходом, потому что он гораздо, гораздо более толковый».
Чтобы не пропустить другие статьи ФРИИ о развитии IT-стартапов и их продуктов, а также анонсы мероприятиятий, — подписывайтесь на пятничную рассылку ФРИИ!
При переходе от проектного бизнеса (например, веб-студии или компании аутсорсинговой разработки) к продуктовому (разработка и вывод на рынок собственного решения) — происходит то же самое. Сложно избежать привычного подхода к бизнесу. Директор Акселератора ФРИИ Дмитрий Калаев рассказал о шести привычках проектного бизнеса, которые мешают продуктовому расти, а в самых тяжелых случаях — убивают стартап.
В проектном бизнесе к вам приходит клиент, чтобы решить конкретную задачу, и часто эта задача возникает только в его бизнесе. Клиент составляет техническое задание, и за его выполнение вам платят. Например, у вас веб-студия или компания аутсорсинговой разработки: вы продаете свою экспертизу и человеко-часы. Причем, возможно, у вас есть отдел, который аутсорсит разработку для американского стартапа или компании. В случае успеха стартапа у отдела возникает ощущение сопричастности, но по факту он все равно выступает для этой американской компании в роли подрядчика и не принимает бизнес-решения.
Если сравнить проектный бизнес с продуктовым — одни и те же паттерны поведения не всегда ведут к одинаковым последствиям для разных типов бизнеса.
Привычка 1: «Чем больше проектов — тем лучше»
Для проектного бизнеса ведение одновременно многих проектов — это выгодно. У вас есть десяток заказчиков: один из них задерживает оплату, другой меняет подрядчика. Это могло бы стать причиной кассового разрыва, но за счет того, что у вас есть другие клиенты, вы не провисаете. Это диверсифицирует компанию по отраслям и помогает при спадах.
Для продуктового бизнеса расфокусировка — это смерть. Вы «размазываете» ресурсы внутри одной компании на десяток маленьких продуктов — одновременно делаете slack, trello и подобие facebook на консьюмерском рынке. В конечном счете вы создаете продукт «все в одном» и не решаете конкретную проблему клиента. То есть — не показываете результат, увеличиваете риски и проигрываете компаниям-конкурентам, где вся команда работает на создание понятного и простого продукта с ограниченной функциональностью.
Поэтому в продуктовом бизнесе на старте нужно фокусироваться на одном сегменте. И двигаться в соседний сегмент — только когда есть понимание, что ваша компания стала лидером в своем сегменте и уверенно доносит ценность, а процесс продаж уже выстроен.
Привычка 2: «Все клиенты, у которых есть деньги, — наши клиенты»
В проектном бизнесе вы продаете свою экспертизу клиенту, у которого есть деньги. Если он ставит адекватную задачу и готов за нее заплатить, а ваша компания может ее решить, — это ваш клиент. Исключение — если у проектного бизнеса заказов в избытке, и он может позволить себе не брать заказы менее интересных клиентов.
В продуктовом бизнесе нужно научиться выбирать «своих» клиентов — фокусироваться на определенном узком сегменте, достаточном для быстрого развития. И один из навыков, который должен быть сильно развит в продуктовом — это умение отказывать «не своим» клиентам.
Если продукт не готов для продажи потенциальному клиенту, и требуется значительная доработка или создание нового продукта — не стоит сразу бросать все и идти делать под него продукт. Лучше положить этот запрос клиента в «копилку». И когда у вас накопится какое-то количество клиентов с запросом по подобному продукту, можно начать думать, стоит ли его делать для этой ниши.
Задача основателя продуктового бизнеса — найти массовый рынок, где клиентов, которым подходит наш продукт, на порядки больше. А не переделывать продукт под каждый запрос нового клиента.
Привычка 3. «Мы сделаем продукт, и этого будет достаточно»
По большому счету проектному бизнесу достаточно отгрузить software-продукт клиенту, а отстройка процессов, маркетинг и продажи именно этого продукта — уже лежат на стороне клиента.
В продуктовом бизнесе недостаточно просто составить ТЗ и согласовать с заказчиком результат. Во-первых, необходимы компетенции в продакт-менеджменте, чтобы экспериментировать с разными версиями продуктов, изощряясь тратить на это минимальные ресурсы, — чтобы в итоге создать продукт, нужный клиенту.
Во-вторых, когда продукт готов, у основателей появляется ощущение, что дальнейшие продажи и маркетинг — произойдут сами собой. Или же они воспринимаются как одна из наименьших частей бизнеса: на вывод продукта на рынок в бюджете компании заложено либо 0, либо не более 10-20% от цены разработки. Основатели думают: «Мы сделали классный продукт, дальше он распространится и продаст себя сам».
На самом деле, вывод на рынок обычно стоит больше разработки готового продукта — потому что в эту стоимость помимо затрат на маркетинг заложены серьезные компетенции в маркетинге и продажах. Знать свой продукт лучше всех — недостаточно для того, чтобы сделать из него лучший бизнес. Продукт — это не то, что программисты разработали и протестировали, а вы выпустили, продукт — это то, что стал покупать клиент. От окончания разработки до покупки продукта клиентом происходит еще очень много работы, которая в проектном бизнесе просто отсутствует. Поэтому чтобы стать лучшим в сегменте бизнесом, также надо иметь лучшие компетенции по продажам и маркетингу, и это стоит дополнительных денег.
Привычка 4. «Клиент всегда прав»
В проектном бизнесе часто возникает история «мы делаем все, что попросил клиент» — он голосует деньгами, поэтому и имеет право заказывать нужные ему функции и сценарии работы с продуктом. Здесь происходит следующее: клиент отправил техническое задание, он платит за реализацию, компания над ним работает, выполняет и таким образом повышает свою ценность для других клиентов, в том числе потенциальных.
В продуктовом бизнесе такой рефлекс тоже нередко срабатывает: если клиент просит и готов заплатить, компания идет отрабатывать запрос. Но в случае с продуктовым бизнесом не стоит забывать про roadmap, стратегию развития, и какой продукт делает ваша компания. Работа с фичами здесь строится так же, как и с типами клиентов: вы смотрите, насколько запланированные функции вписываются в развитие продукта — они усложняют или упрощают работу вашей основной клиентской базе? Например, у вас уже есть 500 клиентов, и 501-й хочет, чтобы появилась красная кнопка «Купить». Но это значит, что красная кнопка появится не только у него, но и у других 500 клиентов, которые уже пользовались продуктом. И не факт, что они будут счастливы. Поэтому надо уметь балансировать: помнить о юнит-экономике и клиентах, которых вы считаете целевыми. Это значит, что функции всегда проходят процесс оценки: пойдут они в плюс или в минус вашему продукту для всей целевой аудитории, как повлияют на общую маржинальность бизнеса.
Есть и еще одна веская причина поспорить с клиентом — наработанная экспертиза. В продуктовом бизнесе зачастую вы становитесь большим экспертом в бизнесе заказчика, чем он сам: у вас появляются сотни и тысячи клиентов с одинаковой ситуацией. Поэтому вы приносите клиенту не только набор функций, но и экспертизу по решению задач, которые у него есть. Поэтому вы также знаете, какие требования клиента удовлетворять не надо — они не ведут к результату.
В проектных бизнесах же не всегда есть возможность глубоко проникнуть в бизнес-процессы и начать переносить экспертизу из одного клиента в другого, чтобы можно было смело сказать клиенту, какие функции делать не надо, потому что они не принесут результата с точки зрения бизнес-целей. Субъективное мнение необходимо подкреплять аргументами и кейсами.
Привычка 5. «Больше фич = больше денег»
Когда я спрашиваю у коллег, вышедших из проектного бизнеса, как они могут зарабатывать больше, они всегда говорят: «Мы добавим фичи». Для проектного бизнеса работает правило «больше фич = больше денег». При этом если компания делает что-то по техническому заданию клиента как подрядчик, она не может отследить, как добавленные функции влияют на прибыльность клиента. Работа с клиентом заканчивается на этапе сдачи-приемки: когда продукт запущен, багов нет, и клиента все устраивает.
Бывает, что это правило работает и в продуктовом бизнесе. Допустим, компания сделала продукт, который составляет рабочий календарь сотрудников в ритейле в зависимости от загрузки. Решая задачу «как можно больше зарабатывать на клиенте», скорее всего, основатель решит добавить больше интеграций, ускорить процесс расчета и т.п. Если все эти фичи будут дополнительно оплачиваться — схема работает.
Но на самом деле, вопрос «как клиент может платить больше» — не про фичи, а про ценность: если мы с этим продуктом приходим к магазину с 5-ю сотрудниками, выгода от него будет на порядок меньше, чем для магазина с 50-ю сотрудниками. Вопрос ценности регулируется не количеством функций, а тем, как ваш клиент использует их в своей деятельности: может ли он на них зарабатывать больше или сокращать какие-то издержки благодаря им. Продуктовый бизнес — не про фичи, а про результат для клиента.
Кроме того, для продуктового бизнеса бывает и противоположная зависимость: «больше фич = меньше денег». В некоторых случаях фичи наоборот ухудшают продажи: одна из известных компаний сначала добавила на сайт возможность покупать билеты на самолет, потом — бронировать отели. И после добавления последней фичи компания потеряла выручку: конверсия упала в 2 раза, а чек не вырос. Поэтому важно хорошо подумать, какой функционал покажет результат, и как функции влияют на деньги. Процесс разработки в продуктовом бизнесе завязан не на приемке заказчиком, а на том, уменьшается или увеличивается количество денег на счете вашей компании с новой функцией.
Привычка 6. «Отгрузим бесплатно — потом возьмем больше денег»
В проектном бизнесе компании могут взять за работу аванс, разбить оплату по этапам или получить всю сумму по итогам работы — им часто выгодно начать отгружать услуги бесплатно.
В случае с продуктовым бизнесом иметь готовый продукт сразу — вообще не обязательно. Еще до разработки продукта можно проверить, готов ли клиент платить за него: так вы получите подтверждение того, что продукт для клиента что-то значит. Но стоит помнить о том, что обещания перед клиентом должны быть выполнены.
Любая отгрузка продукта бесплатно не отвечает на вопрос, получает ли результат клиент. Только система «деньги вперед» показывает, насколько клиент заинтересован в вашем продукте.
Комментарий Алексея Кулакова, директора по продукту Ridero и директора digital-агентства JetStyle.
«Так вышло, что я имею опыт работы по обе стороны баррикад: и в проектном бизнесе, и в продуктовом. С 2004 года — являюсь директором digital-агентства JetStyle, где несколько раз пытался создать внутренние продукты, удачно развивать которые не получалось — основной бизнес съедал еще не родившиеся.
В проектном бизнесе ответственность за конечный результат лежит не на исполнителе, а на заказчике. Исполнитель может быть сколь угодно ответственным: мы, например, не сторонники подхода «брать любые деньги, если их дают» и «делать все, что просит клиент» просто потому, что наш профиль клиента — «длинный клиент». Для такого клиента важно демонстрировать эффективность комбинации из его и наших специалистов — это здорово роднит наш подход с продуктовым. Несмотря на это, на нас, действительно, всегда лежит только фрагмент ответственности: мы можем заниматься реализацией UX, но не можем отвечать за конечную пользовательскую ценность, «подводные» клиентские процессы. Мы просто делаем свою работу хорошо, но именно клиент решает — что сейчас самое главное, на что направлять деньги и усилия. Если задача поставлена клиентом грамотно — для нас, как для проектного бизнеса, это безопасно и дает предсказуемо хороший результат.
Хороший проектный менеджер в заказной разработке — это человек, который переформулирует запрос заказчика в термины прикладных целей и потом реализует проект. Его главная забота — чтобы клиент получал предсказуемый эффект в контуре его цели.
Как только начинаешь работать в продукте, сразу оказываешься в «Зоне смерти». Это такая стратегема в Сунь-цзы, когда мосты сожжены. Не очень важно, есть ли у вас на первом этапе инвестиции, или вы делаете «старт на свои» — вы оказываетесь перед внезапным осознанием, что из всего спектра возможностей выбирать вам и только вам. Задача хорошего менеджера продукта — уметь всеми силами сохранять концентрацию на главном клиентском процессе. Для этого ему нужно очень хорошо знать, за что именно ему платят клиенты, и четко видеть, какой у него ключевой клиентский процесс. Соблазн в каждый момент времени «прикрутить» к продукту еще одну маленькую штуковину — ПОЛЕЗНУЮ! — очень велик. Об этом будут просить инвесторы, совет директоров, партнеры, клиенты и друзья. Сделать неверный выбор — страшно, но если ваше дерево продукта вместо одного ствола превратится в куст — вы обречены. Такое не масштабируется.
В проектном и продуктовом бизнесах также могут быть разные подходы к расчету эффективности. Например, digital-тусовка использует термин «перформанс маркетинг» там, где в области самостоятельных технологических предприятий принято говорить о «юнит-экономике». Это очень похожие подходы, но разница в деталях приводит к очень разным стратегиям и действиям. Перформанс маркетинг, по большому счету, сводится к количеству лидов и стоимости привлечения. Драйвером выступают люди, продающие конкретный инструментарий — ux, таргетированная реклама или еще что-то. Важно то, что с помощью такого подхода удобно находить нишу, в которой ваш инструмент эффективен, и объяснять клиенту, как его заказывать и в чем считать эффект.
Юнит-экономика добавляет к перформанс-маркетингу вторую часть уравнения — сколько и с помощью какого процесса мы заработали на клиенте, которого привели. Digital это не слишком интересует ровно потому, что эта часть — ответственность клиента. Но когда начинаешь решать эту задачу в контексте юнит-экономики, резко меняется и набор инструментов, и подход к их проверке, и вообще вся стратегия.
Это очень сложно почувствовать на практике, пока вы на стороне разработчика. Но однажды врубившись, вы всегда будете пользоваться этим подходом, потому что он гораздо, гораздо более толковый».
Чтобы не пропустить другие статьи ФРИИ о развитии IT-стартапов и их продуктов, а также анонсы мероприятиятий, — подписывайтесь на пятничную рассылку ФРИИ!
Комментарии (5)
alekseyspb
15.12.2017 16:15Все по делу, отлично!
Для организаций занимающихся заказной разработкой я бы посоветовал в первую очередь обратить внимание на существование дисциплины «управление продуктом» и роли «менеджера продукта».
Они упомянуты в статье, но хочется подчеркнуть, что именно самотечный подход к управлению продуктом чаще всего подводит владельцев. Даже крутых разработчиков. Возможно их даже больше, так как они уверены, что их крутость определит успех продукта.
JediPhilosopher
15.12.2017 23:07Да, все так. Работал в компании, которая пыталась из проектной переквалифицироваться в продуктовую. Ну типа «хей, мы столько лет пилим проекты на одну тематику для других, давайте запилим что-то в этой же сфере для себя». И наблюдал как проектные привычки тянут этот продукт на дно. Было все — и погоня за лишними фичами (на которые было убито уйма времени и которые в итоге никто не использовал), и отсутствие маркетинга и продвижения, и попытки угнаться за всеми возможными клиентами (ради чего готовы были делать кучу работы типа демо и интеграций, которые в итоге так и не оплачивались и не приносили прибыли).
Печальное зрелище.
nekoval
19.12.2017 13:54Тоже присутствовал при попытке сделать продукт внутри аутсорсинговой компании, всё провалились. Действительно, все рассуждения проходили в режиме «давайте сделаем такие фичи и их точно купят». Было сожжено много денег в итоге.
DistortNeo
Интересно, а есть ли нормальный перевод слова «product» на русский язык? Потому что «продуктовый бизнес» у меня ассоциируется только с ларьками-супермаркетами и ничем больше.
Я бы писал просто «продакт-бизнес» вместо «продуктовый», потому что значение слова «продуктовый» в русском языке другое.
alekseyspb
«продуктовый» уже вполне привычно