8-9 ноября в Минске пройдет крупнейшая конференция по Product Management в СНГ - ProductSense https://goo.gl/pzSV3F

ProductSense - это:

500+ участников: менеджеры, дизайнеры, маркетологи и ТОПы из ведущих российских и зарубежных продуктовых компаний.

50 докладчиков (среди них продуктологи Revolut, Spotify и др.) – программа получилась особенная, с большим количеством иностранных докладчиков, и еще большим количеством крутанов из РФ, Беларуси и Украины: Yandex, Skyeng, Grammarly, WANNABY. Полный список докладчиков можно посмотреть тут http://productsense.io/speakers#list

8 вокршопов: 7 ноября участники смогут прокачать свои продуктовые навыки на воркшопах, которые проведут приглашенные эксперты: Itamar Gilad, Wolfgang Wopperer-Beholz, Павел Педенко и Ярослав Степаненко, Никита Ефимов, Алексей Авдей, Дарья Рыжкова, Дмитрий Абрамов и др. Секция воркшопов рассчитана на сто участников.

Cпециальным гостем конференции станет - Ryan Hoover (https://twitter.com/rrhoover) - основатель Product Hunt.

Билеты доступны по ссылке https://goo.gl/T8BGHv. Поторопитесь: Организаторы обещают скорое повышение цен.
Приятный бонус для подписчиков канала - скидка 5% на билеты категории Standart по промокоду: BORODA

Ребята, ура! Свершилось то, что мы так долго ждали: готов отчет по исследованию рынка продакт-менеджеров в России 🎮🔥🎮🔥

Короче, не могу ждать, хочу поделиться. Для фреймворка расписан первый case study "Product Discovery" http://productframework.ru/product_discovery

Изображение пока не оптимизировано под мобилки - нужно смотреть на десктопе. Плюс завтра выложу вторую часть статьи, связанную со слоями стратегии и тестирования гипотез в контексте product discovery.

Есть несколько новостей и все хорошие:

1) Я дописал вторую часть про product discovery http://productframework.ru/product_discovery

Всё так же изображение просматривается только на декстопе, скоро сделаю отображение на мобилках.

2) Все product notes наконец-то были собраны на едином сайте http://productnotes.su/

Забавная история. Домен ru кто-то уже выкупил в этом году. Домен com я пытался купить, но три раза получал отказ. В итоге, плюнул на это дело и купил su (soviet union), чтобы всем неповадно было.

3) До релиза печатного издания остаётся немного времени. Во-первых, к текущим будет добавлено ещё около 20 моделей. В ноябре буду подбирать типографию, чтобы к началу декабря иметь возможность распечатать колоды. Дизайн будет обновлен (отходим от серости к светлоте и простоте) - за эти более, чем полгода, я получил много обратной связи по их виду.

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

4) В среду-четверг я буду в Москве на egconf. Если есть желание пообщаться - давайте.

Доброе утро, коллеги. Может быть среди подписчиков найдутся продакты из крупных компаний, занимающихся ecommerce (Ozon, Lamoda, Mvideo, Eldorado, Петрович, 220-вольт и т.д.). Очень хочется пообщаться, посоветоваться и перенять кое-какой опыт. Если у вас найдется хотя бы полчасика для меня, буду очень благодарен.

Коллеги, до ProductSense, крупнейшей конференции для продакт менеджеров в СНГ, в Минске осталось меньше двух недель.

Расписание конференции уже опубликовано (есть вероятность, что будет круто, ведь будет Ryan Hoover, основатель ProductHunt): http://bit.ly/myproductisamazing

Тем, кто хочет, но до сих пор не купил билет, стоит поторопиться, т.к. цены повысятся сегодня ровно в 23.00. Промокод BORODA (скидка 10% на билеты категории Standard и 5% на Professional) сегодня снова работает. Билеты можно купить тут: http://bit.ly/2PmV5e7

Не теряйте больше время, если откладывали.

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

P.S. Опять забыл сказать главное - я все-таки тоже буду на Product Sense в Минске, можем пересечься при желании, познакомиться, пообщаться.

Не так давно я узнал, что, оказывается, есть вторая версия всем известного Agile Manifest. Причем существует уже довольно давно. Удивляет, что про неё слышали весьма немногие (как я, например), хотя именно она демонстрирует важный эволюционный шаг вперед с точки зрения философии разработки программного обеспечения. Хочу порассуждать о трактовке 2.1.

1. Команда и ответственность важнее индивидуумов и взаимодействия.

Почему старое - неактуально? Потому что раньше, чтобы стать разработчиком, нужно было разбираться не только в структурах данных и алгоритмах, но и немножко сечь в архитектуре. Порог входа был в специальность был намного выше, чем сейчас (почти 20 лет назад): инструментарий языков был беднее, фреймворков было меньше, технологии были сложнее, чтобы изучать тему, приходилось вникать самому или общаться на форумах. В таких условиях хороший разработчик действительно был "высокомотивированным специалистом", который должен уметь взаимодействовать с такими же, как и он, профессионалами. Но сейчас порог входа другой. Рынку нужно больше разработчиков, чем есть в наличии, появилось куча курсов, школ и программ обучения, где все разжевано. Иногда до такой степени, что молодым программистам кажется, что они детально владеют ситуацией, что реальные задачи будут сильно схожи с примерами обучения. В итоге, мы сейчас рынок получил кучу зелёных юнцов, которые хотят дохера, а умеют нихера. Кстати, сейчас подобная ситуация кажется похожей и среди продактов.

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

Да и сами команды теперь нужно трактовать намного шире. Это уже не просто совокупность разработчиков, тестировщиков, архитекторов или других технических специалистов, но м продактов, маркетологов, ux специалистов, аналитиков и т.д. Потому что подход к построению продуктов стал другим по причине пункта 2.

2. Бизнес ценность важнее работающего продукта

Концепция "работающего продукта" была выдвинута в первом манифесте в ответ на долгий цикл проектирования (читай написания документации) и разработки ПО, когда первую работающую версию продукта получали ближе к концу проекта. И пока работали в таком ключе над проектом, кто-то более гибкий уже запускал продукт и получал прибыль.

Однако, это хорошо работало, когда на рынке потребность в IT продуктах была выше, чем их предложение. Когда не хватало даже необходимых приложений. Концепция minimum viable product - тоже часть этой эпохи, когда ваше "быстренькое" решение должно было проверить гипотезы необходимости тех или иных фич, чтобы долго не лабать никому не нужный продукт.

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

В итоге, даже разработав "гибко" продукт, в нем может тупо не оказаться бизнес-ценности. Поэтому именно поиск и разработка бизнес-ценности (product discovery) стала намного важнее самого программного обеспечения. И если команда концентрируется на её поиске, при этом не написав и строчки кода, это правильный подход.

3. Развитие партнёрских отношений важнее сотрудничества с клиентом

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

перманентном состоянии разработки, так и не достигнув собственных целей. Партнёрские же отношения подразумевают ситуацию "win-win", когда обе стороны достигают поставленных перед ними целей. Как своих собственных, так и совместных. Смотрели фильм "Игры разума"? Там как раз был эпизод про этот принцип, именуемый равновесием Нэша.

4. Готовиться к изменениям важнее реакции на изменения

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

Вспомним историю. Когда ПО строилось по "изначальным планам", выраженным в скучных технических заданиях, его разрабатывали долго. Но знаете... Оно работало! Оно реально работало. С переходом на гибкую разработку, реагирующую на изменения, мы получаем продукты быстрее, но их качество оставляет желать лучшего. В итоге ПО, разрабатываемое таким образом, довольно быстро доходит до пределов возможностей своей бизнес-логики, утопая в техническом и архитектурном долге. После чего приходится пилить новый продукт, который бы решить проблемы старой системы. Тем самым та пресловутая гибкость, о которой говорится в манифесте, оборачивается жёсткими ограничениями в развитии.

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

Кстати

В пятницу

Коллеги, все привет. Раскрою тайну, почему так мало было полезного за последний месяц - я участвовал в подготовке интенсива по работе с воронками конверсий для UX-специалистов. И это неспроста, ведь мы ищем UX-стажера на внешние и внутренние проекты. А когда стажер действительно подходит компании? Когда он обучается на кейсах компании. Поэтому вместе с UX Boost мы вместе готовили интенсив максимально набивая в него кейсы LAF24 и те подходы к проектировани и аналитике, которые мы используем. С учетом моей любви к структурности, интенсив получился весьма методологичным. В конце команда даже сокрушалась, что в нём мало воды.

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

Занятия начнутся 17 ноября и будут идти по субботам и вторникам. Группа будет небольшая (12 человек), преподавателей будет двое: Глеб Долгов (Head of Product Design в БигДатаТехнологии, работал в Рамблере и Mail.ru) и Иван Серебренников (Chief UX officer в DSX.uk, работал в EPAM и SEMrush.com, 15+ лет опыта в дизайне, автор канала UX Boost). Я принимаю участие с точки зрения ответа на вопросы и передаче обратной связи.

В программе:
1. Бизнес, бизнес модель и место сайта в бизнес-модели
2. Выбор метрика для бизнеса, типы бизнеса и на что может влиять дизайнер
3. Путь пользователя, основные типы сайтов, цели и триггеры
4. Как заставить разработчиков поставить цели в Метрику и их обработать
5. Визуализация воронки и конверсии, формулы и работа с таблицами
6. Линейные зависимости и сходящиеся воронки
7. Сегментирование по ролям, источникам, запросам и т.д., сводные таблицы
8. Интерпретация данных и ошибки в них

Данный интенсив - один из планируемых в линейке обучения для UX-специалистов на реальных кейсах и методологиях. Курс будет полезен не только специалистам по работе с интерфейсами, но и дизайнерам, начинающим маркетологам, ecommerce-менеджерами и продактам в ритейле. Инжойте https://uxboost.school/

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

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

Любой продакт встречается с критикой. Постоянно. Это его перманентное состояние. Вас критикует команда, вас критикует начальство, вас критикует продажники и маркетологи, ключевые клиенты, партнеры, конкуренты и уборщица баба Галя. На вас давят, пытаются манипулировать критикой, угрожать и так далее.

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

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

Вот открыли вы, скажем, магазин. А потом в один прекрасный момент в туалете для клиентов уборщица увидит, извините, дерьмо в раковине (реальный кейс, к сожалению). Не очень приятно вам, как владельцу магазина, так и другим клиентам, которые, не дай бог, это увидят. Перформанс красноречивый, но качество магазина от этого не изменится, т.к. неясно, что послужило причиной данной аллегории.

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

На самом деле в положительных отзывах нет никакой полезной информации для улучшения продукта. Информация есть только в критике.

Да, и еще одна важная новость. Рекламы курсов здесь больше нет и не будет. Их стало уже столько, что деваться некуда. Все предыдущие я выпилил из канала (кроме тех, в которых принимаю участие, уж извините).

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

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

Конечно же, эти аксиомы могут быть выбраны "неверно" в том значении, что в ходе построения доказательств мы найдем истинное суждение, опровергающее исходные посылки. Тогда дерево наших рассуждений отбрасывает ветви, растущие из неправильных мест. Ну, как при доказательстве от противного в школьном курсе тригонометрии ("Предположим, что это не так, тогда...").

С другой же стороны, наши рассуждения могут привести к парадоксам, т.е. истинным ситуациям, для которых нет логического объяснения в рамках выбранной теории. Например, как экономическая теория рационального выбора Адама Смита дошла до своих пределов в виде новых теорий иррационального выбора, представленных в трудах Ричарда Тайлера, Даниэля Канемана и Вернона Смита.

Я использовал фразу "дойти до предела", т.к. она важна для понимания, что у любой системы рассуждений есть свои границы. Другими словами, любая формальная теория либо включает в себя ложные высказывания (является противоречивой), либо содержит парадоксы (является неполной). Парадокс здесь - это некое высказывание, которое нельзя ни доказать, ни опровергнуть в рамках данной формальной теории. Для того, чтобы разрешить парадокс, необходима более сильная теория, включающая в себя первую плюс набор новых аксиом. Этот как создание Agile Манифеста, который положил основу для разрешения проблем, связанных со скоростью разработки, введя в теорию проектного управления четыре аксиомы приоритезации.

Существование таких границ в системах рассуждений доказал Курт Гедель чуть менее века назад. Любая теория имеет свои границы, которые можно расширить другой теорией. Многие думают, что мастерство применения инструментов, моделей или практик заключается в том, что вы знаете, когда их нужно применять, чтобы они работали. Это не так. Мастерство заключается в знании границ, после которых они перестают работать.

Начну свой рассказ с выделения аксиом.

Аксиома первая. Цель любого бизнеса - захватить большую долю рынка.

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

Аксиома вторая. Форма любого бизнеса определяется его миссией.

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

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

Например, текущая миссия Microsoft звучит как "Microsoft – технологическая компания, задача которой – дать возможность каждому человеку и каждой организации на планете достичь большего. Наша стратегия состоит в том, чтобы создавать лучшие в своем классе платформы и сервисы производительности для интеллектуального облака и intelligence edge, наполненного искусственным интеллектом." Это отличается от сформулированного им в 2006 году послания "Наша миссия – помочь людям и бизнесам по всему миру осознать свой потенциал. Достичь этой цели нам поможет технология, которая изменит то, как люди работают, играют и общаются.". И, уж тем более, от старого "Компьютер на каждый стол и в каждый дом.".

Именно миссия, которой предшествует некоторая идея, является фактором, определяющим форму бизнеса. Если ваша миссия - открыть ларек с шавермой, у вас будут одни границы, в рамках которых вы реализуете свой потенциал. Если ваша миссия состоит в том, чтобы стать "Life Style Banking" компанией, как Тинькофф, или компанией, решающей городские транспортные проблемы, как Uber, то и коридор ваших возможностей совершенно другой. Ваш майндсет становится совершенно другим, что влечет за собой смену фокуса, приоритетов и стратегии развития. Старая формула "Думай иначе" не прекратит быть актуальной никогда.