🔬💰🗺 #Полезное #Нельзя_просто_так_оценить_рынок

Для чего считать объём рынка?

На этой неделе я совершенно случайно наткнулся на замечательное видео одной из лекций школы Яндекса по управлению продуктами. 👤Александр Скурихин из ФРИИ делится собственным опытом оценки рынка для стартапов.

Мне эта лекция помогла связать в единую картину всякие PAM, TAM, SAM, SOM с Hype Cycles от Gartner и кривой проникновения инноваций. Стоит заметить, что Александр использует немного другие расшифровки объёмов рынка. Я знаю и много где встречал такие.

Ещё одним приятным моментом стал совет учитывать сегментированность рынка, которую я люблю смотреть в отчётах Mordor Intelligence (не думаю, что к ним имеют отношение Саурон или Саруман). В них отдельная диаграмма есть для этого.

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

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

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

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

💡🎬 #Интересный_кейс #Кто_ничего_не_умеет_тот_учит

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

Так вот, в этот раз я предложил проекты из сферы кинематографии. В голову пришёл продукт для демократизации процесса съёмок фильмов и сериалов: гибрид Steam, ClickUp, Miro и Slack.

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

Интересно то, что в самом начале курса у меня состоялся разговор с руководителем продюсерской компании, в котором я спрашивал о существующих проблемах и сложностях на всех этапах продакшена. Выяснилось, что основная нервотрёпка происходит при координации кучи разных людей и компаний. У каждой свои средства общения, а внедрение какого-то общего канала может быть запрещено службой безопасности. Вот и приходится одним писать в WhatsApp, другим в Telegram, третьим на почту, а четвёртым в Skype. Да и зафиксированных лучших практик по съёмочному процессу тоже ему не известно. По его словам, каждая крупная студия развивает свои собственные процессы, основывающиеся на общих принципах вертикального рынка. А я очень рассчитывал для курса получить наводку на какой-нибудь ITIL из мира кино ☹️

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

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

#Книги #JTBD

Вот уже две недели я читаю книги по JTBD, которые мне приехали в бумажном виде из Amazon. Общая картина начинает вырисовываться.

Пока мне кажется, что Jobs to be done - это больше название подхода к инновационной деятельности (аналог Agile в разработке ПО). Что 👤Кристенсен, что 👤Ульвик, явно указывают на связь процессов инновационного развития с контекстом работ, на которые эти инновации "нанимают". Отчётливо видно, что в книгах пытаются донести мысль о важности контекста выполнения работ: функционального, эмоционального, социального.

Пока мне недостаточно сведений, чтобы определить хронологию возникновению JTBD, но концептуально ситуация такая:
🔹в 80-х годах Ульвик начинает исследовать инновационные компании и оказывать консультационные услуги (а товарищ в IBM до этого работал, между прочим);
🔹в 99-м году Ульвик переименовывает свою компанию в Strategyn (небезызвестный) и публично называет свою методику Outcome Driven Innovation (ODI);
🔹в середине 90-х годов 👤Боб Моэста также начинает активно исследовать инновации и "втягивает" в это Клейтона Кристенсена;
🔹в 99 Ульвик презентует в HBS свой ODI для Кристенсена и его коллег;
🔹а дальше всё самое интересное, которое от меня пока скрыто.

Странно, но книга Моэсты на Amazon вышла только в 2020 году, а на его сайте рекламируется книга Кристенсена, в авторах которой Боба нет.

Как со всем этим связан 👤Клемент я пока не понимаю, но 👤Калбах, судя по всему, пытается в своей книге навести порядок в мире JTBD. Его книга реально крутая! Считаю, что её нужно читать последней.

Теперь буду каждую неделю постить обновления моего понимания.

#Полезное #Software

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

Что можно отметить:
🔸хорошие визуализации взаимосвязей процесса UR и использующихся инструментов;
🔸описываются методологические подходы работы с инструментами;
🔸куча примеров самих инструментов.

Одну из картинок не могу удержаться не приложить 😏

#книги #JTBD

Замечательно у меня получилось каждую неделю делиться новыми знаниями по JTBD...

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

Нашёл краткое содержание книги Кристенсена, так там только одна картинка, которую я и прикладываю. Вот именно так и выглядит JTBD 🤪

Начинаю понимать, из-за чего в этом направлении столько инфоцыган. Последняя надежда на 👤Калбаха. У него и картинки цветные, и таблиц с графиками много😁

Оценки книг:
🔸Кристенсен - 7/10 (Её можно читать первой и не пожалеть);
🔸Ульвик - 6/10 (есть описание подхода Outcome Driven Innovation, который хоть как-то детализирует JTBD);
🔸Клемент - 7/10 (есть описание подхода System Of Progress, который на PDCA основан, и двух вариантов JTBD - as Activities, as Progress).

А ещё забавно, что Клемент в описании значимых личностей, развивающих JTBD, всячески старается не упоминать Кристенсена и Ульвика, но на них активно ссылается и модели показывает. Конфликт, видимо, межличностный 🤨

🖥 💾 👥 #Полезное #Software

Сегодня у меня была очередная попытка найти что-то интересное из мира User research. Как выяснилось, не так-то это просто. Medium за последний месяц ничего интересного не дал, подписки в Feedly тоже. Пришлось рандомно гуглить.

Выяснилось, что есть компания User Interviews, которая уже второй год делает небольшие исследования. В феврале они выкатили 🗺 The 2020 UX Research Tools Map. И там даже многое понятно.

🔗Ссылка на карту

Дополнительно у них ещё есть ежегодный отчёт о состоянии сферы UR: 📑The State of User Research 2021 Report. Про Россию там ничего нет, но посмотреть интересно. В основном там соц. дем, но есть и много другого, например, про популярные инструменты.

🛑Спойлер:
🔹для рекрутинга из собственной базы 30% респондентов используют Calendly;
🔹59% проводят сессии в Zoom;
🔹46% делают опросы в Google Forms;
🔹81% хранят результаты в Excel (специальный софт начинается от 10% (DoveTail) и ниже).

🔗Ссылка на отчёт

Картинку с картой инструментов прилагаю 😎

🗓🐕 #PM #Пёс

Сегодня, ровно 90 лет назад, 👤Neil H. McElroy написал письмо своему руководителю с просьбой учредить новую должность “The Brand Man”.
Произошло это в компании Procter&Gamble, которую мы, по сути, можем благодарить за появление профессии менеджера продукта.

Поздравляю всех продактов с профессиональным праздником 🥳

Краткую историческую справку можно получить в статье.

#книги #JTBD

На прошлой неделе я закончил читать "The Jobs to be Done playbook" от 👤 Джима Калбаха. Книга полностью оправдала мои ожидания. Джим взял и объединил в одной книге полезные техники JTBD. Но не просто, а ещё с указанием авторов, ссылок на первоисточники и личного мнения. Даже историческая справка мне понравилась больше, чем в других книгах. Ну и перечень лиц на задней обложке внушает...

На просторах интернета нашёл иллюстрации из этой книги.

Для себя особо отметил следующие вещи:
🔸таблица с различными определениями JTBD;
🔸концепция увеличения ценности через related jobs;
🔸шаблон описания контекста JTBD;
🔸модель уровней абстракции основной job;
🔸модель "четырёх сил прогресса";
🔸прямая связь JTBD и GDD Алана Купера (после чтения "The Face" в мой обиход вошло "целеориентированное проектирование");
🔸Hypothesis Progression Framework для формулирования гипотез;
🔸Job Atlas, который я считаю недоделанной CJM.

Моё общее понимание JTBD не так уж сильно расходилось с "истиной". Джим тоже считает, что самый проработанный подход к работе с JTBD у Ульвика, причём сам он является именно сторонником Jobs-as-activities. При этом, концепция Jobs-as-Progress также им используется в рамках изучения контекста задач и потребностей потребителей.

Получается, можно вокруг ODI выстроить дополнительные "силы прогресса", а также прочие aspirations, и получить комплексный подход к изучению jobs. Однако, вторая часть ODI требует огромных затрат на качественное проведение экспериментов... У Джима, например, не получилось нормально всё сделать (как самому, так и c менторством Strategyn). Как-то эту пугает 🤨

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

👨🏻‍🔧⚙️🔎👥 #Полезное #Ops_i_did_it_again

Масштабирование процесса пользовательских исследований

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

Должен предупредить, что в их разделе Resources можно залипнуть надолго, потому как там куча ссылок на всякие интересные штуки (некоторые собираются сообществом в AirTable). Особенно хочу выделить имеющуюся ReOps Map. В неё сведены ключевые задачи как самого ReOps, так и смежных областей пользовательских исследований. Прям, интересно было поизучать. На момент публикации в карту включены области:
🔸Governance;
🔸Tools;
🔸Knowledge management;
🔸Internal Communications;
🔸Research Spaces;
🔸Capability and opportunity;
🔸Guides and templates;
🔸Event management;
🔸Recruitment;
🔸Asset management;
🔸ResearchOps;
🔸Budget management;
🔸Team building/care.

Модно сейчас всякие XOps штуки предлагать, но тут я смысл в этом могу понять.

#Software #Yet_another_map

Компания User Interviews выпустила свою ежегодную карту инструментов для UX Research. Совсем недавно я постил карту 2020 года, а тут уже подоспела новая.

В этот раз авторы сократили количество инструментов со 137 до 94. Должен отметить, что заморочились ребятки капитально. Там одна легенда так продумана, что её чуть ли не интереснее изучать, чем сами категории инструментов.

Отметил для себя несколько прикольных инструментов:
🔹Maze - стильная платформа для сбора инсайтов;
🔹Vowel - конференции с транскрайбом и кучей плюшек;
🔹EnjoyHQ - говорят, что на этом можно построить Enterprise ResearchOps;
🔹MAXQDA - если вы любитель комплексных CASE-средств, то эта штука явно для вас 😁

PDF-версия карты.

#Полезное #Storytelling

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

Чтобы не быть голословным приведу в пример нестареющий труд 👤Эрика Берна "Игры, в которые играют люди. Люди, которые играют в игры." На примере трансактного анализа Эрик показывает типичные сценарии, которым в жизни может следовать человек. Чаще всего эти сценарии негативно на него влияют, поэтому задача психолога привести пациента к осознанию этого факта, а в дальнейшем помочь ему захотеть изменить ситуацию. Книга очень сильно сломала моё самомнение, так что читать советую подготовленными.

Ещё один пример, это "Сказкотерапия". Сказки, по сути, отражают базовые паттерны человеческой психики, как и любые другие истории. В указанной выше статье явно сказано: "Исследователь мифологии Кэмпбелл говорил, что в затруднительной ситуации важно просто подобрать правильную сказку, с помощью которой вы сможете найти выход и справиться со стоящими перед вами задачами". Утверждение дискуссионное, но часть правды в этом есть, особенно если учитывать мою ненависть к сегодняшнему кинематографу, который ничего нового уже придумать не может, а лишь переснимает старое на новый лад (да, Дисней? 🤨). Значит новых интересных проблем у людей нет... все старые и известные.

Если вы когда-то читали, например, "Путешествие писателя: Мифологические структуры в литературе и кино" (👤Кристофер Воглер), то помните много примеров построения историй на базовых сюжетных арках. Также и у 👤Роберта Макки с его "Историей на миллион". Получается, что есть стандартные подходы к формированию сценарной основы повествования, на которые можно опираться. Все перечислять не буду, но про 👤Джона Труби не рассказать не могу. Его подход очень многие критикуют (в том числе Макки), но я просто хочу показать ту его часть, которая мне кажется полезной. В его книге "Анатомия истории: 22 шага к созданию успешного сценария" даётся, по сути, пошаговое руководство по написанию сценария. Кажется, что именно этот конвеерный подход и раздражает, но если воспринимать это как фреймворк, то ситуация меняется.

Для меня 22 шага оказались перебором, а вот модель попроще очень удачно вписалась в моё мировоззрение. В сокращенном варианте Джон предлагает 7 шагов истории:
1) слабость/нужда;
2) стремление;
3) противник;
4) план;
5) схватка;
6) прозрение;
7) новое равновесие.

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

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

Если присмотреться, тут даже видна последовательность действий при осуществлении стандартной продажи...

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

В качестве классификатора сюжетов могу предложить 36 сюжетов Польти.

Выглядит логично. Что думаете?

UPD: Забыл добавить ссылку на рекламу, в которой можно все 7 шагов истории найти.

🔍⚙️#ResearchOps #На_чужих_ошибках #Полезное

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

Причём явно отмечается, что из 8 основных направлений ResearchOps им пока удалось поразбираться только с 4-мя:
🔸Scope;
🔸Recruitment & Administrative;
🔸Data & Knowledge Management
🔸Tools & Infrastructure.

В статье есть интересные схемы, которые можно трактовать как "as-is" и "to-be", но с допущениями, конечно.

В качестве репозитория результатов был выбран стек Jira+Confluence, что, как минимум, интересно, а, как максимум, частично переиспользуемо.

🔗Ссылка на статью

И вот мне стало интересно, а есть ли ещё опыт использования Atlassian в таких делах... Оказывается, что глава "global team delivering Research Operations" в Atlassian в следующем году планирует выпустить книгу Research At Scale: the Research Operations Handbook. Там будет целых 24 главы, 5-я из которых мне очень интересна (Chapter 5: When to Operationalize: A Maturity Map). Основная часть книги весьма полно покрывает основные направления:
🔹Chapter 7: Participant Recruitment;
🔹Chapter 8: Data Governance;
🔹Chapter 9: Knowledge Management;
🔹Chapter 10: Research Spaces;
🔹Chapter 11: Guidelines and Templates;
🔹Chapter 12: Tools and Technology–Implementation and Management;
🔹Chapter 13: Finances: Getting the Money Right;
🔹Chapter 14: Capability and Opportunity;
🔹Chapter 15: Impact and Engagement;
🔹Chapter 16: Event Management;
🔹Chapter 17: Team Care.

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

🎙🕵🏻‍♀️ #Эксперт #Полезное #Чужая_трава_зеленее
Вчера вышел очередной подкаст от User Interviews. На этот раз гостем была 👤Amy Chess, UX Researcher в Amazon. Полезно послушать про чужой опыт проведения интервью, особенно от представителей больших компаний. Для справки, Amy активно пропагандирует исследования в подразделениях компании, разрабатывает методологии и специализируется на техниках сбора результатов качественных исследований.

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

Как всегда, есть текстовая и аудиоверсия.
🔗Ссылка

🎣 🧭 🔎 #Полезное #Вот_в_чём_вопрос💀

Обнаружил для себя очередной фреймворк для продуктовых исследований. Выглядит нормально. Называется 3W3 (три вопроса Why, Who, What на трёх уровнях). Если в работе используются "5 Why" или "4W1H", то смело можно пробовать использовать их совместно. Картинка всё прекрасно поясняет, но я кратко всё равно расскажу.

Начинается всё с главного вопроса - Why. Важно понять, почему вообще стоит решать выбранную проблему. Может быть она настолько незначительна в рамках CJM, что пользователи спокойно с ней живут и не жалуются. Три уровня для этого вопроса подразумевают описание:
🔸реальной проблемы и обоснования необходимости её решения (просто why);
🔸обоснования выбранного момента выхода на рынок - почему проблему нужно решать именно сейчас (why-now);
🔸обоснования выбора нас, как разработчика решения, - что в нас уникального и что нам даст решение (why-us).

Второй вопрос - Who. В нём скрыты целевые аудитории. Если мы делаем что-то для всех, то, в итоге, мы делает это ни для кого. Тут в пору сказать, что Customer, Client, User и Buyer могут буть совершенно разными людьми. В статье приводится пример со стримингом, которым пользуются дети, а покупают родители. 👤Роберту Фитцпатрику привет 🙂
Три уровня для этого вопроса подразумевают описание:
🔹основных пользователей и покупателей (просто who);
🔹stakeholders, которые влияют на основных пользователей и покупателей своим мнением и пожеланиями (who-else);
🔹тех, кого мы точно не считаем целевой аудиторией и НИЧЕГО ДЕЛАТЬ ДЛЯ НИХ НЕ БУДЕМ (who-not).

Третий вопрос - What. Лишь на третьем месте описание идеи нашего решения выбранной проблемы. Зная целевые аудитории и их проблемы, можно генерировать множество идей их решения, которые потом проверять. Три уровня для этого вопроса подразумевают описание:
♦️возможных решений выявленных проблем (просто what);
♦️выгод от каждого из решений (помню вопрос "и что?" ещё от 🎸Metallica - so-what);
♦️дальнейших действий (now-what).

Ненавистники разных канвасов могут аккуратно попробовать использовать, мало ли...

🔗Ссылка