Я впервые встретился с Виталиком Мышляевым почти 5 лет назад в Пало-Альто, когда он проходил акселерацию в 500 startups с продуктом Concert With Me. За следующие два года сервис стремительно вырос до годового оборота в несколько миллионов долларов, но потом закрылся из-за неожиданных изменений политик Facebook. После этого команда перезапустилась с новым SaaS-продуктом для автоматизации маркетинга для компаний из ивент-индустрии, вывела его на европейский и американский рынки, привлекла несколько крупных клиентов, дойдя до MRR в десятки тысяч долларов, но вынуждена была его заморозить из-за пандемии коронавируса.
Пришлось придумывать срочный план выживания. Ребята запустили новый продукт для приоритизации задач в бэклоге продукта, который сделали еще два года назад для себя, но использовали его только внутри команды.
Этот запуск привел к очень неожиданным результатам, а также к ряду интересных инсайтов о том, насколько сильно отличается опыт создания и развития продуктов с разным уровнем добавочной ценности на разных типах рынков.
В этом интервью Виталик поделился опытом запуска и развития своих прошлых продуктов, а также размышлениями о том, чем принципиально отличается опыт запуска его последнего продукта для приоритизации задач в бэклоге () от прошлых продуктов на рынке продажи билетов на ивенты.
Рост и развитие продуктов на конкурентном рынке. Или часть про важность каналов дистрибуции и независимости от платформ
Расскажи коротко про историю продукта Concert With Me.
Мы делали классический билетный eCommerce на западный рынок. Сам продукт не сильно отличался от других сайтов для покупки билетов на концерты и другие события. Наша ключевая особенность была в модели привлечения клиентов. Наша уникальная модель роста позволила за несколько лет вырасти до оборота в несколько миллионов долларов на очень конкурентном западном рынке продажи билетов.
Что было ключевым для роста Concert With Me?
Тут все классически — найти канал с дешевым трафиком, который проморгали конкуренты. Нам удалось построить большую автоматизированную систему закупки трафика через Facebook. Строилась она преимущественно на основе скрытого потенциала продукта Facebook Events. Подавляющая часть нашего трафика шла именно оттуда.
Если в классической PPC рекламе на Facebook переходы на сайт нам стоили от доллара и выше, так как приходилось конкурировать за каждый клик в разогретом аукционе, то в модели с Facebook Events переходы стоили единицы центов.
Трафик приземлялся не сразу на сайт, а на созданную в Facebook встречу. Это было лучше по ряду причин:
- Целевое действие было проще — нажать в ленте interested/going и все.
Facebook отправлял уведомления про каждый пост в ивенте (сейчас уже выборочно). - Алгоритм новостной ленты Facebook отгружал огромное количество бесплатного (вирусного) трафика, если люди хорошо подписывались на события.
- Подобрав алгоритм «переливки» трафика (кросс-пост одной встречи в другую), можно было начать получать продажи билетов без первоначальных вложений.
- Маржа с каждого проданного билета реинвестировалась в рекламу соответствующего ивента, что еще больше усиливало органический рост и, как следствие, платный маркетинг и продажи.
- И так много-много-много циклов от ивента к ивенту.
Это было настолько круто, что я даже ездил на встречу в одну из крупнейших билетных компаний мира. Показывал их отделу маркетинга, как мы умеем собирать аудиторию в Facebook Events и конвертировать ее в продажи билетов. На аналогичных ивентах у нас было в разы больше подписчиков и активности в Facebook, чем у компании, которая была лидером индустрии. Мы хотели продать им наши технологии маркетинга, но не срослось.
Как Cambridge Analytica повлияла на Concert With Me?
После потрясения Facebook из-за компания Цукерберга сначала заморозила все интеграции с API платформы, а потом очень многие возможности просто вырезала. Это сильно ударило по тем технологиям, которые мы построили для продвижения ивентов.
Также Facebook обновили многие политики компании, а спустя время ограничили рекламу билетов на мероприятия в том сегменте рынка, в котором мы работали. Тут у нас уже не было особых вариантов: пришлось закрыть сервис.
Получается, что глубокая интеграция с крупной платформой позволила быстро вырасти, но она же вас и погубила. Что вы делали дальше?
Стратегия перерождения была следующей: взять лучшее и убрать худшее из первого продукта.
Мы вытащили все маркетинговые наработки из B2C продукта, которые все еще работали в новых реалиях, пересобрали в B2B-продукт и пошли его предлагать бывшим партнерам, конкурентам и коллегам по рынку
Так на свет появился .
Расскажи историю развития вашего нового SaaS-продукта Tendee.
Tendee задумывался как маркетинговый инструмент для продвижения ивентов, который объединит в себе все нужные для этого инструменты.
Изначально мы задумывали его как self-service SaaS, но такая модель не заработала. Бизнес-модель оказалась гибридом SaaS, интегратора и агентства.
Основной пласт b2b продуктов для ивентов — это билетные системы (выпуск, учет и прием денег за билеты). При этом специализированных инструментов маркетинга не так много, а уровень автоматизации и использования сервисов для продвижения ниже, чем скажем в классическом e-commerce. Именно здесь мы видели нашу возможность.
Главным каналом продаж был личный контакт. Мы начинали с клиентами как маркетинговое агентство, которое настраивало все системы и интегрировало свой продукт. В процессе мы обучали нашему продукту и постепенно переводили его использование внутрь команд наших клиентов.
Рынок ивентов не такой широкий, онбординг клиента каждый раз проходил в ручном режиме, уникальных просьб от каждого клиента было много. Это создавало проблемы на уровне приоритизации задач и определения стратегии компании.
Что было ключевым для роста Tendee?
Для B2B сервисно-SAASной компании на достаточно закрытом и устоявшемся рынке работали только прямые продажи. А при прямых продажах самым важным оказались «кейсы и лого».
Кейсы — это что вы сделали с другими компаниями. Кому, как и в каком сегменте рынка подняли выручку.
Причем у клиентов есть свои четкие сегменты рынка. Как говорит Женя Лисовский из Maps.me: «У клиентов есть свои полочки в голове, на которые он расставляет продукты. Если клиент не понимает, на какую из полочек поставить ваш продукт, он его просто выкинет из головы».
Полочки «автоматизация диджитал маркетинга для ивентов» у клиентов не оказалось, поэтому мы выбрали полочку «специалисты по продвижению ивентов на Facebook». Питчи с таким лейтмотивом хорошо работали.
Лого — это с кем вы работали или кто вас может рекомендовать. «Я знаю человека X», «Мы делали проект для компании Y». Из-за ограниченности и закрытости индустрии все друг друга знают. Поэтому в этот рынок сложно попасть, но если закрыл несколько крупных сделок, то с будущими потенциальными клиентами ты быстро проходишь этап Social Proof.
Как ни странно, но для индустрии офлайн ивентов, главным фактором роста оказался нетворкинг на офлайн-конференциях индустрии. Все представители индустрии встречаются на отраслевых конференциях несколько раз в год. Все друг друга знают, рады видеть и интересуются, каких бы «новых игрушек» для своего театра, стадиона, промоутерской компании прикупить.
Что произошло с ивент-индустрией после принятия карантинных мер из-за коронавируса? Как это повлияло на вас?
Абсолютно все события были отменены или перенесены. Зрители стали массово требовать возврата денег за билеты.
Подавляющее большинство событий финансируются из ранее проданных билетов. В финансовую модель события всегда заложен какой-то небольшой процент возвратов, но это единицы процентов. Поэтому массовые возвраты губительны для организаторов.
В США с этим немного проще, так как большинство билетов на события в Америке являются невозвратными по закону, их можно только перепродать. Но в текущей ситуации компаниям пришлось делать непростой выбор: терять деньги или терять репутацию.
Например, организатор Live Nation сказал: “If the event is canceled or rescheduled, tickets will be exchanged or refunded.” А StubHub готов сделать возврат 120% цены, но только на бонусный счет клиента на будущее.
Это создало цепную реакцию плохих событий, порождающих еще более плохие события. Начались увольнения, сокращения зарплат, суды, разорения и банкротства.
Маркетинговые бюджеты первые полетели под нож. Все наши текущие и будущие проекты мгновенно остановились на неопределенное время.
Если пережить карантин планировала хотя бы половина индустрии, то настрой «Давайте пока все паникуют, готовиться к светлому будущему. Спокойно изучать инструменты автоматизации маркетинга, настраивать аналитику, искать другие интересные решения» я встретил только у одного из сотни.
Все указывало на то, что нам придется отправиться следом за той половиной компаний, которые не планируют пережить карантин.
Недооцененный путь достижения product/market fit. Или часть про то, откуда берется органический рост продуктов
Что вы решили делать дальше?
На дворе было 16 марта 2020 года. Я решил срочно улететь в Нью-Йорк, чтобы после окончания карантина быть ближе к ивент-индустрии и быстрее возобновить контакты.
Ожидая вылет в пустом аэропорту Шереметьево, я написал статью про наш внутренний инструмент для приоритизации задач в продуктовом бэклоге — Дукалис.
Я решил, что если нам оставят пять имейлов, то мы уделим больше внимания продукту и попробуем его продвигать.
Я на коленке собрал лендинг с Google-формой для регистрации, так как авторизации для внешнего мира в сервисе еще не было. В среду 18 марта я опубликовал пост у себя на и в . И в четверг на .
Получилось ли собрать пять емейлов, заинтересованных в вашем сервисе для приоритизации задач в бэклоге?
Результаты анонса оказались ошеломляющими.
За первую неделю пришло 160 заявок от компаний, заинтересованных в продукте. Мы получили десятки восторженных отзывов. Продукт начали рекомендовать друг другу проджект/продакт менеджеры и scrum-мастера, даже появилось несколько публикаций в телеграм-каналах про agile.
Команда провела десятки часов в разговорах с первыми клиентами из банков, известных стартапов, одного из крупнейших автоконцернов в мире и даже с продакт-менеджером из самой Atlassian (разработчик Jira).
Автор телеграм-сообщества Atlassian community предложил сделать вебинар про Дукалиса. Было 92 регистрации, до вебинара дошли 55 человек и дослушали 38. За одну неделю наша компания перешла из предсмертного состояния в фазу суперактивного роста.
Насколько это отличалось от опыта запуска прошлых продуктов?
Очень хороший вопрос. Для ответа надо будет сравнить совершенно разные опыты и отрезки времени, но давай попробуем вместе классифицировать.
Что делал каждый из продуктов?
Concert With Me: билетный eCommerce с продажей точно таких же билетов, как и у всех остальных.
Tendee: комбинация методик продвижения событий и инструменты, которые мы заточили под эти задачи.
Ducalis: сервис быстрой приоритизации задач в бэклоге в Jira и синхронизации целей продуктовой команды.
Почему появился каждый из продуктов?
Concert With Me: хотелось сделать международный eCommerce.
Tendee: хотели переиспользовать навыки, связи и инструменты продвижения в индустрии, которые получили в Concert With Me.
Ducalis: решали личную боль приоритизации задач в разросшемся бэклоге в Jira.
Как продукт создавал добавочную ценность? В чем было ключевое преимущество?
Concert With Me: закупка дешевого трафика из канала, который никто в индустрии не замечал.
Tendee: «все-что-нужно-в-одном-сервисе» для digital-маркетинга событий.
Ducalis: реально работает и решает задачу синхронизации и приоритизации для нашей команды, делает это быстрее и надежнее Jira-плагинов, отдельных сложных сервисов, Google-таблиц.
Что было главым драйвером роста продукта?
Concert With Me: найденный «хак» в продвижении через Facebook.
Tendee: полеты в разные части света на встречи, знакомства, конференции, последующие продажи.
Ducalis: личная история решения проблемы, которая срезонировала с большим количеством людей.
Какой была реакция клиентов на продукт?
Concert With Me: «Почему билеты так дорого стоят? Когда артист X приедет в город Y?»
Tendee: «С кем именно вы уже работаете? Что они говорят?»
Ducalis: «У нас точно такая же проблема с приоритизацией задач! А как вы решали X?»
Давай попробуем обобщить этот опыт запуска продуктов на разных рынках.
Если обобщать, то первые два продукта в основном росли благодаря тому, что мы построили эффективные каналы для их дистрибуции.
Concert With Me существовал на очень конкурентном рынке и давал минимальную добавочную ценность относительно рынка. Его успех связан с тем, что мы нашли маркетинговый канал, который остальные проглядели.
Tendee имел большую добавочную ценность относительно рынка для клиентов, но у самих клиентов не было сформированной «потребности» или осознания проблемы, что такой сервис им нужен. Поэтому требовались прямые продажи и очень долгий онбординг через модель агентства, где мы показывали ценность продукта в решении насущных задач клиента.
С «Дукалисом» все перевернулось с ног на голову.
Мы нашли эффективное решение собственной проблемы, а потом поделились историей продукта с другими людьми. Это нашло отклик, и запустился органический рост без каких-либо инвестиций в маркетинг.
Сравнение опыта запуска «Дукалиса» и прошлых продуктов позволило тебе осознать ряд мыслей, которые ты как-то давно читал в книге Деза Трейнора из Intercom, но до этого не до конца понимал. Расскажи об этом.
Как-то пару лет назад я читал книгу и честно не понимал, что за странные советы в ней давали Дез Трейнор и Мэт Ходжес. Книга начиналась с того, что при выводе продукта на рынок нужно писать какие-то истории и рассказывать их людям:
“No matter how good your product is, if you can’t tell a cohesive, compelling story about it, you’re going to have a very hard time getting people’s attention when you actually do take it to market”
“For decades software was sold using feature-based marketing: But Saas has changed that. A lot of startups spend untold time and resources cooking up some fancy marketing matrix when in fact you just need to have lots of real life conversations with life-minded people about their problems”.
Я читал книгу про маркетинг от основателя очень успешной компании стоимостью более миллиарда долларов и не понимал, о чем он говорит. А где же секреты Google Adwords? А как же сегментация email-баз? Почему нет главы про оптимизацию ставок в Facebook? Какой сервис ремаркетинга надо использовать?
И только сейчас я понял, что в силу специфики моего опыта и рынков, на которых я до этого работал, продвижение продукта мне всегда представлялось каким-то буквальным процессом закупки трафика, настройки аналитики, сбора имейлов, ретаргетинга, прямых продаж и так далее.
И тут я наконец-то, на примере «Дукалиса», понял фразу про продукты, которые начинаются с реальных проблем. Такое сложно понять в теории, можно лишь прочувствовать на своем опыте. Но мало кому посчастливилось не только наткнуться на незакрытую острую проблему, так еще и найти ее эффективное решение.
Истории , , начинались именно так — реальная проблема, которая провоцировала сильную личную боль основателя. А не фраза друга «крутая штука, я бы точно купил это».
Абсолютно искреннее желание сначала полностью решить свою проблему стало ключом к созданию значительной добавочной ценности, и, как следствие, к органическому росту.
Реальная живая история решения собственной проблемы с помощью продукта кардинально влияет на маркетинг продукта. Вам есть что рассказать, вы точно понимаете, на какие точки давить. Люди не кликают на рекламу, потому что она как-то настроена особенно. Они кликают, если обещание в рекламе резонирует с их проблемой.
Часто говорят, что ты — нерепрезентативный, не стоит ориентироваться на свои нужды, но, по-моему, на раннем этапе создания нового продукта именно на это и надо ориентироваться. Когда я работал над играми, то лучшие результаты показывали те игры, в которые люди начинали искренне и увлеченно играть внутри компании, чем обеспечивали жизненно необходимый продукту ранний фидбек. С «Дукалисом» вы тоже решали собственную проблему. Расскажи, как вы пришли к этому продукту.
В какой-то момент работы над Tendee наш бэклог в Jira зарос бесконечным списком идей фичей, которые записывались туда всеми подряд.
Каждый в команде по-своему смотрел на то, что важно, поэтому задачи брались в работу в случайном порядке. Мы нарушали все советы из твоего поста «Почему «нет» — ключевое слово при создании продукта?».
Мы решили переосмыслить систему приоритизации задач в компании. Перебрав несколько систем приоритизаций, мы остановились на гибриде критериев и , для каждого из которых назначили свой коэффициент веса (ниже указан в скобках).
Продакт-менеджер должен был оценить задачу по следующим критериям:
- Sales. Помогает в продажах (1).
- Activation. Показывает выгоду от продукта (1).
- Retention. Возвращение пользователей в продукт (1).
- Service. Уменьшает затраты на поддержку клиентов (1).
- Fb Ads. Приближает нас к статусу Facebook Marketing Partner (1).
- Mass. На много ли клиентов, ивентов или денег влияет (1).
Разработчик должен был оценить задачу по следующим критериям:
- Time. Затраты времени на разработку (-3).
- Value. Важность для разработки и продукта (2).
Вы сразу стали пилить собственный сервис для автоматизации приоритизации задач из бэклога?
Нет. Мы быстро сделали связку «Google Таблиц», Automate.io и Jira Cloud для автоматизации этой задачи. Этот монстр проработал всего пару месяцев, после чего все развалилось.
Основные проблемы и боли приоритизации задач в таблицах Googe Spreadsheets были следующие:
- Google-таблица заросла старыми задачами.
- Появилось много дублей из-за ошибок синхронизации.
- Чтобы понять контекст разных задач, нужно было открыть миллион вкладок.
- Коллеги заполняли таблицу в разное время, поэтому синхронизироваться стало сложно.
- Обновлять критерии для приоритизации задач стало невозможно.
Мы очень хотели решить проблему приоритизации задач в компании (даже создали решение на коленке и интегрировали его в свои процессы), но оно не работало по техническим причинам.
И тогда, понимая все тонкости процесса приоритизации фич, вы уже решили сделать внутренний продукт для решения этой задачи?
Да, разработчики предложили написать свое внутреннее решение. Его делали по остаточному принципу в свободное время, и через пару месяцев появилась первая версия. Мы были уверены, что это будет внутренний продукт только для нас, и поэтому выбрали шуточное название «Дукалис» из-за .
Так как все время уходило на основной продукт (Tendee), то в «Дукалисе» делались только самые важные фичи, без которых мы не могли им эффективно пользоваться. Такой аскетичный подход к разработке продукта привел к тому, что в «Дукалисе» не было ничего лишнего.
Идеи для развития «Дукалиса» мы и оценивали в самом «Дукалисе». Критерии мы выбрали на основе опыта решения задачи приоритизации задач через «Google Таблицы». Так там оказались скорость интерфейса, понимание контекста, возвращаемость в сервис, командная работа, время разработки. Здесь можно прочитать полное .
Мы делали продукт для себя, поэтому получился очень быстрый интерфейс, удобные уведомления в Slack, отличное понимание контекста задачи, нужные подсказки про критерии, формулы. Продукт идеально решал нашу проблему.
Как именно ты понял, что продукт решает вашу проблему?
«Дукалис» активно использовался командой каждую неделю для оценки задач. И это дало заметные выгоды в борьбе с проблемой приоритизации задач:
- На выставление оценок стало уходить по 15 минут в неделю. Система работала как часы, и все быстро научились держать оценки в порядке.
- Родился пятничный ритуал обязательного прочтения всех задач всеми членами команды. Мы намного лучше понимали общий скоуп задач, а также каждую неделю. «Google Таблицы» не могли нас синхронизировать на груминг в одно и то же время без общего созвона.
- Каждый месяц оценки задач обнулялись и нужно было оценивать залежавшиеся задачи еще раз. Часто мы их просто удаляли за ненадобностью.
- Сброс оценок позволил решить проблему «постоянной переоценки ценностей», что опять же было невозможно в «Google Таблицах».
- Такой процесс породил много продуктивных конфликтов. Люди начали говорить «Что это за задача?», «Зачем это делать?», «Я не понимаю описания», «Кажется, что это не важно».
- Команда также стала обсуждать сами критерии, задумываясь о том, как та или иная часть системы влияет на успех всего продукта и компании.
- Продакт-менеджеры и продажники стали понимать важность «рефакторинга гридов». А разработчики осознали, почему верстка справки — это очень важная задача.
- Это даже стало небольшой игрой. «Дукалис» писал в общий канал в Slack, кто “Molodetz”. Поэтому ребята из команды старались оценивать задачи вовремя. И даже расстраивались, когда не получалось этого сделать.
То есть «Дукалис» поменял ваши процессы приоритизации задач при работе над продуктом, сделал вашу команду эффективнее. В этот момент ты уже понял, что вы создали что-то ценное?
Мы вообще никак не пытались оценить коммерческий потенциал «Дукалиса». Все, что мы хотели сделать, — навести порядок в своем хаосе планирования и приоритизации.
Мы не осознавали, что этот продукт может быть полезен другим командам.
Вокруг так много крутых статей, советов и выступлений о правильных продуктовых стратегиях, подходах к приоритизации и формированию роадмапа. Нам казалось, что мы последняя компания в мире, которая не умеет приоритизировать задачи.
Когда ивент-индустрия впала в кому из-за коронавируса, мысль «с первой полки» была «давайте поворачивать продукт в сторону онлайн-событий». Однако такой продукт подразумевает совсем другой маркетинг, к которому Tendee не был готов.
Параллельно я читал новости про рост количества пользователей Zoom и завидовал сервисам, которые полностью работают в онлайне. Как бы это тупо не звучало, но тогда я подумал: «А что если подать “Дукалиса”, как инструмент для удаленных команд?»
И сам удивился, что «подавать» ничего не нужно. Мы же несколько лет удаленная команда, и с помощью «Дукалиса» научились синхронизировать разные точки зрения членов команды на фичи и приоритеты в развитии продукта.
Я даже не рассказал никому из коллег про свой план. А просто решил написать статью и проверить, получим ли мы хотя бы пять имейлов. Но про это я уже рассказывал.
Когда продукт так точно попадает в острую незакрытую проблему, то прилетает огромное количество фич-реквестов и предложений, продукт начинают тянуть в разные стороны. Как вы с этим справляетесь? Какие у вас сейчас ключевые критерии оценки приоритетов в «Дукалисе» для задач для развития «Дукалиса»?
Мы наконец-то поняли заветы Деза Трейнора. Две наши главные задачи сейчас:
- Как можно больше слушать истории, проблемы, боли и задачи клиентов по приоритизации задач. Нам важно глубоко понять клиентов и выделить правильные сегменты рынка.
- Выбрать самые перспективные для нас сегменты и решить, что мы можем и хотим для них сделать. И сколько за это клиенты готовы платить.
Пока по результатам первых нескольких десятков глубинных интервью стало очевидно, что нужно подробнее изучать потребности корпоративного сегмента. Для закрытия сделок с крупными клиентами продукт нужно дорабатывать в сторону безопасности, контроля доступов, шифрования, работы в корпоративных сетях.
При этом мы продолжаем держать в фокусе те факторы, которые выработали для себя после опыта решения задачи приоритизации задач в «Google Таблицах». Мы также уже валидировали, что они все хорошо резонируют с нашими клиентами:
- Скорость: так как Jira очень медленная и здесь мы создаем большую добавочную ценность.
- Retention: сейчас мы шлем уведомления только в Slack, при этом это важный способ возвращения пользователей.
- Collaboration: ключевая задача инструмента — дать общую картину всей команде, синхронизировать видение, запустить важные дискуссии в правильный момент (до начала разработки).
- Self-Service: сделать интуитивно понятный интерфейс, дописать справку, подсказать как и что лучше настроить, какие критерии выбрать.
Все это трансформировалось в наши критерии приоритизации задач в «Дукалисе» по разработке «Дукалиса».
И последний вопрос. Если кратко сформулировать ключевой урок для тебя из всей этой пока еще только начинающейся истории, то что это будет?
Как обычно, все сложнее, чем «одна главная идея».
Мега-платформы не друзья, но и не враги. Мы живем в век мега-платформ, которые монополизировали определенные сегменты рынка: поиск, общение, новости, видео, и т.д. Не зависеть от них практически невозможно, но важно уметь диверсифицировать этот риск. Проектируйте интеграции с платформами подразумевая, что когда-то ее может не стать. Плохой вариант: вариант полной зависимости Concert With Me от Facebook. Хороший вариант: Zapier.
Фокусируйтесь на добавочной ценности продукта, на том, как вы решаете задачу людей, а не на багах, фичах и других атрибутах. На Tendee клиенты часто жаловались на баги, несколько раз это было причиной остановки сотрудничества (не вышел пост, не подкачалась метрика). На звонках по «Дукалису» клиенты пару раз просили меня перестать извиняться за мелкие баги. Говорят, что все понимают и верят, что мы все поправим. Баги есть у всех, но если продукт действительно решает проблему клиентов, это не будет причиной их ухода.
Не стоит буквально воспринимать фидбек клиентов, нужно вырабатывать эмпатию к ним и стараться глубже понять их задачу и реальную мотивацию. Слушайте и переслушивайте звонки с клиентами. Но не стоит буквально записывать все хотелки. Вдумывайтесь в причины и мотивы, почему они что-то делают или просят, пытайтесь понять, какую задачу они реально хотят с помощью этого решить. Пока клиентов не очень много и физически возможно послушать все их истории — слушайте. Мы с командой записали несколько десятков звонков и периодически пересматриваем их.
Искренняя личная история решения проблемы лучше самого длинного списка фичей. Абсолютно на всех звонках клиенты говорили, что у них срезонировала та или иная мысль из сервиса. Никто не говорил «да, вот это прикольная фича». Наша реальная и подробная история решения проблемы заменила отзывы первых клиентов (которых не было) и стала для нас лучшим лендингом, продажником и маркетологом.
В заключение
Дальше прямая речь Виталика Мышляева:
Если вы тоже испытываете проблемы с приоритизацией задач из бэклога вашего продукта, то напишите нам и поделитесь своими историями. Пишите в чат на сайте .
