Кстати, к Новому году как раз :)
Нашла подробную статью с примером заполнения Lean Canvas для Санта Клауса: http://ru.wiki.rademade.com/lean-canvas-santa

#product
@projectsproducts

Продолжу выкладывать записи лекции.
Сегодня «Школа менеджмента Яндекса — О продуктовом мышлении.» (Юрий Подорожный)

Со временем сложность систем имеет свойство накапливаться.
В связи с этим нужно вспомнить слова Джона Галла (теоретика в области систем):
«Сложная система, созданная с нуля, никогда не заработает.
Начинать надо с работающей простой системы.»
Всегда важно начинать с простой работоспособной системы.

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

Аргументы, которые вам могут приводить:
- «Просят пользователи»
- «Есть у конкурентов»
- «Требует начальство»
- «Василий написал, что это круто»
- «Команда хочет»
- «Пишут в интернете»
- «Просит наш главный клиент».

И продакт-менеджеру (или человеку ответственному за продукт) нужно уметь ответить нет.

Мораль: необходимо развить в себе умение говорить «нет». Не «позже» или «может быть», а «нет».

Если мы научились говорить «нет», то как же дальше выбирать, что стоит делать, а что нет?
Поговорим теперь о важном и неважном.

И тут есть несколько вопросов, которые нужно себе задавать:
- Насколько это соотносится с вашим видением продукта?
Опросы, мнения пользователей, метрики и т.д. — это далеко не
всё.
Любой может провести опрос, посмотреть на метрики или найти аналитику.
Только вы определяете какую проблему решает ваш продукт и
как он это делает.
- Будет ли это иметь смысл через 5 лет?
- Что произойдёт, если этого не делать? (проиграем ли мы конкурентам? продолжит ли наш продукт существовать?)
- Увеличит ли это прибыль?
- Сколько будет стоить поддержка? (хватит ли у вас ресурсов, чтобы поддерживать эту фичу в следующем году или следующие 10 лет?)

Продолжение следует…

Ссылка на видео - https://www.youtube.com/watch?v=m8h_KsDovRw&list=PLEs8EuAPI73Bj78n7-BIW3s1we0r15yJl&index=3

#product
@projectsproducts

Часть 2, продолжение записи лекции «О продуктовом мышлении»:

Переходим ближе к практике.
Поговорим об идеальном пути.

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

И если идти по идеальной воронке, то часто бывают проблемы на стыке взаимодействий:
1. Дизайнер подумал только про идеальный сценарий.
2. Разработчик нашёл и другие сценарии, но у него нет
времени думать о том как решить проблему.
3. Разработчик предполагает как должно быть. И делает как
считает нужным.
4. Так ошибка проектирования становится ошибкой в продукте.

Чтобы такого не было, очень полезно задавать себе вопросы:
- Что если пользователь не читал инструкцию?
- Что если во время отправки данных пропало соединение?
- Что если пользователь прервался во время выполнения
действия?
- Что если пользователь не подтвердил адрес почты?
- Что случится, если в этом месте всё пойдёт не по плану?
- Что если изменится место или контекст пользователя?(человек будет использовать ваше приложение из другой страны или города?)

Еще расскажу про самые распространённые сценарии, которые стоит учитывать при разработке:
- Пустые экраны
- «Ничего не найдено» в результатах поиска
- Отображение ошибок (валидация, получение, отправка)
- Потеря соединения с интернетом
- Местоположение пользователя
- Контекст пользователя
- Локализация (текст на другом языке может занимать сильно больше места, чем вы оставили на макете)

О сценариях, про которые не стоит забывать, я писала в посте - https://t.me/projectsproducts/30

Кроме этого полезно пользоваться методом от обратного. Когда вы задаете себе вопрос: «Как сделать самый неудобный интерфейс на свете?» (Почитать подробнее: Ководство Артемия Лебедева. § 150. От обратного - https://www.artlebedev.ru/kovodstvo/sections/150/)

Резюмируя: Мир не идеален, поэтому помните о пограничных случаях. Ожидайте неожиданное.

Продолжение следует…

Ссылка на презентацию - https://yadi.sk/i/XTn44y8S3NmteL

#product #book
@projectsproducts

Часть 3 (заключительная), продолжение записи лекции «О продуктовом мышлении»:

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

Тут хочется рассказать историю про корабль Васса, который строили 3 года в Швеции (1625г), на первом же своем выходе корабль утонул.
Проводили расследование «Почему утонул корабль?». Расследование выяснило, что это была «Божья воля».

Позднее выяснились факты строительства самого корабля:
- Длина корабля менялась дважды по ходу строительства
- Добавили ещё одну палубу для пушек
- Количество пушек менялось несколько раз
- Позолоченные статуи, резные скульптуры. Дорого-богато
- Документации не было. Конструктор умер за год до трагедии
- Ширину корабля втайне от короля увеличили на 2,5 метра

Какие выводы можно сделать из этой истории?
- Фиксируйте объём работы
- Ведите документацию
- Тестируйте на реальных пользователях
- Вникайте в устройство вещей.

И еще совет:
Применяйте метод Сакити Тоёда:
«Задавая вопрос «Почему?» 5 раз, вы определяете характер проблемы, решение становится понятным.»

И в заключение еще одна цитата:
«Верить или не верить, это не имеет никакого значения. Интересно лишь задавать себе всё больше и больше вопросов.»- Бернар Вербер.

Ссылки на видео и презентацию были в постах выше.

#product
@projectsproducts

​​Сегодня про книгу «Спринт» (Джейк Кнапп, Джон Зерацки, Брейден Ковитц. Все трое – сотрудники Google)

Спринт является составной частью широко известной концепции Scrum, но авторы его модифицировали.
Это 5 дней работы команды (до семи человек), которые занимаются только заранее обозначенными задачами.

Все расписано по дням:
- Понедельник - ставим цель (долгосрочную, на полгода-год).
- Вторник – каждый делает “набросок финального решения”.
- Среда - выбираем только один набросок.
- Четверг - делаем максимально возможный прототип. прорабатываем сториборд.
- Пятница - тестируем (всего 5 человек на тест! так как “85% проблем выявляются после интервью всего с пятью пользователями”.) и решаем, будет ли проект жить.
при тестировании главную ценность представляет именно спонтанная реакция потребителей

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

“В целом демократия – прекрасная вещь, если речь идет об управлении государством, но она совершенно неуместна при проведении «спринтов»”.

#book
@projectsproducts

​​Когда писала про лекцию Юры Подорожного в Яндексе, обратила внимание на сайт, на который у него была ссылка:
http://www.productstrategymeanssayingno.com/

Это страница ярко иллюстрирующая одну мысль: «Продакт-менеджеру нужно уметь говорить нет!».

Сайт говорит: Saying no is hard, but a great product manager isn’t afraid to make tough decisions to keep their product bloat-free.

А здесь подробный рассказ про то, когда же нужно говорить «Да»:
https://blog.intercom.com/rarely-say-yes-to-feature-requests/

Собственно ровно это и было в лекции Юры, но если вы хотите почитать подробнее оригинал Интеркома, то ссылка выше.

#product
@projectsproducts

Менеджер по продукту знает, куда ведёт продукт, а менеджер проекта знает, как успешно привести проект к финишу.
И оба должны быть сильными командными игроками, лидерами (в хорошем смысле), мотиваторами.

Смотрим новый ролик с примером отличного менеджера :)

https://www.youtube.com/watch?v=9MO1aY1xC80

#project #product
@projectsproducts

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

Нашла у себя среди записей заметку:
Последние несколько лет в США было много исследований, направленных на изучение преимуществ "гибких" методологий по сравнению с традиционной водопадной моделью. Например, согласно “7th Annual State of Agile Development Survey” (Version One):
84% респондентов (разработчиков) признали, что подход "Agile" более эффективный, чем традиционный подход.
Кроме того, 70% опрошенных в этом же исследовании признали, что "Agile"-проекты намного быстрее реализуются.

А вот исследование российского рынка от компании ScrumTrek в 2017 году:
- Средний опыт применения Agile в России: у людей – 3 года, у компаний – 2,5.
- Мы отстаем на 1-2 года от среднего по миру опыта.
- Год назад финансы и телеком начали осваивать Agile: новичков там 56-59%.
- И в разработке ПО по-прежнему бурный рост: 31% с опытом не больше 1,5 года.

Ссылка на полный отчет - https://scrumtrek.ru/userfiles/reports/AgileSurvey17.pdf

#project
@projectsproducts

#project
@projectsproducts

Кстати, из тех же отчетов, о которых писала выше:
В 7th and 8th Annual State of Agile Development Survey (Version One) самые популярные гибкие методологии: "Extreme Programming" (XP), "Scrum", "Lean Development", "Feature Driven-Development" (fdd) and "Kanban".

И в России ничего нового: доля Scrum составляет 48%, причем с ростом зрелости компании в Agile процент компаний, использующих Scrum, становится чуть выше.

#project
@projectsproducts

#project
@projectsproducts

​​Книга «Заряженные на результат. Культура высокой эффективности на практике» (Нил Доши, Линдси Макгрегор).

Лучше всего работает 3 типа мотивации («прямые мотивы»):
- Игра (когда работа просто доставляет удовольствие),
- Цель (когда ты действительно ценишь результат своего труда) ,
- Самореализация (когда достигаешь чего-то важного для себя).

Деньги и премии - это хорошо, но только в комбинации с вышеперечисленными типами мотивации.

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

“Когда миссия организации совпадает с ценностями ее команды и клиентов, включается мотив цели”.

“Ощущение игры возникает, когда вы занимаетесь своим делом просто потому, что оно вам нравится. Сама работа становится для вас наградой. Ученые описывают такого рода мотивацию как «внутреннюю»”.

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

Если еще короче:
Лучше всего способствует высоким трудовым результатам мотив игры, когда сотрудник просто увлечен своим делом.
Но при этом у человека на любой должности и в любом отделе должна быть возможность подняться по карьерной лестнице. Например, для исследователей и ученых должны быть престижные и высокооплачиваемые должности, в том числе такие, где им не нужно будет заниматься административными делами.

#book
Вопросы (как и всегда) отправляйте на почту elena.kotina@gmail.com
@projectsproducts

В книге «Заряженные на результат» наткнулась на упоминание принципа Питера (как-то раньше это прошло мимо меня), который на русском звучит так:
«В иерархической системе каждый индивидуум имеет тенденцию подняться до уровня своей некомпетентности».

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

Обоснование автор получил, рассмотрев типичный порядок выдвижения работников на определённую должность:
- Компетентные повышаются
- Некомпетентные не понижаются
- Отказ от повышения маловероятен

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

Итальянские ученые даже провели исследование (“The Peter Principle Revisited: A Computational Study”):
применив агентное моделирование, создали систему, в которой соблюдается принцип Питера. На этой модели они показали, что лучшая тактика — повышать человека СЛУЧАЙНО!!!

За эту работу они получили шнобелевскую премию 2010 года в области менеджмента.

Считается, что это «шутка, над которой стоит задуматься».

#project #product

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

А вот выдержка из рассказа Эрика Риса (Eric Ries) про MVP (the minimum viable product):

Существует подход в разработке «release early, release often», который многие знакомые практикуют.

Но недостаточно просто следовать RERO-принципу, так как в итоге вы будете бегать по кругу: выкладывать код с небольшими фичами, получать фидбек, проводить фокус-группы, но в итоге все придет к тому, что у вас не будет глобального долгосрочного видения того, что вы делаете.

Идея минимального жизнеспособного продукта (MVP) в том, что вы можете сказать:
мы хотим создать такой продукт, который будет решать проблему клиентов, и наши «ранние пользователи/последователи» уже смогут использовать это решение, и готовы за него заплатить.

Начать проверку вашего продукта можно с создания целевой страницы (landing page) с возможностью подписаться на новости о выпуске продукта, или просто текст с его описанием.

Если вы пустили трафик на эту страницу, и увидели, что 0% целевой аудитории подписываются на новости, то скорее всего вся идея нашего продукта была ошибочной.

Но если Вы не обескуражены тем, что никто не заинтересовался вашим лэндингом, и продолжаете работу над следующей итерацией, делаете продукт более сложным, и если после 10й итераций у вас так и не появилось «благодарной аудитории» вам стоит сказать себе:
«Хм, мы движемся не в том направлении. На самом деле, мы прошли точку минимального жизнеспособного продукта. Это просто **НЕ жизнеспособный продукт.**»

#product

​​Новая запись Школы менеджмента.
Продуктовые исследования. (Иван Замесин)

Главные причины провала продуктов (по данным агентства CBinsights.com):
- Нет потребности рынка. (42%)
- Сделали плохой продукт.
- Вышли за рамки бюджета.
- Неправильно подобранная команда.
- Слишком высокая цена.
- Игнорирование клиентов.
- …
Ссылка на полный отчет - https://www.cbinsights.com/research/startup-failure-reasons-top/

Если все это суммировать, то главная проблема: не найденный product market fit.

Давайте посмотрим на жизненный цикл стартапа (см. картинку ниже).

После того, как вы разработали продукт и вышли на «долину смерти» вам очень важно получить обратную связь.
Если вы сделали продукт, который не покупают, вам важно понять, почему не покупают.
Использовать CustDev - это самый простой и верный способ.

«Customer Development (CustDev) - это процесс получения инсайтов от пользователей для создания, проверки и оптимизации идей развития продукта с помощью интервью и структурированных экспериментов» (Steve Blank)

Как применять CustDev:
1. Валидировать продуктовые идеи
2. MVP - это тоже Customer Development (это не просто создание лэндинга и сбор адресов, но и разговор с теми, кого заинтересовала идея)
3. Проверить, за сколько стоит продавать свой продукт.

Проводить CustDev важно на всех этапах жизненного цикла продукта.

Почему многие не пользуются этим инструментом:
- Нет времени или лень.
- Страшно разговаривать.
- Не знают как правильно делать.
- Боятся осознать, что продукт никому не нужен.
- Боятся, что украдут идею.
- Не умеют задавать вопросы.
- Не умеют критически мыслить.

Сustomer Development может проводится следующими способами:
- Интервью 1на1 (лично или скайп).
- Опрос с помощью чатбота/GoogleForm (по опыту через чатбота отвечают в 4 раза больше людей и сильно быстрее).
- Группа лояльных пользователей.
- Коридорный опрос.
- Юзабилити-исследование. (особенный тип интервью) Цель - выявить паттерны.

CustDev - это исследование, которое делают только люди из команды и делают это быстро (за неделю-две).

Как CustDev вписывается в Lean Startup Model?
- На этапе «Learn» - разговариваем с людьми, правда ли есть проблема?
- На этапе «Build» - делаем MVP или макет в Balsamiq, идем к пользователям и спрашиваем, это то что им нужно?
- На «Measure» - смотрим на релевантные метрики
- На шаге «Learn» снова смотрим, что изменилось, что еще нужно.

У метода CustDev есть границы применимости:
- НЕЛЬЗЯ понять какое будет будущее.
(нельзя задать вопрос «купишь ли ты вот это?» и получить на него правдивый ответ)
- МОЖНО достать факты: что люди делают сейчас, какие есть нюансы использования продукта.

О том, как правильно проводить интервью, читайте во второй части.

#product
@projectsproducts

Часть 2, продолжение записи лекции Продуктовые исследования. (Иван Замесин).

Как проводить интервью:
1. Найдите Целевую Аудиторию:
- Поймите, кто вам нужен.
- Задайте вопрос-фильтр: Используешь ли ты продукт конкрентов? есть ли у тебя такой кейс?
2. Подготовьтесь к интервью:
- Выпишите максимально разные гипотезы по отличиям в потребности, контекстам, нюансам.
- Проработайте каждую гипотезу на один уровень вглубь. (что если ответит вот так или вот так? )
- Выпишите все вопросы. Все вопросы должны быть открытыми.
3. На каждый ответ пользователя вы должны задать ему 5 ВОПРОСОВ «почему?». Это позволит вам выяснить настоящие мотивы.
4. Как теперь понять, что пользователю можно верить? Нужно правильно слушать и задавать правильные вопросы.

Дальше будет про нюансы описанных выше пунктов.

Где находить людей?
- Через знакомых и их знакомых.
- По вашей базе пользователей.
- В ореолах обитания.
- лэндинги, как сбор адресов, но с очень низкой конверсией
- Организуйте митапы, читайте лекции.
- Платите людям: даже 100 рублей.

Какие задавать вопросы на интервью?
Примеры плохих вопросов:
- «Как вы считаете, хороший ли сервис - уборка за 2000руб. вашей квартиры, пока вы отдыхаете?» : вопрос закрытый, про деньги и про будущее.
- «Вы бы заказывали уборку у вас дома экологичными средствами?» : Вопрос про будущее. Лучше спросить: какими средствами вы убираетесь сейчас? Думаете ли вы о здоровье? Есть ли у вас дети? животные? переживаете ли вы что химикаты вредят их здоровью?
- «Сколько вы готовы заплатить за уборку у вас дома экологичными средствами?» : Вопрос про будущее, и мы не можем правильно интерпретировать ответ. Спрашивать про деньги имеет смысл только в том случае, если вы прям сейчас предлагаете что-то купить и пользователь готов заплатить за ваш продукт прям сейчас. Если он согласился купить, значит цена его устраивает.
- «Заплатили ли бы вы за продукт Х, если бы он стоит У рублей?»

Хорошие вопросы:
- «Какими функциями должен обладать ваш сервис?» : вопрос хороший только в том случае, если вы после ответа задаете еще 5 «почему?» и спрашиваете именно экспертов.
- «Есть ли что-то, что вас беспокоит в уборке вашего дома?»
- «Что будет, если мы это не сделаем?»
- «Расскажите про конкретный опыт?»
- «Вы пробовали похожие продукты?»

Что учитывать при общении с людьми?
- Люди хотят понравится вам, хотят показать, что им понравится ваш продукт. Ведь вы обратили на них внимание и пригласили на интервью.
- Если пользователь делает комплименты «круто!», «все прошло отлично!», «я очень люблю ваш продукт», то этому интервью нельзя доверять.
- Если пользователь обобщает, когда он не помнит конкретный опыт, то вместо рассказа «Я делал так и так» он использует обобщающие фразы: «Я обычно делают так..», «я часто…», «я делал бы…», «я могу…». В таком случае эти ответы нельзя считать фактами.
- Фраза-убийца стартапа «О, я точно это куплю!» - это про будущее, мнение и обобщение.
- Patterns Problem - когда вы пытаетесь себя успокоить через мнение людей, вы не должны на самом старте рассказывать о своей новой функциональности, говорите меньше.

Главные хаки.
- Разделяйте интервью на три части по 10 минут: изучение потребности, рассказ про решение и сбор фидбека, pitch с каким-то действием в конце (идеально, если человек дает вам денег)
- Старайтесь проводить беседу неформально.
- Задавайте открытые вопросы.
- Когда задаете вопрос, думайте не направит ли он человека в другую сторону.
- Спрашивайте много «Почему?», только это позволит докопаться до фактов.
- Важный вопрос: Искали ли вы решение? Сколько времени вы на это потратили?
- В конце интервью обязательно спрашивайте: «Есть ли что-то, про что я не спросил?» и «С кем вы советуете еще про это поговорить?»

#product
@projectsproducts

​​И для закрепления, основные этапы Customer Development на картинке:

Ролик на тему "хорошая и плохая командная работа".
https://goo.gl/Dh9UxB

#product #project
@projectsproducts

Вы делаете хорошие вещи с точки зрения пользователей и бизнеса или нет?

Есть 2 простых фреймворка, с которых можно начать считать метрики вашего продукта:

1. AARRR.

Популяризировал этот подход Dave McClure ( у него есть книга: «Product Marketing for Pirates: AARRR!»).
Представьте ваш продукт в виде воронки: сверху которой вы наливаете трафик и каким-то образом , с какой-то эффективность его конвертируете в полезные вещи для вашего продукта.

Каждая метрика относится к одному этапу работы пользователя с вашим бизнесом:

- Привлечение (Acquisition) — доля клиентов (потенциальных), привлеченных через маркетинговые каналы, и обнаруживших заинтересованность в продукте (не сразу покинувших сайт).
- Активация (Activation) — доля клиентов, получивших положительный опыт использования продукта. Это когда вам удалось склонить пользователя к целевому действию.
- Удержание (Retention) — доля клиентов, повторно использующих продукт. На сколько эффективно вы этих людей удерживаете, как много клиентов из прошлого периода в текущем периоде совершили полезное действие. Обычно измеряют от месяца к месяцу.
- Доход (Revenue) — доля клиентов, которые платят за продукт. доходы на период, сколько вы заработаете с пользователя за период, чтобы понять, сколько можно тратить на продвижение.
- Рекомендация (Referral) — доля клиентов, которые рекомендуют продукт (делятся ссылкой, высылают приглашения).

2. HEART.

Этот фреймворк придумали в Google, испольлзуется в GMAIL. Отлично подходит для долгоиграющих продуктов.

- Happiness - это скорее качественная метрика. Это когда вы спрашиваете пользователя через несколько дней после работы с приложением или по завершению заказа: «на сколько вам понравилось использование сайта/приложения?»
- Engagement - как часто пользователь пользуется тем, что вы предлагаете?
- Adoption - усвоение, на сколько хорошо осваивается пользователями новый продукт или функционал. (сколько людей откатилось до старой версии? )
- Retention - хорошо ли мы удерживаем пользователя от периода к периоду?
- Task success - на сколько хорошо работают ключевые сценарии: качество поиска (средняя позиция клика). Каждый ключевой сценарий в продукте нужно измерять.

(Подробно можно почитать - «Measuring the User Experience on a Large Scale: User-Centered Metrics for Web Applications (Google)» - https://static.googleusercontent.com/media/research.google.com/ru//pubs/archive/36299.pdf)


А для определения «счастья пользователя» можно использовать Тест Шона Эллиса.

Шон Эллис руководит консалтинговой компанией 12in6, которая специализируется на помощи стартапам, находящимся в стадии переходного роста. В качестве проверочного условия для начала сотрудничества со стартапом он использовал опрос клиентов компании, ставивший целью определить наличие раннего привлечения, которое, в свою очередь, является хорошим показателем того, что стартап находится на верном пути.

В ходе опроса клиентам предлагалось ответить на несколько вопросов:

Как бы вы чувствовали себя, если бы не смогли больше пользоваться продуктом этой компании?
1. Очень расстроенным
2. Слегка расстроенным
3. Совсем не расстроенным (он не очень мне нужен)
4. Не знаю, я больше не пользуюсь этим продуктом

Если более 40% ваших клиентов говорят, что они будут «очень расстроены» отсутствием вашего продукта, то у вас есть большой шанс построить устойчивый и масштабируемый бизнес на этом безусловно нужном продукте.

Показатель 40% был выведен эмпирически по результатам анализа деятельности сотен стартапов.

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

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

#product #book
@projectsproducts

#AllTags

В свои посты я добавляю теги, чтобы вам было удобнее ориентироваться, и находить необходимую информацию.

А здесь пополяемый список моих тегов:

#project - всё про управление проектами.
#product - то, что нужно знать менеджеру и руководителю продукта.
#foundation - основы основ. Базовые вещи/понятия/определения, о которых хочется напомнить.
#book - посты с кратким содержанием книг, цитатами или рекомендациями полезной литературы.

#AllTags
@projectsproducts