Что значит быть крутым проект-менеджером
На английском (full version)
1. Главные обязанности ПМ: Стратегия. Менеджмент (время). Руководство (коммуникации).
2. 3 качества успешного ПМ-а: Любовь к знаниям, Широкий кругозор, Преодоление ограничений.
3. ПМ стоит на пересечении трех компетенций: Технологии (осуществимость), Бизнес, UX.
#product_dump @pm_dump

Короткая выжимка из выжимки Артёма Астапова про make sense Минск.
1. Dogfooding - пользуйтесь своим продуктом сами и по-настоящему.
2. Фреймворк Jobs To Be Done
3. Чтобы ввести продакта в курс дела максимально быстро и хардкорно, ему нужно поработать 2-3 дня в саппорте, провести 15 интервью, много следить за вебвизором, расписать краткосрочные и долгосрочные цели в продукте.
4. Чтобы потестить запрос фичи - можно сделать фейковые кнопки, по нажатию на которую будет предупреждение, что сейчас сервис недоступен, но с вами свяжется менеджер и поможет
5. Точность - стратегия микрониши. Нужно выбрать самые важные 10% функционала.
6. Для стартапа супер продакт: кодит продукт, сам общается с юзерами, думает о смысле и пользе, а не о инструментах.
7. В команде из 20 человек хороший продакт: мотивирует сотрудников, находит лучших специалистов, делегирует задачи.
8. В компании из 200 человек хороший СРО: создал корп культуру, написал миссию и принципы компании, инструменты - jira.
#product_dump @pm_dump

10 наиболее важных навыков хорошего проект-менеджера.
1. Знать, как проводить хорошие митинги. Оптимальное время - 30 минут.
2. Понимать код. Необязательно писать - надо понимать.Одна из основных проблем, с которой сталкивается ПМ — оценка времени на выполнение задач. Не понимая код, будет очень трудно поставить адекватные сроки.
3. Знать, как продавать свои идеи (разработчикам).Разработчики воплощают любую хорошую идею в жизнь. Они не просто «ресурс», они строители и хранители того, что придает жизнь проекту. “продажа идей команде” подробно прописана в предыдущей статье про приоритезацию.
4. Помогать другим. Четко понимай, что важно для компании. Хороший ПМ поддерживает и стимулирует сотрудников. Он не просто ставит задачи, а видит сильные стороны каждого человека и использует.
5. Четко понимать, о чем говорит статистика.
6. Часто контактировать с клиентами. Важно создать сильную клиентскую базу. Задача ПМ-а наладить тесную эмоциональную связь с клиентами. КастДев и всё такое. Регулярно общайся НЕ про продукт, а про жизнь. И никогда не спрашивай клиентов про будущее.
7. Уметь правильно подбирать слова.
8. Управлять своим временем. Пользуйтесь механизмами планирования времени.
9. Делегируй.
10. Не стесняться признаваться в том, что чего-то не знаете.
#project_dump @pm_dump

Как не сделать “какашку”? Личный опыт создания продукта.
Внутри подход Spotify по созданию продуктов: Think it, Build it, Ship it, Tweak it.

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

Build it - создай минимально работоспособный продукт, готовый для реальных пользователей.
Переходим от бумажных прототипов в рабочим. Делаем только то, что поможет проверить гипотезы. Только те фичи, без которых не может существовать продукт.
Результат этапа: нарратив продукта (зачем и для кого он), MVP на реальных пользователей.

Ship It - постепенно предоставь 100% пользователей доступ к нему, измеряя параметры и улучшая продукт.
Постепенно расширяй аудиторию с 5-10% до 100% пользователей, улучшаясь итеративно.
Результат этапа: продукт выпущен на 100% пользователей и проверен.

Tweak it - Постоянно совершенствуй продукт. Это действительно окончательное состояние; продукт находится здесь, пока не будет закрыт или пересмотрен (= вернуться к Think It)
Результат этапа: продукт достиг локального максимума в выбранных метриках, выбрана новая цель для кратного улучшения (от think it и далее снова).
Теоретическая статья - обзор фреймворка.
#product_dump @pm_dump

Как перестать приоритизировать и начать жить. Эволюция продуктовых процессов

1. Что должен делать продакт-менеджер: тестировать продуктовые гипотезы, приоритизировать разработку, выпускать MVP на рынок как можно раньше, собирать фидбек, считать юнит-экономику, тестировать новые каналы и так далее.

2. В статье тестирование гипотез, канбан доски и выстроенные процессы. Очень полезно.

3. За рамками промо сервиса Kaiten описано как выстроить процесс от маленькой команды до большой компании, включая доски и подходы для real-time информирования акционеров по текущему прогрессу компании.
Summary: если правильно ограничить одновременное количество задач в работе, то высвободится время продакта на действительно важные процессы, способствующие кратному улучшению разрабатываемого продукта.
#product_dump @pm_dump

MVP за 7 недель. Как это было
1. Мы «забили» на инфраструктуру. До поры до времени необязательно.
2. «Нафиг» — стало нашей любимой фразой.
3. Практический опыт пременения Бритвы Оккама для разработки продукта в сжатые сроки.
#product_dump @pm_dump

Сокровищница аналитика.
Набор полезных ссылок на курсы, инструменты и вот это всё.
От аналитикса и метрики до mySQL, Python и R.
#naked_links @pm_dump

Как писать User Stories
User story - это то, как ваш пользователь должен взаимодействовать с вашим продуктом. Это не технические требования.
1. На выполнение истории не больше 1 итерации, иначе нужно разбить

2. Если какую-то из трех частей можно убрать, то она бесполезна:
- Актор (один) - сделать подгруппы и под них писать истории (персоны)
- Действие (одно) - писать нужно ЧТО делает пользователь, а не КАК. Это важно.
- Ценность (одна) - Не обязательно писать "чтобы". Можно сделать быстрее: щас 60 секунд, должно быть 15 секунд. Ценность должна линковаться с целью продукта. Используйте "Impact map".

3. Каждую юсторию можно оценить по критериям «INVEST»:
- Independent. Reduced dependencies = easier to plan;
- Negotiable. Details added via collaboration;
- Valuable.
- Estimable. Too big or too vague = not estimable;
- Small. Can be done in less than a week by the team;
- Testable. Good acceptance criteria;

4. Советы к написанию user stories:
- Лучше написать много историй поменьше, чем несколько громоздких.
- Каждая история в идеале должна быть написана избегая технического жаргона.
- Истории должны быть написаны таким образом, чтобы их можно было протестировать
- Тесты должны быть написаны до кода.
- Как можно дольше стоит избегать UI. История должна выполняться без привязки к конкретным элементам.
- Каждая история должна содержать оценку.
- История должна иметь концовку — т.е. приводить к конкретному результату.
- История должна помещаться в итерацию.

Summary: юстории помогут вам более чётко понимать зачем вы делаете ту или иную фичу, потому что ваш продукт должен решать пользовательскую задачу или проблему. Выработать US можно с помощью брейншторма или CJM.
#product_dump @pm_dump

Сеть оценок для планирования в Scrum.
Story points — это относительные оценки объёма работы в истории. Но SP всегда сравниваются с другими историями и существуют относительно друг друга - это проблема любой команды и PM, в частности. По ходу проекта забывается что такое один story point из-за регулярной переоценки задач.
Предлагается решение “оценочная сетка” - это таблица, где на одной линии стоят задачи одного размера. Для размера используются числа Фибоначчи (½, 1, 2, 3, 5 etc.)

Совет: добавляйте на такую таблицу только “типичные” повторяемые задачи. Исключительные и редкие задачи там не нужны. И заносите туда задачи только после реализации (по факту).

Правило: 5 - это интервал от 3 до 5, если задача чуть больше 3 или чуть меньше 5, то это 5. В каждой линии 2-5 карточек для простоты (много не надо).

Рекомендация: не делать доску больше 8, т.к. история должна помещаться в спринт.
#project_dump @pm_dump

"Оценочная сетка" для типизации оценок юсторий
#project_dump @pm_dump

Сила CJM в продукте (видео).

Откуда брать user stories? Один из вариантов - Customer Journey Map (Experience Map)
Цель любого продукта - принести ценность пользователю через взаимодействие с вашим продуктом.

CJM - это техника визуализации процесса взаимодействия пользователя с вашим продуктом и оценки «суммы всех впечатлений» (=ценности)

Точка взаимодействия с юзером - это зона пересечения круга потребностей юзера и потребностей бизнеса.

Внутри CJM (примеры в pdf):
1. Цели пользователя (чего хочет добиться);
2. Цели бизнеса;
3. Критерии успеха, ожидания;
4. Процесс и действия пользователя;
5. Каналы;
6. Проблемы и барьеры;
7. Моменты истины (MoT: Moments of Magic, Moments of Madness);
8. Эмоции, настроение, цитаты;
9. Степень критичности и приоритет;
10. Идеи и улучшения.

«Сила» Experience Map:
- Комплексный и непрерывный UX;
- Поиск проблемных точек взаимодействия;
- Лояльность пользователей;
- Ответственность и вовлеченность команды;
- Повышение качества разработки;
- Новое и уникальное взаимодействие.

Бонус трек:
1. Крутой сервис с шаблонами - UXPressia
2. PDF презентация
3. “Как использовать конкурента для экспоненциального роста” - видео, 11:25
#product_dump @pm_dump

“Сила CJM в продукте”. Анастасия Ковалева-Геливер, CPO RocketBody

#product_dump @pm_dump