Как решить, какой пользовательский фидбэк стоит реализовать (а какой отпустить)
Как только люди начинают пользоваться вашим приложением, запросы льются рекой. Вот простой способ решить, какой пользовательский фидбэк стоит реализовать с помощью ИИ-конструктора приложений, какой отложить, а какому вежливо сказать «нет».
Первые несколько недель после того, как люди начинают пользоваться вашим приложением, — тихие. Потом начинаются сообщения. «Можете добавить тёмную тему?» «Было бы здорово экспортировать в PDF». «Можете сделать кнопку синей?» «Нам очень нужны интеграции с инструментом, которым мы уже пользуемся». За месяц у вас накапливается список из сорока пунктов и ИИ-конструктор приложений, который с радостью соберёт любой из них за полдня.
Вот эта последняя часть и есть ловушка. Когда сборка каждой функции дёшева и быстра, трудным вопросом перестаёт быть «могу ли я это построить?» и становится «стоит ли?». Узкое место смещается с ваших рук на вашу способность судить — а руководства по этому вам никто не вручает.
Этот пост — простой способ рассортировать входящий фидбэк по трём стопкам — реализовать, отложить, отпустить — без необходимости быть продакт-менеджером. Цель не в том, чтобы говорить людям «нет». Цель в том, чтобы то, что вы реализуете, действительно двигало ваше приложение вперёд.
Почему «просто реализуй» перестаёт работать
Для первых десяти функций «просто реализуй то, что просят» — нормальная стратегия. У вас ещё недостаточно пользователей, чтобы их мнения противоречили друг другу, и каждая функция делает приложение полезнее, чем та пустота, которой оно было на прошлой неделе.
Это перестаёт работать примерно тогда, когда у вас появляются реальные, разные пользователи. Фрилансер хочет одно, небольшое агентство хочет противоположное, а случайный посетитель хочет что-то, чем ни тот, ни другой никогда не воспользуется. Реализуйте все три — и ваше приложение превратится в ящик с хламом: всего полно, ничего не найти, тяжело таскать. Каждая добавленная функция — это функция, которую вам придётся вечно поддерживать в рабочем состоянии, объяснять новым пользователям и не сломать, когда вы меняете что-то рядом.
ИИ-конструктор приложений делает это хуже, прежде чем сделать лучше, потому что убирает естественный тормоз. Когда функция занимала у разработчика две недели, вы крепко задумывались, стоит ли она этих двух недель. Когда у конструктора она занимает двадцать минут, вы не задумываетесь вовсе — просто говорите «да». Цена никуда не делась. Она переехала из «времени на сборку» в «вес, который нести», а вес заметить труднее.
Три вопроса, которые сортируют почти всё
Когда приходит запрос, прогоните его через три вопроса по порядку. Большинство вещей сортируются уже после первых двух.
1. Помогает ли это тем, для кого я это строил? Вы строили своё приложение для кого-то конкретного — свадебных фотографов, тренеров детских футбольных команд, ведущих инди-подкастов. Запрос от одного из таких людей стоит больше, чем запрос от того, кто забрёл случайно и больше не вернётся. Если функция помогает вашим ключевым людям делать то главное, ради чего они пришли, — она идёт ближе к верху. Если она помогает посетителю, который вам не совсем пользователь, — ближе к низу, как бы громко он ни просил.
2. Сколько людей реально будут этим пользоваться? Не «кто попросил» — а кто будет пользоваться. Один человек, просящий громко, — это не то же самое, что десять, кому это тихо пригодилось бы. Будьте честны здесь, потому что громкие запросы кажутся большими запросами, а обычно таковыми не являются. Хороший признак: спросите человека, что он делает вместо этого сегодня. Если у него есть неуклюжий обходной путь, которым он пользуется ежедневно, — это реальная потребность. Если он «наверное, иногда бы пользовался» — это «приятно иметь», нарядившееся в костюм.
3. Во что мне обойдётся нести это вечно? Некоторые функции лёгкие. Новый вариант цвета, переформулированная подпись, лишнее поле в форме — реализовал и забыл. Некоторые функции тяжёлые: всё, что касается платежей, всё, что отправляет письма реальным людям, всё, что добавляет целый новый раздел со своими правилами. Тяжёлые функции — не плохо, но они должны заслужить свой вес, пройдя первые два вопроса с запасом.
Три стопки
Прогоните эти вопросы — и почти всё ляжет в одно из трёх мест.
Реализовать. Помогает вашим ключевым людям, ею воспользуются несколько человек, а цена «нести» разумна. Это лёгкие случаи. Делайте — и сообщите тому, кто попросил: люди, которые видят свою идею выпущенной, становятся вашими самыми лояльными пользователями и вашим лучшим источником следующей хорошей идеи.
Отложить. Идея хорошая, но рано, или хочет её только один человек, или она тяжёлая, а вы пока не уверены. Не говорите «нет» и не реализуйте. Запишите её туда, куда вы реально будете заглядывать, — простой список, заметка, доска. Если за следующий месяц о том же попросят ещё трое — она сама повысила себя до стопки «реализовать» и сама вам об этом сказала. «Отложить» — это не кладбище, это зал ожидания.
Отпустить. Не вписывается в то, для чего ваше приложение, послужит лишь одному человеку или сделает приложение хуже для всех остальных. Тут нужно вежливое, честное «нет». «Это вдумчивая идея, но я не планирую её добавлять — вот что я бы предложил вместо этого» сохраняет отношения и защищает приложение. Умение сказать «нет» — это тоже функция. Каждое «нет» — это «да» тому, чтобы приложение оставалось достаточно простым, чтобы люди его понимали.
Небольшой пример
Одна наша знакомая держит приложение для записи к преподавателям музыки, собранное целиком с помощью ИИ-конструктора приложений. За одну неделю ей пришло три запроса: преподаватель хотел автоматические напоминания ученикам по SMS, родитель хотел способ видеть уроки всех своих детей в одном месте, а один человек хотел перевести приложение на латынь «ради забавы».
Напоминания прошли все три вопроса — ключевые пользователи, с прогулами сталкиваются многие, и SMS-функция тяжёлая, но того стоит. Реализовано. Родительский режим был хорошей идеей от одного человека, поэтому она его отложила; за три недели попросили ещё двое родителей, и он сам себя повысил. Перевод на латынь получил тёплое «нет». Ни одно из этих решений не потребовало таблицы. Им хватило трёх вопросов и готовности честно ответить на третий.
То, о чём вам никто не говорит
Самый сложный фидбэк — не плохие идеи. Это хорошие идеи от людей, которые вам симпатичны, для приложения, которое не может быть всем сразу. Отпускать их ощущается как подвести человека. Это не так. Самое доброе, что вы можете сделать для людей, которые пользуются вашим приложением, — держать его достаточно сфокусированным, чтобы оно оставалось хорошим в том одном деле, ради которого они пришли.
В следующий раз, когда запросы накопятся, не открывайте сначала ИИ-конструктор приложений. Откройте свой список, прогоните каждый пункт через три вопроса и рассортируйте по стопкам. Сборка теперь — лёгкая часть. Решать, что стоит собирать, — вот настоящая работа, и эту работу вы можете делать, не написав ни строчки кода.