Мы делаем платформу SEOWORK, которая помогает ecom, маркетплейсам и крупному бизнесу улучшать сайты и увеличивать органический трафик, поэтому в первую очередь расскажем о планировании релизов для B2B. В сфере digital все достаточно динамично, и планировать релизы, особенно в долгосрочной перспективе (год и больше), очень сложно, — хотя и необходимо. Надо понимать, куда идет компания, в каком направлении развивается продукт и какие ресурсы для этого потребуются.
Внутри компании работу с релизами мы условно делим на 3 типа:
- разработка и релизы глобальных фич (например, нового продукта или модуля);
- разработка или трансформация существующих фич, напрямую влияющих на LTV;
- доработка текущего функционала.
Планирование в долгосрочной перспективе
Глобальные релизы мы планируем на долгосрочном горизонте, исходя из коллективного продуктового видения (CEO + PM + тимлид разработки), и конечно, на основе рыночной аналитики и данных по конкурентам. На этапе долгосрочного планирования подробную детализацию сделать сложно, к тому же, на нашем рынке ситуация быстро меняется и для нас важно иметь гибкий, а не детальный план. Поэтому при долгосрочном планировании мы лишь размечаем основные задачи, а детализируем их уже ближе к делу.
Например, в прошлом году мы решили разработать новый продукт. Когда начали закапываться в бизнес-требования, быстро поняли — разработка займет не меньше года. И что будет, если выкатить этот продукт, а он не выстрелит? Цена ошибки оказалась бы слишком высокой.
Поэтому мы сфокусировались на тестировании гипотез: реализовали похожий функционал в текущем продукте и сравнительно недорого проверили, насколько он актуален для пользователей. Разработкой нового продукта мы обычно занимаемся параллельно с основным — но приоритет у него будет более низким, пока не придет достаточная положительная обратная связь от рынка.
Мы пишем о менеджменте продуктов и развитии в телеграм-каналах make sense и Продуктовое мышление.
Детализация разработки
В деталях разработку нового и доработку текущего функционала мы планируем в краткосрочной перспективе — до квартала (точный срок зависит от сложности реализации). Приоритет выставляем исходя из нескольких критериев: важность фичи в привязке к LTV, потребностям пользователей, трендам аналитики, изменениям рынка. А в стандартные спринты у нас уже входят текущие срочные задачи или баги, кототрые стоят в плане.
Если прогнозируемый рост LTV покрывает стоимость разработки, с большой долей вероятности функционал мы возьмем в реализацию. Это может быть функционал, интересный только небольшому числу наших клиентов — но клиентов с высокой прибыльностью и LTV.
Мы постоянно общаемся с клиентами и получаем от них обратную связь: какие задачи они решают, какие функции хотели бы видеть в продукте. Наши клиенты — B2B-компании со своими процессами и особенностями. Зачастую у них уникальные запросы, которые релевантны только очень узкой группе других клиентов. Но мы все равно собираем и анализируем все запросы. И если видим, что запрос популярный, а идея кажется нам стоящей, берем идею в проработку: дополнительно проводим CustDev, создаем прототипы и показываем их клиентам. И положительный отклик для нас становится сигналом, чтобы включить новые фичи в бэклог и запланировать реализацию.
Один клиент попросил нас помочь с автоматизацией сбора семантики — для него это была критичная задача. Он пытался решить ее сам, но на это уходило слишком много времени и ресурсов. Понимая, что у нас есть все данные для того, чтобы реализовать такую фичу, и много времени она не займет, мы поставили эту функцию в план. Интересно, что клиент был готов заплатить за реализацию этой функции — но мы вряд ли возьмем с него деньги, потому она будет полезна всем клиентам. Решая эту задачу, мы провели глубокий CustDev, обсудили разные способы реализации и в итоге внедряли фичу, которую уже проверили на типовом клиенте.
CustDev провели по классике: задавали открытые вопросы, пытались понять, насколько клиенту важны те или иные задачи, почему и как он их решает сейчас, какие варианты решения рассматривал. Мы всегда проводим интервью лично — в формате встреч или созвонов — и обязательно записываем разговор, чтобы потом можно было к нему вернуться, переслушать с коллегами или уточнить отдельные формулировки.
Внедрение новых функций и продуктов
Нам удалось сформировать сообщество профи — экспертных пользователей продукта. Участники этого сообщества первыми получают доступ ко всем новым фичам и модулям, активно ими пользуются и дают обратную связь, на основе которой мы или выпускаем релиз, или возвращаем функции на доработку.
Приоритизация по доработке фич основана на частоте жалоб от пользователей — говорят ли они о недостаточности функционала в данном виде или объеме. Наши клиенты — крупный ecom, это опытные компании, а их запросы логичны и соответствуют потребностям бизнеса.
Обратную связь мы получаем регулярно и оперативно, потому что находимся в постоянном контакте с клиентами. Форма откликов абсолютно различна: это вопросы клиентов в чате поддержки или по электронной почте, прямое общение с эккаунт-менеджерами или же опросы и клиентские исследования.
Все похожие обращения мы собираем в Product Board — там, где это возможно, процесс мы автоматизировали (например, запросы из чата поддержки автоматически попадают в Product Board), а что автоматизировать невозможно — валидируем и заносим в базу вручную. В Product Board мы связываем запросы пользователей с конкретными фичами. Таким образом запросы рынка становятся наглядными, и мы понимаем, какие функции и какие обновления клиенты ждут больше всего.
При планировании (независимо от сроков) важно грамотно распределять ресурсы и время команд. Нам в этом помогает ретро: по уже закрытым таскам мы понимаем, сколько ресурсов и времени потребуются для выполнения аналогичных задач, уложимся ли мы в обозначенные сроки и нужны ли нам дополнительные ресурсы.
Коммуникации внутри команды
Как бы тщательно мы ни планировали, мы не можем предусмотреть абсолютно все сценарии событий на рынке — так что планы периодически надо актуализировать. Для этого мы проводим backlog grooming — обсуждение и корректировку бэклога. Обычно он проходит раз в квартал, но по необходимости может инициироваться и чаще. Менеджеры продуктов максимально погружены в в контекст и понимают, какие из запланированных фич еще актуальны, а от каких можно отказаться.
Дополнительно мы синхронизируемся по приоритетам в рамках еженедельных собраний CEO + PM + тимлид разработки.
Ежемесячно проводим встречи менеджеры продуктов + маркетинг + продажи — они помогают синхронизироваться и удерживать связку продукт-пользователь. Как правило, это 2 встречи:
- В рамках первой мы рассказываем, что у нас сейчас в работе, что планируем на ближайший месяц, а отдел продаж и маркетинг понимают, что можно будет подсветить клиентам в ближайшее время.
- На второй встрече продажи делятся с продуктовым отделом запросами от клиентов. После валидации от менеджеров продуктов запросы попадают в Product Board и учитываются при планировании и приоритизации.
У нас распределенная команда — поэтому большинство встреч проходит онлайн. По итогам всем участникам рассылается запись — информация всем доступна, к ней можно вернуться в любой момент.
Product Board для планирования релизов
С помощью Product Board мы фиксируем многие из наших идей — а потом приоритизируем их объединенной командой менеджеров продуктов, разработчиков и эккаунт-менеджеров.
После этого мы отслеживаем жизненный путь каждой фичи — от формирования бизнес-требований и создания прототипов до разработки и выкатки в прод. Благодаря такому процессу, команда оперативно реагирует, если фича застряла продолжительное время на каком-то этапе, или если важные фичи не попадают в работу.
Из плюсов работы в PB можем отметить удачную перелинковку с другими нашими рабочими инструментами — Jira и Miro.
