Четыре инженера не равны команде продукта. 📦
Когда мы делали pdf2latex, нас было четыре инженера. Мы умели собирать Telegram-ботов, обучать модели, распознавать формулы, работать с изображениями и думать об архитектуре. Для второго курса это казалось почти идеальной командой.
Но потом стало понятно, что четыре инженера не обязательно образуют продуктовую команду. Иногда это просто четыре человека, которые умеют очень хорошо строить технологию.
Для MVP не нужна большая компания и набор формальных должностей. Не обязательно сразу искать отдельного продакта, маркетолога, продавца, дизайнера и руководителя проекта. Но две функции в команде должны быть закрыты с самого начала:
1) человек, который отвечает за технологию и может быстро собрать решение.
2) человек, который отвечает за дистрибуцию: разговаривает с потенциальными пользователями, понимает их проблему, ищет первые каналы привлечения, предлагает продукт и получает обратную связь от рынка.
Это не значит, что в команде обязательно должно быть всего два человека. Один и тот же человек иногда может закрывать несколько функций. Но если никто не отвечает за технологию, нечего проверять. А если никто не отвечает за дистрибуцию, команда очень быстро начинает проверять не рынок, а собственные инженерные фантазии. ⚙️
Я видел много команд, состоящих только из инженеров. Обычно их история развивается похоже. Сначала появляется хорошая идея. Потом команда решает, что перед запуском нужно сделать всё системно: продумать архитектуру, заложить масштабирование, убрать технический долг, предусмотреть редкие сценарии, сделать интерфейс удобнее и добавить ещё одну важную функцию.
Каждое решение по отдельности звучит разумно. Проблема в том, что рынок в этот момент всё ещё не сказал, нужен ли ему продукт вообще. В таком режиме команда может жить очень долго. Пока люди не выгорят. Пока не закончится финансирование. Пока не станет очевидно, что конкуренты уже успели запуститься, поговорить с пользователями, исправить ошибки и сделать решение лучше. 🤡
Самое опасное, что это происходит не только с новичками. Я видел зрелые команды из сильных и опытных инженеров, с большими бюджетами и высокими ФОТами. Уровень разработки был действительно серьёзным. Но продукт всё равно месяцами или годами оставался «почти готов». Потому что готовность продукта определяет не команда. Определяет не количество написанного кода, не красивая архитектура, не покрытие тестами и даже не удобство интерфейса, которое инженеры оценили на внутренней демо-встрече. Всё это может быть важно позже. Но на этапе MVP главный вопрос другой: готов ли кто-то регулярно отдавать за ваше решение деньги? 💰
Если рынок голосует рублём, значит продукт уже создаёт ценность, с которой можно работать дальше. Улучшать опыт, убирать ограничения, строить систему, масштабировать продажи. Если не голосует, это не всегда означает, что идея плохая. Возможно, выбран не тот клиент, не та проблема, не та цена или не тот способ донести ценность. Но это означает, что дальнейшая разработка не должна автоматически считаться прогрессом.
Когда мы делали pdf2latex, нас было четыре инженера. Мы умели собирать Telegram-ботов, обучать модели, распознавать формулы, работать с изображениями и думать об архитектуре. Для второго курса это казалось почти идеальной командой.
Но потом стало понятно, что четыре инженера не обязательно образуют продуктовую команду. Иногда это просто четыре человека, которые умеют очень хорошо строить технологию.
Для MVP не нужна большая компания и набор формальных должностей. Не обязательно сразу искать отдельного продакта, маркетолога, продавца, дизайнера и руководителя проекта. Но две функции в команде должны быть закрыты с самого начала:
1) человек, который отвечает за технологию и может быстро собрать решение.
2) человек, который отвечает за дистрибуцию: разговаривает с потенциальными пользователями, понимает их проблему, ищет первые каналы привлечения, предлагает продукт и получает обратную связь от рынка.
Это не значит, что в команде обязательно должно быть всего два человека. Один и тот же человек иногда может закрывать несколько функций. Но если никто не отвечает за технологию, нечего проверять. А если никто не отвечает за дистрибуцию, команда очень быстро начинает проверять не рынок, а собственные инженерные фантазии. ⚙️
Я видел много команд, состоящих только из инженеров. Обычно их история развивается похоже. Сначала появляется хорошая идея. Потом команда решает, что перед запуском нужно сделать всё системно: продумать архитектуру, заложить масштабирование, убрать технический долг, предусмотреть редкие сценарии, сделать интерфейс удобнее и добавить ещё одну важную функцию.
Каждое решение по отдельности звучит разумно. Проблема в том, что рынок в этот момент всё ещё не сказал, нужен ли ему продукт вообще. В таком режиме команда может жить очень долго. Пока люди не выгорят. Пока не закончится финансирование. Пока не станет очевидно, что конкуренты уже успели запуститься, поговорить с пользователями, исправить ошибки и сделать решение лучше. 🤡
Самое опасное, что это происходит не только с новичками. Я видел зрелые команды из сильных и опытных инженеров, с большими бюджетами и высокими ФОТами. Уровень разработки был действительно серьёзным. Но продукт всё равно месяцами или годами оставался «почти готов». Потому что готовность продукта определяет не команда. Определяет не количество написанного кода, не красивая архитектура, не покрытие тестами и даже не удобство интерфейса, которое инженеры оценили на внутренней демо-встрече. Всё это может быть важно позже. Но на этапе MVP главный вопрос другой: готов ли кто-то регулярно отдавать за ваше решение деньги? 💰
Если рынок голосует рублём, значит продукт уже создаёт ценность, с которой можно работать дальше. Улучшать опыт, убирать ограничения, строить систему, масштабировать продажи. Если не голосует, это не всегда означает, что идея плохая. Возможно, выбран не тот клиент, не та проблема, не та цена или не тот способ донести ценность. Но это означает, что дальнейшая разработка не должна автоматически считаться прогрессом.