Как разработать продуктовую стратегию и какие подходы применяются для ее улучшения?
Валерий: Если речь идет о разработке продукта, то все просто: берем аналитиков, готовим Vision and Scope и переходим к ее внедрению. Если говорим о стратегии создания и запуска продукта, то это включает в себя целый комплекс мер: это и финансовый план, и план разработки, и маркетинговый план. При этом они должны быть взаимосвязаны. Мы часто совершаем классическую ошибку при запуске продукта и формировании стратегии, когда пытаемся копировать методы корпораций. Но если мы запускаем что-то совсем новое или хотим протестировать идею, методы корпораций слишком дорогие для таких проектов. Нам нужна простая стратегия, которую можно уместить на “салфетке”: на этапе запуска продукта, исследования рынка и тестирования гипотез, у нас нет большинства входных данных для того, чтобы выстроить финансовый план, мы не можем подсчитать, к примеру, стоимость привлечения клиентов и другие параметры.
Самое главное в продуктовой стратегии это рынок, в котором вы работаете. Как его изучить? Конкуренты, общая емкость рынка, целевая аудитория и анализ тех, с кем вы боретесь за трафик. Дальше идет стоимость продукта: по примерным параметрам мы можем просчитать, сколько денег нам нужно на маркетинг, чтобы привлечь пользователей. Но эти цифры ответят нам только на один вопрос: а есть ли вообще смысл ввязываться в этот проект с точки зрения рентабельности? Остается решить, готовы ли мы рискнуть какой-то суммой денег, потенциально списав ее в случае, если что-то пойдет не так.
Стратегия должна быть максимально консервативной, но всегда должно быть место для позитива – верьте в лучшее, но планируйте реальность.
Важный фактор – это стоимость развития продукта. Мы думаем, что после разработки расходы пойдут только на маркетинг, но когда мы выходим на рынок и получаем от пользователя фидбек, мы начинаем с ним работать и реагировать. Нужно закладывать стоимость развития, потому что это повлияет на ваш денежный поток: если вы не хотите прийти к моменту. что деньги закончились, а инвесторы утвердили другой бюджет и больше его не выделяют, нужно бюджет на развитие заложить заранее. Дальше нам нужно двигаться и пробовать. Когда мы разрабатываем продуктовую стратегию, мы постоянно должны ее анализировать с точки зрения того, как она исполняется, какие новые факты открываются: о рынке, о потребителе, о самом продукте, который мы планировали сделать. Эти факты всегда должны влиять на стратегию: она не должна быть статичным документом, она должна всегда дорабатываться и быть адаптивной.
Есть ли какие-либо особенности разработки продуктовой стратегии в условиях кризиса?
Моя концепция такова: когда вы запускаете продукт, вы в любом случае работаете в кризисе, вне зависимости от положения рынка. Мыслите кризисной моделью: работайте на минимуме, потому что в таком случае вы потеряете минимум если проект будет неуспешным. Если проект будет успешным, все дополнительные приятности вы получите как бонус. Мы должны исходить из негативного кризисного сценария в планах и цифрах, в том, что мы для себя рассчитываем. Если мы говорим о запуске продукта и стартапа, то это модель Lean Startup – “бережливый стартап”: начинай с малого, тратя по минимуму, двигайся короткими шагами, учитывай изменения и корректируй план согласно этим изменениям. Причем план ни в коем случае нельзя забрасывать, он должен меняться и адаптироваться.
Кризис – это всегда перезагрузка рынка, неизбежный этап развития.
Если вы работаете с аудиторией, вы всегда должны спускаться на уровень потребителя и понимать, как он изменил свой подход и привычки: так вы поймете, куда склонился рынок. Перезагрузка означает, что некоторые отрасли постепенно уходят и приходят новые. Применяйте кризисную стратегию: идите в ту сторону, в которую рынок перераспределяется в данный момент. Например, пандемия: для кого-то это был кризис, а для кого-то прирост. Те, кто делали видеозвонки до пандемии, те, в конечном итоге шли туда, куда перераспределялся рынок, пандемия стала лишь катализатором перераспределения. Сейчас мы можем говорить о неком постковидным периоде, когда все постепенно возвращается к привычной жизни. Насколько сильно сейчас мир откатился к исходной точке? Большинство привычных нам вещей сохранилось и многое стало для нас привычкой. Формат видеоконференций полностью не отменился: конечно, период спада будет, но до исходной точки, как было до пандемии, он не упадет, и если вы правильно продумали идею и движетесь в верном направлении, то вы в любом случае будете расти.
Почему вы выбрали Agile, Kanban и Scrum в качестве методологии разработки?
Валерий: Когда мы действуем в условиях ограниченной предсказуемости, где от каждого исполнителя и его компетенций во многом зависит результат, нам нужна определенная гибкость, возможность быстро переключиться и перепланировать. Именно это и позволяет сделать Аgile: это не отсутствие плана, это гибкий подход к планированию, к управлению и к работе.
В Agile большая роль отводится исполнителям, поэтому мы делаем упор на самоорганизацию и самоуправление. Эта методология учит людей работать правильно: Аgile не просто расписывает процесс работы, он пытается сделать правильный подход к работе и командную игру твоей привычкой. Kanban, как Scrum и Аgile позволяет работать и управлять всеми процессами, основываясь на фактах. Сделав короткую итерацию или задачу, мы получаем результат, в промежутке его контролируем и двигаемся дальше.
Самое главное в принятии управленческих решений – это информация, которая тебе поступает.
Мы принимаем решения на базе аналитики, конкретных данных, качество аналитики прямым образом влияет на качество принимаемых тобой решений. При этом важны и компетенции самого управленца, от которых также зависит качество решений.
Аgile позволяет нам делать короткие итерации и показывать результат, после чего получать фидбэк и критику. Качество принимаемых в таком подходе решений будет выше, чем если работать без обратной связи. Так или иначе, мы работаем под заказчика: он может быть конечным потребителем или группой заинтересованных лиц, которые занимаются приемкой и анализом, он сможет быть Product Owner, но в любом случае, он вам дает фидбек в моменте, что позволяет делать существенные улучшения.
Если вы хотите, чтобы продукт приносил конечный результат – монетизацию, вам изначально нужно смотреть на продукт не как на разработку скажем приложения, а как на запуск бизнес-проекта. В таком случае у вас отпадут вопросы необходимости в этом участвовать, в необходимости планирования и необходимости гибко реагировать на изменения.
Во многих продуктовых компаниях есть Product Manager. Нужна ли эта должность в Scrum-команде или как она трансформируется в этом фреймворке? Чем отличаются Product Owner и Product Manager, каковы их цели и обязанности?
Валерий: Разница между Product Manager и Product Owner в одно слово и в одну методологию: Product Owner это Scrum, Product Manager это PMBOK. Это одна и та же роль при разных подходах: PMBOK говорит о том, что Product Manager управляет продуктом, стратегией его развития. Его ответственность – вывести продукт на рынок. У него могут быть помощники в виде проектного менеджера, который сопровождает непосредственно процесс разработки. Product Owner – это определение из Scrum. Если мы сравним базово их функции и обязанности, то они совпадают в целом: это один и тот же человек, но из разных методологий. Конечно, в каких-то нюансах и деталях они отличаются, но это потому, что сами методологии отличаются друг от друга. PMBOK изначально более детально и четко описывает функционал, требования и подходы, Scrum менее детализирован. Но вывод один: менеджер продукта и владелец продукта – это человек, который отвечает за реализацию целей продукта и его ценность.
Часто ли инвестор соглашается на роль владельца продукта, хочет ли он брать ее на себя?
Валерий: Всегда есть две модели: если ваш заказчик крупная компания, то Product Owner не будет инвестором или собственником продукта, это будет один из сотрудников компании, который работает в этом направлении и хорошо знает доменную область. Если мы говорим о небольших проектах, скорее всего у компании не будет ресурсов, чтобы нанять отдельного сотрудника. Они захотят на этом сэкономить, выделят кого-то из среды руководителей заказчика, руководителя направления или того, кто эту идею придумал.
Какие требования у Product Owner?
- Во-первых, понимать как работает методология.
- Во-вторых, понимать ту область, в которой запускается продукт, чтобы сделать приоритизацию требований для максимизации ценности продукта.
- В-третьих, понимание финансовой части и метрик, через которые он будет измерять эффективность работы команды и отдачу от реализации продукта.
Если заказчик – это большая корпорация, то они очень часто просят у исполнителя нанять Product Owner. Но тогда возникает проблема: инструмент контроля у заказчика будет опосредован, а вовлеченность в продукт ниже. Я стараюсь, чтобы Product Owner был со стороны заказчика, потому что он должен быть максимально вовлечен в процесс создания своего продукта. Заказчик лучше всего знает доменную область в которой он работает, понимает чем живет рынок для которого мы делаем продукт.
Другая проблема: обычно заказчик дает человека с нужными компетенциями, но тот вообще не понимает, как устроена методология Scrum. Приходится тратить время на onboarding, выстраивание взаимоотношений и обучение. Но если этот период обучения пройден, дальше может получиться команда, которая действительно будет запускать крутые продукты для заказчика. Этот подход более эффективный, потому что вовлеченность заказчика будет выше, компетенции и знания с обеих сторон профильные и глубокие. Если мы выработали определенную синергию, у нас будут партнерский дух и мы сможем проникнуться идеями друг друга.
Поговорим про Pivot в процессе разработки продукта. Как понять, что вам пора делать пивот?
Если мы говорим о развороте продукта, то он нужен тогда, когда ты получил другую информацию о потребителе и рынке. Разворот продукта – это смена направления деятельности. Вы сформировали продуктовую стратегию, но она не должна быть слишком строгой, она должна отвечать на базовые вопросы. Дальше мы непрерывно создаем элементы продукта и показываем их потребителям на рынке или ограниченном кругу потребителей. После получаем новую информацию, помимо этого обращая внимание на рыночные сигналы о том, что ситуация меняется, и в моменте принимаем решение о развороте в какую-то из сторон. Работа по Agile строится на принципах, что пивот – это непрерывное явление, он привязан к ретроспективам и анализу полученного результата: можно поехать на конференцию и вдохновиться, получить новые данные, аналитику по продуктам и решиться на разворот.
Иногда под этим определением мы понимаем нечто масштабное, но на самом деле решения принимаются на уровне команд. Это вопрос масштаба продукта: чем он меньше, тем меньше количество людей, которые принимают решения, исходя из новых данных, которые нам поступили. Кроме внешних факторов, таких как изменение рынка, существуют и внутренние, когда вы чем-то вдохновились и хотите немного изменить свой формат. Третий фактор – это потребители: они дают обратную связь, на основании которой нужно делать выводы и принимать решения. Можно ли концептуально изменить бизнес-модель продукта очень быстро? Это, опять же, зависит от масштабов продукта. В любом случае, если вы двигаетесь в разработке маленькими итерациями, то такими же маленькими итерациями вы делаете пивот. В Agile – это непрерывная работа с входящими данными от потребителей, внешних факторов рынка и от команды.
На основании чего строится Roadmap продукта? На что нужно обращать внимание при составлении дорожной карты?
Валерий: Roadmap, по сути, это часть большой продуктовой стратегии. Если мы делаем продукт, собирая идеи из аналогов, то будем честны: у нас нет никакой идеи в основе и тогда а мы начинаем собирать фишки, в итоге собирая машину из фильма “Безумный Макс”. Чтобы этого не было, нужна стержневая идея. Безусловно, мы будем что-то находить для себя на рынке, выносить из книг и статей, продуктов-аналогов и т.д., но стержневая идея позволяет нам через ее призму смотреть на входящую информацию критически, понять как ее использовать и отфильтровать все ненужное. Если стержневой идеи нет, то продукт – это список наших “хочу”. Для этого и нужен Product Owner: он формирует стержневую идею, изучает боль рынка. Идея продукта – это решение проблемы потребителя. Product Owner находит эту идею, формулирует ее и ищет способ реализации. На основании этой идеи он будет строить Roadmap, дальше работая по гибкой методологии: создавать продукт и переосмысливать его, исходя из поступающей информации. Нужно смотреть на жизненный цикл продукта так: он создан, чтобы решать проблему потребителя и зарабатывать деньги. Чтобы это работало, нужно всегда быть в тренде и на волне рынка, но при этом обязательно понимать своего потребителя.
Как не уйти в ненужный функционал? Почему при разработке продукта основной фокус нужно делать не на новых фичах и актуальных трендовых фишках, а на решении проблем и достижении целей?
Валерий: Не все, что в тренде, результативно. Мы редко можем оценить результат трендовой вещи, поэтому ее всегда нужно прогонять через призму своей стержневой идеи. У вас должна быть глобальная цель, которая декомпозируется на подцели и на задачи. Если вы начинаете с фич и у вас нет цели, то вы занимаетесь экспериментаторством. Для нас должен быть важен не хайп, а работа с потребителем. Представьте, что ваш потребитель находится вне волны этого хайпа. Безусловно важны внешние источники информации: чем живет рынок, какие продукты запускаются, но все нужно пропускать через стержневую идею и потребителя – возможно ваша аудитория хайпом не затронута.
Валерий: Нужно реагировать на внешние сигналы: от рынка, от потребителей, от заинтересованных лиц. Если говорим о команде, то это вопрос вовлеченности в процесс разработки.
Как формируется вовлеченность?
- Первое: возможность влиять на конечный результат. Agile как раз к этому и призывает: через фидбек и ретроспективы мы даем возможность людям влиять на конечный результат продукта.
- Второе: возможность влиять на подходы и практики, которые вы используете при совместной работе. Если через фидбек и ретроспективы люди влияют на создаваемый продукт, таким же образом они должны иметь возможность повлиять и на организацию, в которой работают.
- Третье: постройте внутри организации процессы и покажите на практике, что неважно, какая у тебя должность, положение и статус в иерархической структуре компании – все подчиняются процессам одинаково. Так мы сможем усилить вовлеченность команды в работу и достичь лучших результатов.
– Валерий, большое спасибо за такое развернутое и информативное интервью! Было очень приятно с вами пообщаться.
– Валерий: Вам спасибо! 😊
Уважаемые читатели, оставайтесь на связи! Каждый месяц в блоге мы будем выпускать для Вас полезные и интересные статьи о разработке продуктов от наших ведущих экспертов. До новых встреч 😊!
