Не соглашусь. Как раз в больших компаниях круг обязанностей продакта сильно ограничен, потому что там много людей, роли между ними распределены. В небольшой компании ты как раз этим и занимаешься — всем, что необходимо для успешности твоего продукта. Ну или ищешь тех, кто этим займется. Я тут не про требования писала, а про реальность, с которым сталкиваются менеджеры продукта, когда погружаются в это. И самое страшное — это как раз разнообразие и количество задач, которые нужно сделать. Потом ты привыкаешь и понимаешь, что все это не страшно, но в самом начале это все очень сильно накрывает. Это то, что мне говорят все начинающие продакты
Генерировать идеи не сложно. Сложно генерировать идеи, которые будут приносить пользу. И топить свои же идеи, которые пользу не приносят. Если продакт только бегает между стейкхолдерами и приоритизирует таски, то либо остальное за него делают другие, либо продукт будет себя чувствовать не очень хорошо (и обычно наступает второй вариант). Я бы такого человека назвала фиче-мастер, а не менеджер продукта
Помимо кода у тебя может быть миллион других проблем — какой фреймворк выбрать и как его использовать, где вести задачи (какие тулзы лучше использовать), как эффективно коммуницировать с другими разработчиками, менеджерами и смежными отделами, как легко справиться с ростов команды…
Если ты просто кодишь, и других вопросов у тебя вообще не возникает, то мои совету не подойдут. Но тогда какой вообще профит ехать на конфу? О трендах ты можешь с тем же успехом почитать или потом посмотреть видосики. Эффект будет тот же
Для разработчиков это еще более актуально. Тусить тоже можно с пользой — находить новых интересных людей (да, я знаю, что это ад интроверта, сама такая), задавать им вопросы, которые ты сам не можешь решить. От этого гораздо больше пользы, чем просто стоять в углу на вечеринке и говорить со своими же.
И новые знания тоже можно получать по-разному. Можно послушать, сказать: «прикольно» и вернуться к тому же, с чем приехал. А можно рассказать всем в компании, попробовать что-то применить, найти ответы на нерешенные проблемы своих коллег, которые не поехали.
Но это именно то, что я хотела донести. Все советы о том, что нужно делать, чтобы конференция стала самой бесполезной. Не читай описание, и велика вероятность, что попадешь на доклады, которые будут тебе неинтересны. Не получишь пользы — profit! Мы же этого добиваемся
Иногда у меня, как у продуктолога, нет выхода.
Выбор достаточно жесткий:
— или мы даем рынку хоть что-то, что закроет его боль
— или это дают конкуренты, и нас вытесняют с рынка
Все еще усугубляется тем, что мы делаем b2b решения — это значит, что клиентов у нас мало, каждый платит много (потеря даже одного клиента ощутима), они все другу друга знают. Сарафанное радио работает очень быстро.
Мы, конечно, стараемся баланс сохранять, но если мы потеряем клиентов, то любая куча кода будет бесполезна.
Вот тут есть риск, что тебе начнут сразу закладывать двигатель, что потребует еще 2 недели разработки. А потом окажется, что железная коробка вообще не подходит. И колеса не нужны — а нужны крылья. И вообще оно по земле перемещаться не может в силу ограничений бизнеса клиента.
Ну и сценарии не всегда понятны, когда ты первопроходец.
И вот тут вы не правы. Им нужно не просто подумать «мне нужно, что бы мой код делал X», а «Как мне написать так, что бы мой код делал X», что далеко не всегда тривиальная задача, иначе бы им не платити так много. И вы их просите подумать еще дополнительно о том «Хотел бы я этим пользоваться? Удобно ли бы мне было?». Это дополнительная работа, которая требует время.
Любой навык можно тренировать. В первый раз вы потратите на это 2 дополнительных часа. Во второй — 1,5. В третий — час. И т.д. Со временем вы привыкнете к продукту и к такому мышлению, и это будет происходить очень быстро. И если мне разработчик скажет, что он потратит 2 часа, чтобы понять функционал продукта, я с радостью включу эти 2 часа в план разработки.
Потому что это принесет много дополнительных бонусов. Как минимум, вы начнете отлично разбираться в функционале и будете видеть всю картину целиком.
Тут еще стоит заметить, что у некоторых разработчиков (например, у меня), немного другие подходы к оценке удобства инструментов, чем у пользователей.
Тут согласна, есть замечательная книга на эту тему «Психбольница в руках пациентов». Никто не говорит, что вы полностью должны проводить ревью функционала, но иногда команда действительно может заметить какие-то неудобства или предложить решение, которое менеджеру просто не пришло в голову, потому что он над этой задачей сидит уже 5 дней, и у него банально взгляд замылен.
Нужно просто обращать на это внимание. И если возник вопросы, не думать: «Зачем я за менеджера буду его работу делать? Он пусть и думает. Не написано, значит не делаю.» Иногда действительно достаточно просто вопрос правильный задать
Как раз очень важно соблюдать баланс между гибкостью стартапа и налаженными процессами крупной компании. Среди продуктологов это очень актуальная тема сейчас. И у некоторых получается.
никто не любит сидеть по 12 часов на работе
Тут полностью согласна, я совершенно против овертаймов
— непродуманная архитектура, помноженная на многократные доделки и переделки, рождает блохастое чудовище, которое проще усыпить чем вылечить. Через пару лет существования такого продукта неожиданно окажется, что добавление новой фичи или устранение простой на вид ошибки вызывает у разработчиков непропорционально большие трудозатраты. И не говорите тогда, что вас не предупреждали — все эти стоны разработчиков про необходимость рефакторинга, это вам четкий сигнал, что продукт с гнильцой.
Это один из рисков быстрой разработки.
На другой чаше весов — мы будем продумывать архитектуру, писать ТЗ, долго и качественно все реализовывать, а потом, например, выйдет закон, который скажет, что так больше делать нельзя (а такое часто бывает с b2b продуктами). И мы получим много потраченных денег и ненужный продукт, но зато с классной архитектурой.
Вопрос лишь в том, что вы считаете большим риском.
низкая мотивация в команде
Надеюсь, что нет. Я как раз очень стараюсь донести, что гордиться надо не идеальным кодом, а тем, что твой продукт приносит пользу людям
Также хорошо видно, что автор не понимает термин MVP
Автор понимает, что такое MVP, а эта картинка стоит у нее в качестве заставки на рабочем столе.
Если посмотреть на эту картинку, то видно, что на первом этапе MVP, например, не имеет двигателя. Я прихожу к разработчику и говорю: «Давай сделаем железную коробку на колесах, чтобы ее можно было вручную толкать». Разработчик делает. Потом я прихожу и говорю: «Давай двигатель добавим», а в ответ слышу: «Мы это в архитектуру не закладывали», так что пусть и дальше руками толкают.
постыдились бы такое писать!
Я как раз и писала это в негативном свете, что я ловлю себя на мысли, что так делаю, хотя это неверно. Я тоже неидеальна. И иногда замечаю, что не объяснила что-то разработчикам, потому что для меня это очевидно, а для них — нет. Когнитивные искажения никто не отменял.
Не полное ТЗ, постоянная коммуникация с PM, аналитиком, в заказчиком прежде чем приступить к выполнению задачи.
Я вас понимаю) Как и своих разработчиков, которые тоже этого хотят.
В статье я как раз попыталась приоткрыть завесу и рассказать, почему зачастую это очень сложно (а еще долго, дорого и может оказаться никому ненужным)
У вас прямо тут скрыто противоречие. Перед тем, как делать задачу, мне нужно отвлечься от погружения в код и технический реализации и подумать про то, как это должно быть для конечного кастомера, и, очень вероятно, задать кучу вопросов менеджеру, потому что у него банально знаний о кастомерах довольно мало.
Не вижу противоречий. Когда вы садитесь делать задачу (я говорю о продуктово задаче, а не о технической, где четко прописано, в какой функции что нужно изменить), вы должны сначала понять, что именно должны запрограммировать.
Бэкенд и фронтенд садятся и пишут спеку на основе прототипа от дизайнера, например. Они уже трогают функционал. Нужно просто сделать маленький шажок и посмотреть на это не с точки зрения: «Мне нужно, чтобы мой код вот так делал», а с точки зрения: «Хотел бы я этим пользоваться? Удобно ли бы мне было?»
Продуктовое мышление требует затрат по времени, особенно от программистов, так как очень часто из-за процессов и экономии по времени они не посвящены даже в концепции продукта.
Так разработчики как раз и должны быть посвящены в концепцию продукта. Задача менеджера продукта, в том числе, объяснять команде, кто и как использует продукт, зачем мы вообще его делаем.
И если разработчики этого не знают (хотя хотели бы), то это уже ошибка менеджера.
Когда я писала статью, я не ставила целью дать обратную связь команде — обратную связь я даю в другом формате.
Так же моей целью не была критика разработчиков. Я хотела указать на причину одного из самых частых моих конфликтов с командой и показать, почему я уделяю столько сил и времени продуктовому мышлению, почему для меня это важно (и, возможно, важно для ваших менеджеров).
И да, что касается разработки — моя команда действительно классная. Иногда даже слишком) Они действительно могут построить архитектуру и написать классный код.
И опять же таки, постоянно переделывать это тоже плохо, потому что постоянные хаотичные переделывания очень плохо сказываются на качестве продукта и обычно означают, что у вас проблемы с долгосрочным планированием.
Я как раз и пыталась донести мысль, что в быстроразвивающемся продуктовом мире, где постоянно нужно проверять гипотезы (чем больше, тем лучше), долгосрочное планирование — непозволительная роскошь.
У нас, конечно, есть общее стратегическое планирование, но знать заранее, какой функционал будет востребованным через 3/6/9 месяцев очень сложно. Недавний пример — 54ФЗ, фактически создавший новую отрасль.
Если мы будем так планировать каждую фичу, то будем уступать юрким стартапам. Им терять нечего, они проверяют больше гипотез, и находят те самые алмазы, за которые люди готовы платить.
Моя команда не идеальна, и я не вижу ничего страшного в том, чтобы об этом говорить. В моей жизни вообще мало чего-то идеального. Да и себя я бы менеджером мечты не назвала.
Но это не значит, что я не стремлюсь стать лучше. И от команды я хочу того же. Замалчивая проблемы и не озвучивая ожидания, сложно получить то, чего хочешь.
Про конфликт и «идеальную архитектуру» полностью согласна. Я тоже понимаю разработчиков. И как я «продаю» свои продуктовые таски команде, я хочу, чтобы мне «продавали» технический долг. Я никогда не откажусь выделить время на рефакторинг, если мне расскажут, что это избавит нас от каких-то конкретных проблем.
Боль даже не в том, что продуктовыми тасками жертвуют ради рефакторинга, а в том, что разработчики хотят написать сразу «бетон» и больше его не переделывать. А в современной продуктовой разработке это почти невозможно (как раз и пыталась донести, почему)
Проще всего сказать — «Я тут просто код пишу, а вы дальше сами мучайтесь, это не моя задача.»
Так же, как и я, менеджер, могу вообще о коде не думать, не понимать, что такое API, и как там внутри все взаимодействует. Могу не разбираться в железках, а каждый раз дёргать админа, когда мне задают вопрос по оборудованию.
Менеджер проекта может не читать документацию, которую нам прислали партнеры для интеграции, а просто скинуть ее в задачу (Нам часто присылают неполную документацию или вообще не то. Мы стараемся сами ее просматривать и просим уточнения, чтобы лишний раз разработчиков не отвлекать).
Да много чего можем не делать, что не входит в круг наших прямых обязанностей. В тоже время я понимаю, что иногда мне проще пожертвовать своим временем, чем просить это сделать разработчика.
В этом смысл командной работы — помощь друг другу, коммуникации.
Ну и еще момент — продуктовое мышление не требует дополнительных затрат времени. Когда ты открываешь задачу, ты не просто как робот ее выполняешь, а сначала задаешь вопросы — себе и менеджеру, если нужно. В большинстве случаев этого достаточно.
По опыту общения с другими менеджерами — такая проблема не только у меня. Я верю, что где-то есть разработчики моей мечты — зрелые, самоорганизующиеся и с продуктовым мышлением. Я описываю те проблемы, с которым сталкиваюсь именно сейчас. Я надеюсь, что мы с командой их перерастем
Мы занимаемся автоматизацией кинобизнеса. У нас линейка b2b продуктов, которая закрывает все потребности кинотеатров от составления репертуара до отчетности по проданным билетам.
Всего у нас 6 продуктовых команд, каждая из которых занимается своим направлением.
Я — менеджер продуктов для 2-команд (одна отвечает за продажи офлайн, другая — за онлайн)
Если ты просто кодишь, и других вопросов у тебя вообще не возникает, то мои совету не подойдут. Но тогда какой вообще профит ехать на конфу? О трендах ты можешь с тем же успехом почитать или потом посмотреть видосики. Эффект будет тот же
И новые знания тоже можно получать по-разному. Можно послушать, сказать: «прикольно» и вернуться к тому же, с чем приехал. А можно рассказать всем в компании, попробовать что-то применить, найти ответы на нерешенные проблемы своих коллег, которые не поехали.
И вот так пользы в разы больше
Но это именно то, что я хотела донести. Все советы о том, что нужно делать, чтобы конференция стала самой бесполезной. Не читай описание, и велика вероятность, что попадешь на доклады, которые будут тебе неинтересны. Не получишь пользы — profit! Мы же этого добиваемся
Выбор достаточно жесткий:
— или мы даем рынку хоть что-то, что закроет его боль
— или это дают конкуренты, и нас вытесняют с рынка
Все еще усугубляется тем, что мы делаем b2b решения — это значит, что клиентов у нас мало, каждый платит много (потеря даже одного клиента ощутима), они все другу друга знают. Сарафанное радио работает очень быстро.
Мы, конечно, стараемся баланс сохранять, но если мы потеряем клиентов, то любая куча кода будет бесполезна.
Ну и сценарии не всегда понятны, когда ты первопроходец.
Любой навык можно тренировать. В первый раз вы потратите на это 2 дополнительных часа. Во второй — 1,5. В третий — час. И т.д. Со временем вы привыкнете к продукту и к такому мышлению, и это будет происходить очень быстро. И если мне разработчик скажет, что он потратит 2 часа, чтобы понять функционал продукта, я с радостью включу эти 2 часа в план разработки.
Потому что это принесет много дополнительных бонусов. Как минимум, вы начнете отлично разбираться в функционале и будете видеть всю картину целиком.
Тут согласна, есть замечательная книга на эту тему «Психбольница в руках пациентов». Никто не говорит, что вы полностью должны проводить ревью функционала, но иногда команда действительно может заметить какие-то неудобства или предложить решение, которое менеджеру просто не пришло в голову, потому что он над этой задачей сидит уже 5 дней, и у него банально взгляд замылен.
Нужно просто обращать на это внимание. И если возник вопросы, не думать: «Зачем я за менеджера буду его работу делать? Он пусть и думает. Не написано, значит не делаю.» Иногда действительно достаточно просто вопрос правильный задать
Тут полностью согласна, я совершенно против овертаймов
Это один из рисков быстрой разработки.
На другой чаше весов — мы будем продумывать архитектуру, писать ТЗ, долго и качественно все реализовывать, а потом, например, выйдет закон, который скажет, что так больше делать нельзя (а такое часто бывает с b2b продуктами). И мы получим много потраченных денег и ненужный продукт, но зато с классной архитектурой.
Вопрос лишь в том, что вы считаете большим риском.
Надеюсь, что нет. Я как раз очень стараюсь донести, что гордиться надо не идеальным кодом, а тем, что твой продукт приносит пользу людям
Автор понимает, что такое MVP, а эта картинка стоит у нее в качестве заставки на рабочем столе.
Если посмотреть на эту картинку, то видно, что на первом этапе MVP, например, не имеет двигателя. Я прихожу к разработчику и говорю: «Давай сделаем железную коробку на колесах, чтобы ее можно было вручную толкать». Разработчик делает. Потом я прихожу и говорю: «Давай двигатель добавим», а в ответ слышу: «Мы это в архитектуру не закладывали», так что пусть и дальше руками толкают.
Я как раз и писала это в негативном свете, что я ловлю себя на мысли, что так делаю, хотя это неверно. Я тоже неидеальна. И иногда замечаю, что не объяснила что-то разработчикам, потому что для меня это очевидно, а для них — нет. Когнитивные искажения никто не отменял.
Я вас понимаю) Как и своих разработчиков, которые тоже этого хотят.
В статье я как раз попыталась приоткрыть завесу и рассказать, почему зачастую это очень сложно (а еще долго, дорого и может оказаться никому ненужным)
Не вижу противоречий. Когда вы садитесь делать задачу (я говорю о продуктово задаче, а не о технической, где четко прописано, в какой функции что нужно изменить), вы должны сначала понять, что именно должны запрограммировать.
Бэкенд и фронтенд садятся и пишут спеку на основе прототипа от дизайнера, например. Они уже трогают функционал. Нужно просто сделать маленький шажок и посмотреть на это не с точки зрения: «Мне нужно, чтобы мой код вот так делал», а с точки зрения: «Хотел бы я этим пользоваться? Удобно ли бы мне было?»
Так разработчики как раз и должны быть посвящены в концепцию продукта. Задача менеджера продукта, в том числе, объяснять команде, кто и как использует продукт, зачем мы вообще его делаем.
И если разработчики этого не знают (хотя хотели бы), то это уже ошибка менеджера.
Так же моей целью не была критика разработчиков. Я хотела указать на причину одного из самых частых моих конфликтов с командой и показать, почему я уделяю столько сил и времени продуктовому мышлению, почему для меня это важно (и, возможно, важно для ваших менеджеров).
И да, что касается разработки — моя команда действительно классная. Иногда даже слишком) Они действительно могут построить архитектуру и написать классный код.
Я как раз и пыталась донести мысль, что в быстроразвивающемся продуктовом мире, где постоянно нужно проверять гипотезы (чем больше, тем лучше), долгосрочное планирование — непозволительная роскошь.
У нас, конечно, есть общее стратегическое планирование, но знать заранее, какой функционал будет востребованным через 3/6/9 месяцев очень сложно. Недавний пример — 54ФЗ, фактически создавший новую отрасль.
Если мы будем так планировать каждую фичу, то будем уступать юрким стартапам. Им терять нечего, они проверяют больше гипотез, и находят те самые алмазы, за которые люди готовы платить.
Но это не значит, что я не стремлюсь стать лучше. И от команды я хочу того же. Замалчивая проблемы и не озвучивая ожидания, сложно получить то, чего хочешь.
Про конфликт и «идеальную архитектуру» полностью согласна. Я тоже понимаю разработчиков. И как я «продаю» свои продуктовые таски команде, я хочу, чтобы мне «продавали» технический долг. Я никогда не откажусь выделить время на рефакторинг, если мне расскажут, что это избавит нас от каких-то конкретных проблем.
Боль даже не в том, что продуктовыми тасками жертвуют ради рефакторинга, а в том, что разработчики хотят написать сразу «бетон» и больше его не переделывать. А в современной продуктовой разработке это почти невозможно (как раз и пыталась донести, почему)
Так же, как и я, менеджер, могу вообще о коде не думать, не понимать, что такое API, и как там внутри все взаимодействует. Могу не разбираться в железках, а каждый раз дёргать админа, когда мне задают вопрос по оборудованию.
Менеджер проекта может не читать документацию, которую нам прислали партнеры для интеграции, а просто скинуть ее в задачу (Нам часто присылают неполную документацию или вообще не то. Мы стараемся сами ее просматривать и просим уточнения, чтобы лишний раз разработчиков не отвлекать).
Да много чего можем не делать, что не входит в круг наших прямых обязанностей. В тоже время я понимаю, что иногда мне проще пожертвовать своим временем, чем просить это сделать разработчика.
В этом смысл командной работы — помощь друг другу, коммуникации.
Ну и еще момент — продуктовое мышление не требует дополнительных затрат времени. Когда ты открываешь задачу, ты не просто как робот ее выполняешь, а сначала задаешь вопросы — себе и менеджеру, если нужно. В большинстве случаев этого достаточно.
Всего у нас 6 продуктовых команд, каждая из которых занимается своим направлением.
Я — менеджер продуктов для 2-команд (одна отвечает за продажи офлайн, другая — за онлайн)