Простота и фичеризм
Есть вещь, которая объединяет успешные продукты — они решают одну задачу и делают это лучше остальных. За счет простоты и фокуса компании привлекают первых клиентов, находят product/market fit и захватывают долю рынка. Например, Instagram стартовал как сервис чекинов Burbn. Но феноменальный рост у соцсети случился только когда основатели удалили все фичи, кроме нескольких — загрузки фотографий (причем в одном формате) и их обработки фильтрами.
С течением времени бизнес разрастается, ресурсов становится больше, но само направление развития выглядит размытым. Что делать дальше, куда бежать? Часто на этом этапе продуктовые команды начинают внедрять много крутых штук без особой приоритизации и фильтрации, просто чтобы поддерживать рост. Причин тому несколько:
- Компания не до конца понимает свою целевую аудиторию и пытается подстроиться под всех;
- Время разработчиков стоит дорого. Чтобы команда не простаивала, ей дают новые задачи в работу;
- Присутствует страх, что конкуренты запустят новую фичу и переманят клиентов;
- На рынок выходит новая технология и, конечно же, хочется использовать её в продукте;
- Нет единого видения, как в итоге должен развиваться продукт.
Всё это зачастую приводит к новым проблемам.
Дело не в количестве фич
На первый взгляд кажется, что большое количество функций приносит больше ценности людям. Но дело обстоит ровно наоборот.
Во-первых, с увеличением количества фич новым клиентам становится сложнее обучаться, а текущим — выполнять ключевые задачи. Продукт становится лучше только для нескольких процентов продвинутых пользователей, которые давно его используют и знают вдоль и поперёк.
Во-вторых, запуск новой фичи не ограничивается только дизайном и разработкой, а включает тестирование, маркетинг и постоянную поддержку нововведения. А это приводит к дополнительной сложности в виде возможных багов и зависимостей, и как результат затратам ресурсов команды в будущем.
Как расти и сохранять простоту
Что же делать, чтобы продукт и дальше продолжал развиваться, но вместе с тем оставался понятным для людей?
Развивайте продукты вглубь, а не вширь.
Вот что можно делать, чтобы достичь этой цели:
Запускайтесь раз, итерируйте постоянно
Релиз фичи — это первый шаг на пути к её внедрению в продукт на высоком уровне качества. После релиза вы получите реакцию реального мира. Знания о том, что сработало, а с чем у пользователей возникают проблемы, которые невозможно выявить на тестах. Благодаря частым итерациям новые фичи можно сделать понятнее для пользователя. В противном же случае, такой функционал может иметь много ошибок и стать ненужным для людей.
Проводите аудит продукта
Время от времени аудируйте продукт, чтобы знать, чем пользуются ваши клиенты, а что обходят стороной. В качестве эксперимента можно проводить ухудшающие A/B тесты — отключать функционал для части пользователей и смотреть на реакцию. Возможно, почти никто не заметит отключение определенной фичи, а вы избавите команду и продукт от лишней нагрузки.
Не бойтесь убивать фичи
После аудита нужно понять насколько тот или иной функционал соответствует стратегии развития продукта и является ценным для пользователей. А дальше самое сложное — принять решение, стоит ли поддерживать фичу или вырезать её. Конечно, на разработку уже были потрачены время и силы, а какой-то процент клиентов мог к ней привыкнуть. Но если это ухудшает опыт подавляющего большинства пользователей, то избавляйтесь от таких фич.
Понимайте глубинную мотивацию пользователей
Не воспринимайте фидбек пользователей напрямую, а понимайте их боли и потребности. Люди любят приходить с уже готовыми решениями. Ваша цель понять в чем корень проблемы, стоит ли вашему продукту решать её и для какого процента клиентов она актуальна.
И наконец, регулярно напоминайте себе и команде, какую проблему вы решаете
В рабочей рутине и потоке задач команда забывает, какую ключевую «работу» продукт делает для пользователей. Так появляются ненужные фичи, работать с сервисом становится все сложнее и клиенты переключаются на конкурентов. Чтобы не терять фокус, важно постоянно возвращаться к вопросу «Зачем продукт существует?» в моменты принятия решений. Именно это позволяет строить продукты, которые действительно приносят пользу людям.
Важно, чтобы сервис был построен вокруг одной ключевой идеи (а не набора фич) и был целостным в понимании пользователей.
