Наличие багов не тождественно плохой продукт
Сколько раз вы сталкивались с ситуацией, когда присутствие ошибок в продукте приравнивали к плохому или сырому продукту?
Бывает, пишет/звонит пользователь и эмоционально высказывается, что найденная им ошибка мешает жить, да и сам продукт не продукт. И оказывается выявленная ошибка старая и в беклоге давно лежит себе спокойно с минорным приоритетом. Плохой ли продукт, если статистика по обратной связи от других пользователей говорит об обратном?
Другая ситуация. Кто-нибудь внимательный к деталям из менеджмента, стейкхолдеров или заказчик, начинает считать баги в продуктовом беклоге и оценивать продукт как плохой. Ведь в хорошем, ошибок быть недолжно. Плохой ли продукт?
Как правило ошибки в беклоге отсутствуют в двух случаях. В первом, продукт ещё не вышел, не продается, или даже не прошёл первоначального тестирования. Во втором случае он уже давно мёртв и не поддерживается. Что нужно уже сделано, остальное закрыли за ненадобностью.
В живом продукте всегда есть баги. Жирные пугающие, связанные с большим рефакторингом, мелкие досадные - неточности в пользовательском интерфейсе. Баги с высоким приоритетом и с низким. И весь этот супчик варится в беклоге нормального развивающегося продукта. Даже у именитых продуктов есть огромным беклог с проблемами, которые иногда не исправляются годами и которые не мешают ему развиваться и привлекать все новых и новых пользователей.
Управление техдолгом и его результатом и частым спутником - перечнем багов, одна из важных частей управления развитием продукта.
А что насчëт плохого/хорошего? Хороший продукт может быть тот, который монетизируется и востребован, с растущей базой пользователей, который достигает целей по метрикам и статистике. Количеством зарегистрированных багов это не оценивается.
@aheadofthepack
Сколько раз вы сталкивались с ситуацией, когда присутствие ошибок в продукте приравнивали к плохому или сырому продукту?
Бывает, пишет/звонит пользователь и эмоционально высказывается, что найденная им ошибка мешает жить, да и сам продукт не продукт. И оказывается выявленная ошибка старая и в беклоге давно лежит себе спокойно с минорным приоритетом. Плохой ли продукт, если статистика по обратной связи от других пользователей говорит об обратном?
Другая ситуация. Кто-нибудь внимательный к деталям из менеджмента, стейкхолдеров или заказчик, начинает считать баги в продуктовом беклоге и оценивать продукт как плохой. Ведь в хорошем, ошибок быть недолжно. Плохой ли продукт?
Как правило ошибки в беклоге отсутствуют в двух случаях. В первом, продукт ещё не вышел, не продается, или даже не прошёл первоначального тестирования. Во втором случае он уже давно мёртв и не поддерживается. Что нужно уже сделано, остальное закрыли за ненадобностью.
В живом продукте всегда есть баги. Жирные пугающие, связанные с большим рефакторингом, мелкие досадные - неточности в пользовательском интерфейсе. Баги с высоким приоритетом и с низким. И весь этот супчик варится в беклоге нормального развивающегося продукта. Даже у именитых продуктов есть огромным беклог с проблемами, которые иногда не исправляются годами и которые не мешают ему развиваться и привлекать все новых и новых пользователей.
Управление техдолгом и его результатом и частым спутником - перечнем багов, одна из важных частей управления развитием продукта.
А что насчëт плохого/хорошего? Хороший продукт может быть тот, который монетизируется и востребован, с растущей базой пользователей, который достигает целей по метрикам и статистике. Количеством зарегистрированных багов это не оценивается.
@aheadofthepack
Скрытые потребности
Одна из проблем разработки, отсутствие видения картины в целом. Потери истинных потребностей конечных пользователей продукта или его ценности для бизнеса часто случаются, когда разработку отдают на аутсорсинг. При этом не важно, будет ли это разработка продукта целиком, или же это какая-то часть большого проекта, например только дизайн и иллюстрации.
При этом, в отсутствии открытости информации, между заказчиком и исполнителем встают странные барьеры: «Зачем знать, как конечный продукт будет использоваться? Есть сухое ТЗ. Этого достаточно». Происходит то ли боязнь, что бизнес-идея будет украдена, то ли нежелание уделять время на погружение в особенности своего бизнеса, процессов, работы остальных контрагентов. В итоге бизнес-требования остаются недосказанными, а то, что было сделано в соответствии с системными из технического задания не закрывает потребности пользователя, либо доставляет ему значительные неудобства.
Вместо ситуации win-win, получаем противоположную. Появляются лишние издержки денег и времени на многократную доделку и переделку продукта. Продукт получается кривее, дороже и выходит на рынок позже, чем мог бы. Что уж говорить об удовлетворенности пользователя.
Но такие ситуации могут быть не только с аутсорсингом, но и внутри одной компании, когда люди бизнеса - маркетинг и продажи варятся в своём котле. К примеру, не предоставляют информации о рынке и обратной связи от пользователей, если процесс настроена подобным образом.
В результате недопонимания людей бизнеса и людей разработки и незнания истинных целей может рождаться большое количество дорогого техдолга, о котором периодически пишу. Ведь именно с бизнес-процессами, ролевой моделью, пользовательскими сценариями прорабатывается глубокое понимание первоначальных потребностей и закладывается правильная архитектура, удобные интерфейсы и дизайн.
@aheadofthepack
Одна из проблем разработки, отсутствие видения картины в целом. Потери истинных потребностей конечных пользователей продукта или его ценности для бизнеса часто случаются, когда разработку отдают на аутсорсинг. При этом не важно, будет ли это разработка продукта целиком, или же это какая-то часть большого проекта, например только дизайн и иллюстрации.
При этом, в отсутствии открытости информации, между заказчиком и исполнителем встают странные барьеры: «Зачем знать, как конечный продукт будет использоваться? Есть сухое ТЗ. Этого достаточно». Происходит то ли боязнь, что бизнес-идея будет украдена, то ли нежелание уделять время на погружение в особенности своего бизнеса, процессов, работы остальных контрагентов. В итоге бизнес-требования остаются недосказанными, а то, что было сделано в соответствии с системными из технического задания не закрывает потребности пользователя, либо доставляет ему значительные неудобства.
Вместо ситуации win-win, получаем противоположную. Появляются лишние издержки денег и времени на многократную доделку и переделку продукта. Продукт получается кривее, дороже и выходит на рынок позже, чем мог бы. Что уж говорить об удовлетворенности пользователя.
Но такие ситуации могут быть не только с аутсорсингом, но и внутри одной компании, когда люди бизнеса - маркетинг и продажи варятся в своём котле. К примеру, не предоставляют информации о рынке и обратной связи от пользователей, если процесс настроена подобным образом.
В результате недопонимания людей бизнеса и людей разработки и незнания истинных целей может рождаться большое количество дорогого техдолга, о котором периодически пишу. Ведь именно с бизнес-процессами, ролевой моделью, пользовательскими сценариями прорабатывается глубокое понимание первоначальных потребностей и закладывается правильная архитектура, удобные интерфейсы и дизайн.
@aheadofthepack
T-shaped специалисты во фрилансе
Тут много пишу о инхаус разработке, росте командной экспертизы и прокачке T-shaped навыков внутри команды. Но разработка не всегда целесообразна и возможна только за счёт внутренних ресурсов. Иногда бывает лучше отдать часть работы на аутсорсинг, либо фрилансерам. И мне приходилось с этим сталкиваться и нанимать внешний ресурс для проектов.
Развитие T-shaped специалистов – это трендовое направление современных продуктовых команд. И тут не поспоришь. Но, если продуктовые команды еще как-то могут существовать и работать на старых I-shaped подходах, то во фрилансе дела обстоят несколько иначе. Именно тут проявляется необходимость развития дополнительных навыков.
Начал писать пост об этом, но в итоге вышла небольшая 👉 Cтатья на VC
Тут много пишу о инхаус разработке, росте командной экспертизы и прокачке T-shaped навыков внутри команды. Но разработка не всегда целесообразна и возможна только за счёт внутренних ресурсов. Иногда бывает лучше отдать часть работы на аутсорсинг, либо фрилансерам. И мне приходилось с этим сталкиваться и нанимать внешний ресурс для проектов.
Развитие T-shaped специалистов – это трендовое направление современных продуктовых команд. И тут не поспоришь. Но, если продуктовые команды еще как-то могут существовать и работать на старых I-shaped подходах, то во фрилансе дела обстоят несколько иначе. Именно тут проявляется необходимость развития дополнительных навыков.
Начал писать пост об этом, но в итоге вышла небольшая 👉 Cтатья на VC
vc.ru
T-shaped специалисты во фрилансе — Карьера на vc.ru
Какие навыки хорошо бы подкачать фрилансеру, чтобы войти выстроить долгосрочную стратегию работы? И причем тут T-shaped?
❤3👍2
Как менеджеру мотивировать себя, если не видно прямого результата его работы?
Ух, сколько раз сталкивался с ситуацией, когда, работая в роли менеджера на операционке невозможно поделить свою работу на задачи, списывать часы и получать внутреннее удовлетворение от законченной работы. Вроде работаешь работаешь, а работа «не твоя». Но если не закрывать задачи, как же самомотивироваться?
Да, конечно, можно брать за основу корпоративные KPI/OKR. И очень хорошо, если они не спускаются откуда-то далеко сверху, а часть из них выработана в совместных усилиях. Но достижение каких-то показателей тоже не решает проблему полностью.
Как мне видится, гораздо важнее помимо корпоративной «обязаловки» ставить еще и свои собственные цели. Ведь внутренняя мотивация куда сильнее любой внешней. Честно, гораздо приятнее работать с какими-то вызовами и челленджами самому себе. И тут есть некоторые вещи, которые могут очень даже мотивировать:
🔹Возможность изучить и освоить что-то новое даёт классную мотивацию. Это может быть новая технология, метод или подход. Расширение кругозора в процессе работы круто мотивирует. Особенно прёт, когда есть возможность применить к месту эти новые знания. Для некоторых это даже является веской причиной смены вроде бы хорошей работы.
Следующая ступень – это возможность делиться этими знаниями внутри компании или даже вне её. Как говорится, сам изучил, обучи других.
🔹Достижение каких-то измеримых метрик, где они не встроены в общую систему. Например, метрик процесса разработки. Не секрет, что кому-то свойственно настраивать процессы, оптимизировать их и следить за тем, как улучшаются их метрики. Не менее интересны и метрики продукта. Причем в них можно получить иногда чуть ли не экспоненциальный рост. Само это может мотивировать.
🔹 Сопричастность с результатом общего труда. Менеджер проекта или продукта на то и менеджер, что сам он сделать в одиночку не сможет. Не сможет прейти к цели за адекватный отрезок времени. Но может это сделать с командой и ресурсами, приложив свои качества для достижения результата.
Поэтому, вне зависимости от того, выстроена ли корпоративная мотивация менеджеров, самомотивация может быть сильным драйвером. Главное, у менеджеров как правило гораздо больше направлений деятельности и, следовательно, возможностей замотивировать себя, чем у линейных сотрудников.
Подумать и написать пост на тему самомотивации менеджеров мы договорились с Александром Субботиным, CTO и автором канала Saturday Night Hack
Поэтому, рекомендую почитать его мнение по этому вопросу: 👉эволюция мотивации менеджера
Ух, сколько раз сталкивался с ситуацией, когда, работая в роли менеджера на операционке невозможно поделить свою работу на задачи, списывать часы и получать внутреннее удовлетворение от законченной работы. Вроде работаешь работаешь, а работа «не твоя». Но если не закрывать задачи, как же самомотивироваться?
Да, конечно, можно брать за основу корпоративные KPI/OKR. И очень хорошо, если они не спускаются откуда-то далеко сверху, а часть из них выработана в совместных усилиях. Но достижение каких-то показателей тоже не решает проблему полностью.
Как мне видится, гораздо важнее помимо корпоративной «обязаловки» ставить еще и свои собственные цели. Ведь внутренняя мотивация куда сильнее любой внешней. Честно, гораздо приятнее работать с какими-то вызовами и челленджами самому себе. И тут есть некоторые вещи, которые могут очень даже мотивировать:
🔹Возможность изучить и освоить что-то новое даёт классную мотивацию. Это может быть новая технология, метод или подход. Расширение кругозора в процессе работы круто мотивирует. Особенно прёт, когда есть возможность применить к месту эти новые знания. Для некоторых это даже является веской причиной смены вроде бы хорошей работы.
Следующая ступень – это возможность делиться этими знаниями внутри компании или даже вне её. Как говорится, сам изучил, обучи других.
🔹Достижение каких-то измеримых метрик, где они не встроены в общую систему. Например, метрик процесса разработки. Не секрет, что кому-то свойственно настраивать процессы, оптимизировать их и следить за тем, как улучшаются их метрики. Не менее интересны и метрики продукта. Причем в них можно получить иногда чуть ли не экспоненциальный рост. Само это может мотивировать.
🔹 Сопричастность с результатом общего труда. Менеджер проекта или продукта на то и менеджер, что сам он сделать в одиночку не сможет. Не сможет прейти к цели за адекватный отрезок времени. Но может это сделать с командой и ресурсами, приложив свои качества для достижения результата.
Поэтому, вне зависимости от того, выстроена ли корпоративная мотивация менеджеров, самомотивация может быть сильным драйвером. Главное, у менеджеров как правило гораздо больше направлений деятельности и, следовательно, возможностей замотивировать себя, чем у линейных сотрудников.
Подумать и написать пост на тему самомотивации менеджеров мы договорились с Александром Субботиным, CTO и автором канала Saturday Night Hack
Поэтому, рекомендую почитать его мнение по этому вопросу: 👉эволюция мотивации менеджера
Telegram
Saturday Night Hack
Субъективно про продуктивность и IT
Автор: @alexsubbotin, Software Engineer в Raycast, ex. CTO Appbooster.
Автор: @alexsubbotin, Software Engineer в Raycast, ex. CTO Appbooster.
👍4❤3
Эго-продукты
Успешный продукт всегда основывается на реальных потребностях пользователей и на решении их проблем. К сожалению, часто об этом забывают и пилят какое-то решение в угоду одного из сильный лидеров компании. Кто переборет внутренних менеджеров - конкурентов, тот и захватывает власть над штурвалом продуктовых приоритетов.
В итоге продукт получается как правило однобоким, сформированным виденьем одного человека на основе собственных представлений о рынке и пользователях. Это виденье может быть ярким и зажигательным, с кораблями, бороздящими просторы малого и большого, и прочими красотами. Но это имеет больше общего с миражем и галлюцинациями, нежели реальностью.
Ещё бывает достаточно частый кейс, когда проект под одного заказчика пытаются превращать в массовый продукт. Да, никто не запрещает работать на такого стратегического клиента. Такие альянсы прочны и полезны в перспективе. Но рыночным продуктом результат этого проекта не станет.
Поэтому так часто приходится закрывать разработанный эго-продукт на стадии MVP, и отправлять его на продуктовое кладбище. В менее трагичном варианте, проводить полноценное исследования потребностей пользователей заново и пивотиться в следующее направление.
В любом случае, стоит с большей эмпатией подходить к рынку, чем тешить своё эго.
@aheadofthepack
Успешный продукт всегда основывается на реальных потребностях пользователей и на решении их проблем. К сожалению, часто об этом забывают и пилят какое-то решение в угоду одного из сильный лидеров компании. Кто переборет внутренних менеджеров - конкурентов, тот и захватывает власть над штурвалом продуктовых приоритетов.
В итоге продукт получается как правило однобоким, сформированным виденьем одного человека на основе собственных представлений о рынке и пользователях. Это виденье может быть ярким и зажигательным, с кораблями, бороздящими просторы малого и большого, и прочими красотами. Но это имеет больше общего с миражем и галлюцинациями, нежели реальностью.
Ещё бывает достаточно частый кейс, когда проект под одного заказчика пытаются превращать в массовый продукт. Да, никто не запрещает работать на такого стратегического клиента. Такие альянсы прочны и полезны в перспективе. Но рыночным продуктом результат этого проекта не станет.
Поэтому так часто приходится закрывать разработанный эго-продукт на стадии MVP, и отправлять его на продуктовое кладбище. В менее трагичном варианте, проводить полноценное исследования потребностей пользователей заново и пивотиться в следующее направление.
В любом случае, стоит с большей эмпатией подходить к рынку, чем тешить своё эго.
@aheadofthepack
👍6❤3
Ошибка выбора
Всегда ли новый продукт должен быть инновационным?
Больше 15 лет назад, когда я был разработчиком различных сложных железяк с софтом, мы делали приборы. Это были очень классные штуки для отечественного рынка телекома.
Пришёл я в проект который разрабатывали и интегрировали с модным на тот день КПК от HP. Идея была технически великолепна, запихать низкопроизводительные вычислительные функции и GUI в КПК. А специализированную вычислительную начинку с интерфейсами сделать внешним модулем. Продукт был приличный. Он имел больше функций чем ближайшие аналоги на рынке, при этом был маленький, лёгкий и с современным дизайном в основном за счёт использования HP.
В том числе это и сыграло с ним злую шутку. Основные клиенты просто не восприняли продукт в таком форм-факторе, да ещё и с эстетичным дизайном. Для них он выглядел как игрушка, а не как мощное решение и они продолжали покупать тяжёлые традиционные "кирпичи". Ощущение от кирпича было соразмерным затратам: "Фирма заплатила кучу денег, и получила серьёзный прибор и чемоданчик для его транспортировки в придачу. Почему за кроху надо платить столько же или даже больше?" Никто не подумал предварительно исследовать психологическую готовность платить за такое решение.
Второй проблемой была зависимость от поставок чужого железа от HP, известная как vendor lock-in. Никому не нужен отличный софт, если нет платформы на которое его можно запускать. Этот риск невозможно было устранить, кроме как набив склады ненужным железом и вморозив финансы. Так или иначе эта проблема должна была в дальнейшем вывести продукт с рынка.
Этот продукт потерпел фиаско с финансовой точки зрения. Но он послужил хорошей основой для следующего удачного, разработанного с учётом набитых шишек.
Вспоминая этот болезненный опыт, уже будучи владельцем других продуктов и в других направлениях, я с командой отвергал и подмораживал самые инновоционные идей нацеленные на более консервативные рынки. Это было бы слишком рискованное решение.
Стоит соизмерять ценности и не уходить в креативные новшества там, где это не является главной идеей продукта. Инноваторов среди пользователей, как правило, совсем не много.
@aheadofthepack
Всегда ли новый продукт должен быть инновационным?
Больше 15 лет назад, когда я был разработчиком различных сложных железяк с софтом, мы делали приборы. Это были очень классные штуки для отечественного рынка телекома.
Пришёл я в проект который разрабатывали и интегрировали с модным на тот день КПК от HP. Идея была технически великолепна, запихать низкопроизводительные вычислительные функции и GUI в КПК. А специализированную вычислительную начинку с интерфейсами сделать внешним модулем. Продукт был приличный. Он имел больше функций чем ближайшие аналоги на рынке, при этом был маленький, лёгкий и с современным дизайном в основном за счёт использования HP.
В том числе это и сыграло с ним злую шутку. Основные клиенты просто не восприняли продукт в таком форм-факторе, да ещё и с эстетичным дизайном. Для них он выглядел как игрушка, а не как мощное решение и они продолжали покупать тяжёлые традиционные "кирпичи". Ощущение от кирпича было соразмерным затратам: "Фирма заплатила кучу денег, и получила серьёзный прибор и чемоданчик для его транспортировки в придачу. Почему за кроху надо платить столько же или даже больше?" Никто не подумал предварительно исследовать психологическую готовность платить за такое решение.
Второй проблемой была зависимость от поставок чужого железа от HP, известная как vendor lock-in. Никому не нужен отличный софт, если нет платформы на которое его можно запускать. Этот риск невозможно было устранить, кроме как набив склады ненужным железом и вморозив финансы. Так или иначе эта проблема должна была в дальнейшем вывести продукт с рынка.
Этот продукт потерпел фиаско с финансовой точки зрения. Но он послужил хорошей основой для следующего удачного, разработанного с учётом набитых шишек.
Вспоминая этот болезненный опыт, уже будучи владельцем других продуктов и в других направлениях, я с командой отвергал и подмораживал самые инновоционные идей нацеленные на более консервативные рынки. Это было бы слишком рискованное решение.
Стоит соизмерять ценности и не уходить в креативные новшества там, где это не является главной идеей продукта. Инноваторов среди пользователей, как правило, совсем не много.
@aheadofthepack
👍7❤3
Бери риски по себе, чтоб не падать при ходьбе
Менеджеры по разному работают с рисками и реагируют на события, когда эти риски срабатывают. Одним нормально работать в ситуации, когда вокруг все в огне: то прибыль взлетает ракетой, то начинаются кассовые разрывы. У других же даже сдвиг расписания по формальной задачке уже будет вызывать нервную дрожь в коленках.
Это связано с тем, что у всех людей совершенно разная чувствительность к риску. Есть конечно уникумы, которым с одной стороны любая зубодробительная задача нипочëм, а с другой и разгрузить мозг на потоковой работе могут без негативных последствий. Но таких единицы. Большинству людей комфортно работать в своей зоне рисков.
По степени роста неопределенности и рисков можно выделить три направления: проектное, продуктовое и личный предпринимательский опыт. Конечно, деление скорее условное, тут есть много нюансов и перекрытий.
👷♂️Кто-то из менеджеров склонен работать на проектах с низкой степенью риска. К примеру, разработка типового сайта. Когда берёшься за 101ый проект, зная, что все просчитано досконально. Как правило уже проработана рисковая модель, построенная на предыдущем проектном опыте. Отклонения сроков и бюджетов, вызванные возможными событиями вполне контролируемы.
💡Другим нравится работа над новыми продуктами. Тут масса неизвестных и результат до конца непредсказуем, а пивоты случаются с завидной регулярностью. Просчитать куда двинется развитие продукта заранее часто невозможно. Поэтому строить какие-либо модели гораздо сложнее. Вероятность и воздействие рисков возрастают существенно. Далеко не всем комфортно работать с такой неопределённостью и у них опускаются руки. А кто-то чувствует себя в таких условиях как рыба в воде.
🚀Третьи готовы рискнуть не только своим временем, но и собственными деньгами, а также деньгами, полученными из источников FFF (Friends, Family, Fools), т е друзей, семьи и хороших людей. Не беда, что по итогу можно оказаться с пустыми карманами, да еще и долгами и выгоревшими в ноль от бесконечных перегрузок и разочарований. При этом таким людям рутина стандартных проектов и процессов может показаться жутким болотом по сравнению с американскими горками собственного предпринимательского опыта.
Однако повышать риски ради того, чтобы пощекотать себе нервы, не всегда оправдано. Вне зависимости от того, с какой степенью риска вам комфортно работать, надо стараться здраво оценивать и те бенефиты, которую вы можете извлечь из процесса. Это не всегда могут быть деньги, но и интерес, получаемый от самой работы.
@aheadofthepack
Менеджеры по разному работают с рисками и реагируют на события, когда эти риски срабатывают. Одним нормально работать в ситуации, когда вокруг все в огне: то прибыль взлетает ракетой, то начинаются кассовые разрывы. У других же даже сдвиг расписания по формальной задачке уже будет вызывать нервную дрожь в коленках.
Это связано с тем, что у всех людей совершенно разная чувствительность к риску. Есть конечно уникумы, которым с одной стороны любая зубодробительная задача нипочëм, а с другой и разгрузить мозг на потоковой работе могут без негативных последствий. Но таких единицы. Большинству людей комфортно работать в своей зоне рисков.
По степени роста неопределенности и рисков можно выделить три направления: проектное, продуктовое и личный предпринимательский опыт. Конечно, деление скорее условное, тут есть много нюансов и перекрытий.
👷♂️Кто-то из менеджеров склонен работать на проектах с низкой степенью риска. К примеру, разработка типового сайта. Когда берёшься за 101ый проект, зная, что все просчитано досконально. Как правило уже проработана рисковая модель, построенная на предыдущем проектном опыте. Отклонения сроков и бюджетов, вызванные возможными событиями вполне контролируемы.
💡Другим нравится работа над новыми продуктами. Тут масса неизвестных и результат до конца непредсказуем, а пивоты случаются с завидной регулярностью. Просчитать куда двинется развитие продукта заранее часто невозможно. Поэтому строить какие-либо модели гораздо сложнее. Вероятность и воздействие рисков возрастают существенно. Далеко не всем комфортно работать с такой неопределённостью и у них опускаются руки. А кто-то чувствует себя в таких условиях как рыба в воде.
🚀Третьи готовы рискнуть не только своим временем, но и собственными деньгами, а также деньгами, полученными из источников FFF (Friends, Family, Fools), т е друзей, семьи и хороших людей. Не беда, что по итогу можно оказаться с пустыми карманами, да еще и долгами и выгоревшими в ноль от бесконечных перегрузок и разочарований. При этом таким людям рутина стандартных проектов и процессов может показаться жутким болотом по сравнению с американскими горками собственного предпринимательского опыта.
Однако повышать риски ради того, чтобы пощекотать себе нервы, не всегда оправдано. Вне зависимости от того, с какой степенью риска вам комфортно работать, надо стараться здраво оценивать и те бенефиты, которую вы можете извлечь из процесса. Это не всегда могут быть деньги, но и интерес, получаемый от самой работы.
@aheadofthepack
👍8❤3
Привет, Железяка!
Продукты, состоящие не только из программного обеспечения, но и железа (Hardware, а по нашему аппаратной части) имеют свою предметную область со своими особенностями. Для простоты буду называть такие продукты железяки.
А поскольку есть нюансы, подход к разработке и развитию этих железяк будет отличаться. Да и путь в менеджеры продукта может быть несколько иной со своими закавыками и приоритетами по скилам.
Написал статью👉 Привет, Железяка! Управление продуктом в хардварных стартапах
Порассуждал об особенностях таких продуктов, об их прототипировании и циклах разработки, которые иногда сложно подружить с Agile подходами. Также коснулся вопросов работы с заинтересованными сторонами, рисками и экономикой.
Постарался переложить это всё на те навыки, которыми неплохо бы обладать любому менеджеру, занимающемуся развитие этих непростых железячных продуктов.
@aheadofthepack
Продукты, состоящие не только из программного обеспечения, но и железа (Hardware, а по нашему аппаратной части) имеют свою предметную область со своими особенностями. Для простоты буду называть такие продукты железяки.
А поскольку есть нюансы, подход к разработке и развитию этих железяк будет отличаться. Да и путь в менеджеры продукта может быть несколько иной со своими закавыками и приоритетами по скилам.
Написал статью👉 Привет, Железяка! Управление продуктом в хардварных стартапах
Порассуждал об особенностях таких продуктов, об их прототипировании и циклах разработки, которые иногда сложно подружить с Agile подходами. Также коснулся вопросов работы с заинтересованными сторонами, рисками и экономикой.
Постарался переложить это всё на те навыки, которыми неплохо бы обладать любому менеджеру, занимающемуся развитие этих непростых железячных продуктов.
@aheadofthepack
vc.ru
Привет, Железяка! Управление продуктом в хардварных стартапах — Карьера на vc.ru
Продукты, состоящие не только из программного обеспечения, но и железа (Hardware, а по нашему аппаратной части) имеют свою предметную область со своими особенностями. Для простоты буду называть такие продукты железяки. А поскольку есть особенности, подход…
👍14❤5
Вовлечённые соучастники
По настоящему классные продукты не разрабатывают в кабинетах директоров. Там вряд ли можно найти креативные идеи даже после очередного мозгового штурма до 11 вечера после тяжёлого дня. Как правило участникам уже либо хочется слинять домой, либо они уже в посттрудовой коме.
Классные, читай полезные и удобные, продукты рождаются скорее в результате продолжительного контакта с пользователями. Которые уже становятся не совсем безвольными "пользователями", "потребителями" услуги или продукта, обычными лояльными клиентами, а вовлечёнными участниками процесса создания продукта для себя самих.
Стоит перестать мыслить категориями: "Мы эксперты, мы вас научим, мы вам покажем как надо". Лучше периодами переходить в позицию обучающегося. Ведь так можно получать новую информацию и инсайты.
Из ранних пользователей всегда получаются самые лучшие бета-тестеры. Они предоставят обратную связь о том, насколько удобно пользоваться продуктом. Вовлеченные соучастники дадут кучу полезных советов, а кто-то даже багрепорты по свежему продукту. Куда же без багов.
Стоит ли привлекать к участию в разработке всех подряд, вопрос спорный. Это скорее зависит от типа продукта (B2B, B2C), рискам распространения иногда не самой полезной для маркетинга информации о новом продукте.
Но так или иначе, чем раньше удаётся выйти из стеклянной банки в которой проводятся исследования и разработка, тем больше шансов получить результат.
@aheadofthepack
По настоящему классные продукты не разрабатывают в кабинетах директоров. Там вряд ли можно найти креативные идеи даже после очередного мозгового штурма до 11 вечера после тяжёлого дня. Как правило участникам уже либо хочется слинять домой, либо они уже в посттрудовой коме.
Классные, читай полезные и удобные, продукты рождаются скорее в результате продолжительного контакта с пользователями. Которые уже становятся не совсем безвольными "пользователями", "потребителями" услуги или продукта, обычными лояльными клиентами, а вовлечёнными участниками процесса создания продукта для себя самих.
Стоит перестать мыслить категориями: "Мы эксперты, мы вас научим, мы вам покажем как надо". Лучше периодами переходить в позицию обучающегося. Ведь так можно получать новую информацию и инсайты.
Из ранних пользователей всегда получаются самые лучшие бета-тестеры. Они предоставят обратную связь о том, насколько удобно пользоваться продуктом. Вовлеченные соучастники дадут кучу полезных советов, а кто-то даже багрепорты по свежему продукту. Куда же без багов.
Стоит ли привлекать к участию в разработке всех подряд, вопрос спорный. Это скорее зависит от типа продукта (B2B, B2C), рискам распространения иногда не самой полезной для маркетинга информации о новом продукте.
Но так или иначе, чем раньше удаётся выйти из стеклянной банки в которой проводятся исследования и разработка, тем больше шансов получить результат.
@aheadofthepack
👍19❤5
Вечные сложности B2B
Часто в В2В конечный пользователь продукта и тот, кто принимает решение о закупке - разные люди. У них разные роли в компании и разные критерии выбора. Одним важны какие-либо свойства продукта, другим цена, взаимодействие с контрагентами и много чего ещё. При переходе из разработки ориентированной на В2С в направление В2В, об этом иногда забывают.
Здесь важно понять, какие компании будут потреблять продукт, как у них устроена "внутренняя кухня" принятия решений. Кто будет лицом принимающим решение (ЛПР), а кто только советует и влияет на принятие решения (ЛВР). Как правило, в небольших организациях у конечных пользователей больше возможностей донести свои требования и хотелки наверх. И их требования тоже учитываются. В крупных компаниях с многоуровневой иерархией, тендерной системой, и прочими подобными атрибутами процесс может выглядеть сильно иначе.
Сколько раз встречалась ситуация, когда линейный персонал говорит: "Вот это классная штука, мне бы с ней поработать!" Но в реалиях существования бизнеса этого никогда не произойдёт, из-за массы всевозможных факторов, влияющих на закупку. Поэтому, как бы этого не хотелось, при разработке опрометчиво ориентироваться преимущественно на хотелки данной категории. Кстати, это можно даже проследить по посредственному UX многих продуктов для бизнеса. Но сейчас с этим уже есть положительные изменения.
Чтобы привести продукт B2B к успеху, надо получить ответы на вопросы о том, какие компании будут заинтересованы в продукте и как организованы их внутренние процессы. Хорошо бы эти ответы получить ещё до построения стратегии по продукту. Иначе, может оказаться, все выстроенные в стройный ряд плюшечки, проработанные и упоминаемые при продвижении, будут совершенно не оценены теми, кто будет принимать решение о начале сотрудничества.
@aheadofthepack
Часто в В2В конечный пользователь продукта и тот, кто принимает решение о закупке - разные люди. У них разные роли в компании и разные критерии выбора. Одним важны какие-либо свойства продукта, другим цена, взаимодействие с контрагентами и много чего ещё. При переходе из разработки ориентированной на В2С в направление В2В, об этом иногда забывают.
Здесь важно понять, какие компании будут потреблять продукт, как у них устроена "внутренняя кухня" принятия решений. Кто будет лицом принимающим решение (ЛПР), а кто только советует и влияет на принятие решения (ЛВР). Как правило, в небольших организациях у конечных пользователей больше возможностей донести свои требования и хотелки наверх. И их требования тоже учитываются. В крупных компаниях с многоуровневой иерархией, тендерной системой, и прочими подобными атрибутами процесс может выглядеть сильно иначе.
Сколько раз встречалась ситуация, когда линейный персонал говорит: "Вот это классная штука, мне бы с ней поработать!" Но в реалиях существования бизнеса этого никогда не произойдёт, из-за массы всевозможных факторов, влияющих на закупку. Поэтому, как бы этого не хотелось, при разработке опрометчиво ориентироваться преимущественно на хотелки данной категории. Кстати, это можно даже проследить по посредственному UX многих продуктов для бизнеса. Но сейчас с этим уже есть положительные изменения.
Чтобы привести продукт B2B к успеху, надо получить ответы на вопросы о том, какие компании будут заинтересованы в продукте и как организованы их внутренние процессы. Хорошо бы эти ответы получить ещё до построения стратегии по продукту. Иначе, может оказаться, все выстроенные в стройный ряд плюшечки, проработанные и упоминаемые при продвижении, будут совершенно не оценены теми, кто будет принимать решение о начале сотрудничества.
@aheadofthepack
👍36❤5
Есть шаблон?
Замечаю, что в отсутствии структурированных знаний о предмете исполнители часто просят предоставить готовый шаблон.
Профиты понятны. Шаблон унифицирует повторяющееся действие. Шаблон можно быстро заполнить по образу и подобию. Особенно, если есть готовый пример. С шаблоном сложно накосячить. Ну и можно не напрягать думательную мышцу лишний раз, экономя энергию.
Однако, хорошо бы понимать откуда взялся этот очередной шаблон. Вариантов источников масса. Как правило, это:
✔️Стандарты разработанные серьёзными организациями. К примеру, если взять область менеджмента, солидными источниками могут являться: PMI, IEEE, ISO, и другие. Наверное, это самые правильный источник информации и шаблонов. Он подойдет, где не страшна лишняя обобщенность, и где область знаний меняется не так быстро. Качественно, но пригодно не всегда.
✔️Самостоятельная творческая фирменная разработка, основанная на каких-то внутренних исследованиях. Велосипедами все горазды обзаводится, от микробизнесов до матерых корпораций. Всем, кому не жалко своих ресурсов.
✔️Заимствование извне, от одного из признанных экспертов в предметной области. Понятные риски лежат на поверхности. "Не все йогурты одинаково полезны", но по инновационным направлениям шаблоны можно нарыть как раз в этой сложной категории источников.
✔️ Нагугленное в непонятных и недостоверных источниках на просторах интернета.
Последний пункт несмотря на странность имеет распространение из-за простоты, но является причиной кучи проблем в дальнейшем. Особенно, когда причастные люди давно покинули фирму и концов не найти, такие подозрительные артефакты продолжают храниться и дублироваться по каталогам.
Не скажу, что шаблоны - это зло. Как раз наоборот, это полезная штука. Особенно, если приготовлена правильно и из правильных ингредиентов.
@aheadofthepack
Замечаю, что в отсутствии структурированных знаний о предмете исполнители часто просят предоставить готовый шаблон.
Профиты понятны. Шаблон унифицирует повторяющееся действие. Шаблон можно быстро заполнить по образу и подобию. Особенно, если есть готовый пример. С шаблоном сложно накосячить. Ну и можно не напрягать думательную мышцу лишний раз, экономя энергию.
Однако, хорошо бы понимать откуда взялся этот очередной шаблон. Вариантов источников масса. Как правило, это:
✔️Стандарты разработанные серьёзными организациями. К примеру, если взять область менеджмента, солидными источниками могут являться: PMI, IEEE, ISO, и другие. Наверное, это самые правильный источник информации и шаблонов. Он подойдет, где не страшна лишняя обобщенность, и где область знаний меняется не так быстро. Качественно, но пригодно не всегда.
✔️Самостоятельная творческая фирменная разработка, основанная на каких-то внутренних исследованиях. Велосипедами все горазды обзаводится, от микробизнесов до матерых корпораций. Всем, кому не жалко своих ресурсов.
✔️Заимствование извне, от одного из признанных экспертов в предметной области. Понятные риски лежат на поверхности. "Не все йогурты одинаково полезны", но по инновационным направлениям шаблоны можно нарыть как раз в этой сложной категории источников.
✔️ Нагугленное в непонятных и недостоверных источниках на просторах интернета.
Последний пункт несмотря на странность имеет распространение из-за простоты, но является причиной кучи проблем в дальнейшем. Особенно, когда причастные люди давно покинули фирму и концов не найти, такие подозрительные артефакты продолжают храниться и дублироваться по каталогам.
Не скажу, что шаблоны - это зло. Как раз наоборот, это полезная штука. Особенно, если приготовлена правильно и из правильных ингредиентов.
@aheadofthepack
👍32❤5
Эмоциональные связи
При продуктовой разработке эмоциональную составляющую часто недооценивают.
Одной лишь логикой невозможно сделать выбор. Кроме логики есть и значительная неосознанная часть. Можно называть её интуицией или чем-нибудь еще. Люди не роботы. Сами того не осознавая мы часто выбираем неосознанно. Именно эмоции определяют значимость того или иного решения, или ценность качеств продукта в конкретной ситуации.
Логика, как более медленный процесс, включается уже после совершения действия - когда эмоциональный выбор уже давным давно совершён. Ха-ха. Бывает, мы подыскиваем правильные аргументы, чтобы постфактум обосновать принятое решение. Строим сложные таблицы с многофакторным скорингом, а потом подкручиваем цифры, где это возможно, чтобы результат вписался в сделанный выбор. Ну, чем не пример?
Из этого следует некоторый вывод. Разработать MVP продукта из минимального набора наиболее востребованных функций не всегда достаточно. Да, можно сделать что-то похожее на продукт. Может быть он будет даже полезен. Но будет ли этот урезанный продукт восприниматься пользователем как желанный? Вызовет ли он желание воспользоваться им и в последующем купить.
Не раз встречал ситуацию, когда на этапе покупки, такого желания как раз не возникало. Мало того, даже при поведении решенческих интервью, где проверяется лишь потенциальная возможность заплатить за минимальный продукт или его описание, результат был отрицательный. Решение было принято не в пользу продукта, в том числе из-за отсутствия эмоциональной связи. Заходя на следующий шаг, пропадает и возможность расширения аудитории на ранних стадиях за счёт рекомендаций продукта окружению.
Кроме MVP есть концепция MLR (Minimum Loveable Product), о которой я уже как-то писал. Такая концепция разработки прототипов и проверки решения боем, лучше подходит для решения проблемы неопределённости. Не во всех случаях, но во многих, эффективнее применять именно её.
@aheadofthepack
При продуктовой разработке эмоциональную составляющую часто недооценивают.
Одной лишь логикой невозможно сделать выбор. Кроме логики есть и значительная неосознанная часть. Можно называть её интуицией или чем-нибудь еще. Люди не роботы. Сами того не осознавая мы часто выбираем неосознанно. Именно эмоции определяют значимость того или иного решения, или ценность качеств продукта в конкретной ситуации.
Логика, как более медленный процесс, включается уже после совершения действия - когда эмоциональный выбор уже давным давно совершён. Ха-ха. Бывает, мы подыскиваем правильные аргументы, чтобы постфактум обосновать принятое решение. Строим сложные таблицы с многофакторным скорингом, а потом подкручиваем цифры, где это возможно, чтобы результат вписался в сделанный выбор. Ну, чем не пример?
Из этого следует некоторый вывод. Разработать MVP продукта из минимального набора наиболее востребованных функций не всегда достаточно. Да, можно сделать что-то похожее на продукт. Может быть он будет даже полезен. Но будет ли этот урезанный продукт восприниматься пользователем как желанный? Вызовет ли он желание воспользоваться им и в последующем купить.
Не раз встречал ситуацию, когда на этапе покупки, такого желания как раз не возникало. Мало того, даже при поведении решенческих интервью, где проверяется лишь потенциальная возможность заплатить за минимальный продукт или его описание, результат был отрицательный. Решение было принято не в пользу продукта, в том числе из-за отсутствия эмоциональной связи. Заходя на следующий шаг, пропадает и возможность расширения аудитории на ранних стадиях за счёт рекомендаций продукта окружению.
Кроме MVP есть концепция MLR (Minimum Loveable Product), о которой я уже как-то писал. Такая концепция разработки прототипов и проверки решения боем, лучше подходит для решения проблемы неопределённости. Не во всех случаях, но во многих, эффективнее применять именно её.
@aheadofthepack
👍35❤5
Развязанные шнурки и техдолг
Бежит по улице человек с не завязанными шнурками. Быстро перебирает ногами, торопится куда-то вперед. Штанина уже испачкалась в грязи от болтающихся туда сюда по грязному асфальту шнурков. Но незнакомцу всё некогда завязать шнурки, ведь впереди большая и важная цель. Так и бежит, пока не запнется об них и не упадёт. И сэкономленное время тут же пропадёт в никуда. Да ещё и одежду придется потом приводить в порядок, теряя время или деньги.
Так и с техническим долгом. Иногда не обращают на него внимание, выпуская софт, релиз за релизом, повышая риски и накапливая долговые проценты. Ну как же, есть дорожная карта по которой нужно вовремя успевать. Ещё один костыль будет не лишним в придачу к десятку других, подпирающих ветхий продукт?
Но приходит время и понимание того, что продукт в тупике из-за легаси и надо переделывать уже основательно, а цель вдруг юркнула далеко за горизонт. Казалось бы, вот вот успел схватить удачу. Но нет, проклятый техдолг, давно болтающийся как развязанные шнурки, сначала тормозил процесс, а потом вовсе подставил подножку в неподходящий момент.
Стоит ли копить долги, если не можете виртуозно ими управлять? Думаю, не стоит заведомо причислять себя к малой толике везунчиков, которым посчастливилось вновь и вновь уворачиваться от любых рисков.
Ещё о техдолге читайте в ранних постах: «Вредный» технический долг
@aheadofthepack
Бежит по улице человек с не завязанными шнурками. Быстро перебирает ногами, торопится куда-то вперед. Штанина уже испачкалась в грязи от болтающихся туда сюда по грязному асфальту шнурков. Но незнакомцу всё некогда завязать шнурки, ведь впереди большая и важная цель. Так и бежит, пока не запнется об них и не упадёт. И сэкономленное время тут же пропадёт в никуда. Да ещё и одежду придется потом приводить в порядок, теряя время или деньги.
Так и с техническим долгом. Иногда не обращают на него внимание, выпуская софт, релиз за релизом, повышая риски и накапливая долговые проценты. Ну как же, есть дорожная карта по которой нужно вовремя успевать. Ещё один костыль будет не лишним в придачу к десятку других, подпирающих ветхий продукт?
Но приходит время и понимание того, что продукт в тупике из-за легаси и надо переделывать уже основательно, а цель вдруг юркнула далеко за горизонт. Казалось бы, вот вот успел схватить удачу. Но нет, проклятый техдолг, давно болтающийся как развязанные шнурки, сначала тормозил процесс, а потом вовсе подставил подножку в неподходящий момент.
Стоит ли копить долги, если не можете виртуозно ими управлять? Думаю, не стоит заведомо причислять себя к малой толике везунчиков, которым посчастливилось вновь и вновь уворачиваться от любых рисков.
Ещё о техдолге читайте в ранних постах: «Вредный» технический долг
@aheadofthepack
Telegram
На шаг впереди
«Вредный» технический долг
Продуктовая разработка и технический долг ходят рука об руку. Я еще не встречал ни одного продукта, где бы техдолг отсутствовал полностью. Хотя может быть такие и есть на кладбище продуктов? :)
По традиции начать стоит с плохого.…
Продуктовая разработка и технический долг ходят рука об руку. Я еще не встречал ни одного продукта, где бы техдолг отсутствовал полностью. Хотя может быть такие и есть на кладбище продуктов? :)
По традиции начать стоит с плохого.…
👍41❤7
Репутационные опоры
Если вы ведёте любую открытую деятельность в публичном поле, строите бизнес, налаживаете социальные связи, деловая репутация крайне важна. Это тот нематериальный актив, который можно положить в фундамент подобных начинаний. Тем, кто игнорирует публичное поле, приходится сложнее наводить мосты. Не все готовы сотрудничать и работать с noname персонами.
Репутация не изолирована в вакууме и это не одноуровневая оценка. Мы многогранны в своей личности и наша репутация тоже может быть различна в разных кругах и группах, к которым мы относимся. Это и репутация в кругу знакомых и личный бренд в рабочих тусовках и сообществах. С другой стороны не стоит забывать и о гео-признаках и принадлежности к определённой культурной среде или большему бренду. Влияние тут взаимно. К примеру, работник может как подпортить, так и усилить репутацию фирмы, к которой он относится. Недаром на первых порах некоторые хотят устроиться в компании с солидными именами, откусив кусок репутационного пирога. Это же справедливо и в обратную сторону. И компании готовы делать подобный манёвр - привлекать каких-то известных личностей.
Построение репутации и бренда - процесс длительный. Разрушение, как правило, стремительный и сложнообратимый. Строительством бренда, как и любым другим стратегическим активом, можно заниматься годы. А потом все потерять.
В условиях кризиса доверия и потери имиджа можно опираться на те круги, которые остались. Несмотря на то, что для одной части репутации нанесён значительный ущерб, есть нетронутые круги. Не стоит сжигать мосты и рушить всё до основания. Надо находить неразрушенные части и строить фундамент заново опираясь на них.
@aheadofthepack
Если вы ведёте любую открытую деятельность в публичном поле, строите бизнес, налаживаете социальные связи, деловая репутация крайне важна. Это тот нематериальный актив, который можно положить в фундамент подобных начинаний. Тем, кто игнорирует публичное поле, приходится сложнее наводить мосты. Не все готовы сотрудничать и работать с noname персонами.
Репутация не изолирована в вакууме и это не одноуровневая оценка. Мы многогранны в своей личности и наша репутация тоже может быть различна в разных кругах и группах, к которым мы относимся. Это и репутация в кругу знакомых и личный бренд в рабочих тусовках и сообществах. С другой стороны не стоит забывать и о гео-признаках и принадлежности к определённой культурной среде или большему бренду. Влияние тут взаимно. К примеру, работник может как подпортить, так и усилить репутацию фирмы, к которой он относится. Недаром на первых порах некоторые хотят устроиться в компании с солидными именами, откусив кусок репутационного пирога. Это же справедливо и в обратную сторону. И компании готовы делать подобный манёвр - привлекать каких-то известных личностей.
Построение репутации и бренда - процесс длительный. Разрушение, как правило, стремительный и сложнообратимый. Строительством бренда, как и любым другим стратегическим активом, можно заниматься годы. А потом все потерять.
В условиях кризиса доверия и потери имиджа можно опираться на те круги, которые остались. Несмотря на то, что для одной части репутации нанесён значительный ущерб, есть нетронутые круги. Не стоит сжигать мосты и рушить всё до основания. Надо находить неразрушенные части и строить фундамент заново опираясь на них.
@aheadofthepack
👍46❤6