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

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

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

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

• предприниматель регулярно выполняет такую работу;
• другие компании нанимают людей для поиска и первичной оценки помещений;
• значительную часть первичного отбора можно автоматизировать;
• нижний слой получения объявлений необязательно создавать самостоятельно.

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

Я закрыл гипотезу отдельного сервиса поиска коммерческой недвижимости, но не саму задачу автоматизации.

Сначала все выглядело как хорошая продуктовая возможность

В первой статье серии я описывал исходную ситуацию. Предприниматель регулярно искал коммерческие помещения и хотел получать не сотни объявлений, а несколько объектов, которые действительно подходят под его требования. Индивидуальную разработку такой системы одно из агентств оценило примерно в 490 тысяч рублей и около 10 недель работы.

Сам клиент не хотел покупать отдельную разработку. За готовое решение он называл ориентир примерно 3-5 тысяч рублей в месяц. Это был сигнал одного клиента, а не рыночная цена. Но разрыв выглядел достаточно большим, чтобы проверить гипотезу: если похожая работа повторяется у многих компаний, возможно, систему можно создать один раз и продавать как готовый сервис.

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

Готовые данные одновременно усилили и ослабили гипотезу

Следующим вопросом было получение объявлений. Эту часть я разобрал в статье почему я не стал собирать объявления Авито самостоятельно. Для проверки гипотезы результат был хорошим: на рынке уже есть поставщики, которые позволяют получать объявления программно и применять базовые фильтры. Значит, необязательно сначала строить и постоянно поддерживать собственный сбор данных.

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

требования конкретного бизнеса -> квалификация объекта -> оценка -> список подходящих помещений -> передача результата в рабочий процесс.

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

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

Это уже хуже соответствует идее простого массового сервиса.

Вакансии подтвердили функцию, но не продуктовый рынок

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

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

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

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

Количественная проверка изменила картину сильнее всего

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

За 30 дней по России пересечение поиска по названиям должностей и обязанностям дало 431 вакансию у 183 работодателей. После ручной проверки к прямому сценарию я отнес 44 работодателя и 185 вакансий.

Самое важное оказалось не в числе 44, а в распределении. Шесть крупнейших работодателей дали 118 из 185 прямых вакансий, то есть около 64 процентов. У 25 из 44 прямых работодателей в выборке была только одна вакансия.

44 компании не являются размером всего российского рынка. Это результат конкретного запроса по открытым вакансиям за конкретный 30-дневный период. Компании могут не нанимать, использовать другие названия должностей или закрывать функцию действующими сотрудниками.

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

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

Главная проблема оказалась между стандартизацией и ценой

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

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

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

• продавать хочется простой недорогой сервис;
• создавать ценность приходится через глубокую настройку;
• самые заметные потенциальные покупатели имеют сложные процессы;
• массовость небольших покупателей не подтверждена.

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

Отдельно остается зависимость от источника объявлений

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

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

Вместе эти факторы делают отдельный стандартизированный сервис менее привлекательным.

Что я бы автоматизировал для конкретного клиента

Закрытие продуктовой гипотезы не означает, что сама работа плоха для автоматизации. Для конкретной компании я по-прежнему вижу рабочую схему:

готовый источник данных -> критерии клиента -> автоматическая квалификация -> список подходящих объектов -> интеграция в рабочий процесс.

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

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

Для Brain4 такой вариант выглядит логичнее: сначала зафиксировать исходный процесс и экономику конкретного клиента, затем автоматизировать повторяемую часть и проверить измеримый эффект.

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

Я не считаю решение необратимым. Гипотезу можно открыть снова, если появятся новые доказательства. Для этого мне нужны были бы одновременно несколько сигналов:

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

Если эти условия появятся, продуктовую модель можно проверять заново. Сейчас таких доказательств у меня нет.

Что я считаю результатом исследования

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

Исследование позволило остановиться раньше и последовательно проверить более важные вещи:

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

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

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

Я закрыл продуктовую гипотезу до разработки. В данном случае именно это и было полезным результатом исследования.