Обновить

Самый громкий клиент не всегда самый важный

Есть одна интересная ловушка в продуктовой разработке.

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

И есть ещё сотня пользователей, которые ничего не предлагают. Просто работают и периодически платят.

Угадайте, чьи пожелания команда будет обсуждать чаще? :)

С первым всё понятно. Он подробно объяснил проблему, прислал скриншоты, расписал сценарий использования. Можно практически сразу заводить задачу.

А остальные молчат.

И постепенно получается интересная история. Мы начинаем развивать продукт под тех, кто лучше всех умеет объяснять свои потребности и идеи. Но это не озачант что эти изменения действительно важны.

Особенно весело становится, когда активный клиент ещё и крупный. Тут уже любое пожелание легко превращается в «стратегически важную доработку».

Я не говорю, что активных клиентов не нужно слушать. Наоборот, их обратная связь часто очень полезна.

Но между «клиент попросил» и «нам нужно это разработать» должен быть ещё один вопрос.

А рядовые пользователи сталкивается с этой проблемой?

Причём спрашивать стоит не только тех, кто пишет в поддержку. Иногда люди молча терпят неудобство годами, а потом просто уходят к конкуренту.

В итоге самое сложное в работе продакта, наверное, не собрать пожелания пользователей. А научиться иногда говорить «нет» даже очень хорошему клиенту.

И желательно до того, как команда потратит месяц на функцию, которая нужна только ему.

А у вас бывало, что разработали что-то по настойчивой просьбе клиента, а потом выяснилось, что больше этим почти никто не пользуется?

Теги:
0
Комментарии0

Почему UFW не спасает от Docker: анатомия сетевой подставы и что ищут боты в открытых портах БД

Типичная картина при переезде на свежий VPS. Подняли чистую Ubuntu или Debian под новый проект, сразу навели базовый порядок: ufw default deny incoming, снаружи оставили только 22, 80 и 443. Глянули ufw status — всё четко, лишнего не торчит. Дальше ставится Docker, через компоуз взлетает бэкенд с PostgreSQL и Redis. Чтобы удобно ходить в базу с ноута через DBeaver и гонять миграции, на автомате дописываем ports: - "5432:5432". Кажется, что мы в домике: наружу ничего не светит, фаервол же режет всё, кроме веба и SSH.

А через пару дней прилетает абуза от хостера или срабатывает алерт в мониторинге: все ядра в полке, в htop резвится какой‑нибудь kdevtmpfsi или kinsing, а вместо таблиц в базе лежит одна записка README_TO_RECOVER с биткойн‑кошельком. Грабли старые, как сам Docker. Но на них с завидной регулярностью наступают и джуны, и вполне опытные админы, привыкшие доверять выводу ufw status.

Почему UFW не спасает от Docker: анатомия сетевой подставы и что ищут боты в открытых портах БД

Публикации