Дилемма продуктовода в стартапе
Ура! Наступил тот час, когда стабильная версия вашего продукта выпущена, а маркетинг и отдел продаж работают в поте лица, чтобы как можно больше клиентов попробовали и купили ваш продукт или подписались на ваш сервис. Шампанское выпито, надувные шарики сдулись, и вы начинаете думать, что делать дальше.
Надо оговориться: во многих сфотверных стартапах используется упрощённый подход к разработке: у вас есть команда из, скажем, 10 разработчиков, 2 писателей, 5 тестеров и 2 менеджеров команды и проектов. На них в операционном бюджете компании выделены деньги, которые будут выданы зарплатой даже в случае простоя команды. Есть альтернативный подход (если ваш CFO или COO хочет навести структуру сразу, и CEO его/их внимательно слушает): на каждый новый релиз делать не только план, но и бюджет с расписанной стоимостью работы каждого работника. Если в структуре капитала вашей компании есть заёмные или инвесторские средства — скорее всего, вы уже столкнулись с тем, про что я пишу в этой статье. Подобная структура может напугать неопытного продуктовода, и вот почему:
так сложилось, но когда на каждый релиз есть отдельый бюджет, автономия продуктовода в принятии решений сводится почти к нулю — точнее, к ответственности за выслушивание других людей, имеющих мнение. Вот как это бывает в обычной жизни:
У вас есть бюджет $100 000 (нужную сумму подставьте сами) на каждый релиз, и предыдущий релиз подходит к логическому завершению, поэтому срочно нужно «замораживать» объём работ на новый релиз. Если вы сильно не озабочены бюджетом — вы просто посмотрите на vision продукта, на его roadmap и самостоятельно определите объём работ. Но само наличие бюджета на проект гарантирует тот факт, что к вам периодически будет наведываться COO или CFO и интересоваться, на что и как тратятся деньги. Из просто Loss Centre (т.е. подразделения, не отвечающего за прибыль) ваше подразделение теперь превращается в Loss Centre с Input into P&L (т.е. участвующее в процессе получения прибыли). А это уже игра совершенно по другим правилам.
Теперь каждая новая функция продукта должна иметь материальное обоснование. Сказать, что «эта функция приближает нас к светлому будущему», уже недостаточно: на вас набросятся люди, у которых есть вполне конкретные мысли по поводу того, что на самом деле должно быть в продукте. Плюс в том, что для вас процесс принятия решения упрощается, т.к. вы из него практически исключены :) Ваша роль — роль модератора и, если повезёт, — роль «адвоката дьявола» (только если эту роль не хочет играть COO или кто-то, на ком лежит ответственность за принятие финансовых решений): на вашем столе лежит описание 10 функций, реализация каждой из которых будет стоить по $25k (что включает в себя не только разработку, но и тестирование, документацию, обучение, изменение макетов рекламных листовок и т.п.), но реально вы сможете сделать только 4. Можно вообще сделать выбор очевидным, посчитав «удельный вес» заявки (я являюсь фанатом данного подхода независимо от типа стартапа), включающий в себя сумму весовых коэффициентов ответов на следующие вопросы:
А уж опытному продуктоводу решить задачу сортировки полученных значений по убыванию — делать нечего. Разумеется, вы тоже можете (на равных условиях!) делать собственные заявки, но в этом случае их должен рассматривать кто-то другой.
Теперь собственно про дилемму: ваша работа как продуктовода — не в том, чтобы делать самые крутые и навороченные функции продукта, утерев нос конкурентам и завистникам. Ваша работа, как ни странно, сделать и поддерживать продукт, который в вас не нуждается. Чтобы вы создали или участвовали в создании группы поддержки, которая бы была ответственной за работу с вашим продуктом, и чтобы маркетинг и продажи со своими просьбами шли именно к ним, а не к вам. Это позволит вам сконцентрироваться на том, что действительно важно, — поиске ниш, которые можно было бы занять с помощью вашего продукта. Или, если вы чувствуете в себе силы, — на создание своего стартапа, где, как вас сейчас кажется, вы будете принимать решения самостоятельно.
Надо оговориться: во многих сфотверных стартапах используется упрощённый подход к разработке: у вас есть команда из, скажем, 10 разработчиков, 2 писателей, 5 тестеров и 2 менеджеров команды и проектов. На них в операционном бюджете компании выделены деньги, которые будут выданы зарплатой даже в случае простоя команды. Есть альтернативный подход (если ваш CFO или COO хочет навести структуру сразу, и CEO его/их внимательно слушает): на каждый новый релиз делать не только план, но и бюджет с расписанной стоимостью работы каждого работника. Если в структуре капитала вашей компании есть заёмные или инвесторские средства — скорее всего, вы уже столкнулись с тем, про что я пишу в этой статье. Подобная структура может напугать неопытного продуктовода, и вот почему:
так сложилось, но когда на каждый релиз есть отдельый бюджет, автономия продуктовода в принятии решений сводится почти к нулю — точнее, к ответственности за выслушивание других людей, имеющих мнение. Вот как это бывает в обычной жизни:
У вас есть бюджет $100 000 (нужную сумму подставьте сами) на каждый релиз, и предыдущий релиз подходит к логическому завершению, поэтому срочно нужно «замораживать» объём работ на новый релиз. Если вы сильно не озабочены бюджетом — вы просто посмотрите на vision продукта, на его roadmap и самостоятельно определите объём работ. Но само наличие бюджета на проект гарантирует тот факт, что к вам периодически будет наведываться COO или CFO и интересоваться, на что и как тратятся деньги. Из просто Loss Centre (т.е. подразделения, не отвечающего за прибыль) ваше подразделение теперь превращается в Loss Centre с Input into P&L (т.е. участвующее в процессе получения прибыли). А это уже игра совершенно по другим правилам.
Теперь каждая новая функция продукта должна иметь материальное обоснование. Сказать, что «эта функция приближает нас к светлому будущему», уже недостаточно: на вас набросятся люди, у которых есть вполне конкретные мысли по поводу того, что на самом деле должно быть в продукте. Плюс в том, что для вас процесс принятия решения упрощается, т.к. вы из него практически исключены :) Ваша роль — роль модератора и, если повезёт, — роль «адвоката дьявола» (только если эту роль не хочет играть COO или кто-то, на ком лежит ответственность за принятие финансовых решений): на вашем столе лежит описание 10 функций, реализация каждой из которых будет стоить по $25k (что включает в себя не только разработку, но и тестирование, документацию, обучение, изменение макетов рекламных листовок и т.п.), но реально вы сможете сделать только 4. Можно вообще сделать выбор очевидным, посчитав «удельный вес» заявки (я являюсь фанатом данного подхода независимо от типа стартапа), включающий в себя сумму весовых коэффициентов ответов на следующие вопросы:
- сколько будет стоить реализация запрошенного?
- сколько денег это принесёт? (например, NPV > 0 через 12 месяцев)
- как это соотносится со стратегическим направлением компании?
- является ли эта функция новой или ответом на действия конкурентов?
- и т.п. (в списке, которым я пользуюсь, 25 вопросов, но приводить его здесь не буду)
А уж опытному продуктоводу решить задачу сортировки полученных значений по убыванию — делать нечего. Разумеется, вы тоже можете (на равных условиях!) делать собственные заявки, но в этом случае их должен рассматривать кто-то другой.
Теперь собственно про дилемму: ваша работа как продуктовода — не в том, чтобы делать самые крутые и навороченные функции продукта, утерев нос конкурентам и завистникам. Ваша работа, как ни странно, сделать и поддерживать продукт, который в вас не нуждается. Чтобы вы создали или участвовали в создании группы поддержки, которая бы была ответственной за работу с вашим продуктом, и чтобы маркетинг и продажи со своими просьбами шли именно к ним, а не к вам. Это позволит вам сконцентрироваться на том, что действительно важно, — поиске ниш, которые можно было бы занять с помощью вашего продукта. Или, если вы чувствуете в себе силы, — на создание своего стартапа, где, как вас сейчас кажется, вы будете принимать решения самостоятельно.



комментарии (2)