💡 Идея: Backlog monetization
Публичный постВсем привет!
У нас в компании довольно большой бэклог/очередь из фич, накопившийся за 15 лет существования компании. При текущем количестве сотрудников нам потребуется лет 10 на то чтобы реализовать все запрошенные улучшения.
Пользователи постоянно предлагают неплохие, рабочие вещи, но как правило рук на все не хватает. Поэтому их предложения уходят в отдельную папочку Suggestions, в которой скопились сотни nice-to-have фич. А как только приходят новые платящие клиенты, свободные руки переходят на клиентский проект, поэтому ресурсов на новую интересную фичу или даже рефакторинг не хватает.
Я пытаюсь придумать, как можно было бы собрать деньги на свободные руки и разгрести папку с предложениями. В голову пришла идея, немного похожая на кикстарстер: можно разослать пользователям письмо с вариантами нескольких фич, мол, выберите функциональность, которая кажется вам самой полезной, и предложить пользователю внести сумму на разработку. Рядом с каждым предложенным функционалом будет указано сколько денег нашей компании нужно будет собрать на разработку.
Допустим, чтобы сделать фичу X, нам нужно $10,000. Малые бизнесы не готовы столько потратить на маленькую улучшалку. Но если 1,000 пользователей скинут по $10, то необходимая сумма появится и мы эту фичу начнем пилить. Если нужную сумму мы не набрали, деньги возвращаем.
Хочу спросить в клубе пробовал ли кто-нибудь сделать похожий опрос пользователей и попытаться собрать деньги на разработку? Если нет, кажется ли идея бредовой или разумной?
Для информации, мы продаем B2B решение для страховых компаний, мне кажется с B2C такое вряд ли прокатит…
Спасибо!
Ещё одна деталь. Тут есть опасность, что юзеры будут голосовать за фичи, которые на самом деле продукту не нужны и лишь добавляют сложность.
В порядке бреда: ход конем (если конечно архитектура позволяет) - открываете часть API наружу и создаете магазин пользовательских плагинов, пусть кому надо - тот сам и пилит.
Просто накидаю пару мыслей:
Являюсь владельцем аналогичного бэклога на 1568 задач.
Моя практика показывает, что 95% этих потребностей появляются лишь однажды, относятся к желаниям уровня «было бы неплохо, а не «киллер-фича, куплю из-за нее» и никак не влияют на продажи продукта или ощущения от его использования.
Ваш продукт, действительно, может стать лучше от их внедрения, но каждая из таких фич потребует не только затрат на проектирование и затрат на реализацию, но и затрат на обеспечение discoverability. Без этого польза для каждого следующего клиента будет ничтожной и вы никогда не окупите эти затраты.
Как можно использовать этот бэклог? Обращаться к нему при эволюционном развитии проекта и смотреть, какие еще старые запросы можно системно удовлетворить, чтобы вы могли удалять из бэклога прямо целые группы задач, которые или уже реализованы или потеряли актуальность после появления нового функционала.
К сожалению, тот факт, что вы стали хранить все входящие запросы не означает, что от этого обязательно должна быть польза или что эти данные можно как-то полезно использовать.
Возможно, компании покупают и используют ваш продукт именно потому, что вы не делаете все эти фичи и сохраняете минимализм во всём.
😱 Комментарий удален его автором...
Вам пора почистить беклог :)
Выберите трешхолд — скажем, 1 год и удалите все неначатые задачи, которые старше года. Они не нужны никому.
Смотрите какая штука: у вас есть уже программисты — ограниченный ресурс. И они сейчас не могут пилить малоприоритетные фичи из беклога, потому что пилят важные для продукта фичи. То есть фичи, которые принесут больше денег (по мнению бизнеса).
Одновременно вы предлагаете как-то где-то собирать деньги, чтобы пилить малозначимые фичи. Кто их будет пилить? Если те же самые программисты — то это конкуренция с важной работой, это плохо.
Если же вы планируете нанять программистов для пиления малозначимых фич — то это добавит оверхеда всей вашей организации как по найму-рампапу-управлению этими новонанятыми программистами, так и сбором денег с беклога, возвратом денег за недопроданные фичи ну и в конце-концов выравниванием нагрузки на программистов. Это больно.
Варианты потому могут быть такие:
После чего экспериментировать, как эти фичи монетизировать:
Делаем конструктор, то есть у нас один проект и много мобильных прилок.
ПМу казалось классной идея продавать беклог и потом раскатывать фичу на всех, и деньги и фичи - все круто.
Но как правило эти фичи с какими-то хотелками, которые потом не подойдут всем, делать надо сразу максимально гибко, а клиент если заплатил, то он хочет чтоб сделали максимально удобно ему. К тому же то, что мы делаем сейчас будет тормозить.
Первые разы я соглашался, потом мы мучались с тем чтобы все красиво встроить в проект и тормозились в тех задачах, которые помогут развиваться.
Теперь я максимально торможу продукта от таких классных идей)
Мне кажется, такое предложение среди значительной части пользователей могут вызывать раздражение.
Если просто собрать "голоса" за фичи - тогда можно и бюджет запланировать, и план, и выделить в отдельюную подписку - что там продакт напридумывает.
И все же большинство платящих пользователей скажет "wat?"
ИМХО такая идея может проканать только в варианте исполнения вживую на каком-нить ивенте. Доклад, слеза, дайтедолор. Ну и вот на моменте кто-то зеленью и проголосует.
Стандартная практика — кастом девелопмент. Клиент хочет улучшить/переделать что-то, он платит за разработку этой фичи, фича улетает всем.
Ну и внедрение фич можно сделать постоянным процессом — каждый день по чуть-чуть, а не наскоком все сразу.
Стоит пойти от обратного и оценить сколько денег фича принесет, и исходя из этого решать стоит ли занять ей разработчика или хвататься за нового клиента.
Ну и в топку рефакторинги, которые не добавляют ценности продукту.
И еще, не задумывались о том, что не удавшийся кикстартер отпугнет клиентов?