Product mindset vs аутсорсинг
Почему продуктовое мышление важно для стартапа
Когда мы обсуждаем тему поиска сотрудников со своими коллегами в других стартапах, часто всплывает вопрос о “продуктовом мышлении” кандидата, в противовес “аутсорсинговому”. Его отсутствие является часто блокером для найма, т.к. с hard skills у кандидата все хорошо.
Что значит продуктовое мышление (product mindset)? Действительно ли это важно при найме инженеров в стартап? Можно ли ему научить? Об этом сегодня и поговорим.
Начнем с определения: что такое product mindset?
Мне кажется тут все просто.
Когда мы говорим о продуктовом мышлении, мы подразумеваем, что разработчику интересна не только проблема сама по себе, но и контекст вокруг нее. Зачем мы делаем то, что мы делаем? Какую проблему пользователя мы пытаемся решить?
В противовес “аутсорсинг-модели”, где тебя интересует только то, принял ли заказчик работу и может быть во сколько часов она ему обошлась. Для чего мы делаем то, что мы делаем и насколько хорошее наше решение часто невозможно понять в принципе, поэтому проще и не пытаться.
Окей, с этим разобрались. Почему же это важно и важно ли вообще?
Самая большая жалоба, которую я слышу от других продуктовых компаний, это разработчик, который не интересуется продуктом и пользователями, а хочет “просто закрывать таски из JIRA”.
Так а в чем проблема, спросите вы. Разработчику платят деньги, чтобы он писал код, разве нет? Если вам так хочется погрузиться в проблему пользователя, это может сделать бизнес-аналитик или ПМ или еще кто-нибудь, им же за это деньги платят.
Типичный ответ из аутсорсинга, скажу я. :)
Проблема в том, что 1) разработка продукта это супер-сложная, креативная задача и 2) роль разработчика в ней ключевая. И если в этом ключевом месте “отключить голову” и делать только то, что написано в ТЗ или о чем подумал ПМ, то результат пострадает.
И результат будет не на 30% хуже. Результат будет в 10 или в 100 раз хуже. Для стартапа это часто разница между успешным продуктом и банкротством.
Любой продукт это тысячи “микро-решений” и компромиссов (trade-offs), которые разработчики принимают каждый день, даже не задумываясь об их важности и ни с кем их не обсуждая.
Если разработчик не думает о продукте и пользователях, команда может потратить полгода на разработку бесполезной фичи, которую можно было забраковать за неделю.
Если разработчик не думает о продукте и пользователях, узким горлышком для развития проекта становится ПМ, на которого ложится задача поиска гипотез для роста. Это плохо и это не масштабируется.
Если разработчик не думает о продукте и пользователях, у команды мало шансов на креативные (читай – “дешевые”) решения проблемы пользователей, т.к. их обычно невозможно увидеть на расстоянии, не имея полного контекста задачи.
ОК ОК, продуктовое мышление это супер важно. Можно ли ему научиться?
Конечно!
Более того, я уверен, что у любого разработчика продуктовое мышление есть априори, потому что именно так мы думаем, если работаем над своим pet project или хобби.
Другое дело, что годы работы в аутсорсинге легко могли его атрофировать, особенно если не было мотивации и/или возможности применять его в контексте проекта. И за попытки его применить еще и активно “били по голове”. Тут кто угодно в какой-то момент махнет рукой и скажет “пока нет таски в джире я ничего не делаю”.
Мне кажется продуктовое мышление это по сути эмпатия к пользователю. Чем лучше мы узнаем своего пользователя, тем сложнее воспринимать абстрактно его проблемы. Мы социальные существа, нам не все равно, что думают о нас другие.
Так и выстраивается положительная обратная связь: чем лучше мы понимаем пользователя и его проблемы, тем лучше можем их решить и тем больше ценим положительный фидбек от пользователя, когда показываем ему наше решение.
Один раз почувствовав этот кайф, вам сложно будет “спрыгнуть” с иглы продукта, я обещаю это.
Еще почитать: