О пользе продуктового мышления сейчас можно услышать из каждого утюга. Действительно, оно необходимо не только менеджерам продуктов, но и всей команде. Тогда мы действительно будем делать качественный продукт, который обладает максимальной ценностью для нашего клиента.
Однако мало где можно прочесть, что это и в чем проявляется.
Ниже хочу изложить свое видение этого процесса.
На одном из митапов у меня спросили: «Как можно протестировать есть у меня продуктовое мышление или нет?» И я подумал, что статью можно рассматривать как диагностический инструмент. Читая каждый пункт, постарайся честно ответить на вопрос: «Есть это у меня или еще есть над чем поработать?»
Ключевая задача продукта — это нести ценность пользователю. И кажется, что добавление отдельной классной фичи увеличит эту самую ценность. Однако целое — это всегда больше, чем сумма составляющих его компонентов.
Когда мы что-то добавляем важно помнить, что это повлияет на весь продукт.
Вот неполный список вопросов, который стоит себе задать прежде, чем делать ту или иную фичу.
Безусловно есть исключения, когда вы делаете продукт для разработки продуктов, но в большинстве случаев это не так.
В психологии есть такой механизм как проекция. Это когда мы переносим свои чувства, мысли, желания на другого человека. Поэтому, как эмпатию не включай, у вас все равно будут разные ценности, взгляды на жизнь, боли и задачи.
В результате, если руководствоваться принципом «Я думаю, что для них будет лучше это», мы будем делать продукт для себя. И это особенно забавно, когда команда бородатых мужиков пилит продукт для мам-одиночек :)
Чтобы сблизить картины мира нашу и пользователя, его нужно постоянно исследовать.
Концептуально есть 2 вида исследований:
Делать это можно по-разному, статей в интернете хватает.
Чтобы не заблуждаться в том, что же нужно нашему пользователю, необходимо все свои предположения формулировать как гипотезу. А гипотеза подразумевает под собой долю сомнения и то, что это нужно проверить.
Поэтому излюбленную «Давайте сделаем …» лучше заменить на «Я предполагаю, что если мы сделаем …, то это повлияет на ...». Тут вам и здравая доля сомнения, и формулировка того, что вы собираетесь делать, и то, как планируете это проверять.
Тут нам в помощь пресловутый HADI-цикл.
Придумали гипотезу -> Запустили эксперимент -> Собрали данные -> Сделали выводы
За каждой гипотезой стоит потенциал роста. Поэтому, чем больше гипотез мы проверим, тем лучше. Пусть первые эксперименты будут синтетические, неправильные, «высосанные из пальца», тут главное начать, если еще не начали.
Очень полезный вопрос по результатам эксперимента, который способствует развитию продуктового мышления: «Что нам стало ясно, что до этого было неочевидно?».
Ключевые характеристики эксперимента, которые важно учитывать:
Нам кажется, что в нашем сервисе все так понятно и очевидно. А пользователи почему-то не понимают, что нужно нажать на эту кнопку и ходят кругами, а потом вообще уходят.
Можно, конечно, назвать их тупыми, только нас это никуда не приведет. При разработке приложения, рассчитывай, что им будут пользоваться и младенцы, и бабушки в 90 лет.
Нам очень неприятно, когда кто-то критикует нашу работу, на которую мы потратили столько сил. Так устроена наша психика. Автоматически включается механизм психологической защиты – обесценивание.
Когда смотришь на обстоятельный отзыв с одной звездой, первое что приходит на ум – «сам дурак». Но опять же, такой путь никуда не ведет. Представь, пользователь сел и потратил часть своей жизни на то, чтобы сообщить вам о своих болях. Тут лучше выдохнуть, сказать ему «спасибо», а затем трезво перечитать отзыв и отделить в нем зерна от плевел.
Опять же, наша психика не любит перемены. И поэтому мы очень профессионально можем найти 10 причин почему новая идея — бред. Причем, чем более интеллектуально развит человек, тем на более высоком уровне работают защиты.
Есть простая фраза – «А давай попробуем!», которая позволяет двигаться вперед. Причем, она хорошо подходит как для предложения что-то сделать, так и для ответа на предложение.
Пункт очень избитый, нам его твердили с детства. Но я настолько часто слышу «зря делали» по поводу какого-то фейла, что решил его добавить в список.
Неэффективные фичи засоряют интерфейс, удлиняют регресс, нагружают техподдержку и т.д.
Звучит вполне логично, но для меня это один из самых сложных пунктов. Так больно отказываться от того, что делали долго, вложили много сил и энергии. И кажется, что вот-вот и все взлетит, а оно все никак…
Список можно продолжать.
Напишите в комментариях, что еще развивает продуктовый майндсет, с вашей точки зрения.
Однако мало где можно прочесть, что это и в чем проявляется.
Ниже хочу изложить свое видение этого процесса.
На одном из митапов у меня спросили: «Как можно протестировать есть у меня продуктовое мышление или нет?» И я подумал, что статью можно рассматривать как диагностический инструмент. Читая каждый пункт, постарайся честно ответить на вопрос: «Есть это у меня или еще есть над чем поработать?»
1. Мысли продуктами, а не фичами
Ключевая задача продукта — это нести ценность пользователю. И кажется, что добавление отдельной классной фичи увеличит эту самую ценность. Однако целое — это всегда больше, чем сумма составляющих его компонентов.
Когда мы что-то добавляем важно помнить, что это повлияет на весь продукт.
Вот неполный список вопросов, который стоит себе задать прежде, чем делать ту или иную фичу.
- Для чего она нужна?
- Как повлияет на продукт?
- Кто/как ей будет пользоваться?
- А что будет если мы это не сделаем?
- Сколько будет стоить поддержка?
2. Вы не ваша целевая аудитория
Безусловно есть исключения, когда вы делаете продукт для разработки продуктов, но в большинстве случаев это не так.
В психологии есть такой механизм как проекция. Это когда мы переносим свои чувства, мысли, желания на другого человека. Поэтому, как эмпатию не включай, у вас все равно будут разные ценности, взгляды на жизнь, боли и задачи.
В результате, если руководствоваться принципом «Я думаю, что для них будет лучше это», мы будем делать продукт для себя. И это особенно забавно, когда команда бородатых мужиков пилит продукт для мам-одиночек :)
3. Исследуй
Чтобы сблизить картины мира нашу и пользователя, его нужно постоянно исследовать.
Концептуально есть 2 вида исследований:
- с привлечением пользователей (анкетирование, интервью и т.д.)
- без привлечения пользователей (сбор аналитики)
Делать это можно по-разному, статей в интернете хватает.
4. Всё гипотеза
Чтобы не заблуждаться в том, что же нужно нашему пользователю, необходимо все свои предположения формулировать как гипотезу. А гипотеза подразумевает под собой долю сомнения и то, что это нужно проверить.
Поэтому излюбленную «Давайте сделаем …» лучше заменить на «Я предполагаю, что если мы сделаем …, то это повлияет на ...». Тут вам и здравая доля сомнения, и формулировка того, что вы собираетесь делать, и то, как планируете это проверять.
5. Экспериментируй
Тут нам в помощь пресловутый HADI-цикл.
Придумали гипотезу -> Запустили эксперимент -> Собрали данные -> Сделали выводы
За каждой гипотезой стоит потенциал роста. Поэтому, чем больше гипотез мы проверим, тем лучше. Пусть первые эксперименты будут синтетические, неправильные, «высосанные из пальца», тут главное начать, если еще не начали.
Очень полезный вопрос по результатам эксперимента, который способствует развитию продуктового мышления: «Что нам стало ясно, что до этого было неочевидно?».
Ключевые характеристики эксперимента, которые важно учитывать:
- быстро;
- дешево;
- достоверно.
6. Пользователь не тупой, он такой, какой есть
Нам кажется, что в нашем сервисе все так понятно и очевидно. А пользователи почему-то не понимают, что нужно нажать на эту кнопку и ходят кругами, а потом вообще уходят.
Можно, конечно, назвать их тупыми, только нас это никуда не приведет. При разработке приложения, рассчитывай, что им будут пользоваться и младенцы, и бабушки в 90 лет.
7. Лояльно воспринимай фидбек пользователей
Нам очень неприятно, когда кто-то критикует нашу работу, на которую мы потратили столько сил. Так устроена наша психика. Автоматически включается механизм психологической защиты – обесценивание.
Когда смотришь на обстоятельный отзыв с одной звездой, первое что приходит на ум – «сам дурак». Но опять же, такой путь никуда не ведет. Представь, пользователь сел и потратил часть своей жизни на то, чтобы сообщить вам о своих болях. Тут лучше выдохнуть, сказать ему «спасибо», а затем трезво перечитать отзыв и отделить в нем зерна от плевел.
8. Будь открыт новому
Опять же, наша психика не любит перемены. И поэтому мы очень профессионально можем найти 10 причин почему новая идея — бред. Причем, чем более интеллектуально развит человек, тем на более высоком уровне работают защиты.
Есть простая фраза – «А давай попробуем!», которая позволяет двигаться вперед. Причем, она хорошо подходит как для предложения что-то сделать, так и для ответа на предложение.
9. Отрицательный результат – тоже результат
Пункт очень избитый, нам его твердили с детства. Но я настолько часто слышу «зря делали» по поводу какого-то фейла, что решил его добавить в список.
10. Отказывайся от неэффективных фич
Неэффективные фичи засоряют интерфейс, удлиняют регресс, нагружают техподдержку и т.д.
Звучит вполне логично, но для меня это один из самых сложных пунктов. Так больно отказываться от того, что делали долго, вложили много сил и энергии. И кажется, что вот-вот и все взлетит, а оно все никак…
Список можно продолжать.
Напишите в комментариях, что еще развивает продуктовый майндсет, с вашей точки зрения.
Комментарии (7)
MikhailZakharov
23.10.2019 17:41Проверка гипотез, фидбеки и портреты конечного пользователя хорошо работают только на b2c и рынка SMB. Если ваш заказчик крупнее, то методики будут другими.
Мой подход это ответ на три вопроса: кому, что и как.
Кому продаем. Здесь будет описание рынка.
Что именно. Ответ на этот вопрос позволит отойти от фич к продуктам
Как продаем. Ответ на этот вопрос даст понимание как нужно планировать продукт, и как формировать его цену.
Для людей, которые не занимаются продукт менеджментом, продуктовый подход развивает следующее упражнение (я так детям его даю)
— Надо выбрать любой предмет, который нравится. Можно нематериальный (музыка, фильм), но он обязательно должен быть создан человеком.
— Почему он нравится?
— Кто те люди, котом он тоже понравится? Возраст, пол, род занятий и т.п.
— Далее надо выбрать предмет (также музыка, фильм, любой созданный человеком) который совсем не нравится.
— Есть ли люди, которые, наоборот, будут платить за него деньги? Кто они, возраст, пол, род занятий и т.п.?
SadOcean
25.10.2019 00:44Можно, конечно, назвать их тупыми, только нас это никуда не приведет. При разработке приложения, рассчитывай, что им будут пользоваться и младенцы, и бабушки в 90 лет.
Сами себе противоречите.
Очевидно, что нужно прежде всего рассчитывать, что приложением будет пользоваться целевая аудитория в самом широком смысле. Для них и нужно делать, а не для младенцев и бабушек. Если конечно они в нее не входят.
Hvm Автор
25.10.2019 22:08Этот пункт не про целевую аудиторию. Безусловно, младенцы и бабушки будут статистическим выбросом в большинстве ЦА. Это про запас прочности. Если ориентироваться при разработке на них, то для остальных точно будет все очевидно.
DrunkBear
Отловить случайных людей с коридора, а ещё лучше — представителей заказчика и посадить на пол часа к вашей прорывной системе, чтоб они без объяснений сделали типичные действия пользователя.
Потом — записывать «что не так», молча обтекать и думать, какие правки вносить:
то, что за пол года работы над UI стало для вас очевидным, скорее всего, для сторонних вообще не очевидно, а вот эта вот функция, которой вы гордитесь — будет мешать половине пользователей.
Например, если вы захотите сделать «умного» клиента, который сам просканирует доступные сети и найдёт свой правильный сервер для конторы с чуткими безопасниками — лучше не надо.
kuzuzu
я бы не торопилась сразу обтекать)), меня в этой ситуации всегда смущает, что опросить много людей сложно и дорого, получается мы поговорим с несколькими представителями ЦА, потестируем на них, возможно, что-то допилим, потом посмотрим, как новые функции зашли пользователям (их будет больше, статистика достовернее)
и вот если зашло, а раньше об этом никто и не думал, тогда можно начинать обтекать))
Hvm Автор
Вы оба верные вещи говорите.
Качественные анализ в виде глубинных интервью 10-и человек может позволить выявить 70% ключевых недочетов в сервисе. Из этих интервью вы формулируете гипотезы и проверяете их уже на большей аудитории при помощи количественных методов, например, через A/B тестирование.
DrunkBear
Обтекать — это по собственному опыту, ситуация аналогична любому тестированию ( да хотя бы на аварийного переключения сервисов между кластерами), которое раньше не делали: в целом оказывается «всё хорошо, НО...» столько мелочей, что хорошо оказывается погребено под ними (как и самомнение разработчиков)