Друзья, воспользуюсь служебным положением и спрошу вашего совета :) как вы читаете книжки?

В электронном варианте (на ридерах типа PocketBook) – 202
👍👍👍👍👍👍👍 26%

В бумажном варианте – 185
👍👍👍👍👍👍 24%

В электронном варианте (в специальных приложениях типа BookMate) – 183
👍👍👍👍👍👍 24%

В электронном варианте (на планшете типа iPad) – 165
👍👍👍👍👍👍 22%

В электронном варианте (на компьютере) – 31
👍 4%

👥 766 people voted so far. Poll closed.

Пообсуждать можно в нашем чате https://t.me/joinchat/AAAAAEHjvA0Dw0g6W4Irog или поделиться опытом в личку @Anna_Boo

Вдогонку к книжной теме - поделюсь любимыми каналами про классные книжки:

https://t.me/helloskaplichniy -
канал Сергея Капличного, копирайтера МИФа. Сергей пишет исключительно по делу и по сути, но при этом интересно и увлекательно. А еще первее всех рассказывает про скидки в МИФе ;)

https://t.me/biggakniga -
чудесные рецензии от Насти Завозовой, с которой мы в свое время были коллегами. Настя сама пишет и переводит (например, сделала перевод "Щегла", который по части стиля и языка, возможно, даже превосходит оригинал) - и очень много читает.

https://t.me/prochitalanapisala -
уютный авторский канал с отличными отзывами, после которых я хочу скупить пол-амазона ;)

Возрадуйтесь, друзья: последний пост про job stories и JTBD. Начало тут (https://t.me/proproduct/269%0A), на этой неделе планирую свести все в один большой материал на Medium.

И наша сегодняшняя тема - когда же “работа” продукта должна заканчиваться.

---

Продукты решают не изолированные проблемы, а проблемы, которые происходят в каком-то workflow: есть то, что случилось “до”, и то, что произойдет “после”. То есть, таким образом, у “работающего” продукта есть начальная и конечная точки. Вопрос в том, как их правильно определить.

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

Так где же золотая середина?

Давайте разберем на простеньком примере. Допустим, вы пишете приложение-будильник; в этом случае workflow может выглядеть так:

1. Пользователь вечером штырит инстаграмчик
2. Понимает, что уже очень поздно и пора спать
3. Ставит будильник на 7
4. Спит
5. Просыпается, идет на кухню выпить воды
6. Спит
7. Будильник звенит в 7, пользователь переставляет его на 7–30
8. Будильник звенит в 7–30, пользователь встает
9. Включает радио
10. Делает зарядку.

“Работа” вашего продукта должна начинаться с того шага, где вы можете добавить какую-то ценность для пользователя. Для нашего примера это, скорее всего, шаг 3. Мы, конечно, можем влезть и раньше: например, если пользователь обычно встает в 7 утра, а уже 12 вечера, и телефон активен, наше приложение отправит ремайндер: котик, а не хотите ли поставить будильник и пойти спать? Можем пойти еще дальше: сделать фитнес-браслет, который будет трекать пульс и активность пользователя и рекомендовать ему лучшее время, чтобы пойти спать (и будить его, соответственно, тоже в лучшее время для подъема). Нужно ли это? Испытывает ли пользователь “боль”, соответствующую масштабам исследований и разработки? Это и нужно понять и решить продуктовой команде в самом начале. 

А когда же “работа” должна заканчиваться?
Когда:
- у следующего шага в workflow есть однозначные маркет-лидеры, и вы не хотите с ними конкурировать
- следующий шаг в workflow может быть решен миллионом разных способов и миллионом разных типов пользователей
- на следующем шагу у нас радикально меняется аудитория
- следующий шаг не добавит никакой ценности продукту.

Всем большой привет из Нью-Йорка! Следующие две недели я с ограниченной связью, не теряйте :) а пока - обещанный сводный материал про JTBD и job stories https://medium.com/@buldakova/что-такое-jobs-to-be-done-и-job-stories-4c57c1dc84cf

Ещё не все знают, поэтому позволю себе напомнить: помимо этого канала, есть ещё канал с лучшими продуктовыми вакансиями в России и за рубежом @hireproproduct - присоединяйтесь!

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

Я обожаю искать аналогии с несмежными областями, и как раз по этой теме лучшим ресурсом оказалась методичка от National Patient Safety Agency по оценке рисков для здоровья пациента. Вы можете почитать оригинал по ссылке на английском языке здесь:

http://www.nrls.npsa.nhs.uk/EasySiteWeb/getresource.axd?AssetID=60138&type=full&servicetype=Attachment

Поделюсь с вами краткой выжимкой.

Для оценки рисков надо ответить на несколько простых вопросов:

1. Что может пойти не так?

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

2. На кого/ на что это может повлиять? (кто/что попадет под удар?)

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

3. Насколько ужасны могут быть последствия?
4. Какова вероятность, что это случится?
5. Нужно ли что-то предпринять?
6. Кто будет ответственен за предотвращение/ решение ситуации, если она произойдет?

Посмотрите на следующую картинку - это пример матрицы, которую можно составить по параметрам Последствия/Вероятность того, что это случится.

Мы не в силах предусмотреть все, и даже при грамотной оценке рисков все равно что-то может пойти не так. Поэтому не пытайтесь "закрыть" каждую мелочь, лучше сосредоточьтесь на том, что действительно может нанести вред.

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

Когда работаешь с одним продуктом на протяжении долгого времени, многие риски можешь оценивать сходу и довольно точно. Поэтому я составляю чеклисты для разных стадий разработки: о чем надо подумать и о чем не забыть. Подробнее про суперсилу чеклистов можно почитать в Checklist Manifesto, но если вкратце - обязательно делайте и составляйте. Экономит кучу времени, спасает от роковых ошибок ;)

Всем привет! Вернулась из Нью-Йорка, с кучей тем для заметок и вдохновения :) пока борюсь с джетлегом и пытаюсь разгрести завалы писем, ловите еще один выпуск рубрики #лучшиекнижки.

И сегодня своими фаворитами делится Иван Горшунов, экс-эксперт по мобильным продуктам Google, один из основателей Rutech:

1. Marty Cagan. Inspired: How to Create Products Customers Love

https://www.amazon.com/Inspired-Create-Products-Customers-Love/dp/0981690408

2. Rob Fitzpatrick. The Mom Test

http://momtestbook.com/

3. Gayle Laakmann McDowell. Cracking the PM Interview

https://www.amazon.com/Cracking-PM-Interview-Product-Technology/dp/0984782818

4. Eric Ries. The Lean Startup

http://theleanstartup.com/

PS К слову, Иван и Rutech сейчас организуют конкурс для стартапов: 5 лучших бесплатно поедут на UK-Russia Techbridge Bootcamp - 9-дневную программу для российских технологических компаний в Лондоне. По ссылке подробности: http://rutechclub.com/bootcamp

Слушала сегодня интересный подкаст с дизайн-стратегом Google и хочу развить пару мыслей из его интервью.

Мысль №1 (про которую мы уже вскользь говорили): если вы хотите получить оффер от зарубежной компании мечты, обратите внимание на два момента.

Хорошо ли у вас развиты soft skills? В частности, умение общаться, аргументированно и корректно доносить свою точку зрения, сопереживать коллегам, быть толерантным и вежливым в любой ситуации, проявлять лидерские качества. Тенденции таковы, что работодатели предпочитают взять, скорее, хорошего середнячка с развитыми soft skills, чем гения с soft skills в зачаточном состоянии. Уже не раз слышала про подобные ситуации, например, в Facebook и Google, и не только про продактов - то же касается разработчиков и дизайнеров. Многие компании даже начинают ставить сессии на проверку soft skills первым этапом в процессе, чтобы сразу отсеять неподходящих кандидатов.

Провалиться здесь можно очень легко. Например, на вопрос “Почему вы хотите у нас работать?” ответить что-то не про достоинства компании, а про “свалить из страны”. Отпустить шуточку по поводу женщин или геев. Заявить, что тестовые задания очень простые и рассчитаны на идиотов. Начать спорить с рекрутером и доказывать, что он не прав (даже если он действительно не прав).

Единственное, что здесь можно посоветовать, - тренируйтесь. Обязательно продумайте ответы на самые часто задаваемые вопросы (почему хотите уйти из текущей компании; что привлекает в данной позиции; вопросы к собеседующему). Вспомните 5 рабочих ситуаций, которые подадут вас в выгодном свете (чаще всего, вопросы на эту тему попадут в одну из категорий - достижение; ошибка; конфликт; сильные стороны; слабые стороны). И ни-ког-да не ввязывайтесь в спор с рекрутером, никогда! Дискуссия - дело другое ;)

Второй момент - виден ли процесс размышления за вашей работой или вашими ответами? В частности, в интервью говорилось про портфолио на Dribble, которые присылают в Google на вакансии дизайнеров.
(Вот, кстати, интересная заметка на эту же тему
[The dribbblisation of design https://blog.intercom.com/the-dribbblisation-of-design/)
Красиво расположенные прямоугольники и кружочки уже никого не интересуют - рекрутерам важно, что происходило у вас в голове, когда вы их рисовали, почему вы принимали то или иное решение. Поэтому - готовите ли вы портфолио или решаете задачу на интервью - не торопитесь выдать финальный результат. Когда я училась в Британке, основным критерием оценки работы было качество проведенного исследования. Без исследования никакой оценки не могло быть в принципе. Само решение, безусловно, тоже очень важно: можно размышлять здраво и правильно, а потом вдруг сделать совершенно неадекватные выводы. Но чаще всего почему-то забывают именно про доказательную часть. То же самое, если бы Толстой сжег 4 тома “Войны и мира” и подытожил на одном листочке: Андрей Болконский умер, Пьер женился на Наташе.

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

Мысль №2: все мокапы для индустриального дизайна, для hardware рисуются в контексте - то есть, например, на скетче нового телевизора рисуется не только телевизор, но и комната вокруг, и семья, которая его смотрит. В мокапах же для софта про контекст часто забывают и рисуют тупо экраны, без всякого понимания user journey, где и когда это происходит.

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

Внешние ограничения

Контекст времени – сколько времени есть у пользователя в момент, когда он открыл наш сайт/приложение. К сожалению, очень часто при прототипировании создается ощущение, будто время пользователя бесконечно и линейно. В реальности же время в приложении идет такой пунктирной линией, где пробелы - это interruptions (других приложений или других дел пользователя), а линии - ограниченные с обеих сторон отрезки (начало и конец взаимодействия). То есть, если в прототипе конец взаимодействия – это, чаще всего, последний шаг в воркфлоу (например, зашел на сайт - задал параметры поиска - выбрал товар - положил в корзину - оплатил - купил - получил подтверждение), то в реальности конец взаимодействия может случиться на любом из этих шагов.

Контекст пространства – где пользователь работает с нашим продуктом. Есть ли вокруг другие люди? Шумно ли? Есть ли хороший доступ в интернет? И так далее.

Внутренние ограничения

Я очень советую всем продактам почитать Дахигга и Эяла, чтобы понимать и внутренние (психологические) ограничения пользователя. Самое важное, на мой взгляд:

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

- количество воспринятой информации. Есть некоторая точка пресыщения, когда пользователь не может справиться с объемом полученной информации и выходит из приложения, чтобы эту информацию переварить. Это огромная тема, как отсрочить этот момент (например, в том же Инстаграме основной режим просмотра не плитка, а лента, где каждый объект отображается последовательно, один за другим; на это же работают сравнительные таблицы - почитайте, например, https://www.nngroup.com/articles/comparison-tables/). Тренды про simple design ровно про то же: очистить приложение от информационного шума и не перегружать пользователя. Главное, не забывайте об этом;)

Друзья, несколько важных объявлений:

- Product Club укомплектован и начнет работу в мае

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

- если вы присоединились недавно, все старые материалы можно почитать тут https://medium.com/@buldakova. Все остальные ресурсы - в описании канала.

Ловите, новая #задачкавыходногодня :)

RealtimeBoard.com – сервис для совместной работы, который позволяет организовывать и упорядочивать идеи, задачи и воркфлоу. Основная аудитория – продуктовые команды (продакт-менеджеры, UX-дизайнеры, agile-коучи, разработчики). Основные задачи, которые решают пользователи, - работа над UX (сервис-дизайн и проектирование), Agile management (user story mapping, retrospectives), Ideation.
Основные метрики продукта – retention и paid team subscriptions.

Вы видите большой потенциал в росте за счет аудитории продакт-менеджеров и хотите увеличить количество активаций таких пользователей. Придумайте фичу, которая помогла бы вам достичь этой цели и при этом не уронить основные метрики. В вашем распоряжении 1 fullstack разработчик и 1 дизайнер.

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

Ответы присылайте мне в личку @Anna_Boo, а еще лучше на почту abuldakova42@gmail.com до следующего четверга включительно. Лучший ответ будет опубликован на канале (но исключительно с согласия автора) в следующую пятницу; также авторы трех лучших ответов получат в качестве приза годовую премиум-подписку на RealtimeBoard. Дерзайте!

Что вы делаете с прочитанными книжками, которые перечитывать не собираетесь, а выкидывать жалко? Предлагаю устроить продуктово-книжную барахолку!

Если у вас есть книги, хоть каким-то образом относящиеся к разработке (а это дизайн, маркетинг, психология, программирование, менеджмент, копирайтинг и тд), смело записывайте их в табличку. Если вас интересуют книжки из списка, смело связывайтесь с продавцом и уточняйте детали - продавец, не забывайте потом поменять статус товара :) Пожалуйста, делитесь ссылкой только со знакомыми вам людьми (чтобы не удалять потом из таблички объявления о продаже пластиковых окон ;)

https://docs.google.com/spreadsheets/d/1YAu8JVEkMJ0ZawMaWTtjFwSixGKFNIfk1hlrBwzqMC4/edit?usp=sharing

Если у вас есть книжки в электронном виде, которыми не жалко поделиться, напишите мне в личку @Anna_Boo

Забавные и классные задачки на аналитику и проектирование со вступительного экзамена в AGIMA University

https://docs.google.com/document/d/1rWS9r55bIZc5ByBT9mi9bCXrDO82VAInZ7z9iporfro/edit - аналитика

https://docs.google.com/document/d/19jL9zJ93OXXhQecEBFdia_VIhOn1ra3kJLrRP1oliHM/edit#heading=h.ocdvihjcp2zp - проектирование

Обещаю вам на этой неделе все же подготовить саммари по классной книжке от Google Ventures, а пока читайте саммари на английском от них же и с картинками:

https://designsprintkit.withgoogle.com/

Одна из моих любимых историй - про то, как в 1975 году инженер Kodak изобрел цифровую камеру, но руководство решило, что инвестировать в разработку слишком рискованно, и предпочло сфокусироваться на уже захваченном и освоенном рынке. Все ведь помнят, что случилось потом? В 2012 году Kodak заявила о банкротстве.

Эта история говорит нам о том, что никогда нельзя останавливаться в развитии - особенно если вы технологическая компания. Технологии имеют свойство довольно быстро устаревать, и лидеры спокойно могут превратиться в аутсайдеров. Что с этим может сделать продакт-менеджер?

1. Периодически делать ревизию внедренных фич и проектов (желательно с engineering manager) и вносить в roadmap улучшение/апдейт для них.

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

3. Следить за тем, что появляется на рынке. Я постоянно смотрю на "новинки" на ProductHunt и Y Combinator, каждую неделю скачиваю по 2-3 новых приложения и анализирую их с продуктовой точки зрения.

4. Читать исследования, аналитику и новости про инновационные разработки. Вот чем пользуюсь я:

https://stratechery.com/ - отличный аналитический блог от Ben Thompson, я еще подписана на платную рассылку

https://research.google.com/ - публикации от исследователей в Google
https://www.thinkwithgoogle.com/ - интересные исследования (в более лайтовой форме, чем по ссылке выше :) и инсайты от Google

https://t.me/groks - классный канал с заметками и инсайтами про технологии и аналитику. Здесь же @addmeto и @techsparks

Делитесь в чатике, чем пользуетесь вы!

https://t.me/joinchat/AAAAAEHjvA0Dw0g6W4Irog

Кстати, дорогие котики, не забывайте про задачку выходного дня, которая еще и с призами в этот раз! Чем больше будет ответов, тем больше вероятность новых задачек :)

https://t.me/proproduct/313

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

Я не говорю сейчас про обычный рабочий процесс, тут понятно, что это нечто среднее. А вот представьте ситуацию - по плану разработчик уже две недели как должен работать над новым, важным для компании проектом. План и сроки согласовывались с самим разработчиком и тимлидом. По факту все эти две недели разработчик занимался рефакторингом, утверждая, что без этого сложно двигаться дальше. По его оценке, на рефакторинг понадобится еще 2-3 недели.

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

Приходите обсуждать в чатик https://t.me/joinchat/AAAAAEHjvA0Dw0g6W4Irog, голосуйте в опросе ниже - как бы вы вели себя в таких ситуациях? Для интереса убрала полумеры, оставив только два полюса :)

Каким должен быть руководитель/менеджер?
anonymous poll

Жестким и требовательным; не прощать ошибок, не спускать на тормозах, не позволять команде расслабляться – 352
👍👍👍👍👍👍👍 69%

Мягким и пушистым; не ругаться, не кричать, не требовать, не пушить – 158
👍👍👍 31%

👥 510 people voted so far.

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

В идеальном мире и в идеальной команде люди знают о сильных и слабых сторонах (своих и коллег), могут здраво оценивать свою работу и свои способности и видеть направления для роста.

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

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

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

Собственно, есть несколько подходов. Первый - создать такую культуру компании, где менеджер знает, как себя вести, независимо от сетапа команды. Яркий пример - Амазон, где со стороны топов идет жесткий контроль и отсутствие похвалы, но хорошее денежное вознаграждение. Или Гугл, где на тренингах по управлению говорят о том, что люди - главная ценность; критиковать нельзя, можно давать качественный фидбэк и подсказывать направления для развития.

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

Мне очень нравится цитата из исследования HBR https://hbr.org/2005/03/what-great-managers-do:

Average managers play checkers, while great managers play chess. The difference? In checkers, all the pieces are uniform and move in the same way; they are interchangeable. You need to plan and coordinate their movements, certainly, but they all move at the same pace, on parallel paths. In chess, each type of piece moves in a different way, and you can’t play if you don’t know how each piece moves. More important, you won’t win if you don’t think carefully about how you move the pieces.

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

Самая большая ошибка, которую можно допустить, - прийти в команду и начать применять принципы с прошлой работы. Даже если они суперклассные и правильные, так это не работает.
Заложите минимум месяц, чтобы просто понаблюдать и пообщаться со всеми, не вмешиваясь в процесс. Мой любимый вопрос на 1-1 - Расскажи, как выглядит твой идеальный рабочий день: что ты делаешь, с кем коммуницируешь, и тд. В HBR предлагают другой вариант: опиши самый классный и самый ужасный рабочий день за последние 3 месяца.

Очень советую почитать "Социальную психологию" Майерса, как минимум - про фундаментальную ошибку атрибуции. Еще из хорошего - 5 levels of leadership Максвелла http://www.johnmaxwell.com/blog/5-levels-of-leadership