# Нелли Юсупова: «Технического сооснователя нужно заслужить, а не искать»

Источник: https://www.youtube.com/watch?v=72Zqhei0XGQ
Канал: Founder Institute
Опубликовано: 26.04.2022

---

Запуск технологического стартапа традиционно считается невозможным без «технического» партнёра. Однако Нелли Юсупова, эксперт, CTO и технический стратег, утверждает, что поиск сооснователя — это часто ложная цель, которая тормозит развитие продукта. В рамках вебинара для Founder Institute она представила методологию, позволяющую предпринимателям без навыков программирования самостоятельно доводить идеи до стадии работающего MVP и привлекать инвестиции.

## 🤝 Почему не нужно «искать» технического сооснователя
[[JUMP:08:00]]

Большинство нетехнических основателей начинают свой путь с мысли: «Мне нужен СТО, чтобы сэкономить деньги (он будет работать за долю) и закрыть вопрос разработки» [08:18]. По мнению Нелли Юсуповой, это ошибочная стратегия. Она считает, что технического сооснователя невозможно просто «найти» — его нужно «заслужить» (earn) [09:24].

Ситуация на рынке труда такова, что высококвалифицированные разработчики сегодня не испытывают проблем с заработком и зачастую склонны к минимизации рисков [10:02]. Чтобы привлечь такого человека в стартап, основатель должен детерминировать (снизить) риски проекта. Юсупова выделяет три шага, которые позволяют «заслужить» партнёра:

*   **Валидация идеи и создание кликабельного прототипа.** Это доказывает, что продукт нужен рынку [10:56].
*   **Формирование сообщества.** Наличие аудитории подтверждает маркетинговые навыки основателя [11:22].
*   **Инвестиции собственных средств в MVP.** Это демонстрирует веру в проект и наличие «шкуры в игре» [11:36].

По словам эксперта, наличие первых результатов (traction) меняет тон переговоров с «ты мне нужен» на «это отличная возможность, и тебе повезло стать её частью» [12:16].

## 💍 Опасность поспешного партнёрства
[[JUMP:14:47]]

Нелли Юсупова сравнивает поиск сооснователя с процессом свиданий и браком. Она утверждает, что многие основатели совершают ошибку, соглашаясь на партнёрство слишком рано [15:13]. Сооснователь — это человек, с которым придётся решать сложнейшие задачи в течение минимум 5–7 лет [15:38].

Согласно статистике, приведённой Юсуповой, основной причиной провала стартапов на ранних стадиях является конфликт между основателями [15:50]. Они не могут договориться о пути развития компании или просто не совместимы по ценностям. Эксперт рекомендует сначала нанимать потенциального партнёра как контрактника на конкретный проект, чтобы проверить совместимость в деле, прежде чем отдавать долю в компании [16:17].

## 🏗️ Проблемы аутсорсинга и роль процесса
[[JUMP:17:25]]

Для нетехнического основателя аутсорсинг часто становится единственным быстрым способом запустить продукт. Однако Юсупова отмечает, что это сопряжено с огромными рисками. Она упоминает случаи из своей практики, когда стартапы теряли от $60 000 до $100 000 посевного раунда, доверившись недобросовестным подрядчикам [18:31].

Ключевая проблема, по мнению Юсуповой, заключается не в «плохих разработчиках», а в самом предпринимателе, который не знает, как управлять процессом [19:47]. Основные ошибки основателей:

*   Отсутствие понимания процесса разработки мобильных и веб-приложений [19:47].
*   Неумение правильно нанимать и контролировать технических специалистов [20:01].
*   Слепое доверие разработчикам в вопросах принятия бизнес-решений [20:14].

Юсупова подчёркивает, что без понимания основ разработки основатель похож на клиента автосервиса, который не смыслит в машинах: он верит любому слову механика и платит за ненужный ремонт [20:39].

## 💊 Секрет №1: Валидация и прототипирование
[[JUMP:23:20]]

Первое правило экономии бюджета — не строить лишнего. Любая идея на старте является лишь гипотезой, которую нужно доказать [24:01]. Юсупова разделяет идеи на «обезболивающие» (painkillers), решающие острую проблему, и «витамины», которые люди хотят иметь, но не готовы за них платить [24:13].

Основатель должен использовать «customer development» — глубинные интервью один на один. Юсупова предостерегает от использования фокус-групп или простых опросов [25:47]. Она рекомендует забыть о своём решении в процессе интервью и сосредоточиться на проблемах клиента [27:35].

Второй этап — создание кликабельного прототипа без написания кода. Эксперт рекомендует использовать такие инструменты, как:

*   Figma;
*   Balsamiq;
*   InVision;
*   Marvel App [31:58].

Кейс одного из учеников Юсуповой, риелтора Гейба, показывает эффективность этого подхода: имея на руках только кликабельный прототип (без бэкенда), он смог заключить контракт с агентством недвижимости и получить предоплату за разработку еще не созданного продукта [32:39].

## 📉 Секрет №2: Оптимизация стоимости MVP
[[JUMP:35:16]]

Правильное определение рамок MVP (Minimal Viable Product) критически важно. Юсупова утверждает, что одна и та же задача может стоить $10 000 или $100 000 в зависимости от технических деталей [36:09].

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

По словам Юсуповой, одна из её учениц смогла сократить стоимость разработки с $50 000 до $15 000 и сроки с 4 до 2 месяцев, просто пересмотрев технические требования и отказавшись от избыточного функционала [37:53]. Она настаивает, что разработчики часто не предлагают такие способы экономии, так как им выгодно строить больше [38:31].

## 🏃 Секрет №3: Lean и Agile управление
[[JUMP:39:52]]

Основатель должен внедрить культуру «учись рано, учись часто, учись дёшево» [40:17]. Нелли Юсупова рекомендует использовать методологию Agile, которая позволяет получать рабочий код каждые две недели (или чаще) [40:43].

Ключевые рекомендации по управлению:

1.  **Прозрачность процесса.** Если основатель не видит код каждые 1–2 недели, проект, скорее всего, идёт под откос [40:55].
2.  **Роль основателя.** Если нет денег на профессионального менеджера продукта (Product Manager), основатель обязан сам выполнять эти функции [45:31].
3.  **Модель «Разработчик как сервис» (Developer as a Service).** Юсупова считает, что не важно, в штате разработчик или на аутсорсе, если основатель напрямую управляет процессом и внедряет свои стандарты [44:52].

Эффективный процесс позволяет не только экономить деньги (кейс Эрика — экономия $500 000 за три года [42:38]), но и быстрее находить ошибки и корректировать курс.

## 🧠 Техническая грамотность для CEO
[[JUMP:45:30]]

Юсупова утверждает, что основатель «технологического» бизнеса обязан быть технически грамотным, даже если он не пишет код [48:48]. Это включает понимание:

*   того, как работает веб (браузеры, серверы);
*   базового технического жаргона;
*   того, что такое API, базы данных и библиотеки [46:23].

Отсутствие этих знаний делает основателя уязвимым. Эксперт приводит пример, когда отношения между сооснователями испортились, и технический партнёр просто забрал код, а нетехнический основатель остался ни с чем, так как даже не знал, где хранятся исходники [47:45]. Техническая грамотность позволяет основателю вести переговоры с позиции силы, а не нужды [47:17].

## ❓ Ответы на вопросы участников
[[JUMP:53:50]]

**О краже идеи:**
Нелли Юсупова считает, что идея сама по себе ничего не стоит без исполнения [53:50]. Если кто-то может украсть идею и реализовать её быстрее и лучше вас, значит, ваша команда проигрывает в скорости. «Вы должны бежать на 10 шагов впереди конкурентов за счёт скорости процесса», — утверждает гость [54:17].

**О распределении долей и компенсации:**
Сложность обсуждения долей (equity) — это первый тест на совместимость сооснователей. Если вы не можете спокойно обсудить этот вопрос, вы не сможете построить совместный бизнес [58:50]. Юсупова не рекомендует давать долю аутсорсинговым компаниям на старте: сначала нужно проверить их в деле на платной основе [59:28].

**Главный совет начинающим:**
По мнению Юсуповой, самое важное — найти проблему «уровня 12 из 10» [1:01:42]. Она признаётся, что как технарь раньше тратила месяцы на создание «идеальных» решений, которые в итоге оказывались никому не нужны [1:02:08]. Сначала — глубокое понимание боли клиента, только потом — технология.