Грамотно и вовремя выбирать фичи для разработки и не прогадать – это про искусство приоритизации. Как найти критерии оценки, необходимые для своего продукта, вырастить стратегические показатели, предложить клиентам еще больше ценности, наладить все внутренние процессы в команде и добиться других наглядных показателей с помощью качественной приоритизации?
Эта статья написана по материалам доклада “Что дальше? Или искусство приоритизации”, с которым я выступил 26 июня на конференции BDS. Marketing.
В докладе я рассказал о том, как мы приоритизируем фичи в компании Hygger.io — системе управления проектами для продуктовых команд.
Прежде чем перейти к описанию нашего процесса, хочу кратко напомнить о том, почему приоритизация так важна.
Управление продуктом состоит из трех больших блоков:
На стадии планирования мы «лепим» образ будущего продукта. И очень важно использовать такие материалы, которые улучшат показатели нашего продукта, его прибыльность, его UX, UI и так далее.
И не будем кривить душой — я думаю, что многие product managers кайфуют от такой «лепки». От возможности влиять на то, каким будет продукт.
Легко взять и потратить бесценное время команды на разработку фич, которые никому не нужны. Особенно эта проблема актуальна для стартапов, время и бюджет которых очень сильно ограничены.
Стоит вспомнить интуицию — нашего лучшего «помощника», который постоянно «шепчет» нам на ухо: «Вот эта фича ну точно всех порвет!» И в другое ухо: «А вот эта фича догонит и порвет всех, кого не порвала первая фича».
Мы делаем такие фичи и потом удивляемся, почему вообще ничего не изменилось в продукте.
Известный в Силиконовой долине Marty Cagan в своей книге Inspired выделил три типа менеджеров продукта:
В условиях жесткой конкуренции и неопределенности, в которой находятся как стартапы, так и бизнесы, жизненно важно уметь проводить правильную приоритизацию.
Теперь я хочу рассказать о процессе, который помогает нам в Hygger выбирать будущие фичи и делать продукт все лучше и лучше.
На самом деле, все просто: мы ставим себе цели на 2 месяца, выбираем метрики для контроля, собираем и отбираем идеи, которые могут улучшить эти метрики. Далее мы проводим бережливую приоритизацию идей, делаем скоринг фич, и, наконец, пишем ТЗ на фичи, которые выиграли. Вот и все — фичи готовы к разработке.
Если все это систематизировать:
Теперь подробнее.
У нас в продукте есть 2-х недельный trial. Мы хотим увеличить число компаний, которые после триала покупают платную подписку. Это наша основная цель на ближайшие 2 месяца. Также нам нужно отстроиться от конкурентов, ибо на рынке порядка 500 систем для управления проектами.
У нас есть основная метрика и вспомогательные. Важно, что все эти метрики находятся в нашей зоне влияния.
Основная метрика — конверсия trial-to-paid.
Второстепенные метрики:
AHA-момент — это момент, когда пользователь понял ценность продукта для себя или даже использовал эту ценность.
У каждого продукта своя ценность. Например, в Tinder это успешный обмен сообщениями, в Facebook — просмотр непустой ленты в течение какого-то времени.
Пользователей, которые прочувствовали эту ценность мы называем активированными. Наша задача увеличить число таких пользователей. В Facebook посчитали и выяснили, что на активацию влияет число друзей — чем больше друзей, тем больше лента и тем больше времени юзер зависает в ленте и больше рекламы смотрит.
Вот главные источники обратной связи для нашего продукта:
Так как фидбэка у нас очень много, то мы постоянно наводим порядок в нашем продуктовом бэклоге. Это помогает нам быстро находить нужные вещи и не отвлекаться на ненужные.
Как мы структурируем наш product backlog:
Из интересного отмечу то, что мы линкуем все запросы клиентов с фичами. Например, поступил запрос функции через Intercom. Support-менеджер добавляет его на доску, а менеджер продукта дальше линкует эти запросы к фичам. Таким образом, мы оцениваем, насколько будет востребована та или иная фича.
Периодически, по мере накопления новых идей мы оцениваем их с помощью метода Lean Prioritization. Это простая матрица 2x2 c двумя осями — сложность и ценность:
В каждом продукте под Value понимают что-то свое. В нашем случае, Value получают фичи, которые:
1) Улучшают метрики конверсии trial-to-paid (metrics movers)
2) Помогают привлечь новых пользователей (aha-момент)
Это фичи, которые помогают нам зацепить новых пользователей во время онбординга. Но не нужно забывать про то, что большинство юзеров «отвалиться» уже на второй день. Например, в SaaS отличным показателем для day 1 retention считается 15%. То есть 85% людей попросту уходят на второй день. Поэтому здесь следует думать про фичи, которые увидит как можно больше новых пользователей как можно ближе к моменту регистрации.
3) Помогают удержать старых пользователей
Клиенты купили подписку и теперь просят сделать какую-то фичу. Мы не «бросаемся» слепо делать все подряд. Мы накапливаем статистику по каждой фиче — сколько клиентов ее просили. И потом делаем самые востребованные фичи.
4) Добавляют ценности продукту и отстраивают нас от конкурентов
На рынке порядка 500 систем управления проектами. Чтобы выжить и преуспеть, нам нужно делать что-то совершенно новое, желательно кратно улучшающее жизнь пользователей или кратно сокращающее издержки.
Здесь мы ищем фичи, которые могут дать нам конкурентное преимущество, то есть создадут причину, из-за которой клиенты конкурентов придут к нам. Это конкурентное преимущество должно быть уникально, трудно повторимо и, в идеале, не воспроизводимо.
Для оценки идей мы используем Planning Poker:
Daniel Zacarias собрал в коллекцию 20 техник приоритизации и сгруппировал их по двум свойствам — внешняя/внутренняя и количественная/качественная техника.
Пример внешней количественной техники — модель Кано, где мы даем опросник пользователям. А пример внутренней количественной техники — Lean Prioritization (или Value vs Cost). Я описал этот метод выше.
Скорим мы не все фичи, а только те, которые выиграли в Lean Prioritization, потому что скоринг — трудозатратная операция.
Мы оцениваем каждую фичу по выбранным критериям, по шкале от 0 до 10. Далее эти значения умножаем на веса и получаем некую финальную числовую оценку, которая позволяет нам сравнивать фичи между собой.
Вот различные критерии, которые можно использовать для скоринга:
Итак, какие результаты принес нам этот процесс:
А как вы выбираете фичи для разработки?
Эта статья написана по материалам доклада “Что дальше? Или искусство приоритизации”, с которым я выступил 26 июня на конференции BDS. Marketing.
В докладе я рассказал о том, как мы приоритизируем фичи в компании Hygger.io — системе управления проектами для продуктовых команд.
Прежде чем перейти к описанию нашего процесса, хочу кратко напомнить о том, почему приоритизация так важна.
Почему без приоритизации не выжить?
«Управление продуктом» означает принятие решения о том, что мы делаем для продукта, а затем его реализацию.
Райан Сингер, продуктовая стратегия Basecamp
Управление продуктом состоит из трех больших блоков:
- User research (исследование пользователей)
- Planning (планирование)
- Execution (исполнение)
На стадии планирования мы «лепим» образ будущего продукта. И очень важно использовать такие материалы, которые улучшат показатели нашего продукта, его прибыльность, его UX, UI и так далее.
И не будем кривить душой — я думаю, что многие product managers кайфуют от такой «лепки». От возможности влиять на то, каким будет продукт.
Отвлекающие факторы буквально убивают стартапы. Строительство ради строительства подобно самоубийству. Поэтому наличие строгого и честного процесса приоритизации для разработки функций имеет решающее значение для контроля внимания и устранения лишнего.
Бен Йосковитц, автор Lean Analytics, инвестор и стартап ментор.
Легко взять и потратить бесценное время команды на разработку фич, которые никому не нужны. Особенно эта проблема актуальна для стартапов, время и бюджет которых очень сильно ограничены.
Заблуждается тот, кто считает, что новая добавленная фича сразу заставит людей захотеть использовать весь продукт.
Джошуа Портер, UX директор в HubSpot
Стоит вспомнить интуицию — нашего лучшего «помощника», который постоянно «шепчет» нам на ухо: «Вот эта фича ну точно всех порвет!» И в другое ухо: «А вот эта фича догонит и порвет всех, кого не порвала первая фича».
Мы делаем такие фичи и потом удивляемся, почему вообще ничего не изменилось в продукте.
Известный в Силиконовой долине Marty Cagan в своей книге Inspired выделил три типа менеджеров продукта:
- Backlog administrator. Его задача — просто аккуратно сложить все «хотелки» CEO и ничего не потерять.
- Roadmap administrator, который уже может что-то предложить сам, но решает все равно группа стейкхолдеров.
- Настоящий менеджер продукта. Только этот тип может принимать решения самостоятельно. Вот именно таким менеджерам и пригодится мой процесс. Если вы менеджер другого типа — меняйте работу, потому что изменить mindset CEO очень сложно.
В условиях жесткой конкуренции и неопределенности, в которой находятся как стартапы, так и бизнесы, жизненно важно уметь проводить правильную приоритизацию.
Процесс приоритизации в Hygger
Теперь я хочу рассказать о процессе, который помогает нам в Hygger выбирать будущие фичи и делать продукт все лучше и лучше.
На самом деле, все просто: мы ставим себе цели на 2 месяца, выбираем метрики для контроля, собираем и отбираем идеи, которые могут улучшить эти метрики. Далее мы проводим бережливую приоритизацию идей, делаем скоринг фич, и, наконец, пишем ТЗ на фичи, которые выиграли. Вот и все — фичи готовы к разработке.
Если все это систематизировать:
- Формулируем цели компании на 2 месяца
- Выбираем метрики под цели
- Собираем и организуем идеи
- Проводим непрерывную Lean-приоритизацию
- Делаем скоринг фичей
- Детализируем фичи и складываем их в очередь.
Теперь подробнее.
Формулируем Цели
У нас в продукте есть 2-х недельный trial. Мы хотим увеличить число компаний, которые после триала покупают платную подписку. Это наша основная цель на ближайшие 2 месяца. Также нам нужно отстроиться от конкурентов, ибо на рынке порядка 500 систем для управления проектами.
Выбираем Метрики
У нас есть основная метрика и вспомогательные. Важно, что все эти метрики находятся в нашей зоне влияния.
Основная метрика — конверсия trial-to-paid.
Второстепенные метрики:
- Конверсия посетителей в регистрации
- Активация (aka AHA moment)
- Удержание — retention 1d.
AHA-момент — это момент, когда пользователь понял ценность продукта для себя или даже использовал эту ценность.
У каждого продукта своя ценность. Например, в Tinder это успешный обмен сообщениями, в Facebook — просмотр непустой ленты в течение какого-то времени.
Пользователей, которые прочувствовали эту ценность мы называем активированными. Наша задача увеличить число таких пользователей. В Facebook посчитали и выяснили, что на активацию влияет число друзей — чем больше друзей, тем больше лента и тем больше времени юзер зависает в ленте и больше рекламы смотрит.
Собираем идеи
Вот главные источники обратной связи для нашего продукта:
- Системы поддержки пользователей (customer support: Intercom.com, Zendesk.com)
- Inspectlet.com (или AppSee.com для мобильных устройств) — запись на видео пользовательских сессий
- NPS. Каждый месяц мы задаем вопрос — Насколько вероятно вы порекомендуете нас друзьям или коллегам? Wootric.com, Satismeter.com. Пользователи раз в месяц отвечают на этот вопрос от 1 до 10 и также могут указать свой комментарий.
- Продуктовая аналитика (Amplitude.com) — просматриваем аналитику и формулируем новые гипотезы.
- Анализ конкурентов (Feedly.com) — внимательно читаем все анонсы конкурентов и изучаем их новые фичи.
- Интервью (Custdev.com, Temi.com, Rev.com) — записываем аудио интервью и потом делаем транскрибирование не сами, а с помощью внешних сервисов.
- A/B тесты
- Обзоры. Используем App Store, Google Play, Capterra.com, Appfollow.io или Appannie.com
- UX тестирование
- Опросы
Организуем идеи
Так как фидбэка у нас очень много, то мы постоянно наводим порядок в нашем продуктовом бэклоге. Это помогает нам быстро находить нужные вещи и не отвлекаться на ненужные.
Как мы структурируем наш product backlog:
- по компонентам (backend, frontend, API, mobile apps)
- по сфере применения (UX, marketing, tech debts, bugs)
- отмечаем «флагами» самое стратегически-важное
- линкуем инсайты и фичи, чтобы понять востребованность фич.
Из интересного отмечу то, что мы линкуем все запросы клиентов с фичами. Например, поступил запрос функции через Intercom. Support-менеджер добавляет его на доску, а менеджер продукта дальше линкует эти запросы к фичам. Таким образом, мы оцениваем, насколько будет востребована та или иная фича.
Делаем Lean-приоритизацию
Периодически, по мере накопления новых идей мы оцениваем их с помощью метода Lean Prioritization. Это простая матрица 2x2 c двумя осями — сложность и ценность:
- Ценность — какой вклад дает фича в продукт.
- Сложность — трудозатраты на реализацию фичи.
- Берем в работу сначала Quick Wins — фичи, которые дают большую ценность, но которые можно очень быстро запилить.
- Далее — Big Bets. Это фичи, которые могут принести большую ценность, но их трудно реализовать.
- Затем – Maybes – задачи и функции, которые не приносят большой ценности, но легко реализуются. Они могут вполне быть реализованы позже.
- И, наконец, Time Sinks. Этим фичам сейчас не нужен приоритет и должное внимание.
В каждом продукте под Value понимают что-то свое. В нашем случае, Value получают фичи, которые:
1) Улучшают метрики конверсии trial-to-paid (metrics movers)
2) Помогают привлечь новых пользователей (aha-момент)
Это фичи, которые помогают нам зацепить новых пользователей во время онбординга. Но не нужно забывать про то, что большинство юзеров «отвалиться» уже на второй день. Например, в SaaS отличным показателем для day 1 retention считается 15%. То есть 85% людей попросту уходят на второй день. Поэтому здесь следует думать про фичи, которые увидит как можно больше новых пользователей как можно ближе к моменту регистрации.
3) Помогают удержать старых пользователей
Клиенты купили подписку и теперь просят сделать какую-то фичу. Мы не «бросаемся» слепо делать все подряд. Мы накапливаем статистику по каждой фиче — сколько клиентов ее просили. И потом делаем самые востребованные фичи.
4) Добавляют ценности продукту и отстраивают нас от конкурентов
На рынке порядка 500 систем управления проектами. Чтобы выжить и преуспеть, нам нужно делать что-то совершенно новое, желательно кратно улучшающее жизнь пользователей или кратно сокращающее издержки.
Здесь мы ищем фичи, которые могут дать нам конкурентное преимущество, то есть создадут причину, из-за которой клиенты конкурентов придут к нам. Это конкурентное преимущество должно быть уникально, трудно повторимо и, в идеале, не воспроизводимо.
Planning Poker
Для оценки идей мы используем Planning Poker:
- собираемся группой
- ведущий берет идею, и группа обсуждает ее вслух, чтобы прийти к общему знаменателю и пониманию
- каждый участник оценивает идею по шкале Фибоначчи и кладет карту рубашкой вверх
- далее ведущий вскрывает все карты
- люди, которые поставили max и min поясняют свое решение
- далее команда пытается найти консенсус
- в итоге, приходим к общему знаменателю и потом переходим к следующей идее.
Техники приоритизации
Daniel Zacarias собрал в коллекцию 20 техник приоритизации и сгруппировал их по двум свойствам — внешняя/внутренняя и количественная/качественная техника.
Пример внешней количественной техники — модель Кано, где мы даем опросник пользователям. А пример внутренней количественной техники — Lean Prioritization (или Value vs Cost). Я описал этот метод выше.
Скоринг Фичей
Скорим мы не все фичи, а только те, которые выиграли в Lean Prioritization, потому что скоринг — трудозатратная операция.
Мы оцениваем каждую фичу по выбранным критериям, по шкале от 0 до 10. Далее эти значения умножаем на веса и получаем некую финальную числовую оценку, которая позволяет нам сравнивать фичи между собой.
Критерии для скоринга
Вот различные критерии, которые можно использовать для скоринга:
- целевые метрики
- увеличивает прибыль
- помогает привлечь новых клиентов
- помогает удержать старых клиентов
- ценность для пользователей
- стратегическая ценность — сейчас не даст, но потом поможет что-то сделать
- можно ли решить задачу через существующий функционал
- сильная инновация
- есть у многих конкурентов
- нужна многим пользователям
- как часто нужна
- время и стоимость разработки
- время и стоимость внедрения
- уверенность в том, что выстрелит
- ожидаемая по Кано
- желаемая по Кано
- восхищающая по Кано — wow-эффект, ценность для PR
- улучшает код (облегчает доработку и поддержку)
- Pirate Metrics (AARRR)
Результаты
Итак, какие результаты принес нам этот процесс:
- Снизили степень влияния интуиции на принятие решений — теперь мы руководствуемся не чутьем менеджера продукта, а наглядными и осязаемыми критериями оценки.
- «Поставили на место» HiPPO (highest paid person’s opinion). Hippo – это мнение человека с самой высокой зарплатой. Как правило, это босс, который может пользуется своим авторитетом при принятии решений.
- Планомерно растим стратегические показатели: стали двигаться в нужном направлении, которое ведет нас к нашей светлой цели.
- Поставляем нашим клиентам больше ценности в единицу времени. Максимизация Value – это наша цель. Мы хотим, чтобы наши клиенты получали самое важное в первую очередь.
- Команда понимает ПОЧЕМУ мы делаем конкретные фичи. Благодаря скорингу и критериям можно легко пояснить всем любопытным коллегам, почему мы взяли в работу ту или иную фичу.
- Минорные идеи прячутся и не мозолят глаза — все равно 80% идей никогда не будут реализованы. Мы уменьшили временные издержки на груминг бэклога – теперь менеджер просто не видит минорные фичи – они спрятаны от него.
А как вы выбираете фичи для разработки?
