Культура продуктовой команды: почему инженерам важно думать о клиентах, а не только о системах
Много лет работаю с командами разработчиков и вижу одну и ту же проблему: инженеры часто фокусируются на работе систем, а не на потребностях клиентов. В их голове формируется простая связка: я инженер — моя задача — идеальная система.
Что из этого выходит:
• Код выдирается до идеала
• Разработчики ревностно охраняют свой код от изменений
• Архитектура становится важнее клиентского опыта
Почему это проблема? Всё просто: затягиваются релизы, растут затраты, продукт медленнее адаптируется под рынок.
Как должно быть на самом деле? Фокус должен быть на решении проблем клиента. Инженерные навыки — это просто инструмент для работы. Да, краткосрочные решения могут быть неоптимальными с технической точки зрения, но в долгосрочной перспективе продукт будет лучше и полезнее для пользователей.
Главное преимущество такого подхода — это более адаптивный код и высокая удовлетворённость пользователей. Когда разработчики думают о клиентах, им проще находить общий язык в команде и принимать решения.
Что можно сделать? Вовлекать инженеров в работу с клиентами, показывать влияние их решений на бизнес, создавать культуру совместного решения проблем. И главное — оценивать успех по тому, насколько довольны пользователи, а не по красоте кода.
В конце концов, технические решения должны служить потребностям пользователей, а не наоборот. И это не значит, что нужно писать плохой код — просто помнить, что наша конечная цель — это счастливые клиенты, а не идеальная система.
Много лет работаю с командами разработчиков и вижу одну и ту же проблему: инженеры часто фокусируются на работе систем, а не на потребностях клиентов. В их голове формируется простая связка: я инженер — моя задача — идеальная система.
Что из этого выходит:
• Код выдирается до идеала
• Разработчики ревностно охраняют свой код от изменений
• Архитектура становится важнее клиентского опыта
Почему это проблема? Всё просто: затягиваются релизы, растут затраты, продукт медленнее адаптируется под рынок.
Как должно быть на самом деле? Фокус должен быть на решении проблем клиента. Инженерные навыки — это просто инструмент для работы. Да, краткосрочные решения могут быть неоптимальными с технической точки зрения, но в долгосрочной перспективе продукт будет лучше и полезнее для пользователей.
Главное преимущество такого подхода — это более адаптивный код и высокая удовлетворённость пользователей. Когда разработчики думают о клиентах, им проще находить общий язык в команде и принимать решения.
Что можно сделать? Вовлекать инженеров в работу с клиентами, показывать влияние их решений на бизнес, создавать культуру совместного решения проблем. И главное — оценивать успех по тому, насколько довольны пользователи, а не по красоте кода.
В конце концов, технические решения должны служить потребностям пользователей, а не наоборот. И это не значит, что нужно писать плохой код — просто помнить, что наша конечная цель — это счастливые клиенты, а не идеальная система.
⚡2
Хочется похвастаться результатами первого квартала! 🔥
Записали видео с демо изменений. Главное достижение — реально начали избавлять сотрудников от рутины.
Раньше как было: котрудник, вместо того чтобы с клиентами общаться, отправляет сообщения вручную, рассказывает теплым клиентам о скидках, смотрит у кого этап ремонта подходит и пора напомнить о покупке кухни и т.д. А теперь — всё многое стало работать автоматически.
Лично для меня это был такой челлендж — впервые так масштабно взялись за трансформацию и автоматизацию. Когда видишь, как ребята начинают больше времени уделять клиентам вместо того, чтобы выполнять работу руками вместо плохо спроектированной системы — это кайф!
Записали видео с демо изменений. Главное достижение — реально начали избавлять сотрудников от рутины.
Раньше как было: котрудник, вместо того чтобы с клиентами общаться, отправляет сообщения вручную, рассказывает теплым клиентам о скидках, смотрит у кого этап ремонта подходит и пора напомнить о покупке кухни и т.д. А теперь — всё многое стало работать автоматически.
Лично для меня это был такой челлендж — впервые так масштабно взялись за трансформацию и автоматизацию. Когда видишь, как ребята начинают больше времени уделять клиентам вместо того, чтобы выполнять работу руками вместо плохо спроектированной системы — это кайф!
❤6🍾6
Давно не постил ничего. Писал оч крутую статью про Единые мидлы.
Тут все от самой проблематики до самой реализации и итогов.
Это мой самый крупный кейс за все время работы.
https://vladislavershov.ru/blog/product-case-united-middle/
Тут все от самой проблематики до самой реализации и итогов.
Это мой самый крупный кейс за все время работы.
https://vladislavershov.ru/blog/product-case-united-middle/
❤3⚡1🫡1
ВЛАДыка
Давно не постил ничего. Писал оч крутую статью про Единые мидлы. Тут все от самой проблематики до самой реализации и итогов. Это мой самый крупный кейс за все время работы. https://vladislavershov.ru/blog/product-case-united-middle/
Имхо самая интересная часть тут про подход к расчету скорости изменения и эффективности команды.
Если коротко, все строится на тезисе, что все деньги, которые компания платит за специалиста, она платит не по часам за его время, а за результат, который он принесет. При этом результат оооочень косвенно коррелирует с потраченным временем. То есть можно поработать 2 часа и сделать прорыв, а можно все 100 и не добиться ничего.
Нашел пару исследований кмк связанных с этим тезисом:
1. Андерс Эрикссон: Исследования Андерса Эрикссона о развитии экспертных навыков показывают, что лучшие специалисты могут удерживать высокую интенсивность работы и концентрацию не более двух часов подряд. Его работы подчеркивают важность коротких интенсивных периодов работы над задачей.
2. Рой Баумайстер: Исследования Роя Баумайстера о силе воли и самоконтроле указывают на то, что принятие решений в течение дня истощает запасы силы воли, что может снижать эффективность работы во второй половине дня.
3. Кэл Ньюпорт: В своих работах Кэл Ньюпорт обсуждает разницу между занятостью и продуктивностью, подчеркивая, что умственная работа не всегда ведет к результатам и что важно концентрироваться на выполнении задач, а не просто быть занятым.
Если коротко, все строится на тезисе, что все деньги, которые компания платит за специалиста, она платит не по часам за его время, а за результат, который он принесет. При этом результат оооочень косвенно коррелирует с потраченным временем. То есть можно поработать 2 часа и сделать прорыв, а можно все 100 и не добиться ничего.
Нашел пару исследований кмк связанных с этим тезисом:
1. Андерс Эрикссон: Исследования Андерса Эрикссона о развитии экспертных навыков показывают, что лучшие специалисты могут удерживать высокую интенсивность работы и концентрацию не более двух часов подряд. Его работы подчеркивают важность коротких интенсивных периодов работы над задачей.
2. Рой Баумайстер: Исследования Роя Баумайстера о силе воли и самоконтроле указывают на то, что принятие решений в течение дня истощает запасы силы воли, что может снижать эффективность работы во второй половине дня.
3. Кэл Ньюпорт: В своих работах Кэл Ньюпорт обсуждает разницу между занятостью и продуктивностью, подчеркивая, что умственная работа не всегда ведет к результатам и что важно концентрироваться на выполнении задач, а не просто быть занятым.
Секретный соус больших трансформаций
На мой взгляд, при большой трансформации компании или бизнеса ключевое изменение происходит не в бизнес-процессах, потоках финансов или системах, а именно в головах людей, которые эту компанию создают.
Когда мы начинаем трансформацию, первое, что хочется изменить — это внешний вид компании: обновить бренд, интерфейсы и т.д. Но это в корне неверный подход.
Представьте: вы строите новый мир рядом с развалинами старого. Это не трансформация, а просто создание чего-то нового. Причём не с исправлением старых ошибок, а с созданием новых. И, скорее всего, мы окажемся в ситуации, когда и старый мир никуда не делся, и новый так и не возник.
🎯 Как же правильно провести трансформацию?
Используйте знакомые образы! Не пытайтесь создать что-то кардинально новое — возьмите уже существующие процессы и интерфейсы, но добавьте к ним новые функции.
Наша задача — не изобретать велосипед, а улучшить то, что уже есть. Акцентируйте внимание на том, чего раньше не хватало, и объясните, почему это необходимо изменить.
✨ Знакомые образы + новые функции = фундаментальный сдвиг ✨
Когда люди увидят, как знакомые вещи обретают новые возможности, они начнут воспринимать изменения по-новому. И только после этого можно будет обновить форму — это уже будет делом техники.
🔄 Трансформация — это не создание нового, а изменение старого.
На мой взгляд, при большой трансформации компании или бизнеса ключевое изменение происходит не в бизнес-процессах, потоках финансов или системах, а именно в головах людей, которые эту компанию создают.
Когда мы начинаем трансформацию, первое, что хочется изменить — это внешний вид компании: обновить бренд, интерфейсы и т.д. Но это в корне неверный подход.
Представьте: вы строите новый мир рядом с развалинами старого. Это не трансформация, а просто создание чего-то нового. Причём не с исправлением старых ошибок, а с созданием новых. И, скорее всего, мы окажемся в ситуации, когда и старый мир никуда не делся, и новый так и не возник.
🎯 Как же правильно провести трансформацию?
Используйте знакомые образы! Не пытайтесь создать что-то кардинально новое — возьмите уже существующие процессы и интерфейсы, но добавьте к ним новые функции.
Наша задача — не изобретать велосипед, а улучшить то, что уже есть. Акцентируйте внимание на том, чего раньше не хватало, и объясните, почему это необходимо изменить.
✨ Знакомые образы + новые функции = фундаментальный сдвиг ✨
Когда люди увидят, как знакомые вещи обретают новые возможности, они начнут воспринимать изменения по-новому. И только после этого можно будет обновить форму — это уже будет делом техники.
🔄 Трансформация — это не создание нового, а изменение старого.
🫡2
Forwarded from Black product owner | Тигран Басеян о продакт менеджменте и стартапах (Тигран Басеян)
/ Что не так с продуктовыми роадмапами/
Ох, сколько раз я и мои коллеги будучи продактами на платформах и сайтах хвастались единым скопом всех задачек в backlog, по которым были заполнены все оценки по всем столбцам (либо по RICE, либо по своей уникальной системе), задача была после приоритизации сделать единый Roadmap!
Но со временем понимаешь, что это неверный подход, давайте разбираться:
1. ваша работа не в том, чтобы расставлять приоритеты и документировать запросы на новые фичи.
Ваша задача — предоставить ценный, полезный и реализуемый продукт.
Если вы управляетесь не ценностью, а обещаниями функций, то этот фокус размывается. Вы гонитесь за списком, который морально мог устареть за последний месяц.
2. Этот подход противоречит целостному представлению о вашем продукте
Ваша цель — повысить конверсию, или помочь пользователям выполнить свою работу, то есть по факту помочь им решить ихджобу (простите) работу
Ваши строчечки в backlog – это некие представления о том, что может помочь в этом. Но когда эти представления ложатся в дорожную карту, то вы совершенно не можете представить, а эта функция реализуема, а этот комит я смогу выполнить?
Хуже того, вы это не узнаете, пока не пройдете Дискавери по данной функции.
Зафиксировать определенные функции на уровне дорожной карты — значит фактически пропустить самую важную часть вашей работы и ключ к созданию отличных продуктов — Product Discovery.
3. Пользовательский опыт или UX.
Если вы занимались дискавери, а потом проектированием, то вы представляете, что ваши идеи и представления могут координально измениться после дискавери.
Особенно эту путаницу усиливает карта развития многих продуктов. Я был долгое время CPO с разнымии сервисами и мои дорожные карты – это было настолько эпохально. А еще мои карты мигрировали и в маркетинг, что создавало некоторые ожидания о наших продуктах вовне. И по факту я уже не мог поменять свой комит, даже если становилось очевидно, что такой продукт или функция уже никому не нужны.
Если необходимо, поделитесь своим видением, но дайте себе как можно больше места для маневра с точки зрения того, как это видение будет реализовано.
Учитывая все вышесказанное, дорожные карты — один из моих любимых инструментов. Если все сделано правильно, они невероятно полезны для продакта, борда, маркетинга и особенно для разработчиков.
Дорожная карта должна описывать путь от того места, где вы находитесь сейчас, к реализации видения, которое вы изложили в своей стратегии продукта.
У вас же есть продуктовая стратегия, верно?
В противном случае ваша дорожная карта продукта не имеет реального контекста, и это серьезная проблема!
Дорожные карты должны быть очень простыми и высокоуровневыми. Они должны отражать ваши текущие мысли о том, какие цели являются наиболее важными.
Выводить ли продукт на международный уровень?
Есть поддержка мобильных устройств?
Поддержка дополнительных персонажей?
Решаете ключевые проблемы юзабилити?
Дорожная карта не является спецификацией и не представляет собой подробный список функций.
Также помните, что, хотя вы обычно указываете сроки в дорожной карте («в первом квартале мы хотим запустить продукт на Казахстан»), эти даты, по сути, являются лишь вашими надеждами и желаниями.
Только после того, как вы проведете Дискавери, поработаете с разработчиками и проведете грумминг, а управление проектом / PMO фактически запланирует работу, у вас будут реальные даты, в которые можно поверить.
Что думаете?
Ваш @blackproduct
Ох, сколько раз я и мои коллеги будучи продактами на платформах и сайтах хвастались единым скопом всех задачек в backlog, по которым были заполнены все оценки по всем столбцам (либо по RICE, либо по своей уникальной системе), задача была после приоритизации сделать единый Roadmap!
Но со временем понимаешь, что это неверный подход, давайте разбираться:
1. ваша работа не в том, чтобы расставлять приоритеты и документировать запросы на новые фичи.
Ваша задача — предоставить ценный, полезный и реализуемый продукт.
Если вы управляетесь не ценностью, а обещаниями функций, то этот фокус размывается. Вы гонитесь за списком, который морально мог устареть за последний месяц.
2. Этот подход противоречит целостному представлению о вашем продукте
Ваша цель — повысить конверсию, или помочь пользователям выполнить свою работу, то есть по факту помочь им решить их
Ваши строчечки в backlog – это некие представления о том, что может помочь в этом. Но когда эти представления ложатся в дорожную карту, то вы совершенно не можете представить, а эта функция реализуема, а этот комит я смогу выполнить?
Хуже того, вы это не узнаете, пока не пройдете Дискавери по данной функции.
Зафиксировать определенные функции на уровне дорожной карты — значит фактически пропустить самую важную часть вашей работы и ключ к созданию отличных продуктов — Product Discovery.
3. Пользовательский опыт или UX.
Если вы занимались дискавери, а потом проектированием, то вы представляете, что ваши идеи и представления могут координально измениться после дискавери.
Особенно эту путаницу усиливает карта развития многих продуктов. Я был долгое время CPO с разнымии сервисами и мои дорожные карты – это было настолько эпохально. А еще мои карты мигрировали и в маркетинг, что создавало некоторые ожидания о наших продуктах вовне. И по факту я уже не мог поменять свой комит, даже если становилось очевидно, что такой продукт или функция уже никому не нужны.
Если необходимо, поделитесь своим видением, но дайте себе как можно больше места для маневра с точки зрения того, как это видение будет реализовано.
Учитывая все вышесказанное, дорожные карты — один из моих любимых инструментов. Если все сделано правильно, они невероятно полезны для продакта, борда, маркетинга и особенно для разработчиков.
Дорожная карта должна описывать путь от того места, где вы находитесь сейчас, к реализации видения, которое вы изложили в своей стратегии продукта.
У вас же есть продуктовая стратегия, верно?
В противном случае ваша дорожная карта продукта не имеет реального контекста, и это серьезная проблема!
Дорожные карты должны быть очень простыми и высокоуровневыми. Они должны отражать ваши текущие мысли о том, какие цели являются наиболее важными.
Выводить ли продукт на международный уровень?
Есть поддержка мобильных устройств?
Поддержка дополнительных персонажей?
Решаете ключевые проблемы юзабилити?
Дорожная карта не является спецификацией и не представляет собой подробный список функций.
Также помните, что, хотя вы обычно указываете сроки в дорожной карте («в первом квартале мы хотим запустить продукт на Казахстан»), эти даты, по сути, являются лишь вашими надеждами и желаниями.
Только после того, как вы проведете Дискавери, поработаете с разработчиками и проведете грумминг, а управление проектом / PMO фактически запланирует работу, у вас будут реальные даты, в которые можно поверить.
Что думаете?
Ваш @blackproduct
❤1
ВЛАДыка
Закрыл две рабочих задачи так и не приступив к ним. Они стали неактуальны
Это я так воспитываю молодое поколение продактов
❤3😁2