Лишние функции: о чем точно не надо беспокоиться, создавая MVP

Лишние функции: о чем точно не надо беспокоиться, создавая MVP

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

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

В работе над продуктом в целом очень легко увлечься “украшательством” и забыть о главном. Вот еще несколько примеров из нашей ранней практики, которые нас с командой многому научили:

✅Мы внедряли функции, о которых просили 1-2 пользователя. Конечно, мы ценили обратную связь, и хотелось сделать продукт лучше. Из таких примеров - возможность оставлять заметки к заказам. Мы внедрили функционал, но за месяц им воспользовались 1 или 2 раза. Кто-то из пользователей просил добавить возможность оставлять чаевые. По факту их никто не оставлял. Мы стремились дать пользователям широту вариантов оплаты, подключали интеграции с разными платежными системами, но по факту все в основном платили картами или посредством СБП.

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

✅Мы меняли внутренний функционал проекта для удобства команды. Как только команда сменилась, улучшения стали никому не нужны.

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

✅Однажды мы занимались запуском проекта на американском рынке. Когда работали над ним, создали его на двух языках: на английском и на испанском (испанский - второй по популярности язык в США). В угоду пользователю заморочились над тем, чтобы аватарки можно было поставить как со светлым, так и с темным цветом кожи. В результате проект популярности не нашел, но дело было вовсе не в языках и аватарках.

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