Когда мы обсуждаем тему поиска сотрудников со своими коллегами в других стартапах, часто всплывает вопрос о “продуктовом мышлении” кандидата, в противовес “аутсорсинговому”. Его отсутствие является часто блокером для найма, т.к. с hard skills у кандидата все хорошо.

Что значит продуктовое мышление (product mindset)? Действительно ли это важно при найме инженеров в стартап? Можно ли ему научить? Об этом сегодня и поговорим.

Начнем с определения: что такое product mindset?

Мне кажется тут все просто.

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

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

Окей, с этим разобрались. Почему же это важно и важно ли вообще?

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

Так а в чем проблема, спросите вы. Разработчику платят деньги, чтобы он писал код, разве нет? Если вам так хочется погрузиться в проблему пользователя, это может сделать бизнес-аналитик или ПМ или еще кто-нибудь, им же за это деньги платят.

Типичный ответ из аутсорсинга, скажу я. :)

Проблема в том, что 1) разработка продукта это супер-сложная, креативная задача и 2) роль разработчика в ней ключевая. И если в этом ключевом месте “отключить голову” и делать только то, что написано в ТЗ или о чем подумал ПМ, то результат пострадает.

И результат будет не на 30% хуже. Результат будет в 10 или в 100 раз хуже. Для стартапа это часто разница между успешным продуктом и банкротством.

Любой продукт это тысячи “микро-решений” и компромиссов (trade-offs), которые разработчики принимают каждый день, даже не задумываясь об их важности и ни с кем их не обсуждая.

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

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

Если разработчик не думает о продукте и пользователях, у команды мало шансов на креативные (читай – “дешевые”) решения проблемы пользователей, т.к. их обычно невозможно увидеть на расстоянии, не имея полного контекста задачи.

ОК ОК, продуктовое мышление это супер важно. Можно ли ему научиться?

Конечно!

Более того, я уверен, что у любого разработчика продуктовое мышление есть априори, потому что именно так мы думаем, если работаем над своим pet project или хобби.

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

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

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

Один раз почувствовав этот кайф, вам сложно будет “спрыгнуть” с иглы продукта, я обещаю это.

Еще почитать:

1. Как Netflix ведет разработку продукта

2. The Product-Minded Software Engineer

3. EMPOWERED: Ordinary People, Extraordinary Products

4. Daniel Pink: Why We Do What We Do (youtube)