Как перейти от проектного бизнеса к продуктовому

По данным Рейтинга Рунета, в странах СНГ насчитывается более 5000 студий, предоставляющих услуги IT-разработки. Многие владельцы таких организаций в какой-то момент решают, что получили достаточно опыта, чтобы перейти от проектной разработки к созданию продукта. Но, несмотря на то что у компаний могут быть качественно поставленные цели, они знают проблемы своих пользователей через реализованные проекты и идея продукта является ценной, переход к продуктовой бизнес-модели может быть разрушен несколькими событиями, которые вовремя не распознали и не исправили.

В этой статье хочу поделиться успешным опытом, в котором я как менеджер продукта вместе с командой помог перевести компанию к продуктовому подходу и захватить 20 % целевого рынка за два года. Этот опыт может быть полезен в первую очередь владельцам компаний, которые хотят перевести деятельность в продуктовое направление или уже делают это. Также статья может быть полезна менеджерам продуктов, которые хотят устроиться работать в продуктовые стартапы, чтобы лучше понимать проблематику и потенциальный объём задач.

Первое, что я бы хотел сделать, – понять, существует ли вообще у владельцев бизнесов, занимающихся проектами, такая проблема или задача, как переход в продукт. Я обычно долго работаю на одном месте, поэтому личный опыт получил в трёх компаниях: первая занималась продуктом, вторая создала продукт и пыталась повторить этот успех через проектные заказы, и третья была студией, но стала полноценной продуктовой компанией. Остановлюсь на последней организации, где проработал четыре года и застал процесс перехода в продукт от стадии инициации до перевода продукта в стадию его роста. Как мне кажется, основная идея владельца для перехода в продукт – это желание масштабировать успех одного проекта и повторно использовать разработку, таким образом уменьшив основные затраты бизнеса.

Я наблюдаю, как крупнейшая компания России пытается перевести внутреннюю разработку и решение в продукт. И, как вижу это со стороны, – данный процесс, несмотря на наличие огромных ресурсов и лучших специалистов, буксует точно так же, как и студия с оборотом 10–20 млн рублей в год. То есть можно сказать, что деньги и размер компании не гарантируют успеха в транзите в продукт.

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

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

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

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

Настало время рассказать о моём опыте и о том, как мы преодолели препятствия. Выделю несколько инструментов, которые нам помогли.

Первый – это целеполагание, где через фреймворки стратегических сессий и Objective Key Results мы фактически прекратили проектную деятельность и остановили прием новых проектов до момента создания MVP продукта. В этом, конечно, помогло то, что продукт был продолжением проектов, объединял их в одну платформу и собирал паттерны, позволяющие создать именно продукт. Поэтому мой совет – не уходите далеко от ваших самых частых или наиболее прибыльных кейсов (проектов): это поможет с точки зрения и экспертизы, и быстрого поиска клиентов для валидации продуктовой ниши.

Второй инструмент – разделение человеческих ресурсов для продукта и проекта. На данном этапе это будет команда для создания продукта. Она должна быть отдельной и не отвлекаться на посторонние задачи. Более того, я бы рекомендовал также не вливать ресурсы в эту команду из проектов. Выделение команды, которая самостоятельно создаёт продукт, поможет сделать эксперимент чистым и понятным для ретроспективы, а выводы из неудачных запусков я считаю не менее ценными, чем факт создания успешного продукта. В нашем случае мы разделили людей по разным частям офиса. А в дальнейшем полностью перестроили их в соответствии с разделением по субпродуктам (направлениям). Это сложно, совершенно по-новому, появляется больше структурности и разделения ответственности внутри команд. На собственном примере могу сказать, что совмещать проектного и продуктового менеджеров в разных проектах категорически сложно и в целом неэффективно. Помню, как поймал себя на состоянии полной отключённости от диалога, когда просто физически не мог в него включиться. Это было следствием того, что я много недель держал фокус на совсем разных проектах, – в итоге один из моих любимых проектов для послепродажного обслуживания машин закрыли. А время, потраченное на него, могло бы эффективнее применяться в основном продукте. Мой вывод: многофункциональный продакт-менеджер – скорее плохо, чем хорошо.

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

Четвёртое – служба поддержки. В нашем случае её работа была очень хорошо выстроена. Но даже при этом в итоге нам пришлось переводить часть сотрудников ближе к продуктам, превращая их в продуктовые команды поддержки. Хорошая поддержка, адаптированная к конкретному продукту, понадобится на стадиях MVP и первых продаж. Продакт-менеджер уже не может водить всех клиентов «за ручку» по ещё не окрепшим интерфейсам, а поддержка не умеет – таких ситуаций нужно избегать и заранее выстраивать работу поддержки под продукт, который находится в стадии роста. Решать такую проблему «по месту» будет сложно и опасно: есть вероятность потерять первых и последних клиентов и репутацию.

Вторая по важности проблема – идея продукта, которая транслируется команде. Но фактически это не продукт, а проект. Вы создаёте продукт и с каждым новым заказчиком делаете всё больше копий под задачи разных клиентов. Например, ваш продукт работает в облаке, но клиент просит разместить его на своих серверах. Или желает добавить множество фич, без которых он не купит продукт, однако это противоречит планам развития вашего продукта. Решением скорее всего будет – разработать его коробочную версию.

Всё это плохо, на мой взгляд, по одной причине – из-за нехватки ресурсов на поддержку и развитие; когда придёт время улучшений, их потребуется проводить фактически уже на два продукта, и на это нужна отдельная команда, которая, естественно, от работы с одним клиентом не окупается и точно не приносит прибыль. Лично видел коллапсы систем на одной из моих работ, когда анонсированная на все версии продукта фича не попадала в одну из версий продукта, и оперативно добавить её туда было невозможно.

Я прошёл этот путь не без трудностей. Сразу скажу, что мне удалось избежать дупликаций продукта, и на это пришлось потратить много ресурсов. Я подходил к решению задачи по следующему алгоритму:

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

У нас был ещё бонус с построенной системой проектных команд, которые на базе продукта создали проекты. Она показала себя очень эффективной в закрытии таких сделок, но о ней я не буду сейчас рассказывать. Если это интересно, пишите в комментариях – обязательно найду способ ответить.

Снова напомню, что «красный флаг» для системы – когда вы с командой договариваетесь сделать копию продукта. Это говорит о том, что вы продолжаете делать проекты, прикрываясь продуктом.

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

Последняя проблема – «амбиции вместо стратегии». Понимаю, что стратегия для стартапов не самый важный инструмент и иногда может мешать реагировать на вызовы рынка, но я считаю, что амбиции – только хорошая приправа для стартапа. Стратегия и понимание, что и для кого мы делаем, вместе с долгосрочным фокусом помогают преодолевать трудности, которые, несомненно, будут до того момента, когда продукт начнёт окупаться.

На данном этапе мы разобрались с проблемами и их следствиями. Теперь пора показать ретроспективу того, почему же, собственно, получилось у нас. Кратко расскажу историю компании, где я работал. Она начинала деятельность как студия, которая поддерживала в том числе автомобильный сегмент. Далее с ростом клиентской базы и опыта организация была разделена между двумя основателями, и я попал на ту сторону, где продвигался продуктовый подход. Компания объединила подходы по созданию и поддержке сайтов одного автомобильного бренда. Затем под него была создана платформа на «Битриксе», и рост был уже через выход на другие марки и продажу им аналогичных проектов. Каждый бренд приводил 50–150 дилеров своей сети.

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

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

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