Майндсет — это набор правил, убеждений, подходов, которыми человек руководствуется при принятии решений. Продуктовый майндсет очень важен для предпринимателей, стартаперов, ведь позволяет не просто запустить продукт, а развивать его и делать успешным. Co-founder Improve Your Product Наталья Никитюк ( тренер курса “IT Product Management” ) специально для Web Academy рассказывает, что такое продуктовый майндсет и как его развивать в себе и команде.

Из личного опыта

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

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

Мы получили инвестиции под идею и дедлайн — год на то, чтобы показать результат. Все, что я могла сделать неправильно, я тогда сделала. Мы разработали гигантские ТЗ по 50 страниц на каждую фичу, но никто в команде полностью не понимал, как работает система. Мы наняли много людей — в разные периоды у меня в подчинении было 100-150 сотрудников. Я следила за мотивацией людей, думала, какие зарплаты ставить, как обучать, но совершенно не думала, кому нужен продукт, и как он будет работать. Я ни разу не общалась с пользователями, исследования проводила не я. В итоге спустя год, мы потратили все инвестиции, продукта не было, инвестор отказался с нами дальше работать, мы вышли выгоревшие.

Что такое продуктовый майндсет

Майндсет — это способ мышления, то, что помогает определить, как вы смотрите на мир. Представьте раненое животное, например, свинку. Если рядом будет ветеринар, он будет думать, как ее вылечить. Но мясник будет мыслить иначе. То, как мы думаем, определяет наши будущие действия. Майндсет основывается на ряде принципов, убеждений, подходов. Это то, что мы можем поменять.

Термин «продуктовый майндсет» используют в трех разных контекстах. Чаще всего его используют в связке с проджектовым майндсетом. Например, есть человек, который работает в аутсорс компании, занимается разного рода проектами. У него есть сроки, бюджет, рамки. В таком случае можно сравнить подходы, которые использует человек в рамках работы над проектом, с подходами, которые использует человек в рамках работы над продуктом.

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

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

Принципы, которыми руководствуется человек с продуктовым майндсетом

• Всегда задает вопрос «зачем?»: зачем мы что-то строим, зачем пользователь использует это решение, а не другое.
• Фокусируется на пользователях: учитывает мнение рынка и пытается разобрать, какие есть проблемы, потребности у пользователей, подстраивает свои решения под пользователей, а не наоборот.
• Учитывает задачи бизнеса: не просто смотрит на то, что хотят пользователи, а связывает контексты бизнеса и пользователя вместе.
• Outputs важнее inputs.  В проджектовом мышлении важнее всего оказываются наши вводные: сроки, инструменты, которые используем, план действий. В случае продуктового мышления все идет от обратного — мы ориентируемся, в первую очередь, на цель.  От этого отталкиваемся и говорим, какие инструменты будем использовать, в какие сроки уложимся, какой бюджет нужен.
• Интуиция превращается в гипотезы: человек с продуктовым майндсетом стремится любое предположение проверить, а не просто говорить, что то или иное решение нужно реализовать, потому что у него есть такое предчувствие.
• Постоянные улучшения: мы не ориентируемся на что-то заранее спрогнозированное, а постоянно улучшаемся. Нет сроков проекта — есть продукт, который мы постоянно развиваем.
• Гибкость важнее плана. Мы должны, прежде всего, понимать, что важно сейчас, а не пытаться подстроиться под то, что придумали когда-то.

Зачем продакт-менеджеру нужен продуктовый майндсет

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

Зачем продуктовый майндсет команде

1. Коммуникация становится проще. Например, вы просите дизайнера, у которого нет продуктового майндсета, сделать за пару дней простой дизайн, чтобы проверить гипотезу. И он не понимает, как можно за пару дней сделать дизайн, о каких гипотезах речь, если у него в ТЗ ничего подобного не написано, и т.д. Если продуктовый майндсет есть у всей команды, такие вопросы возникать не будут.
2. Больше качественных продуктовых гипотез. У каждого члена команды уникальная экспертиза. Разработчик видит по одному, дизайнер иначе. Они не могут придумывать одинаковые гипотезы — и чем больше разных точке зрения, тем лучше.
3. Команда сильнее вовлекается в создание ценности.
4. Улучшается пользовательский опыт на всех уровнях взаимодействия.
5. Исчезает конфликт между бизнесом и разработкой.
6. Если продуктового майндсета нет, команда фокусируется, в первую очередь, на функционале. А продакт-менеджер становится узким горлышком — он единственный, кто придумывает гипотезы, решения, и это не масштабируется. Команда следует плану, несмотря ни на что, а разные команды не понимают, чем занимаются другие.

В итоге непонятно, зачем что-то делается, страдает качество решений — мы дольше доставляем ценность для пользователя. Но самое ужасное — продукт перестает (или так и не становится) нужным на рынке.

Как развивать проудктовый майндсет у себя

1. Разобраться с базовыми продуктовыми подходами/моделями/принципами, которые продакт-менеджер использует в работе:

• пять зачем или почему — постоянно задавайте вопрос «зачем» себе;
• измеряем все — попробуйте любую идею, которая возникает, оцифровывать, подумайте, на какую метрику она может повлиять;
• эмпатия — позволит лучше понимать пользователя и команду;
• гипотезы вместо идей — попробуйте, когда возникнет идея, не формулировать ее как «о, классная идея, хочу это сделать», а «если мы сделаем это, то, возможно, будет такой результат»;
• ценность в приоритете — в первую очередь, важно ориентироваться на то, какую ценность несет продукт, работа. Думайте не о том, каким инструментом пользоваться, а о том, что вы делаете и кому продукт приносит ценность;
• любопытство — разберитесь, как устроена книга, пульт от телевизора. Посмотрите на мир глазами ребенка и поймите, что привело к тому, что продукт стал таким;
• обучение важнее провалов — не стоит зацикливаться на фейлах;
• время поставки ценности — поставка ценности и поставка продукта на рынок — это разные вещи. Это не о том, как быстро мы выпустим продукт, а о том, как быстро пользователь получит ценность.
• фидбек от команды, личной работы;
• скорость VS качество — если мы проверили гипотезы и уверены, что это сработает, тогда можно что-то делать медленнее, но более качественно. Если нет, то, в первую очередь, нужно быстро проверить гипотезу;
• визуализировать, чтобы показать связи — не пишите огромных ТЗ с самого начала, постарайтесь показать, как что-то устроено;
• 5W1H — прежде, чем что-то делать, задайте себе вопросы: why, what, who, when, where, how.

2. Применять продуктовые подходы ко всему в жизни. Говорят, что продуктовый майндсет — это не про профессиональное качество, а про лайфстайл.

3. Тренировать «напользованность». Если хотите развиваться в сфере мобильных приложений, каждую неделю ставьте себе новое и попробуйте понять, как оно работает, почему так делали, какую метрику хотели вырастить.

3. Запускать свои продукты или поучаствовать в стартапе. Это поможет прочувствовать все на своем опыте.

4. Поработать с ментором.

5. Брать на себя ответственность, которая не входит в основную деятельность.

Как развивать продуктовый майндсет в команде

Вариант № 1 — собрать команду и рассказать, как это работает.

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

Вариант № 2 — начать постепенно со своей команды или с энтузиастов.

Минус — это очень долго. Плюс — такой метод более органичен и имеет долговременный эффект.

И несколько правил:

1. Начинать с простого и растить веру команды в себя, в подход.

2. Всегда задавать вопрос команде «Зачем?» (или «Чтобы что?») и отвечать, когда «Зачем?» спрашивают вас. Когда вы объясняете, зачем нужно то или иное действие, вы помогаете понять, что важно, и какие идеи можно предлагать.

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

4. Звать на демо или планирование своей команды коллег из других команд.

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

6. Создавать возможности, в которых команда может быть ближе к пользователю: приглашать на интервью, давать выжимки из интервью, проводить воркшопы про пользовательские исследования и т.д. Не заставлять, а создать возможности — тот, кто будет готов, воспользуется ими.

7. Использовать метрики. Объяснять свои решения через призму метрик. Научить команду пользоваться аналитикой. То есть, кроме «Зачем?», спрашивать, на какую метрику повлияет решение. Можно повесить дашборд, где будут выведены ключевые метрики продукта — так каждый знает, что происходит, и не нужно обращаться к кому-то, делать рисерч.

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

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

10. Подключать команду к работе еще на этапе исследования идеи.

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

Как не стоит делать

• Директивно указывать команде, что делать, не давая свободы.
• Не объяснять, почему были приняты какие-то решения.
• «Наказывать» за факапы и ругать за провалившиеся инициативы.
• Требовать изменений майндсета, не объясняя, что это значит.
• Просить команду делать то, во что сами не верите.
• Помните, что для изменений нужно время. Какие бы действия вы не предприняли, не ждите мгновенного результата. Это процесс, который никогда не заканчивается.

Барьеры при смене майндсета на продуктовый

• Самолюбие «важных начальников». Когда меняется подход с «Я сказал» на «У нас есть гипотеза, давайте проверим», те, чьему авторитету доверяли, и делали так, как они сказали, будут сопротивляться, потому что это задевает их самолюбие. Не противопоставляйте авторитет подходу с гипотезами, а пытайтесь вовлечь таких людей в процесс также, как остальных.
• Сопротивление любым переменам.
• Люди делают то, что проще, не то, что нужно.
• Польза видна не сразу.
• Неизвестность и невозможность все контролировать пугает команду.
• Fixed mindset, что означает «Я таким родился и никогда не поменяюсь». Таким людям сложно. Пытайтесь обучать их не продуктовому майндсету, а давать возможности для развития в основной сфере. Это поменяет фиксированный майндсет на growth, а потом уже можно работать над продуктовым.