РАЗ. Книга специфическая. Ее автор — геше (магистр буддийских наук), а основная мысль: в бизнесе подходы буддизма приводят к успеху, как и в жизни. В качестве подтверждения автор приводит алмазную компанию Андин, в которой он работал после изучения буддизма в Тибете.

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

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

ДВА. Основная мысль связана с принципами «пустоты» и «отпечатков». Пустота означает субъективность нашего восприятия действительности. Качество этого восприятия зависит от проросших «отпечатков». Для обозначения связи между причиной и следствием автор также использует понятие «корреляции».

Принцип «отпечатка» заключается в том, что наши действия оставляют в нашем мозгу «отпечатки». Эти отпечатки впоследствии усиливаются (прорастают) и определяют наше восприятие окружающего, заполняя пустоту.

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

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

ТРИ. Есть 7 основных корреляций, которые применимы и к жизни, и к бизнесу: что нужно делать, чтобы получить желаемое. Желаемое — действие:

• Деньги — щедрость
• Счастье — мораль
• Здоровье — отказ от гнева
• Лидерство — радость в действиях
• Концентрация — медитация
• Свобода от мира — изучение принципа потенциала и отпечатков
• Достижение целей — сострадание по отношению к другим

Подробнее в «Нить драгоценных камней», Нагарджуна

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

ЧЕТЫРЕ. Способствует успеху во внедрении правильного образа поведения система самоконтроля. Из 46 проблем стоит выбрать 3 главных и шесть раз в день отмечать выполненные действия конкретным описанием. В конце дня полезно проанализировать день.

ПЯТЬ. Также полезны ритуалы круга / лесного круга — уединения (полного и различного по времени) для сконцентрированного решения проблем, обретения нового импульса.

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

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

1. Принципы lean startup (LS)

Пять основных принципов LS:
— подход LS можно применять в любом бизнесе;
— стартапу нужен не только продукт, но и менеджмент;
— для развития бизнеса стоит постоянно проводить эксперименты, чтобы проверять на практике свое видение;
— в основе LS лежит самая быстрая возможная обратная связь от потребителей; задача бизнеса заключается в постоянном производстве цикла «создать-оценить-научиться»: превращать идеи в продукты или их части, узнавать мнение потребителей, принимать решение о сохранении вектора или необходимости «виража»;
— новая отчетность, которая позволяет оценить каждый из экспериментов и бизнес в целом.

2. ВИДЕНИЕ

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

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

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

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

В компании Kodak гипотезы проверяют четырьмя вопросами:
— Признают ли потребители, что у них есть проблема, которую мы пытаемся решить?
— Если предложить им решение этой проблемы, готовы ли они за него платить?
— Станут ли они платить именно нам?
— Можем ли мы предложить решение?
Ошибка компаний в том, что они сразу переходят к четвертому вопросу, игнорируя остальные. Все их можно проверить экспериментами.

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

3. ПРАКТИКА

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

? Аналог. В прошлом технологии А удалось завоевать рынок Б благодаря функции С. У нас есть новая технология А2, которая позволит нам завоевать рынок Б2, потому что у нас тоже есть атрибут С. При уже существующем аналоге Sony Walkman разработчики iPod уже знали, что люди готовы слушать музыку в наушниках в публичных местах.
? Антианалог. Разработчики iPod видели пример сайта Napster, что люди не хотели платить за музыку. Поэтому им пришлось разработать свою модель монетизации.

MVP

Для проверки допущений, или прыжков веры создается минимально рабочий/жизнеспособный продукт (Minimal viable product, MVP) — его стоит запустить как можно раньше. Главная задача первого этапа — определить, приводят ли усилия по разработке продукта к желаемым результатам.

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

Варианты MVP:
— ручная работа (Groupon сначала публиковал предложения на сайте и отсылал купоны вручную по почте);
— видеопрезентация (Dropbox);
— MVP для одного клиента (Food on table — сервис по созданию меню и списка покупок с наиболее выгодными ценами — начинал с того, что руководители работали с одним клиентом, анализируя его боли и пожелания)

Учет инноваций

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

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

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

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

Для успешного учета инноваций стоит:
— правильно настроить метрики. Стоит опасаться «показателей тщеславия» — абсолютных величин, которые имеют у стартапов роста по экспоненте с определенного момента. Большее число платящих пользователей — это хорошо, но если доля таких пользователей в общем объеме сокращается, это говорит о проблемах продукта;
— сделать отчеты максимально понятными для всех;
— обеспечить доверие сотрудникам отчетам;
— настроить процесс разработки пользовательских историй:

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

4. ВИРАЖ

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

«Вираж — это стратегическая гипотеза»

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

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

Большинство сделавших вираж сожалеют, что не сделали его раньше.

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

5. РАБОТА СТАРТАПА

Сама простая формула для перехода к формату бережливого производства: какие наши действия приводят к росту ценности, какие приводят к потерям.

Поток единичных изделий

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

? Пример. Допустим, вам нужно подготовить к отправке 100 конвертов: наклеить марку, написать адрес, вложить письмо с печатью. Разумный подход — сначала поставить печати на всех письмах, потом вложить все в конверты и т. п. Специализация должна сократить затраты. Это работает в условиях определенности. В условиях неопределенности по-другому: письмо может не влезть в конверт и об этом мы узнаем только после простановки печати на всех. Кроме того, при специализации постоянно присутствует большой объем незавершенного производства.

? Пример. Вам как инженеру-конструктору нужно сделать 30 отдельных рабочих чертежей. Подход больших партий — самостоятельно составить все чертежи и отдать на проверку. Он нехорош тем, что коллеги будут потом постоянно отвлекать с вопросами. Лучше выдавать чертежи по одному или смысловыми группами.

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

Модель роста

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

У хороших стартапов работает правило:

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

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

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

?Примеры таких стартапов — сайт по продаже коллекционных товаров, IT-продукт по подписке.

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

?Примеры таких стартапов — Tupperware, Hotmail (подпись — заведите бесплатную почту).

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

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

Адаптивность

Хорошая способность стартапа — адаптироваться к условиям, то есть корректировать процессы и действия в соответствии с текущей ситуацией.

? В компании Эрика IMVU сначала не думали о программе обучения новых сотрудников. Однако ее разработали и получили отличные результаты.

В этом помогает метод «Пяти почему?» С его помощью вы выйдете на истинную причину проблемы.

? Пример 5 почему?

В новой версии оказалась отключена одна из опций. Почему? Потому что возникли неполадки на одном из серверов.

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

Зная причины на каждой из стадий можно рационально распределить ресурсы для их «починки».

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

Этот метод плохо подходит для решения хронических и глобальных проблем.

В университетах США есть традиция нумеровать курсы в пределах направления. Номер 101 — так часто обозначают вводный курс для новичков.

В статье перечислю перечислил то, из чего состоит управление продуктом (PM). Этот список не может быть одним общепринятым и полным. Воспринимайте его как набор терминов, отправную точку для дальнейшего исследования.

Часть 1. Жизненный цикл продукта (PLC)
Часть 2. Идеи (Ideas & User Needs)
Часть 3. Анализ конкурентов и рынка (Competitors & Market analysis)
Часть 4. Развитие на клиентах (Customer Development)
Часть 5. Эксперименты (Experiments) и Минимально жизнеспособный продукт (MVP)
Часть 6. Моделирование (Conceptualizing)
Часть 7. Метрики (Metrics)

По тексту есть ссылки на отдельные методы, подходы, фреймворки.

Даны термины на английском языке. Раньше я не любил включать иностранные слова в русскую речь. Но дело в том, что англоязычные эквиваленты как раз общеприняты. Если вы скажете user story, epic то и вы поймете, о чем речь, и ваш собеседник тоже. Русские эквиваленты (истории пользователей, эпики) не так однозначно понимаемы.

Часть 1. Жизненный цикл продукта (PLC)

Жизненный цикл продукта (Product Life Cycle, PLC)

PLC часто представлен как последовательность 4-х стадий. Каждая из стадий отличается своими особенностями с точки зрения развития продукта и его маркетинга.

1. Внедрение на рынок (Introduction): продвижение среди инноваторов, проверка конкурентных преимуществ, работа в минус.

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

3. Зрелость (Maturity): сокращение прироста, отстройка от конкурентов, рост стоимости новых потребителей.

4. Спад (Decline): сокращение продаж, прекращение работы или переход в нишевой сегмент.

Процесс разработки продукта (New Product Development, NPD)

NPD включает 7 стадий.

1. Задумка (Conceive). Это исследовательский этап, на котором собираются проблемы пользователей, а также идеи по их решению.

2. План (Plan / Research). Проводится исследование рынка и конкурентов, определяются гипотезы по параметру продукта, проводятся интервью пользователей.

3. Разработка (Develop / Execute). Записываются требования к продукту, таймлайн, пишутся user stories и технические спецификации. Итогом становится минимально жизнеспособный продукт (Minimal Viable Product, MVP).

4. Валидация (Iterate / Qualify / Validate). MVP проверяется на реальных пользователях и получение обратной связи от них. Разработка версии для бета- и альфа-тестирования.

5. Запуск (Launch). Разрабатывается стратегия Go-To-Market (GTM), объединяющая усилия разных служб (маркетинг, продажи, PR, финансисты, юристы) по представлению продукта пользователям.

6. Продажи (Steady State / Deliver / Post Launch). Продукт дорабатывается в соответствии с обратной связью пользователей, выводы делаются на основании метрик; работа маркетинга и продаж.

7. Maintain OR Kill / Retire. Принятие решение на основании данных о дальнейшей поддержке или закрытии продукта.

Часть 2. Идеи (Ideas & User Needs)

Сбор идей

Сбор идей происходит на разных стадиях развития продукта: в момент планирования, создания MVP, поддержки уже готового продукта. Распространенные источники идей собраны в аббревиатуру EMUC (Employees, Metrics, Users, Clients), то есть сотрудники, показатели, пользователи, клиенты.

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

Оценка идеи

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

Оценка идеи 2

Альтернативный и дополняющий подход состоит в том, что хорошая идея приводит к одному или нескольким позитивным результатам:
— Рост числа пользователей
— Рост удовлетворенности пользователей
— Усиление бренда

Часть 3. Анализ конкурентов и рынка (Competitors & Market analysis)

Оценка рынка

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

Объем рынка, на который выводится продукт, можно оценивать «сверху» (Top Down) и «снизу» (Bottom Up).

Оценка сверху отталкивается от расчета возможного спроса, емкости.

?Пример. Для оценки рынка мужской обуви в РФ можно идти от того, что мужчины составляют треть населения страны (50 млн чел.) и покупают новую пару раз в год — 50 млн пар обуви в год. Дальше можно уточнять по демографии, виду продукции и т. п.

Оценку снизу получают суммированием известных показателей участников рынка.

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

Поиск конкурентов

Если у вашего продукта нет конкурентов, то это признак того, что:
— нет спроса на продукт или сервис,
— анализ проведен недостаточно хорошо и вы искали только прямых конкурентов и забыли про косвенных, потенциальных и конкурентов с «продуктами-заменителями»;
— вы нашли свой голубой океан ?.

Кроме прямых (предлагают схожий продукт) на рынке могут быть следующие группы конкурентов:
— косвенные. Их продукт решает те же проблемы пользователей, но иным способом и/или для иной целевой аудитории;
— потенциальные. Работают с вашей целевой аудиторией, но решают другие проблемы... пока;
— конкуренты с продуктами-заменителями. Решают те же проблемы, но иным способом.

?Для нового сервиса каршеринга прямыми конкурентами будут Яндекс Драйв, Делимобиль; косвенными — службы такси, доставки городского транспорта.

Оценка конкурентов

Один из возможных подходов к оценке компаний-конкурентов:

— насколько хороша продуктовая команда;
— число пользователей;
— качество дизайна (в широком смысле, включая UX);
— бренд;
— скорость изменений.

По каждому параметру конкуренту присваивают оценку. Шкала может быть какой угодно (от 0 до 5, от 0 до 10 и т.д). Итоговая оценка — это сумма оценок по пяти параметрам.

Таблица свойств (Feature Table)

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

Часть 4. Развитие на клиентах (Customer Development)

Концепцию Customer Development предложил Стив Бланк (S. Blank). Это подход к построению продукта, в соответствии с которым от клиентов и пользователей постоянно получается обратная связь: идеи, гипотезы, пожелания. Акцент именно на постоянном характере обратной связи.

В этом фреймворке разработка продукта, а скорее уже процесс создание стартапа на основе продукта, состоит из четырех циклов:
1. Исследование (Customer Discovery). Определить целевую аудиторию и понять важность решаемой задачи для них. Разработать сценарий MVP
2. Подтверждение (Customer Validation). Построение стандартного процесса продаж и первые продажи ранним адептам. Если модель не подтверждается деньгами, то возможен возврат на предыдущую стадию Исследования.
3. Создание (Customer Creation). Расширение бизнеса за счет увеличения рекламы, действия реферальных программ.
4. Построение (Company Building). Создание формализованной компании.

Виды интервью

Разделение на виды очень условно. В пределах одного интервью могут быть вопросы разного характера. Интервью до выпуска продукта (pre-product) серьезно отличаются от интервью после выпуска (post-product).

1.Исследовательское (Exploratory). Наиболее свободное по форме интервью: открытые вопросы для того, чтобы понять боли, контекст использования продукта, конкурирующие продукты и технологии и уйти с интервью с новыми идеями.

2. Подтверждающее (Validation). Целью является подтверждение или опровержение гипотезы. В ходе интервью нужно стараться объективно понять особенности поведения респондента, не подталкивая его к желаемому ответу. Озвучить решение проблемы можно в завершении, также важно получить объективную оценку.

3. Оценка удовлетворенности (Satisfaction oriented). В чем продукт хорош, а в чем плох.

4. Эффективность (Efficiency interview). Здесь обратная связь используется для изменения продукта с целью повышения выбранных показателей эффективности (с точки зрения бизнеса, клиентов)

Часть 5. Эксперименты (Experiments) и Минимально жизнеспособный продукт (MVP)

Термин MVP (Minimal Viable Product, MVP) был предложен Эриком Ризом (E.Ries) во фреймворке Lean Startup. MVP — это такая версия продукта, которая позволяет собрать максимальный объем данных от пользователей при минимальных затратах.

?Хорошая практика: за один MVP тестировать один функционал. Если одновременно тестируете несколько функционалов, нужно понимать, как эти тесты могут повлиять друг на друга.

Подготовка MVP состоит из семи шагов:

Шаг 1. Определить, в чем состоит боль/потребность потребителей.

Шаг 2. Зафиксировать принятые допущения.

Допущения удобно фиксировать в формате «Продукт будет успешен при условии, что... ». Например, «...при условии, что у моих потенциальных клиентов есть потребность x, за которую они готовы заплатить z, и при этом нет сильных альтернатив».

Допущения ранжируют по степени влияния на продукт, то есть, насколько велики будут отрицательные последствия для продукта в случае, если допущение окажется ложным. Обычно самое рисковое допущение — предположение о наличии потребности у потенциального клиента.

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

На основании комбинации риск-сложность определяют приоритет проверки допущений через MVP:
— Большой риск — Маленькие затраты
— Большой риск — Большие затраты
— Маленький риск — Маленькие затраты
— Маленький риск — Большие затраты (обычно не проверяют)

Шаг 3. Сформулировать гипотезы.

Для проверки в MVP допущения должны быть переведены на язык гипотез. Гипотеза — это письменно зафиксированное утверждение, которое можно подтвердить или опровергнуть результатами теста. Варианты формулировки гипотез (от худшего к лучшему):

a. Мы думаем, что (пользователь, цель) будут (ожидаемое действие), потому что (причина).
b. Если мы (действие), то это приведет к тому, что (пользователь, цель) будут (ожидаемое действие), потому что (причина).
с. Мы думаем, что (пользователь цель) имеют (боль, потребность), потому что (причина). Если мы (действие), это приведет к тому, что метрика (ожидаемое состояние).

Во всех случаях причины лучше описывать в терминах болей и потребностей; хуже — в терминах ценностей и преимуществ.

Шаг 4. Зафиксировать минимальный порог успеха (Minimal Criteria for Success, MCS).

10% результатов экспериментов носят однозначно бинарный характер: мы провели эксперимент и наша гипотеза однозначно подтвердилась или однозначно не подтвердилась.

В 90% случаев результат где-то посередине, поэтому нужно фиксировать MCS — рубеж, по достижению которого гипотеза будет считаться принятой.

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

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

Шаг 5. Выбрать тип MVP-эксперимента.

Протестировать интерес пользователей в цифровой среде можно разными способами.

— Email-анонс. Разослать письма с анонсом нового функционала и собрать обратную связь
— Кнопка (Shadow Button). Разместить на сайте кнопку для доступа к новому функционалу и отслеживать клики. Клики могут переводить на страницу «Скоро».
— 404 / Скоро (Coming soon). При интересе пользователя и переходе пользователя на страницу нового функционала показывать сообщение о скором создании раздела.

? Так часто делает Amazon.

— Видео (Explainer video). В видео рассказать о новом функционале и выгодах для пользователя.

? Так стартовал Dropbox.

— Лендинг (Landing page). Аналогично видео, но рассказать о преимуществах функционала на отдельной странице.
— Консьерж (Concierge service). В случае интереса пользователя прикрепленный менеджер помогает пользователю выполнить те действия, которые потом будут реализованы в функционале.
— Частичный MVP (Piecemeal). Часть функциональности MVP закрывается с помощью существующих сервисов автоматизации, таких как Google Docs, Zapier и проч.
— Волшебник Изумрудного города (Wizard of Oz). Продукт притворяется, в то время как все действия новой функциональности выполняются вручную.

Типы MVP-экспериментов — подробное описание (скоро)

Шаг 6. Провести MVP-эксперимент.

Шаг 7. Подвести итоги и сделать выводы.

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

?Хорошая практика: дополнить численные результаты качественными данными из интервью. Чтобы понять, почему пользователи сделали так, а не по-другому.

Часть 6. Моделирование (Conceptualizing)

Тут все несложно. Самое главное — принято различать три уровня моделей. Их лучше не путать.

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

Как составить схему:
— нарисовать браузер;
— в браузере нарисовать лого и основное навигационное меню;
— понять цель страницы;
— выписать сценарии, которые пользователи проходят на странице;
— добавить на страницу элементы.

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

Прототип (Prototype) — модель, цель которой показать, как пользователь будет взаимодействовать с продуктом. Это самая точная модель, после согласования идет на разработку.

?Взаимодействие с продуктом может быть показано уже на схеме.

Часть 7. Метрики (Metrics)

Метрики показывают, что происходит с продуктом, они свидетельствуют о достижении целей, а также дают базу для проведения экспериментов. Важные метрики входят в число KPI (Key Performance Indicator).

Метрики принято разделять:

— Метрики роста (Growth&Activation). Они показывают рост вашего продукта.
Примеры: число новых пользователей, их структура по источнику трафика, число активаций (пользователей, которые не только установили приложение, но и зарегистрировались и выполнили определенные действия).

— Метрики удержания (Retention). Показывают, как часто пользователи возвращаются к продукту.
Примеры: число пользователей ежедневно использующих продукт, восстановленные пользователи (не использовали некоторое время, но вернулись)

— Метрики вовлечения (Engagement). Показывают, насколько пользователи привязаны к продукту.
Примеры: среднее число визитов, проведенное время, страниц за сессию, число написанных постов или социальных действий.

— Метрики счастья (Happiness). Показывают удовлетворенность пользователей
Примеры: NPS, число жалоб, рейтинг в сторах.

— Денежные метрики (Revenue). Показывают, сколько продукт зарабатывает.
Примеры: LTV, стоимость привлечения новых пользователей, месячный постоянный доход (Monthly recurring revenue, MRR), годовой постоянный доход (Annual recurring revenue, ARR)

Метрики бывают:
— Исследовательские метрики (Exploratory). Показывают специфическую информацию, важную в определенный момент времени. Например, это метрики, связанные с экспериментами (стоимость привлечения и уровень вовлеченности в определенный раздел продукта). Список исследовательских метрик гибкий, он периодически обновляется.
— Отчетные метрики (Reporting). Стабильный список глобальных метрик, по которым из месяца в месяца оценивается динамика продукта.

? Хорошие отчетные метрики:
— понятны, однозначны;
— представляют собой относительную или среднюю величину, не абсолютны (пользователи за день, процент довольных пользователей и т. п.);
— не взаимосвязаны между собой (нет смысла одновременно мерить число визитов за день и за месяц);
— учитывают внешние факторы и их можно улучшить (бесполезно работать над длительностью сессии, если у характерного пользователя есть только 2 часа в день на работу с продуктом)
— относятся к «причинным» метрикам, реже следствиям. Причинная метрика — баланс калорий за день, следственная — изменение веса.

По фреймворку HEART работа над созданием метрик выглядит следующим образом:
— определяете, что хотите измерить. Например, денежные метрики (обычно одна из групп того или иного фреймворка);
— определяете цель, чего конкретно хотите добиться. Например, увеличить выручку и продавать больше;
— определяете сигналы; по сигналам можно определить, что цели достигаются. Увеличение числа заказов и рост выручки;
— определяете метрику. Метрика показывает, как измерить сигнал. Среднее число заказов в день на пользователя, средняя выручка за день.

? Пример: составить метрику, связанную с удовлетворенностью пользователей.
— Цель: обеспечить максимальную удовлетворенность от продукта и сервиса;
— Сигналы: рейтинг в сторе, оценки NPS.
— Метрики: динамика NPS к предыдущему месяцу; число оценок 10 при опросе NPS.

Часть 8. Создание продукта

Пирамида продукта

Части пирамиды продукта:
— Глобальное видение отрасли (Global vision) — живая картинка будущего отрасли;
— Видение компании (Company Vision) — место компании в будущем отрасли с учетом глобального видения;
— Цели (Goals) — видение компании, описанное метриками;
— Инициативы (Initiatives) — крупные направления, которые помогут достичь намеченных целей;
— Элементы бэклога (Product Backlog Items): Релизы (Releases) / Эпики (Epics) / Фичи (Features) / Темы (Themes) / Пользовательские истории (User Stories / Tasks) / Баги (Bugs). В описании Scrum задачи, связанные с разработкой продукта, называются элементами бэклога. Такой подход позволяет каждой команде по-своему создавать свою структуру задач и направлений. У кого-то это только эпики и истории, у кого-то релизы, фичи и истории. Однако большинство команд используют пользовательские истории.

Как писать User Stories

Спецификации

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

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

2. Требования к продукту (Product requirements). Какие изменения должны произойти в продукте, чтобы эпик считался успешным.

3. Требования к дизайну (Design requirements). Специфические ограничения по дизайну: использование гайдов, UI-китов и т. п.

4. Требования к разработке (Engineer requirements). Что должно быть сделано с точки зрения бэкенда и фронтэнда.

Оценки

Оценки в IT сложно давать, поскольку каждая новая задача уникальна. Из SCRUM пришел подход, связанный с оценкой в условных и абстрактных единицах — очках (story point).

На покере планирования (planning poker) команда присваивает пользовательским историям оценку в очках. Со временем команда понимает, сколько очков она способна в среднем закрыть за один спринт. Допустим, вы знаете «скорость» разработки. С этим знанием вы сможете более уверенно набирать задачи на спринт в пределах этого объема, и у вас будет большая уверенность, что они будут выполнены.

Приоритеты

Некоторые способы расставить приоритеты пользовательским историям/фичам/эпиками.

1. «Допущения + Важность»
Метод похож на описанный в разделе про MVP способ расставить приоритеты допущениям. А именно мы закрываем первыми такие истории, которые позволяют проверить наиболее рисковые допущения и которые одновременно мы считаем важными для пользователей. Таким образом для каждой истории мы ставим оценку от 1 до 5 или 10 по критериям:

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

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

— насколько важна задача с точки зрения бизнеса, пользователей.

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

2. BUC (Business, Users, Costs)
Метод также дает одну оценку. Она складыается из трех факторов, которые оцифровываются по любой шкале (1-5, 1-10):
— выгоды бизнеса: рост выручки, упрощение процессов, привлечение новых пользователей;
— выгоды пользователей: удобство использования, дополнительный функционал;
— затраты: насколько сложно историю закрыть.

В результате число получается сложением выгод и вычитанием затрат.

3. MOSCOW (Must, Should, Could, Would)
Этот метод впервые начали применять в 1994 году в Oracle. Истории распределяются по четырем корзинам:

• обязательно нужно сделать. Если историю не закрыть, последствия могут быть значимыми негативными.
• следует сделать. Не самые важные требования, но которые стоит закрыть после обязательных.
• могли бы сделать. Желательные требования, которые сделаем, если останутся ресурсы.
• можем и не делать. Требования зафиксированы, но можно их отложить на следующий спринт, поскольку они не повлияют серьезным образом на бизнес или пользователей.