Предположим, у нас есть проект или идея SaaS-продукта. Возможно, вы уже разработали первую версию, у вас есть пользователи и в целом выкуда-то движетесь. Как понять, что именно разрабатывать дальше, чтобы продукт рос, а пользователи платили? Как понять, какую именно обратную связь принимать от пользователей? Расскажу ниже.

Кому будет полезна статья:

вы разработчик, который развивает свой SaaS пет-проект;
вы разработчик-лид, который влияет на развитие продукта;
вы владелец или продакт\проджект менеджер, который принимает решения о направлении развития SaaS продукта.

Дисклеймеры:

Я буду говорить именно о B2C SaaS-продуктах с подписочной моделью, так как у меня наибольший опыт именно с такими проектами. B2B или продукты, завязанные на разовые продажи, — оставлю для следующих статей. У них много другой специфики.
Речь пойдёт про проекты до начала разработки и про первые версии продукта. Именно на этом этапе важнее всего и сложнее всего понять, что нужно сделать и как правильно собрать обратную связь. В более крупных проектах всё сложнее, поэтому я вынесу их разбор в отдельную статью.
Я не претендую на абсолютную истинность, у меня нет всеобъемлющих знаний. Рассказываю только про свой опыт в роли тимлида (или аутсорс-СТО, смотря как называть) в заказной разработке и в роли разработчика своих пет-проектов.

Содержание

Почему я об этом говорю?
Что такое кастдев, зачем он нужен и кто им должен заниматься?
Что нам нужно выяснить на разных стадиях продукта?
- До разработки продукта
  - Проверяем, что мы не выдумали себе потребность в продукте или его функционале
  - Проверяем, что в целом можем найти нашу ЦА
- Когда продукт уже есть
  - Проверяем, что сделали действительно то, что нужно и что убрали все ограничения для покупки
  - Сверяем наше представление о ЦА и реальность
Почему мы не опираемся на 100% на мнение пользователей?
Лайфхаки из опыта
Какие ошибки можно допустить во время кастдева?
Пример вопросов для кастдева
Что делаем с результатами?
Заключение

Почему я об этом говорю?

Сейчас я сооснователь и СТО no-code платформы для маркетинга. За последние 8 лет я поработал над несколькими SaaS-проектами в заказной разработке. В том числе, запускал собственные проекты. При этом смог продать 2 своих пет-проекта, которые дошли до состояния рентабельности. Ещё штук 5 проектов похоронил. Кстати, негативный опыт зачастую более ценен.

Таким образом, у меня накопилась определённая субъективная насмотренность. Для себя я сделал некоторые заметки о том, как общаться с пользователями, чтобы найти выгодный вектор развития продукта. В то же время набил достаточно шишек, чтобы понять, где лучше не слушать пользователей или что может привести к лишним расходам человеко-часов разработки.

Как полагается, у меня есть Telegram-канал, где я собираю ссылки на свои статьи про разработку, развитие SaaS-проектов и управление IT-проектами.

Что такое кастдев, зачем он нужен и кто им должен заниматься?

Для начала определимся с термином.

Кастдев — это когда мы общаемся с нашей целевой аудиторией, текущими или потенциальными пользователями продукта. Делаем это, чтобы понимать:

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

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

Занимаются кастдевом разные люди в зависимости от проекта. Если это пет-проект, кастдевом занимается сам разработчик (тут уж хоть как-то кастдевить — уже успех). Если у вас стартап на 3–7 человек, кастдевом занимается тот, кто принимает решение о развитии продукта (СЕО, маркетолог, проджект или, в идеале, продакт). Если продукт большой, под кастдев выделяют продактов (при этом кастдев уже подкреплён аналитикой пользовательских действий и статистикой по оплатам).

Что нам нужно выяснить на разных стадиях продукта?

До разработки продукта

Проверяем, что мы не выдумали себе потребность в продукте или его функционале

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

Узнать о своей ошибке можно двумя способами:

Разработать продукт и показать его рынку, чтобы увидеть, что спроса нет (пользователей нет или они не платят).

Обычно это 1–2 месяца работы.
Пообщаться с потенциальными покупателями (по нашему мнению), спросив напрямую: “А это нужно?”, “А платить будете?”. Так мы быстрее поймём, что потребности нет или мы не можем продать продукт.

В лучшем случае — поймём, что нужно скорректировать идею и разработать более перспективный вариант.

Пример из жизни (как я не до конца угадал с потребностью в мониторинге сайтов)

У меня был собранный на коленке down detector (штука для мониторинга доступности сайтов). Я его использовал для своих некритичных сайтов и нужных мне сервисов. Он отправлял уведомления на почту в случае сбоя.

Я решил его немного доработать, подключить оплату и начать продавать.

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

В то же время выяснилось, что у разработчиков есть запрос не только мониторить сайты, но и API, а удобнее получать уведомления не на почту, а в Telegram.

Следовательно, начиная продажи продукта — я сразу закладывал эти опции как уникальное предложение на рынке и строил через него продажи.

Проверяем, что в целом можем найти нашу ЦА

В разработке сервиса, который планируется монетизировать, самое главное — это… продать его. Разработать практически всё можно, вопрос лишь во времени. А вот найти тех, кому продукт действительно нужен и убедить их купить — задача с очень большой звёздочкой.

Начинать продажи нужно с поиска нашей целевой аудитории. Точно ли она есть? Точно ли она совпадает с нашими представлениями? Точно ли ей интересен продукт?

Если мы не можем найти ЦА хотя бы для кастдева, тогда и смысла вкладываться в разработку нет. Искать аудиторию можно по-разному: через знакомых, Telegram каналы, рекламу и т.д.

Когда продукт уже есть

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

Когда продукт уже существует, его не будут покупать 100% пользователей. Конверсия из просмотра или регистрации в продажу может быть разной, но для SaaS нормальный диапазон — 1–10%.

Следовательно, может возникнуть ситуация, когда продукт есть, в нём регистрируются, пользуются, но не платят. Или пользуются какое-то время и уходят. Нужно выяснить, почему так происходит.

В этот момент мы берём ~~телефон~~ Telegram и звоним нашим пользователям (данные которых мы предварительно взяли). Задаём вопросы и пытаемся понять, что именно мешает нам зарабатывать больше. Например, пользователи расскажут о неочевидных проблемах. Или окажется, что мы не угадали с функционалом. Или наш продукт решает потребность раньше, чем пользователь готов за это платить (да, и такое бывает).

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

В сервисе для мониторинга сайтов, который я запустил, был бесплатный и платный тариф. В бесплатном тарифе можно было мониторить 3 сайта раз в 5 минут. В платном — неограниченное число сайтов, раз в минуту, плюс уведомления об истечении SSL-сертификата.

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

В ходе кастдева выяснилось, что у 90% пользователей сервиса 1–2 сайта, а проверка раз в 5 минут им вполне хватает. Предупреждение об истечении SSL их особо не волновало (сайт упадёт — через 5 минут поднимут).

Пришлось поменять подход и сделать всего один тариф, но с тестовым периодом 7 дней и обязательной оплатой после. Конверсия в оплату резко выросла. Пользователи, которые не планировали платить, отпали. За одно и снизили нагрузку на сервис.

Сверяем наше представление о ЦА и реальность

Как бы мы ни исследовали аудиторию до разработки, я ещё не видел, чтобы изначальный расчёт полностью сходился с реальностью. Так или иначе первая версия продукта выпускается в полуслепом формате (* если мы действуем экономно и маленькими итерациями, а не сжигаем инвестиции на год разработки и лишь потом получаем фидбек с болью).

Сначала мы выпускаем более или менее рабочий продукт на основе нашего видения (или видения заказчика). В удачном случае — с предварительным анализом потребностей и целевой аудитории.

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

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

Как я не угадал с целевой аудиторией мониторинга для сайтов

Всё в том же мониторинге для сайтов я ожидал, что моими пользователями будут системные администраторы, девопсы и веб-разработчики. У них будет от 5 сайтов, им важно реагировать за минуту (чтобы исправлять раньше, чем кто-то увидит) и важно заранее знать об истечении SSL’a, если устанавливают его вручную.

Оказалось, что в первых 200 пользователях вообще не было администраторов и DevOps’ов. Были владельцы сайтов (которые их покупали), веб-разработчики с пет-проектами и сайтами заказчиков. В среднем у них по 1.3 сайта. Истекающий SSL практически никого не волновал.

Следовательно, дальнейшее УТП я корректировал исходя их этого нового понимания своих пользователей.

Почему мы не опираемся на 100% на мнение пользователей?

Если вам сказали "классно, буду за это платить" — это вообще не гарантия, что вам будут платить

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

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

Единственная объективная метрика, что вам будут платить — вам внесли предоплату или купили подписку.

Пример из жизни (как IT компания вложила полгода разработки в продукт, который все хотели, но никто не заплатил)

Мой хороший знакомый, владелец сервисной IT-компании, опытный предприниматель, решил диверсифицировать бизнес и заняться разработкой продукта.

Как сферу выбрал разработку специфического сервиса для рынка автозапчастей, т.к. была экспертиза в этом и был понятный рынок (это был ~2017 год). Предварительно он пообщался с ~30 автосервисами. Все единогласно сказали, что всё супер, такое решение нужно, готовы платить.

Он вложился в разработку, за ~полгода разработали первую версию (решение достаточно сложное). Пошли снова к тем же автосервисам. В итоге купило всего несколько штук.

У остальных или пропала актуальность, или не хватило пользы, или попользовались и через месяц отказались, потому что не стали корректировать наработанные бизнес процессы.

Мораль: мнение слушаем, но не опираемся всецело на него.

Нужно считать рентабельность каждой хотелки

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

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

Напоминаю: ресурсы у нас всегда ограничены. Всегда необходимо приоритизировать задачи таким образом, чтобы максимизировать прибыль и поддерживать продукт на достаточном уровне качества. Стремление к идеалу обычно невыгодно.

Например, достижение 99,9% SLA (Service Level Agreement) — необходимая задача. Однако при попытке повысить SLA до 99,99% ресурсы начнут расходоваться экспоненциально. Если мы не являемся банком или поставщиком медицинского ПО, это, вероятно, не принесёт соразмерной ценности в обмен на затраты.

Пример из жизни (считаем рентабельность внедрения мультиязычности в No Code платформе)

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

Но здесь мы учитываем следующее:

Разработка опциональной мультиязычности потребует ~2 человеко-недели (для нас это ~$2 500 прямых расходов + стоимость поддержки). И в это время не будет делаться что-то более важное.
Фидбек приходит от пользователей заведомо неплатежеспособных (значит, расходы отобьются очень нескоро).
Этот запрос приходит от менее чем 1% пользователей (остальным достаточно или английского, или русского языка).

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

Бывают исключения из правил: иногда продажи не зависят от качества продукта

Однажды я столкнулся с ситуацией, когда обратная связь вообще не играла роли и продажи делались несмотря на качество продукта. И умер продукт вообще без привязки к его качеству. Грубо говоря, это ситуация когда вы или получили свободный доступ к клиентам, или вы — монополист.

Детально об этом можно почитать здесь.

В двух словах

В 2023 году я сделал проект “доступ к ChatGPT из России”. Тогда регистрация была по номеру телефона и нейросети не были условно бесплатными. За счёт SEO-оптимизации я вышел на первую строчку в Яндексе и Google. Причём несколько дней в Яндексе сайт показывался выше оригинального ChatGPT (хе-хе).

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

Но это исключение. На такой исход опираться не стоит.

Лайфхаки из опыта

Ищем первую целевую аудиторию через сайт с макетом продукта

Когда продукта ещё нет, бывает непросто объяснить целевой аудитории, что мы планируем разработать. Или мы вообще не можем найти ЦА. Тут выручает сайт с макетом продукта.

Рисуем то, как будет выглядить наш продукт в Figma. Экспортируем в картинки. Выкладываем на сайт. Сам сайт делаем на Tilda за 2-3 вечера (как, в том числе опытный фронтендер говорю, что это самый быстрый и дешевый способ проверить гипотезу).

На лендинг вешаем форму регистрации по нику в Telegram или, в идеале, OAuth регистрацией через Telegram. Форма регистрации ведёт к “продукту”, которого ещё нет. Тогда мы увидим тех, кто почему-то перешел по рекламе и получаем данные для связи.

Кстати, почта тут работает очень плохо, практически никто не отвечает. Поэтому берём именно Telegram (ну или номер телефона).

И запускаем на сайт рекламу! Закупаем в Telegram каналах, настраиваем Яндекс Директ и т.д.

Выйдет немного кривовато, мы не увидим реальную конверсию, буду залётные регистрации. Это нормально! Но на этом этапе нам важно выяснить, что спрос есть в принципе и найти людей для кастдева. Реальную конверсию мы узнаем только через несколько итераций разработки.

Звоним, а не пишем

Я много раз пытался оптимизировать процесс “кастдева”. Пробовал отправлять список вопросов для ответа. Пробовал отправлять Google-форму обратной связи по всей базе пользователей.

Как итог: работает очень плохо. В среднем, форму заполяет 5%. Причём это самые или лояльные, или неплатежеспособные (с кучей свободного времени) пользователи.

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

Собственно, плюсы звонка (в сравнении с сообщениями или опросниками):

Шире выборка. Личная просьба о звонке воспринимается серьёзнее.
Больше информации и контекста. Во время звонка пользователь меньше думает, что написать. Успевает рассказать в деталях о своих проблемах, вы понимаете эмоциональный окрас и контекст.
Можно задавать вопросы. Во время кастдева важно идти “вглубь” дополнительными вопросами. Что не сделаешь через форму обратной связи или список вопросов.
Не надо так

Задаём магический вопрос: “А заплатишь?”

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

В конце разговора уместно задать вопрос: “ Если бы в продукте было всё, что вы перечислили, вы бы заплатили прямо сейчас {ВАША_ЦЕНА}?”. И тут вдруг может выясниться, что нет. Именно здесь всплывают реальные возражения, и вы узнаёте, что не так и над чем нужно работать.

Никогда не игнорируйте этот вопрос.

Предлагайте созвониться лично и давайте что-то за кастдев

Во-первых, старайтесь не писать в общие чаты на 1к+, что вы ищите людей для кастдева. Так вы, скорее всего, соберёте выборку тех, у кого просто много свободного времени.

Это не жёсткое правило: если не знаете, где найти людей, можно “пылесосить” чаты. Но лучше предлагать созвониться в личке. В чатах лучше спрашивать контакты тех, кому стоило бы написать.

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

Если у вас ещё не запущен проект, предложите вашу консультацию как специалиста, помощь или (внезапно) деньги за звонок. Правда с деньгами сложнее, если работаете с аудиторией с доходом от $500. Может выйти дорого.

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

Пример моего сообщение с приглашением на кастдев

Здравствуйте!

Меня зовут Ростислав, я владелец сервиса (блог_не_корпоративный, ссылку_не_ставлю). Увидел, что вы зарегистрированы в сервисе

У меня сейчас есть цель: разобраться, кто на самом деле пользователи моего сервиса (владельцы сайтов, программисты или вебмастера) и какие у них потребности

Могу попросить вас созвониться со мной на 15-20 минут, чтобы задать несколько вопросов о вашей деятельности? Мне важно понять, какой именно человек стоит за строчкой "пользователь")

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

Я буду очень благодарен, если вы сможете созвониться) Мне это сильно поможет

Можем в Zoom, Google Meet или прямо в Telegram.

Какие ошибки можно допустить во время кастдева?

Вообще, про это можно написать штук 10 статей и порекомендовать несколько книг. Но попробую в коротко.

1. Слишком много спрашиваем именно “про мнение”.

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

2. Задаём наводящие вопросы, а не идём “от корня”.

Тут проще на примере:

Неправильно: “Почему вы пользуетесь мониторингом для сайта?” (понятно, что сайт может упасть).

Правильно: “Почему вы думаете, что с сайтом может что-то случиться?” (потому что сайт уже упал и я потерял SEO позиции).

3. Задаём слишком наводящие или закрытые вопросы.

Тоже на примере:

Неправильно: “Я правильно понимаю, что вы боитесь потерять клиентов и репутацию, если ваш сайт упадёт?”

Правильно: “Что будет, если ваш сайт упадёт? Что потеряете?”

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

Например, в предыдущем вопросе, что пользователю вообще без разницы на клиентов и продажи. Можем ему просто важно заметить падение сайта раньше, чем работодатель.

4. Не записываем разговор.

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

5. Не записываем разговор, если делегируем кастдевы.

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

6. Берём слишком маленькую выборку (тут можно вспомнить про портреты ЦА).

В вашей целевой аудитории может быть несколько сегментов. Если опросите слишком мало людей — можете не найти общие черты и потребности. Поэтому старайтесь общаться как можно с большим количеством людей.

Пример вопросов для кастдева

Я много экспериментировал с форматом вопросов: от очень детальных до коротких. В итоге я пришёл к выводу, что звонок должен длиться 20–30 минут. Тогда и пользователи охотнее соглашаются, и вы можете сделать несколько звонков в день. В случае чего-то более масштабного — максимум до часа.

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

До разработки проекта:

Задача: понять ЦА

Кто вы, чем занимаетесь, (спрашиваем про важные для нас метрики: выручка, состояние и т.д.)?

Задача: понять боль

Какая у вас проблема?

Что вы потеряете, если не будете решать (эту) проблему?

Насколько это большая проблема для вас по шкале от 1 (ничего страшного) до 10 (потеряю все деньги бизнеса)?

Чего вы хотите добиться, решением этой проблемы?

А почему раньше не решали эту проблему?

Пользовались ли вы уже другими сервисами? Был негативный опыт?

Задача: понять ценность нашего предложения

(рассказываем о нашем продукте) Есть опасения по пользованию сервисом?

(рассказываем о нашем продукте) Готовы платить {ЦЕНА} за сервис? А почему не готовы?

(рассказываем о нашем продукте) А что нужно сделать, чтобы вы заплатили {ЦЕНА} ? (если ничего - это тоже ОК)

Если проект есть:

Задача: понять ЦА

Кто вы, чем занимаетесь, (спрашиваем про важные для нас метрики: выручка, состояние и т.д.)?

Как нашли наш продукт?

Задача: понять боль

Какая у вас проблема? Для чего вы зарегистрировались в сервисе?

Что вы потеряете, если не будете решать (эту) проблему?

Насколько это большая проблема для вас по шкале от 1 (ничего страшного) до 10 (потеряю все деньги бизнеса)?

Чего вы хотите добиться, решением этой проблемы?

А почему раньше не решали эту проблему?

Пользовались ли вы уже другими сервисами? Был негативный опыт?

Задача: понять ценность нашего предложения

(рассказываем о нашем продукте) Есть опасения по пользованию сервисом?

(рассказываем о нашем продукте) Готовы платить {ЦЕНА} за сервис? А почему не готовы?

(рассказываем о нашем продукте) А что нужно сделать, чтобы вы заплатили {ЦЕНА} ? (если ничего - это тоже ОК)

Задача: понять проблемы в сервисе и нужные функции

(задаём вопрос, почему пользователь не воспользовался важной функцией)

Есть какие-то проблемы, которые вы заметили?

Что бы вы добавили в сервис?

Нужна ли вам функция (рассказываем про функцию)?

Что делаем с результатами?

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

Но кратко шаги следующие:

1. Оцениваем ответы на адекватность. Действительно ли пользователь наша целевая аудитория и его нужно слушать?

2. Выделяем (или корректируем) целевые сегменты пользователей. Нужно понимать, кто “в среднем” наш пользователь.

3. Сортируем предложения или жалобы по важности и частоте упоминаний. В целом, на начальной стадии проекта, можно и субъективно на наш взгляд (или вместе с командой).

4. Брейнштормим и прорабатываем, какие шаги делать по доработке продукта.

5. Сортируем идеи по ценности. Берём в работу то, что даст наибольшую отдачу при меньших затратах.

Заключение

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

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

Надеюсь, моя статья поможет хотя бы нескольких проектам скорректировать свой вектор и начать наконец-то общаться со своей аудиторией! А тем, кто общался, понять задачи, которые нужно решать при помощи кастдева. Те, кто опытнее меня и считают, что я что-то не так написал — буду рад обратной связи и комментариям.

P.S. Если считаете статью полезной, у меня есть Telegram-канал, где я собираю ссылки на свои статьи про разработку, развитие SaaS-проектов и управление IT-проектами.

Как и зачем проводить кастдевы при разработке SaaS-продукта (с примерами из опыта)?