Первых клиентов стартапа подключают к ограниченной версии с понятным порядком доработок

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

Проба на собственных сотрудниках не заменяет чужую компанию. Основатель Slack Стюарт Баттерфилд в интервью First Round рассказал: когда Rdio расширила использование сервиса, людям стало трудно выбирать каналы. Slack добавила к каналам описания и число участников.

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

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

До доступа договоритесь, кто участвует и когда будете разбирать результат. В Service Manual GOV.UK закрытую пробу начинают с ограниченной группы и обратной связи; отдельно требуют готовности команды улучшать сервис и помогать новым пользователям. Это образец процесса, а не правило для бизнеса в РФ.

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

Что проверить перед первой компанией? Пройдите выбранную операцию с новой учётной записью. Демонстрация из аккаунта основателя пропускает ошибки входа и прав, с которыми встретится сотрудник.

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

Подключение откладывают, если ошибка портит данные или открывает чужую компанию. Сначала исправляют её и повторяют проверку. Пометка «пробная версия» такое поведение не делает приемлемым.

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

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

Как вести доработки, когда компании просят разное? Сначала отделите ошибку согласованной операции от новой возможности. Заявка исчезла после отправки: путь сломан. Клиент попросил диаграмму по отделам: появилась новая задача.

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

Случай Rdio у Slack даёт полезный образец отбора. Описания каналов выглядели мелкой правкой, но без них новой команде было трудно освоить сервис. Приоритет определяла помеха использованию.

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

Как понять, что исправление помогло? Верните его участнику пробы и попросите повторить тот же путь. Отметка разработчика «готово» означает, что изменение подготовлено; проба продолжается у клиента.

В кабинете недостаточно увидеть заявку в базе. Заявитель должен открыть её, согласующий принять решение, а заявитель получить результат. Если заявку снова заканчивает основатель вручную, препятствие осталось.

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

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

Подписка на разработку «Один проект» стоит 250 000 ₽ в месяц на 8 октября 2026. У тарифа один поток: одна задача в работе, следующая ждёт. Подключение и доработки ставят в эту очередь, а их состав согласуют до начала.

На /open при проверке 8 октября было 7 107 коммитов за 99 дней: основная ветка с 1 июля 2026, без мерж-коммитов. Это свидетельство работы машины, не число клиентов. Инженер ведёт машину агентов, правила задаёт заранее и принимает результат.

Если компании уже готовы пробовать, но вести исполнение некому, стоит разобрать задачу с инженером. Если заинтересованных компаний ещё нет, сначала найдите участника пробы: подписка на разработку не гарантирует продажи.

1. Выберите узкую операцию и доведите её до результата для сотрудника.

2. До доступа запишите участников, ограничения и день разбора пробы.

3. Исправляйте помехи выбранному пути раньше новых возможностей.

4. Возвращайте правку клиенту и проверяйте повторную операцию.

5. Покупайте исполнение согласованной очереди; продажи и выбор рынка ведите сами.