💡 Идея: Backlog monetization  Публичный пост

Всем привет!

У нас в компании довольно большой бэклог/очередь из фич, накопившийся за 15 лет существования компании. При текущем количестве сотрудников нам потребуется лет 10 на то чтобы реализовать все запрошенные улучшения.

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

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

Допустим, чтобы сделать фичу X, нам нужно $10,000. Малые бизнесы не готовы столько потратить на маленькую улучшалку. Но если 1,000 пользователей скинут по $10, то необходимая сумма появится и мы эту фичу начнем пилить. Если нужную сумму мы не набрали, деньги возвращаем.

Хочу спросить в клубе пробовал ли кто-нибудь сделать похожий опрос пользователей и попытаться собрать деньги на разработку? Если нет, кажется ли идея бредовой или разумной?
Для информации, мы продаем B2B решение для страховых компаний, мне кажется с B2C такое вряд ли прокатит…

Спасибо!

14 комментариев 👇

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

  Развернуть 1 комментарий

@slonoed, мы будем предлагать уже отфильтрованный список, который прошел через наших аналитиков, которые уверены что эти фичи точно сделают систему немного лучше

  Развернуть 1 комментарий
Anton Markelov, Тимлидю (тимлижу?) инженеров инфраструктуры 24 февраля в 06:54

В порядке бреда: ход конем (если конечно архитектура позволяет) - открываете часть API наружу и создаете магазин пользовательских плагинов, пусть кому надо - тот сам и пилит.

  Развернуть 1 комментарий

@strangeman, пока не позволяет, но подумаем над этим... спасибо!

  Развернуть 1 комментарий
Pavel Ditenbir, Lead Software Engineer/Manager в области видео и стриминга 24 февраля в 03:31

Просто накидаю пару мыслей:

  • в опен сорс мире есть bounties, когда есть ряд фич, на которые собирают "с миру по нитке", и тот, кто решит сделать эту фичу, получит собранную сумму
  • возвращать $10 сотням и тысячам клиентов каждый раз, когда не набрали сумму будет геморно, минус налоги. Для этого потребуется отдельный менеджер или даже отдел (с зарплатой, естественно), новые процессы и прочее
  • поддержка продукта с кучей разношерстных фич "за 10 баксов" усложняется. Фокус внимания на основных жирных с точки зрения прибыли размоется. UI усложняется из-за мелких неосновных фич
  • в итоге, есть вероятность, что эти фичи уйдут в минус, если учитывать увеличение процессов в компании (всм. выше), увеличесвшуюся кодовую базу и экстра-архитектурные надстройки
  • иногда даже $10000 - не та сумма, на которую имеет смысл отвлекаться с кучей издержек
  • (вопрос на подумать лично вам) чем лично вам мешают задачи низкого приоритета? По моему опыту (B2B) таких задач всегда достаточно много. Лежат где-то внизу, не отсвечивают. Если сортировку или фильтр не применить - их как будто и нет
  • нельзя угодить всем :)
  • можно вынести кучу более дешевых фич в отдельный более дешевый продукт или план (в случае подписки)
  Развернуть 1 комментарий

@DiPaolo, спасибо за мысли! про open-source bounties не знал, пошел гуглить...

чем лично вам мешают задачи низкого приоритета?

Периодически новые пользователи просят похожие вещи, а мы руками разводим и головой киваем, что добавим в очередь.

  Развернуть 1 комментарий

Являюсь владельцем аналогичного бэклога на 1568 задач.

Моя практика показывает, что 95% этих потребностей появляются лишь однажды, относятся к желаниям уровня «было бы неплохо, а не «киллер-фича, куплю из-за нее» и никак не влияют на продажи продукта или ощущения от его использования.

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

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

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

  Развернуть 1 комментарий

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

  Развернуть 1 комментарий
Миша Гусаров, Инженегр-погромист 24 февраля в 08:51

Поднять всем цену и нанять дополнительных людей, нет?

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

  Развернуть 1 комментарий

Вам пора почистить беклог :)

Выберите трешхолд — скажем, 1 год и удалите все неначатые задачи, которые старше года. Они не нужны никому.

Смотрите какая штука: у вас есть уже программисты — ограниченный ресурс. И они сейчас не могут пилить малоприоритетные фичи из беклога, потому что пилят важные для продукта фичи. То есть фичи, которые принесут больше денег (по мнению бизнеса).

Одновременно вы предлагаете как-то где-то собирать деньги, чтобы пилить малозначимые фичи. Кто их будет пилить? Если те же самые программисты — то это конкуренция с важной работой, это плохо.

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

Варианты потому могут быть такие:

  1. нанимать студентов на практику или джунов, которые бы пилили те малозначимые фичи, после чего выкатывать их методом Canary Deployment, валидировать что новые фичи не портят жизнь основному костяку пользователей,
  2. объявить внутренний хакатон — вдруг кто-то из основных программистов хочет по овертаймить и что-то запилить, за конкретный бонус (внутренняя баунти-программа)
  3. сделать систему плагинов и пока начать пилить плагины своими силами (пунктами 1 или 2).

После чего экспериментировать, как эти фичи монетизировать:

  1. в какой тарифный план включать эти фичи? Либо в бесплатный/базовый (для привлечения внимания), либо в самый дорогой (для мотивации переходить на более дорогой тариф тем клиентам, кто любит много мелких удобностей),
  2. сделать свой маркетплейс и продавать там плагины, которые вы же сами и делаете. Там же принимать предзаказы на следующий плагины: пишете, что такой-то плагин будет доступен с 1 сентября 2021 года. Цена сейчас — 20 долл на 2022й год, а остаток 2021 года даёте бесплатно. А вот тем кто купит после 1 сентября 2021 цена будет уже 30 долл, а с 1.01.2022 — 40 долл за год. Дальше маркетируете плагины всем своим клиентам. Если плагин купило сколько-то пользователей — скажем, 10, — то делаете его во что бы то ни стало. Если купило мньше 10 — то 1 сентября просто возвращаете им деньги, мол, извините, но этот плагин не пойдёт в работу.
  Развернуть 1 комментарий

Делаем конструктор, то есть у нас один проект и много мобильных прилок.
ПМу казалось классной идея продавать беклог и потом раскатывать фичу на всех, и деньги и фичи - все круто.

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

Первые разы я соглашался, потом мы мучались с тем чтобы все красиво встроить в проект и тормозились в тех задачах, которые помогут развиваться.
Теперь я максимально торможу продукта от таких классных идей)

  Развернуть 1 комментарий
Sergei Ruzki, Python Developer, ERP Architect, Odoo User 24 февраля в 11:06

Мне кажется, такое предложение среди значительной части пользователей могут вызывать раздражение.
Если просто собрать "голоса" за фичи - тогда можно и бюджет запланировать, и план, и выделить в отдельюную подписку - что там продакт напридумывает.
И все же большинство платящих пользователей скажет "wat?"

ИМХО такая идея может проканать только в варианте исполнения вживую на каком-нить ивенте. Доклад, слеза, дайтедолор. Ну и вот на моменте кто-то зеленью и проголосует.

  Развернуть 1 комментарий
Влад Клюев, Дизайнер, js-разработчик. 24 февраля в 21:13

Стандартная практика — кастом девелопмент. Клиент хочет улучшить/переделать что-то, он платит за разработку этой фичи, фича улетает всем.

Ну и внедрение фич можно сделать постоянным процессом — каждый день по чуть-чуть, а не наскоком все сразу.

  Развернуть 1 комментарий
Александр Заозерский, Руковожу разработкой 24 февраля в 21:36

Стоит пойти от обратного и оценить сколько денег фича принесет, и исходя из этого решать стоит ли занять ей разработчика или хвататься за нового клиента.

Ну и в топку рефакторинги, которые не добавляют ценности продукту.

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

  Развернуть 1 комментарий

😎

Автор поста открыл его для большого интернета, но комментирование и движухи доступны только участникам Клуба

Что вообще здесь происходит?


Войти  или  Вступить в Клуб