Бесплатный фрагмент - Ешь, молись, создавай ценность

Посвящается всем, кто когда-либо работал со мной рядом, и всем, кто верит: магия творится там, где заклинания превращаются в инструменты.

Предисловие

Вы когда-нибудь сталкивались с ситуацией, когда всё делали правильно, но в итоге получили совсем не ту реакцию, на которую рассчитывали? Или тратили кучу времени на разработку фичи, которая в итоге оказалась никому не нужна? А может, вы получали в работу проект с горой непонятных задач и морем нереализованных обещаний и думали: «И что мне с этим делать?»

Я сталкивался с такими ситуациями. И не раз.

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

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

Я задавал себе эти вопросы много лет.

За моей спиной — долгий путь. Я начинал как дизайнер наружной рекламы. Потом был 3D-художником, арт-директором и руководителем проектов. К управлению IT-продуктами я пришёл через рекламную индустрию, геймдев и собственные попытки бизнеса и видел множество провалов. Зато каждый такой провал учил меня тому, как точно не надо делать. Самые важные знания о продуктах и управлении ими я вынес не из учебников и не из успешных кейсов с конференций. Я вынес их из личного — и далеко не всегда успешного опыта. Из ситуаций, когда казалось, что всё идёт не так, и всё, что у меня есть, — это понимание того, что я чего-то не понимаю. Но вот что в итоге я осознал: управление проектами ещё не значит создание ценности. Ответственность за продукт — это не про набор своевременно выполненных задач, это умение ответить на вопрос «принесёт ли это пользу?».

Как я перестал писать инструкции и начал книгу

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

И вот однажды, в паузе между проектами, я решил: почему бы не воспользоваться моментом и не собрать всё, что я узнал об управлении продуктом, в один структурированный мануал? Но только я начал набрасывать структуру, как понял, что опыт, полученный из всех этих знаний, можно превратить в нечто большее, чем инструкция только для себя. Так появилась идея написать книгу. Создать учебное пособие без заумствований и воды, которое проведёт вас за руку от первых вопросов до первых результатов.

Я пишу эту книгу как Project Manager, который понял: управлять проектами ещё не значит создавать ценность. Я не был продактом с первого дня. Я пришёл к этому через проекты, через команды, через ошибки и через необходимость.

Что вы получите, прочитав эту книгу

1. Перестанете путать управление проектами и управление продуктом.

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

3. Сможете за пару недель внедрить подходы, которые помогают не делать то, что никому не нужно.

4. Начнёте спокойно анализировать любые неудачи и находить в них то самое зерно, которого не хватало для успеха.

Если вы сейчас чувствуете то же, что когда-то чувствовал я — что есть какой-то другой уровень, но вы не знаете, как на него зайти, — эта книга для вас.

Эта книга не заменит вам многомесячный курс по Product Manager-у и не подарит сертификата на стену. Но если вам нужна не «корочка», а рабочие инструменты, которые можно взять и применить завтра утром, — вы по адресу. Здесь — выжимка того, что реально работает.

В этой книге вы не найдёте историй успеха. И вот почему.

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

Формулы успеха не существует, по крайней мере одной для всех случаев. Успех всегда складывается из множества факторов, решений и действий, которые в конкретной ситуации привели к лучшему результату. Моя книга — не про гарантии. Она про то, как анализировать эти факторы, и даёт простые инструменты, чтобы принимать правильные решения здесь и сейчас.

Для кого она

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

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

АНКЕТА: ЭТА КНИГА ДЛЯ ВАС?

Сомневаетесь, стоит ли читать? Ответьте на пару вопросов. Это займёт минуту. И не бойтесь — это не экзамен на профпригодность. Просто способ понять, насколько материал вам откликнется.

1. Вы чувствуете, что управление проектами — это только половина дела, а остальное ускользает? ☐ Да ☐ Нет

2. Вы тратили месяцы на фичу, которая в итоге оказалась никому не нужна? ☐ Да ☐ Нет

3 Вы устали принимать решения на глаз, потому что данных нет, а времени разбираться — тоже? ☐ Да ☐ Нет

4. Вы слышали слова вроде «RICE», «CustDev» и «JTBD», но так и не поняли, как их применять на практике? ☐ Да ☐ Нет

Если вы ответили «да» хотя бы на 2 вопроса — вы взяли правильную книгу. Вы уже нащупали ту грань, где управление проектами перерастает в управление продуктом. И вам нужны инструменты, чтобы перейти на новый уровень.

Если ответили «да» только на 1 вопрос — возможно, вам стоит начать с введения и посмотреть, зацепит ли. Некоторые темы покажутся знакомыми, но, возможно, именно в них вы найдёте недостающий пазл.

Если не ответили «да» ни разу — вы либо уже всё умеете, либо вам нужна другая книга. Ничего страшного. Честность — лучшее, что можно сделать перед чтением.

Остались? Тогда едем дальше.

Как её читать

Я не пытался запихнуть в эту книгу абсолютно всё. Объём — это скучно, а зачастую и бесполезно. Как метко подметили в отечественном автопроме: «We can, but why?».

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

Берите то, что нужно именно вам. Пропускайте то, что уже знаете. Возвращайтесь к тому, что пригодится позже. Если вам не интересны мои истории — не читайте их, сразу переходите к заданиям или следующей главе.

Я не обещаю, что читать будет легко и захватывающе. Я знаю, что слова вроде «ДжейТиБиДи», «КастДев», «Дата-Драйвен» звучат как заклинания на очередной бизнес-коуч-промывке мозгов. Но к концу этой книги все загадочные термины превратятся в простой набор действий, которые помогут спасти не один продукт.

А теперь возьмите тетрадь и запишите одну свою главную проблему в продукте. К концу книги у вас будет план её решения.

Поехали.

Как построена эта книга

Чтобы вы быстро привыкли и не тратили время на поиск нужного, каждая глава этой книги устроена одинаково.

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

2. Артефакты. Перечень документов, которые продакт создаёт на этом этапе. Я объясняю, зачем каждый из них нужен и как они связаны между собой.

3. Практическое задание. Задание, необходимое для закрепления теории прочитанного раздела. Вы сможете применить теорию на сквозном примере.

В конце книги вас ждут:

• Глоссарий — все термины в одном месте.

• Реестр артефактов — чтобы видеть полную картину документов на каждом этапе работы.

• Решения всех практических заданий — для самопроверки.

Об артефактах

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

Артефакты помогают:

• Структурировать мысли и не упустить важное.

• Доносить идеи до команды и стейкхолдеров на понятном языке.

• Фиксировать решения, чтобы к ним можно было вернуться через месяцы.

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

Практические задания на сквозном примере

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

Что такое Clever Notes?

Clever Notes — это мобильное приложение (доступно на iOS и Android), которое помогает пользователям быстро записывать идеи и хранить их в структурированном виде.

Ключевые особенности приложения Clever Notes:

• Бесплатный тариф с базовым функционалом (текстовые заметки, поиск, теги).

• Премиум-подписка ($5 в месяц или $50 в год) за офлайн-доступ, автоматический теггинг, расширенное хранилище и совместный доступ.

• Целевая аудитория — студенты, фрилансеры, творческие профессионалы, которые ведут активную цифровую жизнь.

Все цифры в моих заданиях — удержание, конверсия, LTV, CAC — взяты не из воздуха. Они основаны на реальных бенчмарках приложений из категории «Продуктивность» (App Annie, Sensor Tower) и адаптированы под наш продукт. Так что тренироваться вы будете на данных, которые максимально приближены к жизни.

Вы будете продакт-менеджером Clever Notes. Вы будете исследовать пользователей, приоритизировать фичи, строить роадмап, запускать A/B-тесты, считать юнит-экономику и общаться со стейкхолдерами. В общем, проживёте полноценный рабочий день продакта — или даже недельку с небольшим.

Эти задания необходимы для того, чтобы вы набили руку до того, как столкнётесь с похожими вызовами в реальной работе. И да, вы можете мысленно заменить Clever Notes на свой продукт — механики останутся теми же.

Введение. Project Manager vs Product Manager

---

Project Manager и Product Manager — две разные роли, которые часто путают. Но разница между ними — как между капитаном корабля и штурманом.

Project Manager отвечает на вопрос «Как?». Как мы сделаем это в срок? Как распределим ресурсы? Как минимизируем риски? Его зона ответственности — процесс, сроки, бюджет, команда. Он следит, чтобы корабль не тонул и двигался по карте.

Product Manager отвечает на вопрос «Зачем?». Зачем мы это делаем? Какую проблему пользователя решаем? Какой бизнес-результат получим? Его зона ответственности — видение, стратегия, метрики, ценность для пользователя. Он решает, куда плыть и какой груз везти.

Идеальный продакт умеет и то, и другое. Но если вы чувствуете, что вас засасывает в бесконечные «как», а «зачем» остаётся за бортом — эта книга для вас. Мы будем учиться смотреть на продукт глазами пользователя и бизнеса, а не только через призму таск-трекера и дедлайнов.

Две роли: чёткое разделение

Ключевая идея, которую вы должны прочувствовать:

• Project Manager спрашивает: «Сделаем ли мы эту фичу за две недели?».

• Product Manager спрашивает: «Принесёт ли эта фича дополнительную выручку и стоит ли она двух недель работы?».

Глава 1. Видение и стратегия продукта

---

От автора

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

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

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

И вот я защищаю свой проект. Конечно, я начал не с того — не с бизнес-плана и не с маркетинговых исследований. Я начал рассказывать о том, как «наши космические корабли бороздят просторы вселенной, про великие открытия и эпические сражения». Я был вдохновлён своей идеей и не видел преград. Но инвесторам нужна была совсем другая история. Они выдержали это испытание с достоинством, а потом задали три простых вопроса, которые поставили меня в тупик:

— Для кого конкретно эта игра — какая аудитория?

— Какой будет модель распространения: freemium или free-to-play?

— На какой рынок будет выход: Россия или сразу на World-wide?

Я и понятия не имел, что озвученные вопросы сейчас имеют какое-то значение. Мне казалось, что это само собой разумеющиеся вещи, которые обычно обсуждаются уже после полного завершения проекта. Я не знал, что им ответить, потому что меня тащило вперёд моё неутомимое чувство восторга от собственной идеи. Я уже видел, как пользователь проходит игру, как он ставит нам пять звёзд в отзывах и как приобретает внутренние покупки, чтобы продвинуться дальше в игре. А тут — «На какой рынок вначале?»

Я честно признался инвесторам, что пока не думал об этом и что мой опыт больше подходит для тактических действий, а не для стратегии. На помощь пришёл мой коллега — генеральный директор студии, имевший намного больше коммерческого опыта. Он быстро набросал поверх моего выступления какой-то псевдомаркетинговой пыли, и температура в помещении быстро понизилась.

Несмотря на мой ступор, деньги мы получили. Я сразу приступил к найму команды и формированию структуры проекта. Но как вы думаете, пошёл ли я тогда искать ответы на их вопросы? Конечно, нет. Я только переходил от линейной работы 3D-художника к полноценному управлению студией на правах учредителя и арт-директора. Меня больше заботило, как создать мою замечательную игру, чем вопрос, будет ли в неё вообще кто-то играть.

Сейчас я понимаю: у меня не было видения. Была мечта. А мечта без ответов на эти вопросы — это просто хобби с бюджетом. С тех пор я всегда начинаю с ответов на три вопроса: «Для кого?», «Зачем?» и «Что из этого получится?»

Видение продукта: почему без него вы просто играете в конструктор

Представьте, что вы заходите в комнату, где десять человек собирают один и тот же пазл. У каждого из них своё представление о том, что должно получиться на картинке. Один видит горы, другой — море, третий — космический корабль. И каждый уверен, что прав. Перед вами не команда. Перед вами хаос с претензией на порядок. Именно так будет выглядеть разработка продукта без видения.

Видение продукта (Product Vision) — это не список фич и не дизайн-макет. Это ответ на вопрос: «Каким мы хотим видеть мир благодаря нашему продукту через два-пять лет?» И этот ответ должен умещаться в одно-два предложения. Если вы не можете объяснить видение за тридцать секунд случайному соседу в очереди за кофе — оно не работает.

Шаблон, который действительно помогает:

«Для [целевая аудитория], у которого есть [проблема], наш продукт — это [решение]. В отличие от [конкуренты], он даёт [уникальное преимущество]».

Звучит вроде бы просто? А теперь попробуйте заполнить пропуски для своего продукта. Если у вас получилось связное предложение, которое не вызывает вопросов «а что это значит?» — вы на верном пути. Если вы зависли на первом же пункте — возвращайтесь к исследованиям, потому что вы ещё не знаете, для кого делаете продукт.

Пример из реальности:

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

Видите? Нет ни слова про технические характеристики, ни слова про API, ни слова про то, как мы это сделали. Есть только пользователь, его проблема, наше решение и наше отличие. Всё. Остальное — детали, которые не должны быть в видении.

От видения к измеримым целям: почему мечта без цифр — это просто мечта

Видение вдохновляет. Но одного вдохновения недостаточно для создания ценности. Если вы не можете ответить на вопрос «Мы приблизились к своему видению или нет?», то ваше видение — это просто красивая фраза на доске в офисе. Чтобы превратить его в стратегию, нужно добавить измеримые цели. И здесь к нам на помощь приходит OKR.

OKR (Objectives and Key Results) — это система, которая превращает ваше «мы хотим стать лучшим приложением для заметок» в «мы хотим увеличить удержание пользователей до 40% на седьмой день». Первое — это мечта. Второе — это цель, которую можно проверить.

Пример OKR для приложения Clever Notes:

• Objective: увеличить удержание пользователей.

• Key Result 1: достичь удержания D7 = 40% (это бенчмарк, который мы взяли из App Annie — там такие цифры у топовых приложений в категории «Продуктивность»).

• Key Result 2: снизить месячный отток (Churn) с 5% до 4%.

Почему это работает? Потому что теперь вы не просто «хотите сделать продукт лучше». Вы знаете, что конкретно нужно изменить, чтобы приблизиться к видению. И вы можете измерить, получилось у вас это или нет.

Стратегия: как выбрать путь, когда все дороги кажутся правильными

Видение отвечает на вопрос «куда мы идём?». Стратегия отвечает на вопрос «как мы туда придём?». Это не одно и то же. Можно знать, что ты хочешь покорить Эверест, но выбирать между маршрутом через южный склон и северным — это уже стратегия. И от этого выбора зависит, дойдёшь ты или замёрзнешь на полпути.

Стратегия продукта включает:

1. Целевой сегмент — кого мы обслуживаем в первую очередь. Потому что пытаться угодить всем — значит не угодить никому.

2. Дифференциаторы — что делает наш продукт уникальным. Не «мы лучше», а «мы другие в том, что важно для нашего пользователя».

3. Ключевые инициативы — три-пять крупных направлений на ближайший квартал или год. Не больше. Если у вас их десять — у вас нет стратегии, у вас есть список пожеланий.

4. Метрики — как мы поймём, что стратегия работает.

Четыре типа стратегий — вечная классика

Майкл Портер, человек, который придумал, как конкурировать, ещё когда интернет был роскошью. Он выделил четыре базовых типа стратегий, которые работают и в IT, и в производстве, и в доставке суши. Потому что конкуренция — это всегда про выбор.

1. Лидерство по издержкам

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

Пример: бюджетные аналоги дорогих приложений. Они не лучше — они дешевле. И этого достаточно для огромной аудитории.

2. Дифференциация

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

Пример: Clever Notes с офлайн-режимом и ИИ-теггингом. Конкуренты либо имеют офлайн, но без ИИ, либо имеют ИИ, но без офлайна. Мы — единственные, у кого есть и то, и другое.

3. Фокус

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

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

4. Гибридная стратегия

Вы сочетаете два подхода. Например, вы дёшевы и одновременно уникальны. Это сложно, но иногда работает.

Как выбрать стратегию, когда не знаешь, с чего начать

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

Алгоритм:

1. Изучите конкурентов. Что они делают? Где их слабые места? Где они уязвимы?

2. Изучите аудиторию. Какие проблемы они хотят решить? Что для них действительно важно? Что они ненавидят в текущих решениях?

3. Оцените свои ресурсы. Есть ли у вас бюджет на уникальную технологию? Можете ли вы конкурировать ценой? Есть ли у вас экспертиза, которой нет у других?

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

Пример стратегии для сервиса доставки суши:

1. Сегмент: офисные сотрудники в центре Москвы, ценящие скорость.

2. Дифференциатор: доставка за 15 минут или бесплатно.

3. Инициативы:

• оптимизировать кухню под топ-5 сетов;

• внедрить гео-трекинг курьеров;

• запустить подписку «Суши на неделю».

4. Метрики: доля повторных заказов через 7 дней, средний чек, время доставки.

Пример для Clever Notes:

Мы выбираем дифференциацию, потому что наш продукт предлагает уникальную комбинацию офлайн-доступа и автоматического теггинга. Конкуренты либо имеют офлайн, но без ИИ, либо имеют ИИ, но без офлайна. Мы — единственные, у кого есть и то, и другое.

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

От автора

Был у меня опыт управления одним игровым продуктом, когда я всерьёз взялся за исследование конкурентов. Я начал строить сравнительную матрицу, выписывал их сильные стороны и… вдруг испытал недоумение.

Некоторые игры были уникальны, но значительная их часть являлась просто клонами друг друга. С одинаковой механикой, одинаковой логикой игрового баланса, одинаковыми принципами монетизации. Отличались только графика, названия игр и цены на некоторые покупки внутри игры.

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

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

Их стратегия была проста и цинична: они наводняли рынок похожими продуктами с минимальными изменениями. Это был холодный расчёт, а не зоопарк клонов или банальное воровство. Они использовали каждую игру как полигон для тестирования гипотез: меняли названия, графику, баланс, монетизацию — и смотрели, что работает лучше. Победитель получал всё, а остальные отмирали, как рудиментарные конечности.

В игровой индустрии (и не только) такая стратегия называется «Learn-Fast, Scale-Up» — быстрое обучение и масштабирование. Это была вовсе не попытка захватить мир через клонирование, а способ провести масштабное A/B-тестирование на живом рынке. Запускаешь несколько версий, смотришь, какая «выстрелит», и вкладываешь все ресурсы в победителя. Пока конкуренты гадают, какая механика сработает, ты уже знаешь ответ.

Что я тогда понял и что впоследствии подтвердил опыт: для такой стратегии нужен солидный бюджет, который маленькая студия не потянет. За каждым подобным «клоном» стояла команда специалистов, маркетинговые бюджеты и месяцы отладки. В те времена не было нейросетей, которые рисовали бы графику и писали бы код за пару кликов — за каждым продуктом стояли люди.

Я посмотрел на весь этот «цирк с конями» и сказал себе: «Забудь. Сосредоточься на том сегменте, который у тебя есть». Мы сфокусировались на региональном рынке. Там конкуренция была куда меньше, а наш продукт выглядел вполне сильным.

Иногда лучшая стратегия — найти свою собственную площадку, где у тебя есть шанс победить. Но уметь выбирать стратегию так же важно, как и её иметь — об этом мы поговорим дальше.

Артефакты главы 1

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

1. Vision Statement (Заявление о видении) — документ из 1–2 предложений, фиксирующий целевое будущее.

2. OKR (Objectives and Key Results) — система целей и ключевых результатов.

3. Business Model Canvas (Lean Canvas) — одностраничная схема бизнес-модели.

Зачем они нужны:

1. Vision Statement — чтобы не забыть, для кого и зачем вы делаете продукт. Синхронизирует команду вокруг общей цели.

2. OKR — чтобы перевести видение в конкретные цифры, которые можно измерять. Без них видение остаётся мечтой.

3. Business Model Canvas — чтобы проверить экономическую жизнеспособность идеи и найти слабые места в бизнес-модели.

Как ими пользоваться:

1. Vision Statement — напишите до начала разработки. Повесьте на стену. Покажите команде. Если через полгода вы прочитаете его и не почувствуете, что двигались в этом направлении, — вы что-то делали не так.

2. OKR — формулируйте Objectives как качественные цели, Key Results — как количественные метрики. Обновляйте каждый квартал.

3. Business Model Canvas — заполните на старте проекта. Используйте как основу для обсуждения с инвесторами и командой. Она не должна быть идеальной. Она должна быть честной.

Заключение к главе 1: Видение без стратегии — мечта, стратегия без видения — хаос

Мы начали с видения — с того, ради чего мы просыпаемся по утрам и идём создавать продукты. А закончили стратегией — с тем, как именно мы туда придём. Я хотел бы, чтобы вы запомнили одну простую мысль:

Видение без стратегии — это просто мечта. А стратегия без видения — просто набор бессмысленных действий. Вместе они дают направление и план.

В моей истории про игру и инвесторов у меня было видение — вдохновляющее, яркое, но совершенно не проверенное реальностью. А стратегии не было вообще. Если бы я тогда ответил на три их вопроса — «Для кого?», «В каком формате?», «На какой рынок?» — я бы уже тогда начал строить не просто игру, а продукт.

Что делать прямо сейчас:

Ответьте себе на вопрос: «Каким я вижу свой продукт через два года?» Если ответ у вас есть — вы готовы двигаться дальше. Если нет — вернитесь к шаблону Vision Statement и не переходите к следующей главе, пока не сможете записать его на одной странице. Это самый важный шаг. Всё остальное — уже техника.

Куда идём дальше:

В следующей главе мы погрузимся в исследование пользователей. Потому что даже самое сильное видение и самая продуманная стратегия теряют смысл, если вы не понимаете, для кого вы всё это делаете. Видение говорит «куда», стратегия — «как». А исследования отвечают на вопрос «для кого». Без ответа на этот вопрос все ваши планы — просто игры с самим собой.

Практическое задание №1

Сформулируйте видение продукта для Clever Notes. Опишите целевую аудиторию, ключевую проблему, решение и главные метрики успеха.

Формат сдачи:

1. Vision (по шаблону выше).

2. Strategy (список из четырёх пунктов — сегмент, дифференциатор, три инициативы, две метрики).

3. (Бонус) Заполните Business Model Canvas для Clever Notes. Используйте шаблон из раздела с шаблонами в конце книги.

Глава 2. Исследование пользователей

---

От автора

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

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

Хоть тогда я не был гейм-дизайнером, я не мог не замечать, что наш продукт существенно отличается от конкурентов по многим аспектам в игровом балансе, особенно в росте ставок, суммах выплат и стоимости внутриигровых покупок. Я много играл в нашу игру и в игры конкурентов, отслеживал типовые приёмы визуализации и новые тренды в жанре. Мне казалось странным, что игры конкурентов в отношении игрового баланса были похожи одна на другую, а наша сильно отличалась от них. Даже в совершенно разных продуктах одного жанра, разработанных разными компаниями, соблюдались одинаковые требования к прогрессиям и экономике. Лично мне было очевидно, что с нашей игрой точно что-то не так.

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

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

Ситуация изменилась позже, когда в нашу команду пришел новый гейм-дизайнер и руководитель проекта. Он взял моё исследование в работу и перестроил игровой баланс. Реакция пользователей последовала незамедлительно, рейтинг игры сразу вырос.

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

Почему исследования — это не «поговорить с пользователями»

В учебниках пишут красиво: «Проведите CustDev-интервью, и вы узнаете всё о пользователях». На практике это часто превращается в «я поговорил с тремя друзьями, и они сказали, что моя идея крутая». А потом вы запускаете продукт, и никто не приходит. И вы удивлены.

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

CustDev (Customer Development) — это процесс выявления потребностей через интервью и наблюдения. Главный инструмент — глубинные интервью. Не анкеты, не опросы, не «отправьте ссылку в WhatsApp». А разговор один на один, где вы не задаёте вопросы, а ведёте диалог.

JTBD (Jobs To Be Done) — это подход, который помогает понять, какую «работу» пользователь «нанимает» продукт выполнить. Формулировка JTBD позволяет оторваться от фич и сфокусироваться на проблеме, которую пользователь решает.

Звучит сложно. На деле — проще некуда.

JTBD: как перестать думать о фичах и начать думать о проблемах

Вот формула, которая действительно работает:

«Когда [ситуация], я хочу [действие], чтобы [получить результат]».

Пример, который всё объясняет:

«Когда я жду опаздывающего друга в метро, я хочу быстро проверить соцсети, чтобы убить время и не скучать».

Заметили? Нет ни слова про приложение. Ни слова про интерфейс. Только ситуация, действие и результат. Это и есть JTBD. Это то, что пользователь на самом деле делает — не с вашим продуктом, а в своей жизни.

Теперь пример для Clever Notes:

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

Это не «я хочу офлайн-режим». Это «я хочу, чтобы мои заметки не исчезали, когда интернет пропадает». Разница огромная. В первом случае вы думаете о функции. Во втором — о проблеме.

Как увидеть проблему до того, как пользователь её сформулирует

JTBD — это мощный инструмент. Он помогает понять, какую «работу» пользователь «нанимает» продукт выполнить. Но есть одна проблема: пользователь часто не знает, как устроен его собственный бизнес. Он знает, что у него болит, но не всегда может объяснить, где именно в процессе возникает эта боль.

И здесь на помощь приходит описание бизнес-процессов. Это не про «давайте нарисуем 100 диаграмм в BPMN». Это про «давайте поймём, как на самом деле работает компания клиента».

Зачем продакту разбираться в бизнес-процессах

Когда вы работаете над B2B-продуктом, вы не можете просто сказать: «Мы сделаем красивый интерфейс и добавим отчёты». Вам нужно понять, как клиент зарабатывает деньги, как устроены его внутренние процессы, где он теряет время и деньги, и только потом предлагать решение.

Описание бизнес-процессов помогает:

1. Увидеть картину целиком. Вы перестаёте смотреть на продукт как на набор фич и начинаете видеть его как часть бизнес-системы клиента.

2. Найти корневую проблему. Пользователь может жаловаться на «медленную работу отчётов», а на самом деле проблема в том, что данные вводятся вручную и с ошибками.

3. Синхронизировать команду. Когда вы описываете процесс, вы создаёте общее понимание «как есть» и «как должно быть».

4. Общаться с заказчиком на его языке. Вы говорите не «мы добавим REST API», а «мы ускорим обработку заказов на 30%».

Как описывать бизнес-процессы (без фанатизма)

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

1. Начните с «как есть» (AS-IS)

Попросите пользователя или заказчика пройти по процессу шаг за шагом. Не задавайте общих вопросов. Спрашивайте конкретно:

• «Что вы делаете, когда получаете заказ?»

• «Кто участвует в этом процессе?»

• «Какие данные вы используете?»

• «Что происходит дальше?»

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

2. Найдите узкие места (pain points)

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

3. Нарисуйте простую схему

Не надо использовать BPMN. Просто нарисуйте блок-схему в Miro или даже на бумаге. Прямоугольники — это шаги процесса. Стрелки — это переходы. Красные кружки — это боли.

Покажите эту схему заказчику. Спросите: «Я правильно понял?». Если он скажет «да, но вот здесь ещё есть нюанс» — вы на верном пути.

4. Предложите «как должно быть» (TO-BE)

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

Покажите заказчику новую схему. Спросите: «Если мы сделаем так, станет ли вам легче?». Его реакция покажет, насколько ваша гипотеза верна.

Как это связано с JTBD

JTBD говорит о «работе», которую пользователь выполняет. Описание бизнес-процессов показывает, в каком контексте эта работа выполняется.

Например, JTBD может звучать так:

«Когда я получаю заказ от клиента, я хочу быстро проверить наличие товара на складе, чтобы не потерять продажу».

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

Главные правила интервью, которые вам не расскажут в учебниках

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

1. Не спрашивайте: «Вы бы купили?»

Люди врут, когда отвечают на гипотетические вопросы. Они хотят быть вежливыми. Они хотят вам понравиться. Они скажут «да», даже если в жизни никогда не купят. Поэтому не спрашивайте «купили бы». Спрашивайте: «Расскажите случай за последнюю неделю, когда вы решали эту проблему».

2. Спрашивайте о прошлом опыте

«Расскажите, как вы решали эту проблему вчера. Что вы делали? Что открывали? Какие приложения использовали? Что бесило больше всего?» Прошлое не врут. Гипотетическое будущее — врут всегда.

3. Ищите неприятности (frustrations)

Не ищите, что пользователю нравится. Ищите, что его бесит. Потому что то, что бесит, — это и есть возможность. Там, где он испытывает боль, вы можете принести облегчение.

4. Записывайте прямые цитаты

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

5. Не спрашивайте «почему»

Спросите «что случилось?» или «расскажите подробнее». «Почему» звучит как обвинение. Оно закрывает собеседника. «Расскажите» — открывает.

Как проверить, что вы не гадаете на кофейной гуще

Гипотеза — это не догадка. Это утверждение, которое можно проверить. И оно должно быть построено по шаблону:

«Мы считаем, что [наша идея] решит [проблему пользователя] и приведёт к [измеримому результату], потому что [наше предположение о причинах]».

Пример: «Мы считаем, что добавление офлайн-режима в мобильном приложении повысит удержание на D7 с 25% до 40% в течение двух месяцев, потому что 80% отвалившихся пользователей назвали отсутствие офлайн-доступа главной причиной ухода к конкурентам».

Видите? Есть идея, есть проблема, есть измеримый результат и есть причина, основанная на данных. Это гипотеза. Если у вас нет одного из этих элементов — у вас не гипотеза. У вас просто предположение.

Шаблон вопросов для интервью (который реально работает)

Не берите список из интернета. Сделайте свой. База, которую можно адаптировать под любой продукт:

1. Как вы сейчас решаете эту проблему? Пройдите шаг за шагом.

2. Что в этом процессе бесит вас больше всего?

3. Если бы вы могли изменить одно улучшение, чтобы это было?

4. Что заставило бы вас переключиться на новый инструмент? (цена, функция, опыт)

Opportunity Solution Tree: как не потеряться в инсайтах

Вы провели интервью. У вас куча цитат. Вы знаете, что болит у пользователей. И вы упираетесь в стену: «Я знаю проблему, но что с этим делать?». Здесь на помощь приходит «OST».

Opportunity Solution Tree (OST) — Это инструмент, который помогает связать пользовательские потребности с возможными решениями. Без него вы можете застрять на этапе «мы нашли проблему, но что с ней делать?».

Как строить OST:

1. Напишите проблему (то, что вы выявили в интервью).

2. Под ней напишите возможности — варианты того, как эту проблему можно решить.

3. Под каждой возможностью напишите решения — конкретные фичи или улучшения.

4. Выберите приоритетную возможность или решение.

Пример для Clever Notes:

1. Проблема: «Пользователи не могут работать без интернета».

2. Возможности: «Сделать офлайн-режим», «Разрешить кеширование заметок», «Добавить автосохранение».

3. Решения: для офлайн-режима: «Синхронизировать заметки при подключении к интернету», «Хранить последние 50 заметок локально». Для кеширования: «Автоматически сохранять копию заметки на устройство».

4. Приоритет: «Офлайн-режим — самый высокий приоритет, потому что решает главную боль 80% отвалившихся».

Assumption Mapping: как не потратить ресурсы на фичу, которая не сработает

Assumption Mapping — это инструмент для выявления и проверки рисковых предположений в гипотезе. Он помогает понять, что нужно проверить в первую очередь, чтобы не тратить ресурсы на фичи, которые могут не сработать.

Как использовать:

1. Запишите гипотезу.

2. Выпишите все предположения, на которых она построена.

3. Оцените каждое предположение по двум осям:

• Важность для успеха (насколько это предположение критично для успеха гипотезы).

• Уверенность (насколько вы уверены, что это предположение верно).

4. Сфокусируйтесь на проверке предположений с высокой важностью и низкой уверенностью — это самые рискованные точки.

Обе оси оцениваются по десятибалльной шкале, где 10 — это максимальная важность или абсолютная уверенность, а 1 — минимальная. Здесь нет строгих формул — вы ставите оценки так, как чувствуете, исходя из своего опыта, данных и здравого смысла. Главное — чтобы шкала была единой для всех предположений. Один человек может ставить 8 там, где другой поставит 6, и это нормально. Важно не абсолютное значение, а относительное: какие предположения оказались самыми рискованными по сравнению с другими. Это не точная математика, а инструмент для расстановки приоритетов в проверке гипотез.

Пример Assumption Mapping для Clever Notes

Цифры в таблице — это не истина в последней инстанции, а ваша рабочая оценка. Можете менять их, если появляются новые данные или меняется контекст. Главное — не пытаться угадать «правильную» цифру, а честно ответить себе на вопрос: «Насколько я уверен в этом предположении и насколько оно критично?». Ответы на эти вопросы уже дадут вам направление для следующих шагов.

Customer Journey Map: как увидеть продукт глазами пользователя

Customer Journey Map — это визуальная диаграмма, которая описывает путь пользователя от первого контакта с продуктом до достижения цели (или до момента отказа). Она показывает не только действия пользователя, но и его эмоции, мысли, точки боли и возможности для улучшения.

Зачем она нужна:

1. Увидеть картину целиком. Вы перестаёте смотреть на продукт как на набор экранов и начинаете видеть его как последовательный опыт.

2. Найти точки боли. Где пользователь разочаровывается? Где он застревает? Где хочет бросить всё и уйти?

3. Обнаружить возможности. Где можно удивить пользователя? Где можно упростить процесс?

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

Из каких этапов состоит Customer Journey Map (для Clever Notes):

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

2. Знакомство с продуктом. Пользователь находит Clever Notes, устанавливает приложение, проходит регистрацию.

3. Первое использование. Пользователь создаёт первую заметку, пробует поиск, экспериментирует с функциями.

4. Регулярное использование. Пользователь возвращается, создаёт новые заметки, использует продвинутые функции (теги, поиск, офлайн-режим).

5. Принятие решения (остаться или уйти). Пользователь либо становится лояльным, либо отваливается.

Как строить Customer Journey Map:

1. Определите этапы. Опишите ключевые этапы пути пользователя (от 3 до 7).

2. Опишите действия пользователя. Что именно он делает на каждом этапе?

3. Опишите эмоции. Что пользователь чувствует? (радость, раздражение, удивление, скуку).

4. Найдите точки боли. Где пользователь сталкивается с трудностями? Что его бесит?

5. Найдите возможности. Что можно улучшить на каждом этапе? Где можно удивить пользователя?

6. Визуализируйте. Нарисуйте карту в Miro, Figma или на бумаге.

---

Пример Customer Journey Map для Clever Notes

Как использовать Customer Journey Map в работе:

1. После исследования. Вы объединяете инсайты из интервью в единую картину.

2. Перед приоритизацией. Вы видите, где самые большие точки боли, и можете расставить приоритеты.

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

Артефакты главы 2

В этой главе вы создаёте несколько ключевых артефактов:

1. Interview Script (Скрипт интервью) — заранее подготовленный список вопросов.

2. Interview Notes (Записи интервью) — детальные заметки о каждом разговоре с цитатами и наблюдениями.

3. JTBD Statements — список выявленных «работ», сформулированных по шаблону JTBD.

4. База инсайтов — документ, где вы собираете все наблюдения, цитаты и паттерны из интервью.

5. Personas (опционально) — обобщённые портреты типичных пользователей.

6. Empathy Map (опционально) — визуальная схема, фиксирующая, что пользователь думает, чувствует, говорит, делает, видит и слышит.

7. Customer Journey Map (опционально) — диаграмма, описывающая шаги пользователя от первого контакта до достижения цели.

8. Process Map (Карта бизнес-процесса) — визуальная схема, описывающая ключевые шаги бизнес-процесса клиента.

Зачем они нужны:

1. Скрипт интервью — чтобы не импровизировать и получать качественные данные от всех респондентов.

2. Записи интервью — чтобы не потерять детали и цитаты. Сырые данные — основа для анализа.

3. JTBD Statements — чтобы формулировать проблемы на языке пользователя, а не на языке фич.

4. База инсайтов — чтобы видеть паттерны и формулировать гипотезы на основе данных, а не догадок.

5. Personas, Empathy Map, Customer Journey Map — чтобы углубить понимание пользователя и его контекста, синхронизировать команду.

6. Process Map — чтобы увидеть, как продукт вписывается в бизнес-процессы клиента, и найти точки создания ценности.

Как ими пользоваться:

1. Скрипт интервью — напишите до начала интервью. Используйте один скрипт для всех респондентов. Адаптируйте под конкретную аудиторию.

2. Записи интервью — записывайте сразу после интервью. Храните в структурированном виде (Notion, Google Docs). Не полагайтесь на память.

3. JTBD Statements — выпишите все JTBD из интервью. Используйте как основу для гипотез и приоритизации.

4. База инсайтов — ведите в общей таблице. Регулярно пересматривайте, ищите новые паттерны.

5. Personas — создайте после 5–7 интервью. Используйте для синхронизации команды.

6. Empathy Map — заполните вместе с командой. Используйте для глубокого понимания контекста пользователя.

7. Customer Journey Map — нарисуйте после анализа интервью. Используйте для поиска точек улучшения продукта.

8. Process Map — нарисуйте схему «как есть» (AS-IS) на основе интервью с пользователями. Отметьте точки боли. Нарисуйте схему «как должно быть» (TO-BE) с вашим продуктом. Покажите обе схемы заказчику и обсудите.

Заключение к главе 2: Исследование — это не про так надо, а про уверенность

Мы начали с того, что исследования нужны не для того, чтобы подтвердить свои догадки, а для того, чтобы обнаружить реальные проблемы. Мы разобрали CustDev, JTBD, научились проводить интервью и строить карты. Но главное, что вы должны вынести из этой главы: без качественного исследования вы строите продукт для себя, а не для пользователей.

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

Что делать прямо сейчас:

Проведите 3–5 глубинных интервью с людьми из вашей целевой аудитории. Не спрашивайте: «Вы бы купили?» Спрашивайте: «Как вы сейчас решаете эту проблему?» Записывайте цитаты. Ищите паттерны. И только после этого формулируйте гипотезы.

Куда идём дальше:

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

Практическое задание №2

Проведите 5 глубинных интервью с пользователями Clever Notes, чтобы выявить их JTBD. Используйте скрипт из теории. По итогам интервью сформулируйте 3 ключевых инсайта.

Исходные данные для анализа:

1. Интервью проводились по методике JTBD, выборка — 20 пользователей (15 активных, 5 отвалившихся).

2. Получены следующие распределения:

• 16 из 20 (80%) назвали отсутствие офлайн-доступа главной причиной ухода к конкурентам.

• 3 из 20 (15%) указали на сложность поиска старых заметок.

• 1 из 20 (5%) — другие причины (сложный онбординг, высокая цена).

Используйте эти данные в своём анализе.

Формат сдачи:

1. Краткая характеристика трёх респондентов (пол, возраст, роль).

2. 3 инсайта (цитаты или наблюдения).

3. Одна гипотеза на основе этих инсайтов.

Пример гипотезы: «Мы считаем, что добавление офлайн-режима в мобильном приложении повысит удержание на D7 с 25% до 40% в течение двух месяцев, потому что в 16 из 20 интервью пользователи называли отсутствие офлайн-доступа главной причиной ухода к конкурентам».

4. (Бонус): Постройте Customer Journey Map для одного из ваших респондентов. Опишите его путь от первого контакта с Clever Notes до момента, когда он решил остаться или уйти. Укажите эмоции и точки боли на каждом этапе.

Глава 3. Clarity Sprint: от исследования к плану

---

От автора

Был у меня в жизни период, который я мысленно называю «медицинский ад». Я работал над сложной медицинской информационной системой (МИС). Продукт использовался внутри компании — мы были и разработчиками, и заказчиками, и пользователями одновременно. Звучит как идеальный сценарий для быстрой обратной связи? Не спешите, на практике это было далеко от идеала.

Система имела технический долг таких масштабов, что его смело можно было назвать отдельным продуктом. Документации не существовало в принципе. Модули были написаны по принципу «как не надо делать», и каждый следующий разработчик, заходя в чужой код, крестился и бежал звонить батюшке. В довесок ко всему — каждый руководитель подразделения считал свой функционал самым важным и требовал его реализации «ещё вчера». И у каждого были аргументы: «У нас пациенты ждут!», «У нас отчётность срывается!», «У нас клиенты недовольны!» — стандартный набор криков о помощи в любой крупной компании. Но только мне было не ясно, как можно было всё так запустить.

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

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

Я попытался согласовать стратегические цели, ввести OKR, но всё было тщетно. Никто не хотел и слышать о стратегии. Нужны были сиюминутные спасательные меры, и их требовали от меня прямо сейчас. У меня не было ни времени, ни ресурсов, чтобы внедрять новые подходы. Приходилось спасать ситуацию с тем, что есть. Потому что, когда всё горит одновременно, у тебя нет возможности остановиться на пару недель и перестроить процесс. Есть только время бегать с вёдрами. В этом нет никакой трагедии — это просто факт. Такая у нас была реальность, где мы бегали, тушили, выживали.

Если бы тогда у меня появилась возможность выделить ресурсы на перестройку процесса, я бы без раздумий взял Clarity Sprint. Потому что это именно тот инструмент, который позволяет не бегать с ведром воды, а построить пожарную часть. Я уверен, он сэкономил бы нам месяцы нервотрёпки, тонны выгоревшего топлива команды и времени стейкхолдеров. Но тогда такой возможности не было. И мы просто делали то, что могли.

История не о том, как всё бывает плохо и ничего с этим не поделать. Она о том, что иногда вы знаете правильное решение, но у вас нет возможности его применить. К сожалению, это нормально. Но это и не провал. Это контекст, в котором вы работаете. Главное — не забывать, что правильные инструменты существуют, и когда у вас появится возможность — не упускать её. Потому что, чёрт возьми, они реально работают. В моей ситуации идеально подошёл бы Clarity Sprint, и далее я вам о нём расскажу.

Что такое Clarity Sprint и почему он спасёт вам нервы

Clarity Sprint — это короткий, структурированный процесс (обычно 1–4 недели), который помогает продакту превратить сырые инсайты из исследований в чёткий план действий. Он проходит до начала разработки и отвечает на три главных вопроса:

1. Что мы создаём и для кого? (продуктовое видение, целевая аудитория, ключевая проблема).

2. Почему это будет работать? (бизнес-обоснование, рыночные инсайты, валидация гипотез).

3. Как мы это сделаем? (приоритеты, роадмап, MVP-скоп).

В отличие от классического A/B-теста, который проверяет уже готовые гипотезы, Clarity Sprint проверяет сами гипотезы до того, как они превратились в код. Это не про скорость. Это про правильность направления. Это этап, на котором продакт связывает исследования из главы 2 с планированием из глав 4 и 5.

Почему Clarity Sprint важен:

• Снижает риски. Вы проверяете идеи до того, как команда потратила недели на разработку.

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

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

Когда проводить Clarity Sprint:

• На старте нового продукта или большого релиза. Когда вы ещё не знаете, что именно будете делать, но чувствуете, что пора начинать.

• После завершения исследования (CustDev, JTBD). Когда у вас есть инсайты, но нет плана действий.

• Когда стратегия компании меняется. Чтобы пересмотреть приоритеты и скорректировать курс.

Структура Clarity Sprint (по неделям)

Clarity Sprint — это не магия. Это структура. Четыре недели, четыре фокуса. Каждая неделя имеет своё название и свою задачу.

Неделя 1: Стратегия

Что делаем: формулируем видение продукта, бизнес-цели и ключевые OKR.

Кто участвует: продакт, стейкхолдеры (CEO, маркетинг, продажи).

Артефакт: Strategy Brief — документ на 1–2 страницы, где зафиксированы видение, цели и ключевые метрики успеха.

Неделя 2: UX-исследования и прототипы

Что делаем: строим пользовательские сценарии (Customer Journey Map), создаём кликабельные прототипы ключевых экранов.

Кто участвует: продакт, дизайнер, UX-исследователь.

Артефакт: Prototype (Figma) — кликабельный прототип для проверки сценариев.

Неделя 3: Приоритизация и роадмап

Что делаем: оцениваем фичи по RICE/ICE, формируем бэклог и строим роадмап на ближайшие 1–2 квартала.

Кто участвует: продакт, разработчик (Tech Lead), дизайнер.

Артефакт: Validated Backlog — бэклог, где приоритеты подтверждены данными из исследований.

Неделя 4: Валидация

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

Кто участвует: продакт, UX-исследователь, небольшая группа пользователей.

Артефакт: Validation Report — отчёт по итогам валидации: что подтвердилось, что пошло не так, какие корректировки нужны.

Артефакты главы 3

Три артефакта, которые вы создадите в Clarity Sprint:

1. Strategy Brief — краткий документ (1–2 страницы) с видением, бизнес-целями и OKR.

2. Validated Backlog — бэклог с приоритетами, подтверждёнными данными исследований и валидацией.

3. Validation Report — отчёт по итогам валидации прототипа с выводами и корректировками.

Зачем они нужны:

1. Strategy Brief — синхронизирует стейкхолдеров и задаёт направление для всего спринта. Без него каждый участник будет представлять финал по-своему.

2. Validated Backlog — гарантирует, что вы тратите ресурсы на фичи, которые действительно нужны пользователям, а не на догадки.

3. Validation Report — фиксирует уроки валидации, чтобы вы не повторяли ошибок и могли скорректировать курс.

Как ими пользоваться:

1. Strategy Brief — пишите до начала Clarity Sprint. Покажите стейкхолдерам и убедитесь, что они согласны с направлением.

2. Validated Backlog — формируйте на основе данных из исследований. Каждая фича должна иметь обоснование: «почему мы её делаем» и «какую проблему решаем».

3. Validation Report — пишите сразу после тестирования. Записывайте конкретные выводы, а не общие слова. Используйте их для корректировки бэклога и стратегии.

Заключение к главе 3: Clarity Sprint — это мост между «я знаю проблему» и «я знаю, что делать»

Мы начали с того, что исследования (глава 2) дают нам инсайты. Но инсайты — это ещё не план. Clarity Sprint превращает их в структурированные инициативы, валидирует гипотезы и подготавливает бэклог для приоритизации. Он не про скорость. Он про правильность направления.

Если вы чувствуете, что у вас есть тонна данных, но вы не знаете, с чего начать — вы на месте Clarity Sprint. Он даёт структуру, синхронизирует команду и снижает риски.

Что делать прямо сейчас:

Попробуйте провести мини-версию Clarity Sprint на ближайшие 2 недели. Соберите команду, сформулируйте видение, выберите 3–5 инициатив и проверьте их на живых пользователях. Даже если у вас нет ресурсов на полный спринт — сделайте хотя бы неделю стратегии.

Куда идём дальше:

Валидированный бэклог из Clarity Sprint (глава 3) становится входными данными для приоритизации (глава 4). Там мы будем считать RICE, ICE и Kano — чтобы понять, что делать в первую очередь.

Практическое задание №3

Вы продакт-менеджер Clever Notes. Ваша команда завершила исследование (глава 2) и выявила три ключевых инсайта:

• 80% отвалившихся пользователей назвали отсутствие офлайн-доступа главной причиной ухода к конкурентам.

• 15% пользователей указали на сложность поиска старых заметок.

• 5% пользователей пожаловались на сложный онбординг и высокую цену.

На основе этих данных проведите Clarity Sprint и подготовьте:

1. Strategy Brief для Clever Notes.

2. Validated Backlog для ближайшего квартала (выберите 3–5 инициатив с обоснованием).

3. Validation Report с описанием, как вы проверите одну из инициатив на реальных пользователях.

Глава 4. Приоритизация бэклога

---

Почему приоритизация — это не про «что хочет ceo»

Ваш бэклог — это список задач и фич. Но он не должен быть просто списком пожеланий. И нельзя ставить задачу только потому, что «это хочет CEO» или «это просил самый громкий клиент». Нужно объективно измерить ценность. Три основные методики помогают принять взвешенное решение: RICE и ICE дают численные оценки, Kano — качественную классификацию, а MoSCoW — быстрый способ договориться, когда времени на сложные расчёты нет. Вместе они формируют полную картину.

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

И я помню, как сам столкнулся с этим впервые.

От автора

Как-то мне очень внезапно передали в управление игровой проект. Продюсер позвал меня, чтобы вместе приоритизировать накопленный бэклог и составить на его основе реалистичный роадмап. Бэклог выглядел как огромная куча названий задач в Excel, выстроенных в определённом порядке — на основе видения предыдущего руководителя о том, что важнее.

Забавно, но лично для меня тогда все пункты выглядели одинаково важными. Кроме «бантиков» — их я, перестав быть ведущим художником, уже умел ставить на второй план. Но всё остальное казалось критичным. Если бы я знал про RICE, ICE и Kano! Но я не знал и даже не догадывался о таких крутых штуковинах. До меня всё делалось по наитию, на основе субъективного опыта и «слизывания» с конкурентов. И я на тот момент искренне считал, что это правильный подход.

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

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

Сейчас я понимаю: приоритизация без инструментов — это как пытаться собрать пазл в темноте. Ты видишь кусочки, но не понимаешь, куда их класть. RICE, ICE и Kano — это не просто формулы. Это свет, который показывает, где лежит настоящая ценность, а где — просто «шум».

RICE: метод, который требует данных (и немного смелости)

RICE — это метод численной приоритизации, который учитывает четыре параметра: Reach, Impact, Confidence, Effort. Его главное преимущество — объективность. Его главный недостаток — требует данных. Если у вас нет данных, вы не сможете посчитать RICE. Но если они есть — вы получите чёткую картину.

Параметры для расчета RICE:

1. Reach (Охват)

Сколько пользователей затронет фича за определённый период (например, за месяц). Измеряется в количестве людей, сессий или транзакций. Оценивайте через аналитику (Google Analytics, Amplitude) или аппроксимацию. Например, «новая кнопка покажется всем 100 000 активным пользователям, значит Reach = 100 000».

2. Impact (Влияние)

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

• 3 = гигантское влияние (рост метрики в 2 раза и более).

• 2 = высокое влияние (рост на 30–50%).

• 1 = среднее влияние (рост на 10–30%).

• 0.5 = низкое влияние (рост на 1–10%).

• 0.25 = минимальное влияние (менее 1%).

3. Confidence (Уверенность)

Насколько вы верите в свои оценки Reach и Impact.

• 100% = есть точные данные или успешный эксперимент.

• 80% = есть CustDev-интервью, опросы, логика.

• 50% = общая догадка.

• 20% = «пальцем в небо».

4. Effort (Усилие)

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

Формула: RICE Score = (Reach × Impact × Confidence) / Effort.

Пример расчёта для clever notes:

Фича «Автозаполнение адреса»:

• Reach = 50 000 пользователей в месяц, которые доходят до экрана доставки.

• Impact = 1 (среднее, повысит конверсию на 15%).

• Confidence = 80% (есть исследование).

• Effort = 10 человеко-дней.

• Score = (50 000 × 1 × 0.8) / 10 = 4000.

Фича «Админка логов»:

• Reach = 5 администраторов.

• Impact = 0.25 (удобство, но не влияет на выручку).

• Confidence = 100%.

• Effort = 15 человеко-дней.

• Score = (5 × 0.25 × 1) / 15 ≈ 0.083.

Очевидно, автозаполнение в десятки раз приоритетнее.

ICE — лёгкая альтернатива для тех, у кого нет данных

RICE требует данных об охвате, которые есть не всегда. На ранних стадиях продукта, при оценке growth-экспериментов или в небольших командах без доступа к аналитике, на помощь приходит метод ICE.

ICE расшифровывается как Impact, Confidence, Ease:

1. Impact (Влияние). Насколько сильно задача повлияет на ключевую метрику. Оценивается по шкале от 1 до 10.

2. Confidence (Уверенность). Насколько вы уверены в своей оценке Impact. Оценивается по шкале от 1 до 10.

3. Ease (Лёгкость реализации). Сколько усилий потребуется для выполнения. Чем выше оценка, тем легче реализовать задачу. Оценивается по шкале от 1 до 10.

Формула: ICE = Impact × Confidence × Ease.

В отличие от RICE, ICE не требует данных об охвате, что делает его идеальным для быстрой оценки идей на ранних стадиях. Однако именно поэтому ICE менее точен — он не учитывает, сколько пользователей затронет фича.

---

Когда использовать RICE, а когда ICE:

Пример расчёта ice для clever notes:

Оценим ту же функцию «офлайн-режим», которую мы считали через RICE:

• Impact = 9 (решает главную боль 80% отвалившихся пользователей).

• Confidence = 7 (высокий технический риск синхронизации).

• Ease = 5 (средняя сложность реализации, требует 3 человеко-месяца).

ICE = 9 × 7 × 5 = 315.

Сравните с RICE-оценкой из начала главы 4 — и вы увидите, как по-разному выглядят приоритеты в зависимости от выбранного метода. ICE даёт быструю оценку, RICE — более точную, но требует больше данных.

Kano — качественная классификация, которая объясняет, почему пользователи злятся

RICE и ICE дают числа. Но числа не всегда объясняют, почему пользователи злятся на ваш продукт, даже если вы сделали всё «правильно». Здесь на помощь приходит Kano.

Kano — это модель, которая классифицирует функции по тому, как они влияют на удовлетворённость пользователей:

1. Базовые (Must-be)

Пользователи воспринимают их как должное. Отсутствие вызывает недовольство, наличие не повышает удовлетворённость.

Пример: в мессенджере сообщение должно доставляться.

2. Линейные (Performance)

Чем лучше реализация, тем выше удовлетворённость.

Прямая зависимость: увеличиваем скорость загрузки — выше удовлетворённость.

3. Восторгающие (Attractive)

Неожиданные фичи, которые вызывают вау-эффект. При их отсутствии пользователь не расстроен.

Пример: смешные гифки в чате.

4. Индифферентные (Indifferent)

Пользователям всё равно. Их наличие или отсутствие никак не влияет на удовлетворённость.

Как использовать Kano

Проведите опрос с парой вопросов для каждой фичи:

• Что вы почувствуете, если эта фича будет?

• Что вы почувствуете, если этой фичи не будет?

Варианты ответов: обожаю, ожидаю, нейтрально, терплю, не люблю. Обработка ответов даёт тип фичи.

Стратегия приоритизации по Kano:

1. Сначала закрываем базовые (Must-be) — без них продукт не работает.

2. Затем линейные (Performance) с высоким ROI — они дают измеримый рост метрик.

3. Затем восторгающие (Attractive) — если есть ресурсы.

4. Индифферентные (Indifferent) — делаем в последнюю очередь или не делаем вообще.

От автора

Возвращаясь к истории про медицинский ад.

Стейкхолдеры в той системе были людьми с очень аналоговым опытом. Они понимали бумажки, приказы, отчёты, проверки. Но они не понимали RICE, ICE, Kano и прочие волшебные аббревиатуры. Для них «приоритет» означал «то, что кричит громче всех». И каждый из них был уверен, что его задача — самая важная.

Мои попытки сесть с ними и разобрать по полочкам, что у нас Must-have, Should-have, Could-have, были тщетны. Они смотрели на меня с недоумением: «Какие ещё маст-хэвы? Ты что, не понимаешь, что это надо сделать сейчас? Нет, это надо сделать сейчас! А вот это — вообще вчера!» Это было похоже на попытку объяснить правила шахмат людям, которые всю жизнь играли в догонялки.

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

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

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

Я ввёл простую практику: регулярные встречи раз в неделю, где от стейкхолдеров требовалось только одно — дать оценку каждой фиче по пятибалльной шкале. «Насколько это важно для тебя прямо сейчас? Поставь цифру от 1 до 5, где 5 — это критично, а 1 — можно подождать». Всё. Никаких дебатов, никаких споров, никаких «это надо вчера». Просто цифры. Хотя, по правде сказать, споры, конечно, всё равно были, да ещё какие!

И это сработало. Аналоговые люди оказались вполне способны играть в цифры, если эти цифры не RICE или Kano. Они ставили баллы, я собирал эти баллы, и у меня вырисовывалась картина. Я уже сам, на основе их оценок, раскладывал всё на Must-have, Should-have, Could-have и строил нормальный бэклог. Конечно, их оценки были субъективными, иногда противоречивыми, и они часто менялись от встречи к встрече. Но у меня хотя бы был какой-то ориентир. Вместо «всё важно» у меня появилось «очень важно», «важно» и «подождёт». Я даже смог набросать роадмап на несколько месяцев.

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

Жаль только, что моя работа не стала панацеей. Потому что даже с этой системой приоритетов у меня оставалась одна проблема: ценность фичи, которая для моих стейкхолдеров всё равно менялась чаще, чем раз в неделю.

Это не цинизм и не пессимизм. Это реальность. Продукт-менеджмент — это не про то, чтобы один раз создать идеальный план и следовать ему до конца. Это про то, чтобы каждый раз, когда мир меняется (а он меняется постоянно), у вас была система, которая позволяет быстро перестроиться. И даже упрощённый подход, основанный на пятибалльных оценках и MoSCoW, давал мне эту систему. Не идеальную. Не магическую. Но работающую в тех условиях, в которых мы оказались.

MoSCoW — когда нет времени на RICE, а договориться нужно

Не всегда есть возможность приоритизировать фичи, по точной оценке, их стоимости. В таких случаях на помощь приходит MoSCoW.

MoSCoW расшифровывается так:

1. Must-have — обязательно должно быть в продукте. Без этого продукт не работает.

2. Should-have — очень важно, но не критично. Можно сделать чуть позже.

3. Could-have — полезно, но не обязательно. Приятный бонус, если останется время.

4. Won’t-have — не будем делать в этом релизе (или вообще).

MoSCoW хорош своей простотой. Он не требует цифр и расчётов. Но именно в этом его слабость. Всё решает субъективное мнение: кто-то считает фичу Must-have, кто-то — Could-have. Без данных и численных оценок приоритизация превращается в игру «кто громче крикнет».

Поэтому в этой книге мы не будем использовать MoSCoW как основной инструмент. Мы оставим его для тех случаев, когда нужно быстро и без цифр разложить задачи по полочкам. Для более точных и обоснованных решений у нас есть RICE, ICE и Kano. А MoSCoW — это скорее инструмент для коммуникации со стейкхолдерами, особенно когда они не готовы считать RICE, но готовы ставить оценки по пятибалльной шкале. Как в моей истории про медицинскую систему.

Weighted Scoring — когда RICE не учитывает стратегию

Иногда RICE и ICE не учитывают стратегические приоритеты компании. Например, функция может иметь высокий RICE, но не соответствовать долгосрочной стратегии. Weighted Scoring позволяет добавить веса для разных критериев и учесть их при приоритизации.

Как выбирать критерии для Weighted Scoring:

• Стратегические критерии. Соответствует ли функция долгосрочной стратегии? (вес 7–10)

• Пользовательские критерии. Решает ли функция реальную проблему пользователей? (вес 5–8)

• Технические критерии. Насколько сложно реализовать функцию? (вес 3–6)

• Финансовые критерии. Какой ROI даст функция? (вес 5–8)

• Риски. Насколько рискованна реализация? (вес 2–5)

Как использовать Weighted Scoring:

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

2. Назначьте каждому критерию вес (от 1 до 10) в зависимости от его важности.

3. Оцените каждую функцию по каждому критерию (от 1 до 10).

4. Умножьте оценку на вес и сложите результаты.

Как выбирать веса:

Веса отражают стратегические приоритеты компании. Например, если ваша главная цель — удержание пользователей, критерий «влияние на удержание» должен иметь максимальный вес (9–10). Если ваша команда ограничена в ресурсах, критерий «сложность реализации» должен иметь высокий вес (7–8). Веса можно корректировать по мере изменения стратегии.

Пример Weighted Scoring для Clever Notes