Как приоритизировать фичи до MVP и немного после

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

Сегодня я бы хотел рассмотреть некоторые техники в расставление приоритетов запусков задач. Это статья будет полезна прежде всего тем, кто готовится к MVP или только недавно его запустили и планомерно развивают проект. О приоритизации в давно уже запущенном продукте поговорим в следующих статьях.И так, вы сгенерировали много идей, вывели гипотезы, проверили их и теперь у вас есть с десяток, а то и больше «киллер фич», которые просто обязаны быть в продукте. Отлично, вы молодец, запускаем!

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

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

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

1. Шаг первый. Сделаем таблицу, в котором выпишем все наши фичи. Вместе с командой напротив каждой задачи ставим оценку либо 0, либо 1. Оценка зависит от необходимости данной фичи в MVP. Еще раз, от необходимости, то есть тех задач, которые необходимы, чтобы продукт начал работать! Если мы изобрели велосипед, то для запуска, нам нужны из фич только рама, колеса, руль и тормоза. Им и проставляем единицы. Багажник, крепления для воды, крылья и т.п. - это все те задачи, без которых пользователь сможет обойтись на первом этапе.
Конечно, это банальный и понятный пример. Если ваш продукт немного сложнее, чем просто велосипед, а, например, горный электровелосипед, то и список фич будет не такой очевидный. Именно для этого нам и нужно мнение команды. Но еще раз, 1 - это только то, что жизненно необходимо. Надо понимать, в вашем случае, помимо рамы, колес, тормозов и руля, будут необходимы и такие вещи, как электромотор и зубастая резина (то, что сделает ваш продукт отличающимся) Как итог, оставьте только те задачи, которые собрали наибольшее количество единиц.

2. Шаг второй. Запустили мы MVP, все худо-бедно работает и замечательно! Но теперь пришла пора наш продукт "допиливать", добавлять новые функции на радость пользователя, на благо нам. Пришло время вернуться к бэклогу, где у нас лежат фичи, которые не вошли в первоначальный проект. Выписываем их в таблицу и просим нашу команду выставить оценки от 1 до 3 по мере того, какие фичи они считают наиболее важными, где 1 - не важно, 3 - очень

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

После этого значения важности делим на значения затрат и получаем процентное соотношение:

И так, у нас получается, что в следующем релизе в наш продукт должны попасть фара и багажник

3. Для фильтрации остальной части фич, мы используем модель Кано. Суть это метода в следующем:
Существуют основные шкалы для измерения фич
- Attractive (привлекательные функции, вызывающие восторг)
- One dimensional (это функции, в которых существует прямая одномерная связь между улучшением качества функции и удовлетворенностью клиентов, например объем памяти смартфона или батарея большой емкости)
- Expected (ожидаемые, обязательные функции, без которых сервис не может полноценно существовать)
- Indifferent (безразличные, наличие или отсутствие данных сервисов для пользователя не имеет значения)
- Reverse (функции, которые раздражают пользователей)

И так, на этапе валидации гипотез, вы уже проводили CastDev, думаю, объяснять нюансы не имеет смысла.
Сейчас же, нам надо также использовать респондентов из нашей ЦА и подготовить для них вопросы. Если оставшихся фич много, разбейте их и респондентов на группы в любом порядке. Одной группе интервьюируемых задавайте вопросы по фичам также из одной группы. Так надо сделать, чтобы не утомить опрашиваемых.
По каждой фичи нужно задать два вопроса
- Функциональный: "Какое будет ваше отношение, если эта функция будет в продукте?"
- Нефункциональный: "Какое будет ваше отношение, если этой функции не будет в продукте?"
На каждый из этих вопросов по каждой из фич, пользователь должен ответить следующим образом:
- Да, мне это понравится
- Это ожидаемо (имеется ввиду, что наличие/отсутствие подразумевается по умолчанию)
- Безразлично
- Я смогу это пережить
- Мне это очень не понравится

Следующий шаг - заполняем таблицу ответов:

Например, на вопросы по добавлению крыльев на велосипед респондент отвечает так:
- "Какое будет ваше отношение, если эта функция будет в продукте?" - говорит, что это ожидаемо
- "Какое будет ваше отношение, если этой функции не будет в продукте?" - говорит, что ему это очень не понравится
Смотрим, что у нас получается. На пересечение пункта 1 Функционального вопроса и пункта 5 Нефункционального стоит буква "E". Следовательно, данная фича для человека будет ожидаема, как само собой разумеющееся. А для нас - обязательна к добавлению

Когда вы опросили, например 10 пользователей, вы вносите общие данные в такую таблицу и считаете, какая буква попадается чаще:

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

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

P.S. И пожалуйста, не относитесь к фичам, как к своим детям. Не бойтесь отказываться от них, если оно того требуется!