Свой продукт: от идеи к первым платящим, MVP и проверка спроса

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

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

Рамка трека. Здесь нет юридических, налоговых и бухгалтерских консультаций и нет конкретных ставок, лимитов, порогов и «рыночных вилок цен». Всё, что касается формы деятельности (самозанятость, ИП, ООО), приёма платежей, обработки персональных данных и работы с иностранными сервисами, разбирается как список вопросов, которые вы зададите живому бухгалтеру и юристу, а конкретику проверяете на официальных источниках — ФНС России, Госуслуги, портал правовой информации — на дату, потому что правила и цифры меняются, а неверная цифра из статьи живёт годами.

1. Продукт — это повторяемая сделка, а не готовый код

Инженерное определение продукта («работающая система, которую можно скачать») бесполезно для принятия решений. Рабочее определение такое:

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

Из определения сразу видно, что продукт состоит из четырёх независимых частей, и код — одна из них, обычно самая дешёвая:

Если любая из первых трёх частей неизвестна, написанный код — это не актив, а обязательство: он требует поддержки, платит за инфраструктуру, стареет и морально давит («столько вложено, жалко бросить»). Отсюда практический принцип: сначала снимайте неопределённость там, где она максимальна, а не там, где вам приятнее работать.

1.1. Спектр между услугой и продуктом

Переход не бинарный. Между «пишу на заказ» и «SaaS с самообслуживанием» лежит несколько ступеней, и большинство успешных одиночных продуктов рождается именно на промежуточных.

Практический вывод: лучшая стартовая позиция для продукта — действующая практика услуг. Там уже есть три вещи, которых нет у человека «с идеей»: доступ к людям с деньгами и болью, насмотренность на повторяющиеся задачи и денежный поток, чтобы профинансировать поиск. Как устроен этот поток и как не остаться без него — в Деньги и риски и Юнит-экономике.

1.2. Что меняется в вашей работе

Строка «поддержка не масштабируется» — самая недооценённая. У продукта есть свойство, которого нет у услуг: вы не перестаёте отвечать за проданное. Клиент, заплативший год назад, пишет вам в субботу, потому что у него сломалось. Это не аварийная ситуация, а нормальный режим, и его нужно закладывать в план и в цену.

2. Откуда берутся идеи, которые выживают

Три источника, в порядке убывания надёжности.

1. Боль, которую вы видели в оплаченной работе. Вы трижды писали похожий импортёр выгрузок, потому что у трёх клиентов одна и та же беда. Здесь уже известны сегмент, формулировка проблемы на языке клиента и факт, что за неё платили, — это три четверти работы. Ловушка одна: убедиться, что задача повторяется у разных компаний одинаково, а не выглядит похожей только снаружи.

2. Собственный зуд (scratch your own itch). Вы сделали инструмент себе, он экономит вам часы; плюс в том, что вы сами носитель проблемы и видите качество решения. Минус, губящий большинство таких проектов: сегмент «разработчики вроде меня» — один из худших плательщиков за инструменты, потому что у него всегда есть альтернатива «напишу сам за выходные» при высоком пороге качества. Не запрет, а требование проверять готовность платить особенно рано.

3. Наблюдение за рынком. Чаты профессиональных сообществ, отзывы на существующие продукты («работает, но безумно медленно на больших файлах»), вакансии («ищем человека, который вручную сверяет два реестра» — это описание продукта). Слабее первых двух, но единственный доступный вариант, если вы приходите из найма без клиентской базы.

Чего в этом списке нет: «я придумал идею, которой ни у кого нет». Отсутствие конкурентов чаще означает отсутствие денег в нише, чем незанятую поляну. Существующие конкуренты — хороший знак: кто-то уже доказал, что за это платят, и вам остаётся более узкая и потому более выполнимая задача — быть заметно лучше для конкретного сегмента.

2.1. Фильтр: не «хорошая идея», а «проверяемая быстро»

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

Два квадранта заслуживают комментария. Маркетплейсы и двусторонние площадки — худший выбор для первого продукта в одиночку: нужно одновременно набрать обе стороны, ни одна не приходит без другой, а проверить это дёшево невозможно. Регулируемые рынки (медицина, финансы, всё, что связано с обработкой чувствительных данных) — не «нельзя», но требуют юридической подготовки до первой строки кода, потому что там ошибка стоит не денег, а запрета на деятельность. Это ровно тот случай, когда час юриста покупается заранее.

2.2. Карточка гипотезы

Гипотеза, которую нельзя опровергнуть, — не гипотеза, а надежда. Записывайте так, чтобы через месяц вы могли сказать «да» или «нет», не споря с собой:

# hypothesis-01.yaml — карточка одной проверяемой гипотезы
segment: "техдиры интеграторов 1С, 10-50 человек, делают внедрения на заказ"
access: "12 контактов из прошлых проектов + 2 профильных чата"      # без этого проверка невозможна
problem: "перед сдачей вручную сверяют номенклатуру в двух базах, 3-6 часов на проект"
evidence_now: "видел у 3 клиентов лично; двое жаловались в переписке"
current_workaround: "Excel и сверка глазами; один написал скрипт, но он развалился"
value_hint: "стоимость их часа x объём — считают сами, я не выдумываю цифру"
riskiest_assumption: "готовы ли платить деньгами компании, а не терпеть бесплатную боль"
test: "предложить платный ручной прогон сверки для 5 компаний"
signal_success: "не менее 3 согласий на предоплату в течение 3 недель"
signal_failure: "меньше 2 согласий или все просят «покажите сначала продукт»"
deadline: "3 недели с сегодняшнего дня"
decision_rule: "провал => не строю; успех => 4 недели на сквозной срез"

Три поля тут обязательны и обычно пропускаются: riskiest_assumption (что убьёт затею быстрее всего), signal_failure (заранее описанный отрицательный исход) и deadline. Без них проверка превращается в бесконечное «ещё немного поговорю с людьми».

3. Сегмент раньше идеи: кто платит, кто пользуется, кто мешает

«Это нужно всем» операционно означает «я не знаю, кому это нужно» — и делает невозможными все последующие шаги: непонятно, где искать, что писать на странице, какую цену называть.

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

• Пользователь — у него болит; он ваш союзник, но часто не решает.
• Плательщик — у него бюджет; его волнует не удобство, а деньги, риск и время.
• Блокирующий — безопасность, юристы, ИТ-отдел, «у нас нельзя внешние сервисы». Он ничего не выиграет от покупки, но может её отменить.

Отсюда практическое следствие: сообщение для пользователя и для плательщика разное. Пользователю — «перестанете сверять руками по три часа», плательщику — «сокращается срок сдачи проекта и число возвратов на доработку». Для B2C роли сливаются, зато цена одного клиента ниже, а объём нужен больше — и появляется отдельная сложность канала.

Хороший сегмент для первого продукта проходит четыре теста:

1. Достижимость. Вы можете назвать конкретное место, где эти люди собираются, или способ до них дописаться. Нет способа — сегмента для вас нет.
2. Однородность. У них похожие процессы и словарь. Иначе продукт расползётся на несовместимые требования, а вы вернётесь в заказную разработку, только без оплаты.
3. Наличие денег и полномочий. Они уже за что-то платят в этой области. Люди, которые никогда ни за что не платили, редко начинают с вас.
4. Осознанность проблемы. Они уже пытаются её решать — костылём, вручную, чужим инструментом. Продавать решение неосознанной проблемы — это оплачивать обучение рынка, и в одиночку такое не тянут.

Работа с сегментами и исследованием подробно разобрана в Product management — Discovery и исследование; здесь мы смотрим на то же самое с позиции одиночки, который платит за исследование своим временем.

4. Лестница доказательств: чем сильный сигнал отличается от вежливости

Главный навык этой стадии — различать силу сигналов. Люди добры: им проще сказать «классная идея», чем объяснять, почему они не будут этим пользоваться. Из-за этого начинающий продуктовый инженер регулярно получает сотню одобрений и ноль продаж.

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

Правило дешевле любого фреймворка: сигнал считается настоящим, если человек чем-то пожертвовал — деньгами, временем, доступом, репутацией внутри своей компании. Клик не жертва. Комментарий не жертва. Календарное окно на 40 минут — уже жертва.

4.1. Проблемные интервью без самообмана

Классика жанра — The Mom Test Роба Фитцпатрика: беседа должна быть построена так, чтобы даже ваша мама не смогла соврать из вежливости. Три запрета и три замены:

Что вы ищете в разговоре, по убыванию ценности: конкретный эпизод (когда, сколько времени, чем закончилось) → уже потраченные деньги или усилие (купили инструмент, наняли человека, написали скрипт) → эмоция раздражения → всё остальное. Если человек не может вспомнить ни одного конкретного случая, проблема либо не существует, либо не болит — и то и другое означает «не покупает».

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

5. Предпродажа — самый честный эксперимент

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

Что делать с ответом «покажите сначала готовый продукт»: это не всегда отказ, но всегда сигнал недостаточного доверия или недостаточной боли. Проверяется одним ходом — предложите ручной пилот: вы делаете работу руками, за деньги, без всякого продукта. Согласились — проблема реальна, а вам не хватало доверия к незнакомому решению. Отказались — проблема не стоит их бюджета.

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

6. MVP: что это на самом деле и чем оно не является

Термин испорчен. В повседневной речи «MVP» означает «урезанная первая версия», и с этим пониманием команды делают дорогую бесполезную вещь. В исходном смысле у Эрика Риса (The Lean Startup) MVP — это самый дешёвый эксперимент, дающий максимум информации о жизнеспособности бизнес-идеи. Не версия продукта. Инструмент обучения.

Практическое различие: у урезанной версии критерий готовности — «работает», у MVP — «мы узнали, верна ли гипотеза». Иногда для этого вообще не нужен код.

6.1. Типы MVP по стоимости

«Сделаю руками» пугает инженеров — кажется, что это не масштабируется. В том и смысл: Do Things That Don’t Scale Пола Грэма — ровно про то, что на старте нужна не масштабируемость, а информация. Ручной этап даёт то, чего не даст код: вы видите настоящий процесс клиента, а не его пересказ.

6.2. Как резать объём первой версии

Правило: режем вширь, а не вглубь. Один сценарий, доведённый до конца (включая оплату), даёт информацию; половина всех сценариев не даёт ничего.

Отдельно про соблазн «сделаю сначала фундамент». Очередь, кластер, мультиарендность, плагинная архитектура, i18n на пять языков, тёмная тема — всё это работа, которая ощущается как прогресс и не производит ни грамма информации о спросе. Порядок обратный: сначала сквозной срез с ручными заплатками, потом — только под подтверждённую нагрузку и подтверждённые деньги. Технические решения, которые дорого менять потом, стоит принимать осознанно и записывать; техника этого — в Архитектурные решения и ADR.

6.3. Что нельзя урезать даже в самой первой версии

Список короткий, но невыполнение любого пункта обнуляет эксперимент:

• Приём денег. Без оплаты вы измеряете интерес, а не спрос.
• Сохранность данных клиента. Потерянные данные — это конец репутации в узкой нише и потенциально юридические последствия. Бэкап и проверка восстановления — не «потом».
• Базовая безопасность. Пароли, доступы, разграничение чужих данных. Утечка на этапе MVP убивает проект надёжнее отсутствия спроса; минимум — в OWASP Top 10 и Аутентификация.
• Возможность связаться с вами. Живой канал поддержки на старте — источник данных, а не издержка.
• Честность формулировок. Не обещайте того, чего нет. Одна разоблачённая неправда в маленьком рынке стоит дороже, чем весь полученный от неё эффект.

7. Техника: скучный стек и стоимость владения

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

• Монолит, один процесс, одна реляционная база. Микросервисы и экзотические хранилища решают проблемы, которых у вас нет, и немедленно создают операционные: Монолит и модульный монолит, Выбор и миграция СУБД.
• Стек, который вы знаете лучше всего. Изучение нового фреймворка на продукте — это два эксперимента одновременно, и вы не поймёте, какой из них провалился.
• Управляемые сервисы вместо своей инфраструктуры, пока счёт за них меньше стоимости вашего часа на администрирование; обратный переход тоже бывает выгоден — Стоимость облака и trade-offs, VPS/VDS и bare metal.
• Автоматический деплой с первого дня. Ручной релиз незаметно снижает частоту выкатки, а с ней — скорость обучения.

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

8. Деньги внутри продукта: что нужно решить до первой продажи

Это тот участок, где инженер чаще всего действует «как-нибудь потом разберусь», и именно здесь ошибки самые дорогие и наименее обратимые. Ниже — список вопросов, а не ответы: ответы зависят от страны, вида деятельности, того, кому вы продаёте, и от даты.

Вопросы бухгалтеру:

• В какой форме мне вести эту деятельность и чем формы отличаются по обязанностям и отчётности в моём случае (самозанятость, ИП, ООО)?
• Подходит ли выбранная форма для продажи продукта, а не услуг; есть ли ограничения по видам деятельности и по работе с иностранными покупателями?
• Как оформляются поступления от физлиц и от юрлиц, что считается доходом и когда?
• Какие обязанности возникают при приёме онлайн-оплаты; нужна ли касса и в каких случаях?
• Что происходит с возвратами и как их правильно отражать?
• Что меняется, если продукт по подписке, а не разовая продажа?

Вопросы юристу:

• Что должно быть в публичной оферте или пользовательском соглашении для моей модели?
• Как ограничить ответственность за сбои и потерю данных и что ограничить нельзя?
• Что происходит с правами на код, если часть писалась в период работы по трудовому договору или по договору с заказчиком (см. Договоры)?
• Какие требования к обработке персональных данных возникают в моём случае, нужно ли уведомление, что писать в политике обработки?
• Можно ли законно использовать выбранные библиотеки в коммерческом продукте — совместимы ли лицензии (в частности, копилефт) с моей моделью продажи?
• Что писать в условиях предпродажи: сроки, возврат, ответственность при срыве?

Что решается инженерно, но с оглядкой на предыдущие два списка: способ приёма платежей и провайдер, хранение платёжных данных (кратко: не храните — делегируйте провайдеру), разделение прод-доступов, журналирование операций с деньгами, процесс возврата. Регуляторные и приватностные аспекты полезно заранее прочитать в Приватность и комплаенс — но это обзор понятий, а не заключение по вашей ситуации.

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

9. Что и как считать на ранней стадии

Метрики на стадии поиска отличаются от метрик роста. Регистрации, просмотры и подписчики не отвечают на вопрос «жив ли продукт». Отвечают три вещи: активация (человек получил обещанный результат), удержание (вернулся сам) и повторяемость сделки.

Минимальная модель данных, которой хватает на первый год:

Ключевое поле здесь — EVENT_TYPE.meaning. Событие без записанного делового смысла через три месяца превращается в мусор, который никто не решается удалить. И ACCOUNT.source: без него вы никогда не узнаете, какой канал приносит платящих, а какой — трафик.

Когортное удержание считается одним запросом; смотреть на него нужно по когортам недели регистрации, иначе рост новых пользователей маскирует отток старых:

-- Недельные когорты: доля аккаунтов, вернувшихся к ключевому действию
-- через N недель после регистрации. PostgreSQL.
WITH cohorts AS (
    SELECT id AS account_id,
           date_trunc('week', signed_up_at)::date AS cohort_week
    FROM account
),
activity AS (
    SELECT u.account_id,
           date_trunc('week', e.at)::date AS active_week
    FROM event e
    JOIN "user" u ON u.id = e.user_id
    WHERE e.type = 'core_action'          -- ключевое действие, ради которого платят
    GROUP BY 1, 2
)
SELECT c.cohort_week,
       ((a.active_week - c.cohort_week) / 7) AS week_offset,
       COUNT(DISTINCT a.account_id)                       AS returned,
       COUNT(DISTINCT c.account_id)                       AS cohort_size,
       ROUND(100.0 * COUNT(DISTINCT a.account_id)
             / NULLIF(COUNT(DISTINCT c.account_id), 0), 1) AS retention_pct
FROM cohorts c
LEFT JOIN activity a ON a.account_id = c.account_id
GROUP BY 1, 2
ORDER BY 1, 2;

Как читать результат. Если кривая удержания выходит на плато — есть группа людей, для которых продукт стал частью работы; это и есть зародыш бизнеса, и дальше задача — приводить в него больше похожих. Если кривая уходит в ноль — сколько бы новых пользователей вы ни привели, они вытекут; добавлять маркетинг в дырявое ведро бессмысленно. Подробнее про метрики и их интерпретацию — Product management: метрики и Аналитика и решения.

Ещё один инструмент — опрос Шона Эллиса: «как вы будете себя чувствовать, если продукт исчезнет?» с вариантами «очень расстроюсь / немного расстроюсь / не расстроюсь» (pmfsurvey.com). Доля «очень расстроюсь» — грубая эвристика соответствия продукта рынку, у неё есть критики и она осмысленна только при достаточном числе активных пользователей. Не относитесь к порогу как к закону природы: полезнее не число, а чтение объяснений тех, кто ответил «очень расстроюсь», — там лежит формулировка вашей настоящей ценности, часто отличная от задуманной.

9.1. Сколько платящих нужно, чтобы это имело смысл

Простой расчёт, который стоит сделать до старта: сколько клиентов должно быть, чтобы продукт заменил часть дохода от услуг. Все числа ниже — условные единицы-заполнители; подставляйте свои, никакие «типичные» значения из статей брать нельзя.

"""Прикидка масштаба продуктовой затеи. Все входные числа — ваши собственные.
Единицы условные (у.е.): методика важнее цифр."""
from dataclasses import dataclass


@dataclass
class ProductPlan:
    price_per_month: float      # ваша цена за месяц подписки, у.е.
    monthly_costs: float        # хостинг, сервисы, платёжный провайдер, у.е.
    target_income: float        # сколько продукт должен приносить в месяц, у.е.
    monthly_churn: float        # доля клиентов, уходящих за месяц (0.05 = 5%)
    support_minutes: float      # минуты поддержки на клиента в месяц
    hours_available: float      # ваших рабочих часов в месяц на этот продукт

    def customers_needed(self) -> float:
        """Сколько одновременно активных подписчиков нужно для целевого дохода."""
        return (self.target_income + self.monthly_costs) / self.price_per_month

    def report(self) -> str:
        need = self.customers_needed()
        churn_flow = need * self.monthly_churn        # новых в месяц, чтобы стоять на месте
        support = need * self.support_minutes / 60    # часы поддержки на такой базе
        free = self.hours_available - support
        lines = [
            f"Нужно активных подписчиков: {need:.0f}",
            f"Новых в месяц только на компенсацию оттока: {churn_flow:.1f}",
            f"Часов поддержки в месяц на этой базе: {support:.1f}",
            f"Остаётся часов на развитие и продажи: {free:.1f}",
        ]
        if free < 0:
            lines.append("ВНИМАНИЕ: поддержка съедает всё время — цена или модель нежизнеспособны")
        if churn_flow > need * 0.2:
            lines.append("ВНИМАНИЕ: отток требует непрерывного притока — сначала чините удержание")
        return "\n".join(lines)


# Пример со ВЫМЫШЛЕННЫМИ входами — замените своими
plan = ProductPlan(
    price_per_month=20, monthly_costs=100, target_income=2000,
    monthly_churn=0.07, support_minutes=25, hours_available=60,
)
print(plan.report())

Ценность этого расчёта не в результате, а в двух вопросах, которые он задаёт вместо вас: потяните ли вы поддержку на нужном размере базы и сколько новых клиентов нужно приводить ежемесячно только для того, чтобы не падать. Часто именно здесь становится видно, что при низкой цене нужна аудитория, до которой у вас нет канала, — и разумнее поднять цену и сузить сегмент. Полноценный разбор — в Юнит-экономике, а методика расчёта цены (от затрат и от ценности, а не «как у других») — в Ценообразовании.

10. Жизненный цикл клиента и места разрывов

Три перехода определяют судьбу продукта, и все три чинятся не функциями:

• Signup → Activated. Самая большая утечка у инженерных продуктов. Причина почти всегда одна: пустой экран и требование настроить что-то до первой пользы. Лечится предзаполненными данными, примером «на посмотреть» и сокращением шагов до первого результата, а не новыми возможностями.
• Activated → Habit. Если задача разовая, подписка нежизнеспособна в принципе — это не провал, а сигнал сменить модель на разовую продажу.
• Paying → Churned. Уход почти никогда не происходит в момент отмены; он произошёл за недели до неё, когда человек перестал пользоваться. Поэтому отток нужно ловить по активности, а не по платежам, и разговаривать с уходящими лично: одно интервью с ушедшим клиентом полезнее десяти с довольными.

11. Первые платящие: канал важнее продукта

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

Практические правила первых продаж:

1. Продавайте лично, пока не поймёте, что именно покупают. Автоматизировать имеет смысл повторяющийся разговор, а не гипотетический.
2. Первым десяти клиентам помогайте руками. Вы платите своим временем за понимание, почему они остаются или уходят, — это самая дешёвая аналитика из существующих.
3. Записывайте формулировки клиентов дословно. Слова, которыми они описывают проблему, — готовый текст для вашей страницы; ваши собственные формулировки почти всегда хуже.
4. Не давайте бессрочных индивидуальных условий. «Тебе сделаю особую цену навсегда» создаёт неуправляемый зоопарк условий и мешает поднимать цену.
5. Отказ разбирайте по причинам: нет проблемы / нет денег / нет полномочий / нет доверия / не сейчас. Это четыре разные болезни с разным лечением, и только одна из них лечится доработкой продукта.

12. Как это финансировать и не выгореть

Самый частый способ убить продукт — начать его на голом энтузиазме без денежного контура. Три жизнеспособные схемы:

Схема с подушкой требует честного ответа на вопрос, который лучше задать до старта: на какой срок хватает резерва при нулевом доходе и что вы сделаете, когда он кончится? План «дальше будет видно» — не план. Кассовые разрывы, диверсификация и размер подушки — тема Денег и рисков.

Отдельно про выгорание, потому что в продуктовой работе оно устроено иначе, чем в найме. В найме выгорают от перегрузки; на своём продукте — от отсутствия обратной связи. Месяцы работы без единой продажи, без коллег, без внешнего подтверждения, что вы вообще двигаетесь. Что реально помогает: короткие циклы с наблюдаемым результатом (две-три недели максимум), фиксированные рабочие часы вместо «всегда немного работаю», сообщество таких же одиночек и заранее назначенные точки решения — чтобы неопределённость имела срок годности. Подробнее — Выгорание.

13. Заранее заданные критерии остановки

Самое дорогое в продукте — не деньги, а годы, потраченные на то, что не работало, потому что решение «закрыть» никогда не принимается в моменте: всегда кажется, что нужно ещё чуть-чуть. Единственное лекарство — написать критерии до начала, когда вы ещё беспристрастны.

Разумный формат: горизонт (например, 12 недель), три числа-порога и три действия.

Про пивот важно понимать: это смена одной переменной при фиксации остальных. «Поменяю сегмент, продукт, цену и канал одновременно» — это не пивот, а новый проект, только с усталостью и иллюзией продолжения.

И про закрытие: закрытый вовремя продукт — не провал, а завершённый эксперимент. Что забирать с собой: список контактов и разговоров, понимание сегмента, готовые внутренние инструменты, репутацию человека, который делает и доводит. Это капитал, который переносится в следующую попытку — и в услуги тоже.

14. Типичные ловушки

15. Мини-итог

• Продукт — повторяемая сделка, а не написанная программа; код без сегмента, проблемы и канала — обязательство, а не актив. Лучший старт — из действующей практики услуг.
• Идеи фильтруются не по величию, а по стоимости проверки и доступности аудитории.
• Сигналы спроса различаются по силе: настоящим считается тот, за который человек чем-то заплатил — деньгами, временем или доступом. Комплименты не считаются.
• Интервью — про прошлое поведение, а не про будущие намерения; предпродажа честнее любого опроса.
• MVP — эксперимент ради информации, а не урезанная версия; ручной труд внутри полезен. Режьте объём вширь: один сценарий целиком, включая оплату, вместо половины всего.
• Нельзя урезать: приём денег, сохранность данных, базовую безопасность, связь с вами, честность обещаний.
• Считайте активацию, когортное удержание и повторяемость сделки; регистрации и просмотры ничего не доказывают.
• Юридическое и налоговое — список вопросов специалистам до первой продажи; конкретику проверяйте на ФНС и Госуслугах на дату, из статей и форумов её не берут.
• Критерии продолжения, пивота и закрытия пишутся заранее — потом вы будете необъективны.

16. Источники

• Роб Фитцпатрик. The Mom Test — как разговаривать с людьми о проблеме, не получая вежливую ложь.
• Эрик Рис. The Lean Startup — исходное определение MVP как инструмента обучения и цикл build–measure–learn.
• Стив Бланк. Customer Development — почему поиск бизнес-модели и её исполнение требуют разных действий.
• Пол Грэм. Do Things That Don’t Scale — про ценность ручной работы на старте.
• Джейсон Коэн. Designing the Ideal Bootstrapped Business — критерии ниши и модели для самофинансируемого продукта.
• Роб Уоллинг. Start Small, Stay Small и Эми Хой с Алексом Хиллманом. Stacking the Bricks — практика продуктов одиночки и путь из услуг в продукт.
• Патрик Маккензи. Архив рассылки о SaaS и ценообразовании — продажа через деловой результат.
• 37signals. Getting Real и Shape Up — как ограничивать объём и работать циклами.
• Y Combinator Startup Library и Indie Hackers — источник вопросов, а не готовых цифр.
• ФНС России, Госуслуги, портал правовой информации — единственные источники конкретики по формам деятельности, обязанностям и срокам; проверяйте на дату.

Смежное в портале: MVP и эксперименты, Приоритизация, Ценообразование и рост, Стартап как тип проекта, Поддержка и техдолг.

Что дальше

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

Юнит-экономика для инженера: выручка, затраты, окупаемость, точка безубыточности