Разработчики тоже умеют слушать: как мы проводим кастдев для заказчиков
Время прочтения — 12 минут
Содержание
1. Для чего нужен кастдев: цели, инструменты, эффекты
2. Как в кастдеве участвуют аутсорс разработчики?
3. Инструменты исследования аудитории
4. Как мы улучшили внутренний продукт клиента через кастдев-интервью
5. В каких случаях вам нужен повторный кастдев?
6. А можно совсем без кастдева?
7. Почему мы так любим кастдевы?
2. Как в кастдеве участвуют аутсорс разработчики?
3. Инструменты исследования аудитории
4. Как мы улучшили внутренний продукт клиента через кастдев-интервью
5. В каких случаях вам нужен повторный кастдев?
6. А можно совсем без кастдева?
7. Почему мы так любим кастдевы?
«Вбухал $100k в MVP – и тишина. Ни реклама, ни ретаргетинг, ни спецофер с пробными периодами не двигают цифры».
«Retention просто нулевой – пользователи приходят и тут же исчезают».
«У нас вроде всё шло нормально в начале, были первые загрузки… А потом как будто стенка. Ничего не работает».
Мы слышим это регулярно. И, поверьте, дело почти всегда не в том, что «плохо с маркетингом» или «надо допилить пару фич». Для 42% стартапов, которые не доживали до года с момента запуска, проблема глубже: они не разговаривали с людьми, для которых делали свой продукт.
В мире бизнеса без проведения custdev (Customer development) даже самые гениальные идеи умирают тихо и бесславно. И если такие перспективы вас пугают, разберёмся, как этого не допустить. В этой статье мы расскажем, как проводим кастдев в реальных проектах, почему он нужен даже опытным игрокам и как с его помощью не просто проверить гипотезы, а выстроить продукт, который действительно работает.
Будет много примеров, ошибок и решений, которые помогут вам избежать провала.
Для чего нужен кастдев: цели, инструменты, эффекты
Начнем с матчасти: если вы уже знаете, что такое custdev исследования, переходите к разбору кейсов. Если нет, расскажем основное.
Методология custdev была предложена инвестором Стивом Бланком и легла в основу подхода Lean Startup. Суть проста: мы не строим продукт на предположениях – мы проверяем гипотезы через разговоры с людьми, на которых ориентируемся. И, общаясь с потенциальными пользователями, получаем факты: какую задачу они решают сегодня, что в этом процессе неудобно, за что они уже платят, чего им не хватает.
Кастдев – это не просто опрос «нравится /не нравится». Это системная работа по выявлению реальных потребностей будущих пользователей. Главная цель каждой гипотезы custdev – понять, существует ли в реальности проблема, которую вы хотите решить, и насколько она критична для аудитории. Иначе продукт будет просто невостребован.
Кастдев не проводят единожды. Это цикл, который включает четыре этапа, каждый из которых решает свою задачу:
- Customer Discovery. Выявляем, есть ли у аудитории боль, которую стоит решать. Общаемся с реальными людьми, проверяем гипотезу;
- Customer Validation. Создаём MVP, тестируем на пользователях. Получаем фидбек, уточняем ценность и готовность платить за продукт;
- Customer Creation. Масштабируем продукт – выходим на рынок, растим аудиторию. Продолжаем собирать инсайты;
- Company Building. Формализуем процессы, растим команду. Но продолжаем опираться на голос пользователя – он остаётся ключевым источником правды.
Такой подход позволяет снизить неопределённость на ранних этапах, выстроить гипотезу ценности и оптимизировать ресурсы на разработку.
Как в кастдеве участвуют аутсорс разработчики
Мы понимаем, что жизнь стартаперов устроена немного сложнее, чем туториалы о том, как составлять кастдев по правильному сценарию. Существуют два варианта:
- Идеальный – когда у владельца бизнеса есть возможность нанять профессиональное агентство, специалисты которого положат ему на стол красивые графики и цифры с анализом аудитории и ее потребностей;
- Реальные – когда каждый цент на счету, поэтому кастдев нужно проводить самому, но как именно – непонятно (это уже более типичный путь развития стартапа).
Здесь на помощь может прийти технический партнер для стартапа – аутсорс команда, которая будет заниматься разработкой продукта. Мы часто помогаем нашим клиентам в проведении кастдевов, так как это дает процессу ряд преимуществ:
- Команда будет лучше понимать продукт – дизайнер продумает все пользовательские сценарии, чтобы обеспечить лучшую конверсию, а разработчики оценят потенциальную нагрузку на систему и подберут правильный стек;
- Грамотная приоритизация поможет сократить скоуп работ – вы получите быстрый go-to-market с рабочим MVP для стартапа, функции которого точно нужны пользователям;
- Сформируете бэклог задач для развития продукта – новые функции можно не придумывать с нуля, а постепенно добавлять по мере роста бизнеса.
Да, это не всегда тот самый каноничный кастдев из учебников. Но так мы можем выстроить систему, которая помогает клиенту увидеть пользователей без иллюзий. Вот основные инструменты и подходы, которые мы используем, чтобы найти идеи для развития стартапа.
Инструменты исследования аудитории
Не посчитайте нас слишком принципиальными, но мы никогда не начинаем проект без discovery-фазы. Иначе будет дороже – и себе для репутации, и клиенту для доработки. Вот несколько инструментов, которые мы используем для сбора требований и анализа потребностей целевой аудитории.
✅ Интервью
Начинаем с глубинных интервью – как внешних (с пользователями, клиентами), так и внутренних (со стейкхолдерами, саппортом, продавцами). Вопросы всегда кастомные под проект, но цель одна – понять:
- Какую задачу решает продукт;
- Как её сейчас решают без него;
- Какие решения работают, а какие вызывают раздражение.
✍ Что получает клиент: презентация с разбивкой по вопросам и ключевыми инсайтами, mindmap потребностей и сценариев.
✅ Массовые опросы
Когда нужно собрать данные с десятков/сотен человек, мы рассылаем анкеты по ЦА или в сообщества. Это помогает подтвердить инсайты из интервью и выделить повторяющиеся паттерны.
✍ Что получает клиент: Google Form с выгрузкой ответов, общая сводка по сегментам, рекомендации, что учесть в функциональности или онбординге, чарты, которые визуализируют результаты опросов.
✅ Проверка спроса
Если нужно проверить, есть ли интерес к продукту на рынке, всегда можно начать с MVP и посмотреть на реакцию пользователей. Разработка базового функционала помогает замерить привлекательность оффера, поведенческие паттерны аудитории, комментарии и возражения.
Такой подход мы использовали в проекте OpenOrigin, главной идеей которого был запуск платформы для презентации ИИ-моделей. В результате получился MVP, который позволял потенциальным партнерам размещать описание своих проектов, а другие пользователи сохранять и использовать понравившиеся решения. Однако дальше MVP проект не пошел – оунер оценил спрос, осознал риски и отказался от дорогостоящей разработки. Но предложенные решения стали основой для его другого проекта.
✍ Что получает клиент: Это может быть как лендинг или простой MVP, так и no-code решение, созданное с помощью ИИ.
✅ Анализ конкурентов и рынка
Вместо 100-страничных отчетов мы собираем SWOT-конкурентов, референсы интерфейсов, скриншоты с удачными фичами, и, если нужно – семантическое ядро с поисковыми трендами.
✍ Что получает клиент: папка с UI/UX-референсами и комментариями по адаптации, таблички с обзором конкурентов и зонами роста.
✅ Прототипы
Прежде чем рисовать экраны, собираем карты сайта или схемы экранов, блок-схемы логики ключевых процессов, а также MVP-дерево для приоритезации функций: что нужно обязательно заложить в базу продукта, а какие опции можно оставить на потом. Так у клиента появляется визуальный ориентир, а у нас – уверенность, что не потратим время на ненужные экраны.
✅ Дополнительные форматы
Для дополнительного сбора требований и проверки используем:
- Интервью с отраслевыми экспертами – аналитиками, консультантами, старшими менеджерами со стороны клиента, которые хорошо понимают домен и его особенности;
- Дизайн-сессии – короткие сессии совместного проектирования продукта с клиентом;
- Полевые исследования – наблюдаем, как работает персонал на местах (в ресторанах, точках продаж и т.п.).
Так кастдев становится не просто этапом разработки, а линзой, через которую мы смотрим на развитие стартапа и может усилить ценность продукта.
Запишитесь на бесплатную консультацию, и мы проведем кастдев для вашего проекта
Максим Бонцевич
CEO dev.family
Как мы улучшили внутренний продукт клиента через кастдев-интервью
А теперь перейдем к конкретному кейсу и расскажем, как сделать кастдев, чтобы выявить узкие места в функционале и превратить простое исправление багов в полноценный редизайн процессов.
Запрос клиента
Один из заказчиков, с которым мы уже работали над коммерческим проектом, попросил провести аудит их внутреннего продукта – платформы, на которой завязаны разные процессы: от коммуникации между отделами и обмена файлами до управления проектами и сбора запросов от клиентов. Первичный запрос звучал просто: «Нужно пофиксить баги, улучшить интерфейс и избавиться от неудобств».
Вместо того чтобы сразу браться за доработки, команда предложила начать с кастдева — как части Discovery-фазы. Это позволило не гадать, что именно мешает в работе, а получить конкретные ответы от сотрудников, которые ежедневно пользуются продуктом.
Глубинные интервью и опросы
Первым шагом стали интервью, в котором приняли участие 10 сотрудников из разных отделов: руководители направлений, менеджеры и технические специалисты. На этом этапе нам было важно понять, какие проблемы испытывают специалисты и какие возможности платформы они используют в работе. Проведение интервью заняло около месяца.
Далее мы подготовили анкету с опросом и отправили ее сотрудникам компании, которые также активно пользуются платформой – их нам порекомендовали участники интервью. Вопросы касались как общей картины, так и конкретных сценариев использования и перспектив развития продукта. Вот примеры некоторых из них:
Приоретизация задач
После интервью и опросов мы собрали единый список всех проблем, предложений и идей. Каждая задача была классифицирована по типу «Баг», «Улучшение», «Идея». Также задачи были привязаны к конкретному источнику – подразделению и специалисту, от которого получен ответ. Это помогло понять, откуда пришёл инсайт и насколько он критичен.
Затем мы провели приоритизацию задач по методике RICE, которая позволяет объективно оценить каждую задачу по четырём параметрам:
- Reach – сколько стейкхолдеров затронет улучшение;
- Impact – насколько задача улучшит качество работы и возможности платформы;
- Confidence – насколько мы уверены, что задача принесет пользу;
- Effort – сколько ресурсов потребуется на реализацию.
Далее с помощью Chat GPT мы составили правильные пропорции RICE под полученные ответы, чтобы оценить, какие оценки в каждой колонке будут релевантны с учетом вводных и как считать, что задача действительно приоритетная. В результате получили общий список доработок, который разбили на три группы:
- Проблемы, связанные с производительностью, стабильностью работы и багами – то, что мешает сотрудникам в повседневной работе и требует срочного внимания.
- Улучшения текущего функционала – доработки интерфейса, удобства работы с задачами, мобильной версией и другими базовыми вещами.
- Идеи по развитию – от автоматизации и интеграций до уникальных «фишек» для каждого отдела.
Что изменилось
Изначально клиент предполагал, что нужно просто «починить баги». Но результаты кастдева дали понять, что проблема не только в ошибках, но и в неудобстве использования платформы, отсутствии важных функций и интеграций, которые напрямую влияют на эффективность сотрудников.
Таким образом, вместо точечных правок багов мы предложили клиенту комплексный подход, который принесёт реальную пользу бизнесу: сокращение времени на рутинные задачи и повышение общей продуктивности. А также собрали пул интересных идей от самих сотрудников. Поэтому кастдев – отличный способ услышать пользователей и дать им возможность обозначить свои ожидания от продукта.
Не знаете с чего начать разработку? Обсудим детали и начнем с кастдева
Максим Бонцевич
CEO dev.family
«Но мы же все предусмотрели?!»: в каких случаях вам нужен повторный кастдев
Случаются и ситуации, когда команда заказчика была на 100% уверена в логике продукта, но реальные пользователи – стейкхолдеры, менеджеры, операторы – сталкиваются с проблемами на этапе его тестирования. Так появляются поводы для повторного кастдева.
Где расходятся ожидания и практика
Сейчас мы заканчиваем работу над инструментом :Puls для компании Upjet, который помогает в организации и проведении различных корпоративных мероприятий. Так как аналогичных продуктов и коробочных решений на рынке не существует, весь функционал и бизнес-логику продукта мы построили с нуля. Клиент хорошо знает свой домен и его особенности, поэтому мы полностью опирались на вводные и требования, которые он нам передавал.
Но сами стейкхолдеры увидели :Puls только перед финальным релизом. Продукт разрабатывался секрете, а все ключевые решения принимали два ответственных специалиста. Мы старались предусмотреть разные сценарии и сделать инструмент максимально универсальным. Но на практике это обернулось сложностями.
Каждый участник процесса хотел внести в :Puls что-то своё: дизайнер – добавить больше фирменных цветов и стилей, специалист по проживанию – поменять механику распределения отелей и дат. А в это время другие пользователи – менеджеры и логисты, – сталкивались с тем, что продукт недостаточно хорошо решает их базовые задачи.
В итоге стало понятно: вместо того чтобы пытаться угодить всем сразу, нужно было начать с одного рабочего сценария и строить весь остальной функционал уже вокруг него.
Здесь выйти из ситуации нам помогли:
- Проведение фокус-групп при участии сотрудников Upjet, по результатам которых мы оптимизировали функционал и смогли выстроить внутренние процессы так, чтобы они закрывали потребности всех участников проекта;
- Продуктовый подход нашей команды – еще на старте было понятно, что инструмент будет состоять из множества компонентов, поэтому дизайнер сразу создала дизайн-систему из трех уровней и библиотеку компонентов, благодаря которой разработчики могли быстро дорабатывать продукт даже при существенных изменениях интерфейса.
Несмотря на то, что от некоторых изначальных идей пришлось отказаться, правильная расстановка приоритетов позволила сделать :Puls действительно полезным инструментом. Клиент уже провел с его помощью одно внутреннее мероприятие, и сейчас мы вносим финальные доработки, чтобы выкатить продукт на рынок.
Пользовательский сценарий vs. рабочий регламент
Интересная ситуация произошла и со стартапом Foodclick – агрегатором ресторанов, для которого мы стали техническим партнером. Главную боль администраторов заведений основатель проекта считал правильно – отсутствие автоматизации бронирований и предзаказов, из-за которого персонал тратит много времени на звонки с уточнениями и часто совершает ошибки, а сами гости ленятся перезванивать, чтобы отменить визит. Из-за этого бизнес теряет прибыль.
Решением стал запуск приложения, где каждый ресторан мог завести свою страницу с меню и механикой бронирования, а сами пользователи управлять своими заказами. Мы продумали удобный путь как для гостей, так и для администаторов, и передали клиенту готовый продукт.
Проблемы возникли дальше – на этапе подключения заведений к агрегатору. Выяснилось, что процесс сопровождается большой бюрократией и каждый новый ресторан нужно регистрировать вручную. Также многие управляющие сомневались в эффективности агрегатора и не хотели самостоятельно обучать персонал работе в новом инструменте.
Проблемы возникли дальше – на этапе подключения заведений к агрегатору. Выяснилось, что процесс сопровождается большой бюрократией и каждый новый ресторан нужно регистрировать вручную. Также многие управляющие сомневались в эффективности агрегатора и не хотели самостоятельно обучать персонал работе в новом инструменте.
Так выяснилось, что Foodclick решает основную проблему, но создает сопутствующие. А значит, нужно дополнительно предусмотреть автоматическую регистрацию, онбординг сотрудников и прозрачную систему выгод, которые получает заведение.
Как работает Foodclick сейчас, можно узнать тут.
Foodclick: приложение-агрегатор для бронирования столов, оформления предзаказов и безналичных чаевых
История разработки приложения для бронирования столов и решения других задач – от выбора заведения и предзаказа блюд до автоматической оплаты и безналичных чаевых.
Можно построить сильный продукт с умной логикой, крутым UI и понятным бэклогом. Но пока вы не увидите, как с ним взаимодействуют реальные люди – это всё гипотеза. Даже самый опытный заказчик не всегда может предсказать, как продукт будет жить в реальной среде в условиях ограничений и человеческого фактора.
Поэтому повторный кастдев аудитории – не ошибка. Это ваша страховка. Он помогает скорректировать курс и вовремя переосмыслить приоритеты. Но важно, чтобы сама архитектура продукта была готова к быстрому внесению изменений.
Столкнулись со сложностями в развитии продукта? Мы проведем технический аудит
Максим Бонцевич
CEO dev.family
А можно совсем без кастдева?
Мы часто слышим от клиентов: «Давайте без кастдева – мы и так всё про свою аудиторию знаем». Иногда это действительно так. Есть сценарии, где можно стартовать сразу с разработки, не проводя глубинных интервью или массовых опросов. Но это редкие исключения. И вот два случая, когда кастдев можно заменить уверенной экспертизой – либо в своей аудитории, либо в продуктовой нише.
Когда аудитория уже лояльна
Иногда бизнес уже нарастил такой уровень доверия у клиентов, что новые цифровые решения «залетают» сразу. Так было в проекте с сетью магазинов «Пивточка».
У ритейлера было более 100 торговых точек и стабильная клиентская база. Основная боль – пластиковые карты лояльности, которые неудобны и покупателям, и кассирам. Поэтому идея запустить мобильное приложение с бонусами и акциями попала в ожидания аудитории: к сервису подключились более 250 000 пользователей.
У компании уже была своя аналитика: она показала, какие функции будут востребованы. Так появились семейные аккаунты, «Избранное», комментарии, оценки и другие полезные детали. Приложение не только улучшило пользовательский опыт, но и повлияло на внутренние метрики бизнеса: KPI в магазинах стали рассчитываться по новым параметрам, ориентированным на удержание и интерес клиентов.
А после запуска внутриигровой механики с «Колесом Фортуны» ежедневная активность (DAU) выросла на 20-30% и сейчас составляет около 26 000 пользователей в пиковые одни (обычно, это пятница, сами понимаете). Это пример, где лояльность аудитории и работа с данными могут заменить глубокий кастдев – но только потому, что все гипотезы были подтверждены цифрами.
Приложение программы лояльности для крупного сетевого ритейлера
История разработки мобильного приложения для сети из 189 магазинов разливного пива. Она начиналось как простое обновление программы лояльности. Но в итоге клиент получил полноценный канал коммуникации со своей аудиторией, с которым он начал собирать информацию о покупателях, увеличил сумму среднего чека и улучшил свои предложения.
Когда команда уже запускала похожие продукты
Второй случай – если у заказчика уже есть релевантный опыт в запуске продуктов в своей нише и он хорошо понимает, что нужно пользователям.
Не так давно мы стали техническим партнером дарк-китчина Sizl в Чикаго. Одним из сооснователей выступил Алексей Колесников, хорошо известный на рынке по проекту Local Kitchen. Когда владелец бизнеса понимает суть и ценность продукта, а также рынок, на котором работает, внедрение новых функций уже не столько гипотезы, сколько часть стратегии и экономической модели бизнеса.
В этом случае разработка отталкивается уже от конкретных задач:
- Нужны способы оптимизации – просчитываем на старте необходимое количество приборов на основании заказанных блюд;
- Необходимо лучше управлять стоимостью доставки – добавляем динамический расчет и организуем апсейл через функцию «Быстрая доставка»;
- Хотим масштабироваться в новых локациях – внедряем функцию «Хочу Sizl тут», с помощью которой пользователи могут отмечать на карте районы городах, где хотели бы открыть станцию дарк-китчена.
О других решениях для проекта Sizl можно почитать здесь.
Sizl: как мы стали техническим партнером сети дарк китченов в Чикаго
История работы над приложением для быстрорастущей сети дарк китченов с доставкой еды и самовывозом, которая началась с ребилда и продолжилась разработкой нового функционала. Сразу после релиза продукт привлёк инвестиции, а сама компания продолжила активно расширять своё присутствие в Чикаго.
Опытные фаундеры знают, что гипотезы – это не догадки, а управляемый инструмент, встроенный в стратегию роста. И в таких случаях кастдев превращается скорее в точечную валидацию, чем в открытие новых инсайтов.
Почему мы так любим кастдевы
Одна из главных тревог, когда вы ищете аутсорсинг IT услуг – будут ли разработчики действительно переживать за продукт, или просто линейно пойдут по ТЗ. Проверить надежность технического партнера достаточно просто. Подумайте:
- Участвует ли команда в обсуждении проблем?
- Понимает ли, для кого и зачем создаётся функциональность?
- Просто делает, как вы ей сказали?
Именно поэтому мы не боимся задавать неудобные вопросы, пересобирать процессы и при необходимости – возвращаться к этапу исследования. Это не про сомнение в идее, а про ответственность за результат и уважение к тем, кто с этим результатом будет работать каждый день.
