Сильная стратегия — это та, которая работает?

Кажется, ответ очевиден.

Но и сильные стратегии перестают работать. Часто потому, что мы пишем их, фокусируясь на чем-то одном: продуктовом портфеле, целях бизнеса или опыте пользователя. А сильная стратегия должна учитывать взаимосвязи между всеми этими элементами и не допускать, чтобы они начали конкурировать.

Проверить, насколько это получается у вас, могут помочь вопросы ниже.

🤩 Если все продукты достигают своих целей, означает ли это, что развивается весь продуктовый портфель?

Не всегда.

Локальные успехи могут не складываться в общую стратегию. Продукты начинают конкурировать за ресурсы, решать похожие задачи или мешать друг другу. В таком случае компания управляет отдельными успешными продуктами, но не системой.

🤩 Если стратегия выглядит убедительно внутри компании, значит ли это, что она будет работать для пользователя?

Тоже не обязательно.

Стратегические решения часто принимаются вокруг целей бизнеса, а клиентский путь остается способом проверить уже выбранное направление. Хотя именно он показывает, где пользователь действительно получает ценность и готов голосовать за нее деньгами, а где компания лишь предполагает, что создает ее.

🤩 Что должно стать отправной точкой стратегии: портфель продуктов или путь пользователя?

Пожалуй, ни то ни другое.

Сильная стратегия появляется тогда, когда эти две точки соединяются и образуют стартовую линию, усиливая друг друга.

С разных сторон эту тему раскроют спикеры ProductSense'26.

Анастасия Шатрова, менеджер проектов в «Контуре» покажет, как превратить портфельный аудит из списка отдельных продуктов в инструмент, который помогает видеть взаимосвязи, принимать стратегические решения и выстраивать единую систему развития.

Дмитрий Орлов, агент изменений в «Сбере» разберет, как использовать клиентский путь не как артефакт исследования, а как основу для стратегии, соединяя эмпатию, поток создания ценности и продуктовые решения.

Вместе эти доклады отвечают на один вопрос: как перестать мыслить стратегией как последовательностью отдельных решений и начать видеть ее как систему, в которой бизнес, продукты и пользовательский опыт работают вместе.

Подробнее о ProductSense'26 →

@pplsense

Ответственный исполнитель ≠ выполненная задача
Несколько слов о том, что мы понимаем под ответственностью

Человек взял ответственность → задача будет выполнена.
А если результата нет, значит, не такой уж он и ответственный.
Логично же звучит, правда?

Рассуждая так, мы смешиваем в одном котле две не всегда взаимосвязанные вещи: готовность человека отвечать за свою работу и его реальную возможность обеспечить результат.

Ответственность как личностное качество важна, но сама по себе она не может дать 100%-ную гарантию. Далее разберемся, почему так происходит.

🤩 Человек может отвечать за результат, но не управлять решениями, от которых этот результат зависит

Часто ответственность передают вместе с задачей, но не вместе с правом принимать решения.

Например, руководитель проекта отвечает за срок, но не может менять приоритеты команд. Менеджер продукта отвечает за метрику, но не влияет на бюджет, состав команды или продуктовые ограничения.

Простой способ проверить, действительно ли вы передали ответственность:
Представьте, что сотрудник завтра решил действовать без вашего участия.
Хватит ли ему полномочий, чтобы довести задачу до конца?

Если в критических точках ему все равно придется возвращаться за разрешением, значит, вместе с ответственностью вы передали только обязанность объяснять, почему результата нет.

🤩 Человек может отвечать за задачу, результат которой видит иначе, чем руководитель

«Запустить вовремя», «повысить качество», «разобраться с проблемой» — звучит как цель, но не определяет конечный результат.

Сотрудник может добросовестно делать то, что считает верным, а по итогу узнать, что ждали от него совсем другого.

Хорошая новость: это решается коммуникацией на старте.
Проверьте, одинаково ли вы понимаете:
— какой результат должен появиться;
— по каким критериям он будет принят;
— чем можно пожертвовать, если все условия выполнить невозможно.

🤩 Человек может быть готов отвечать за задачу, но не иметь ресурсов для ее выполнения

Это также легко проверить заранее.

Если сотрудник говорит, что ресурсов недостаточно, спросите: «Что именно тебе сейчас нужно изменить — срок, объем задач, количество людей или доступ к информации, — чтобы результат стал выполнимым?»

Учитывайте его ответы и совместно принимайте решения:
— либо добавляем ресурсы;
— либо уменьшаем объем;
— либо переносим срок;
— либо заранее договариваемся на менее амбициозный результат.

Если ничего из этого менять нельзя, требование «просто взять ответственность» не решит задачу, а лишь переложит последствия ограничений на сотрудника.

🤩 Одной ответственности может быть просто недостаточно для нужного результата

В масштабных задачах результат зависит не только от качества действий одного человека. Гипотеза может не подтвердиться. Поставщик — сорвать срок. Другая команда — изменить приоритеты. Рынок — отреагировать не так, как ожидалось.

Поэтому полезно разделять:
1) за что человек отвечает — качество решений, своевременные сигналы, работу с рисками, исполнение договоренностей;
2) что он не может гарантировать — устранить все внешние воздействия и разрешить все зависимости в срок.

Иначе мы незаметно превращаем ответственность в требование гарантировать неподконтрольное.

Чтобы понять, что помимо необходимых качеств характера человек имеет все возможности довести дело до результата, следует проверить, может ли он ответить «да» на следующие вопросы и пояснить ответ по каждому из них:
1. Я понимаю, какой результат считается успехом?
2. Я могу самостоятельно принимать ключевые решения?
3. У меня есть ресурсы?
4. Я понимаю, за что именно буду отвечать (за качество решений / за риски / за сроки / за что-то иное)?

Ответственность — это не гарантия результата. Это обязательство управлять тем, что находится в вашей зоне влияния, и отвечать за принятые решения.

@pplsense

«Не хватает ресурсов» — самая дорогая фраза в управлении

За последние несколько лет реализовывать идеи стало намного проще. ИИ, готовые сервисы и автоматизация сделали дешевле запуск новых инициатив и проверку гипотез.
Но вместе с этим возник новый парадокс: теперь проблема большинства команд не в том, что они не могут что-то сделать. Проблема в том, что они могут сделать слишком многое.

Сегодня недостаточно решить, что делать и где найти ресурсы. Гораздо важнее уметь объяснить, почему десятки других задач сознательно не берутся в работу. И именно здесь многие руководители совершают одну и ту же ошибку.

Когда руководителя спрашивают:
— Почему эта задача не вошла в план?

Очень часто звучит ответ:
— Не хватило ресурсов.

Иногда это действительно так.

Но гораздо чаще эта фраза становится универсальным объяснением, за которым скрываются совершенно разные причины.

Например:
— команда пока недостаточно понимает задачу, поэтому сначала нужно провести исследование;
— есть инициативы с более высоким ожидаемым эффектом;
— ожидаемая отдача не окупит стоимость реализации;
— у задачи нет человека, который сможет довести ее до результата;
— команда уже проходит через слишком большое количество изменений, и еще одна инициатива только снизит вероятность успеха;
— выполнение задачи зависит от решений другой команды.
И только одна из возможных причин — команде действительно не хватает пропускной способности.

На первый взгляд разница кажется несущественной. Но именно она определяет, какие решения вы будете принимать как руководитель.

Если любую проблему объяснять нехваткой ресурсов, то и решение всегда будет одно — искать новых людей. А это всегда очень большие расходы денег и времени на наём и обучение. В результате руководитель начинает лечить симптомы вместо причин. Компания тратит месяцы на поиск сотрудников, хотя ограничение могло быть вовсе не в количестве людей. Но если назвать настоящую причину, появляются разные рычаги влияния на ситуацию.

🤩Если команда плохо понимает задачу — провести исследование.
🤩Если есть инициативы с более высоким ожидаемым эффектом — сознательно отложить задачу и пересмотреть приоритеты.
🤩Если ожидаемый эффект не оправдывает стоимость реализации — отказаться от идеи.
🤩Если одновременно запущено слишком много изменений — сократить количество параллельных инициатив.
🤩Если нет владельца — определить того, кто сможет довести задачу до результата.
🤩Если задача зависит от другой команды — договориться о совместном плане, синхронизировать приоритеты или изменить порядок выполнения работ.
И только если после этого ограничением действительно остается пропускная способность команды, наём становится осознанным управленческим решением, а не реакцией по умолчанию.

Что можно попробовать уже на следующем планировании?

Если команда предлагает добавить новую инициативу или кто-то спрашивает, почему задача не вошла в план, не останавливайтесь на ответе «не хватает ресурсов». Попробуйте задать себе еще один вопрос: какая именно причина не позволяет нам взять эту задачу сейчас? Не общая, а одна конкретная.

Со временем вы заметите интересную вещь: разговор перестанет сводиться к обсуждению количества людей в команде и задач. Вместо этого вы начнете обсуждать ограничения системы: где не хватает информации, где перегружены процессы, где размыта ответственность, а где действительно достигнут предел возможностей команды.

Когда возможностей больше, чем можно реализовать, руководитель начинает управлять не количеством задач, а причинами выбора.

@pplsense

Вы развиваете продукт, а пользователь — свой опыт взаимодействия с ним

Со временем продукт постепенно перестает быть просто инструментом, которым пользователи закрывают свои потребности. Они начинают строить отношения с другими людьми и самими собой — расширяют опыт взаимодействия с продуктом.

Именно поэтому два похожих продукта могут вызывать совершенно разное желание вернуться.

Проверить, что именно мотивирует ваших пользователей возвращаться к продукту, могут помочь несколько вопросов.

🤩 Если убрать из продукта других пользователей, останется ли его ценность прежней?

Во многих продуктах люди возвращаются не только потому, что могут решить задачу. Они возвращаются за ощущением принадлежности, чувством признания, обменом опытом или возможностью делать что-то вместе.

Даже если люди не взаимодействуют друг с другом в продукте напрямую, ощущение, что продуктом пользуются такие же люди, возможность учиться на чужом опыте или чувствовать себя частью сообщества — могут влиять на желание вернуться не меньше, чем новые функции.

🤩 Что пользователь вспомнит через неделю после использования?

Не каждый экран одинаково влияет на восприятие продукта.

Человек может забыть детали интерфейса, но хорошо помнить, что почувствовал в самом конце: разочарование, облегчение, заботу, уверенность или желание поделиться опытом с другими.

Именно эти впечатления часто определяют, захочет ли он вернуться.

🤩 Что вы на самом деле проектируете: пользовательский путь или опыт?

Хороший пользовательский сценарий помогает выполнить задачу.

А желание вернуться появляется благодаря тому опыту, который остается у человека после взаимодействия с продуктом.

Поэтому, проектируя продукт, полезно спрашивать себя не только: «Что пользователь сделает?», но и: «Что он почувствует?», «Что запомнит?» и «Что заставит его вернуться, даже если задача уже решена?»

Если эти вопросы пробудили в вас любопытство к тому, что именно удерживает пользователей в вашем продукте, на ProductSense'26 можно будет разобрать эту тему на реальных кейсах.

Максим Архипов, руководитель «Сигнала», расскажет, как проектировать социальные механики, благодаря которым пользователи возвращаются не только за функциями, но и друг к другу.

Мария Щербаль, директор департамента клиентского опыта «Ванта Груп», покажет, как исследовать финальный этап пути клиента и понять, какие впечатления действительно влияют на желание вернуться.

Подробнее о ProductSense'26 →

@pplsense