«Несколько ясно выраженных проблем проявляются как задержки запуска: слишком медленная работа, неправильное понимание проблемы, страх перед необходимостью обращаться с пользователями, боязнь осуждения, работа со слишком многими разными делами, чрезмерный перфекционизм. К счастью, со всем этим можно справиться простым средством — заставить себя начать что-то делать довольно быстро.» — Пол Грэм «18 ошибок, убивающих стартапы»
Когда вы проходите через венчурный фонд «Y Combinator» («YC»), то один из получаемых советов — «стартуйте как можно раньше», т.е. запускайте дело задолго до того, как вы полагаете, что готовы к этому.
В моём стартапе мы не просто последовали этому совету. Мы ввели его до почти абсурдной степени во всё, что мы делали. Фактически выдача продукта «быстро и часто» является теперь самым желанным действием компании. Это — та самая преобладающая черта компании, которая, как я полагаю, способствовала нашему росту и принятие которой может принести пользу почти каждому бизнесу.
Здесь я хотел бы поделиться некоторыми тактическими соображениями о том, что это значит и как это работает.
Почему «выдача быстро» имеет значение?
Преимущества выдачи продукта, надо надеяться, ясны каждому. Без такой выдачи у компании нет роста и — по определению — нет стартапа.
Проблема в том, что все мы склонны выдавать продукт слишком поздно и редко. Несколько психологических факторов действует неявно, но вместе препятствуя такой выдаче: гордость, перфекционизм, расползание границ проекта, страх перед критикой, боязнь быть отвергнутым.
Я прошёл через это, получив свой горький опыт. Оглядываясь назад, вижу, что самая первая разработка продукта в нашей компании была до смешного плохой. Мы провели месяцы, работая над чем-то, у чего не было пользователей вообще, базируясь на ошибочной вере, что имеется некоторый набор функций, который мы могли бы разработать и благодаря которому начнётся наш рост.
Как только мы присоединились к YC, стало очевидно, что продукт, который мы создали, просто не работает. (1) Поскольку мы хотели выжить, то мы должны были отставить наше первое великое творение и попробовать что-то другое.
Работайте на «v0», а не на «v1»
Мы начали выпускать серию недавно созданных продуктов, фокусируясь на эффективность. Каждый раз, когда мы запускали что-то, что не находило пользователей, мы откатывались назад, работали и запускали несколько иное. Каждый раз, когда мы отказывались от некоторого продукта, мы жёстко критиковали себя за потраченное на него время и тратили меньше времени на следующий виток.
Наш период созревания «минимально жизнеспособного продукта» сжимался — с трёх месяцев до одной недели, одного дня, и, наконец, достиг нескольких часов. В конце им стал наш самый минимальный выпуск — единственная страница, которая представляла файл и адрес нашего почтового ящика входящих сообщений, что дало нам основную часть успеха.
Мы назвали этот выпуск «v0». Этот «v0» является первым шагом на пути к полному видению какого-то продукта и самой минимальной, примерно соответствующий целевому назначению версией того, что вы стремитесь создать. Ясно, что в вашем «v0» будет отсутствовать много очевидного материала, и это прекрасно, поскольку то, что вы развиваете, содержит в себе предпосылки, которые побудят вас, в конечном счёте, создать требуемые вещи.
«v0» является наименьшим плодом вашей работы, позволяющим сказать: «Ну, это — то, что я сотворил. И как?»
Разработка характеристик продукта «v0»
С новым продуктом много неясного: неизвестно, какие его свойства окажутся важными и какой дизайн или какая реализация сработает. Поэтому так же как ускоренное выведение продукта на рынок («выдача быстро») является важным для подстройки продукта под рынок, быстрая разработка новых характеристик продукта имеет существенное значение для подстройки характеристик под продукт.
Иногда эти характеристики оказывались настолько основополагающими, что при их удалении начинались сетования из-за недостаточной функциональности. Но это было то, что нам надо: мы не затрачивали никаких усилий и быстро узнавали, что клиентам нужна именно эта характеристика.
Используя тщательно проработанную компоновку и методы «Волшебника страны Оз», часто можно маскировать минимальную функциональность, сохраняя время и технические ресурсы, некоторые ваши наиболее ценные активы как стартап.
Главной оборотной стороной такого подхода является то, что ваш продукт будет восприниматься менее зрелым и отработанным, чем это могло бы быть. Но обратная связь — сведения и опыт, получаемые от выпуска «v0», — значительно перевешивает возможный небольшой начальный ущерб репутации.
Мини-демоверсии
Используя концепцию характеристик «v0», мы сделали шаг в направлении, которое мы назвали «внутренние мини-демоверсии».
Когда кто-то у нас работает над каким-то новым элементом, то он должен представить на общее обсуждение предельно раннюю версию этой разработки. Мы, используя проектор, помещаем её на экран в центре офиса. Любой свободный в этот момент сотрудник может, находясь у гигантского экрана, смотреть и высказываться.
Это обычно означает, что демонстрация нового элемента происходит через день работы над ним или даже раньше. Это может быть какой-то новой частью интерфейса или даже скрытой технической особенностью («Я нажимаю эту кнопку, и вся наша инфраструктура восстанавливается — классно, да?»). Мини-демоверсии предназначены не только для запуска какой-то более крупной части работы. Их проводят постоянно, как только появляется что-то новое, что можно показать.
Эти мини-демоверсии потрясающе полезны по многим причинам. Они:
Важно то, что обсуждение мини-демоверсий является продуктивным. Самые полезные комментарии являются весьма специфическими и основываются на каких-то данных или на опыте (например: «В прошлый раз мы выпустили интерфейс только на пиктограммах. Многие клиенты тратили массу времени, чтобы понять, что делает та или иная кнопка.» или «Наш торговый персонал проводит весь день в одном и том же окне. Мы могли бы заставить это окно помнить их предпочтения?»). Остерегайтесь «зацикливания на мелочах» – не позволяйте обсуждению уходить на второ- и третьестепенные направления с маловажными дебатами или критикой.
Так же как основатели компании первоначально отбиваются от быстрой выдачи продукта, так и все сотрудники сначала считают выдачу мини-демоверсии трудновыполнимой. Представление какой-то неряшливой, недоработанной части работы целой комнате людей, на которых хочется произвести хорошее впечатление, вызывает полный дискомфорт, особенно у новых сотрудников, которые только что присоединились к команде. Однако я обнаружил, что при спокойной поддержке и регулярном участии почти все влюбляются в этот способ работы.
Это работает и за пределами информационных технологий
Концепция «выдачи быстро» действует не только в технике. Успешно используя мини-демоверсии для технических продуктов, мы перенесли эту практику на всё в наших командах. Люди идут к проектору и представляют свою новую электронную таблицу оценки потенциальных покупателей, новую статью из раздела справки для клиентов, канал найма, самую последнюю интеграцию Zapier и т.п. Абсолютно любой вид работы может быть представлен и, действительно, представляется как мини-демоверсия.
Чтобы сам процесс представления мини-демоверсии не утонул в догмах или правилах, мы поддерживаем его гибкость. Мини-демоверсии не привязаны к какому-то определённому формату. Мы в шутку называем очень небольшие изменения «микро-демоверсиями»; иногда выдаются крупномасштабные «макро-демоверсии». Они могут быть представлены в любое время. Нередко за чашкой кофе несколько человек друг за другом подходят к проектору в течение нескольких минут и показывают наработанное по какому-то направлению сегодня утром. Перед отправкой готового продукта мы проводим завершающее представление мини-демоверсии с «любыми последними соображениями». Ключ в том, чтобы сделать это интересным и полезным для каждого.
Выдача всего «быстро и часто» является нашим наилучшим практическим приёмом в компании. Благодаря этим мини-демоверсиям мы работаем лучше и быстрее. Надеемся, что другие посчитают эту практику такой же привлекательной, как и мы.
Дэвид Мэк является соучредителем и техническим директором компании SketchDeck (YC W14), обеспечивающей заказные разработки и позволяющей компаниям передавать их презентационные материалы в работу «на сторону» профессиональным разработчикам. Он получил степень бакалавра по вычислительной технике в университете в Кембридже и степень магистра по математике и вычислительной технике в университете в Оксфорде.
Примечания
(1.) Если ситуация с успешностью проекта неясная, то три месяца без отчётливого роста количества пользователей являются обоснованным аварийным сигналом, что пора попробовать что-нибудь ещё.
Когда вы проходите через венчурный фонд «Y Combinator» («YC»), то один из получаемых советов — «стартуйте как можно раньше», т.е. запускайте дело задолго до того, как вы полагаете, что готовы к этому.
В моём стартапе мы не просто последовали этому совету. Мы ввели его до почти абсурдной степени во всё, что мы делали. Фактически выдача продукта «быстро и часто» является теперь самым желанным действием компании. Это — та самая преобладающая черта компании, которая, как я полагаю, способствовала нашему росту и принятие которой может принести пользу почти каждому бизнесу.
Здесь я хотел бы поделиться некоторыми тактическими соображениями о том, что это значит и как это работает.
Почему «выдача быстро» имеет значение?
Преимущества выдачи продукта, надо надеяться, ясны каждому. Без такой выдачи у компании нет роста и — по определению — нет стартапа.
Проблема в том, что все мы склонны выдавать продукт слишком поздно и редко. Несколько психологических факторов действует неявно, но вместе препятствуя такой выдаче: гордость, перфекционизм, расползание границ проекта, страх перед критикой, боязнь быть отвергнутым.
Я прошёл через это, получив свой горький опыт. Оглядываясь назад, вижу, что самая первая разработка продукта в нашей компании была до смешного плохой. Мы провели месяцы, работая над чем-то, у чего не было пользователей вообще, базируясь на ошибочной вере, что имеется некоторый набор функций, который мы могли бы разработать и благодаря которому начнётся наш рост.
Как только мы присоединились к YC, стало очевидно, что продукт, который мы создали, просто не работает. (1) Поскольку мы хотели выжить, то мы должны были отставить наше первое великое творение и попробовать что-то другое.
Работайте на «v0», а не на «v1»
Мы начали выпускать серию недавно созданных продуктов, фокусируясь на эффективность. Каждый раз, когда мы запускали что-то, что не находило пользователей, мы откатывались назад, работали и запускали несколько иное. Каждый раз, когда мы отказывались от некоторого продукта, мы жёстко критиковали себя за потраченное на него время и тратили меньше времени на следующий виток.
Наш период созревания «минимально жизнеспособного продукта» сжимался — с трёх месяцев до одной недели, одного дня, и, наконец, достиг нескольких часов. В конце им стал наш самый минимальный выпуск — единственная страница, которая представляла файл и адрес нашего почтового ящика входящих сообщений, что дало нам основную часть успеха.
Мы назвали этот выпуск «v0». Этот «v0» является первым шагом на пути к полному видению какого-то продукта и самой минимальной, примерно соответствующий целевому назначению версией того, что вы стремитесь создать. Ясно, что в вашем «v0» будет отсутствовать много очевидного материала, и это прекрасно, поскольку то, что вы развиваете, содержит в себе предпосылки, которые побудят вас, в конечном счёте, создать требуемые вещи.
«v0» является наименьшим плодом вашей работы, позволяющим сказать: «Ну, это — то, что я сотворил. И как?»
Разработка характеристик продукта «v0»
С новым продуктом много неясного: неизвестно, какие его свойства окажутся важными и какой дизайн или какая реализация сработает. Поэтому так же как ускоренное выведение продукта на рынок («выдача быстро») является важным для подстройки продукта под рынок, быстрая разработка новых характеристик продукта имеет существенное значение для подстройки характеристик под продукт.
Иногда эти характеристики оказывались настолько основополагающими, что при их удалении начинались сетования из-за недостаточной функциональности. Но это было то, что нам надо: мы не затрачивали никаких усилий и быстро узнавали, что клиентам нужна именно эта характеристика.
Используя тщательно проработанную компоновку и методы «Волшебника страны Оз», часто можно маскировать минимальную функциональность, сохраняя время и технические ресурсы, некоторые ваши наиболее ценные активы как стартап.
Главной оборотной стороной такого подхода является то, что ваш продукт будет восприниматься менее зрелым и отработанным, чем это могло бы быть. Но обратная связь — сведения и опыт, получаемые от выпуска «v0», — значительно перевешивает возможный небольшой начальный ущерб репутации.
Мини-демоверсии
Используя концепцию характеристик «v0», мы сделали шаг в направлении, которое мы назвали «внутренние мини-демоверсии».
Когда кто-то у нас работает над каким-то новым элементом, то он должен представить на общее обсуждение предельно раннюю версию этой разработки. Мы, используя проектор, помещаем её на экран в центре офиса. Любой свободный в этот момент сотрудник может, находясь у гигантского экрана, смотреть и высказываться.
Это обычно означает, что демонстрация нового элемента происходит через день работы над ним или даже раньше. Это может быть какой-то новой частью интерфейса или даже скрытой технической особенностью («Я нажимаю эту кнопку, и вся наша инфраструктура восстанавливается — классно, да?»). Мини-демоверсии предназначены не только для запуска какой-то более крупной части работы. Их проводят постоянно, как только появляется что-то новое, что можно показать.
Эти мини-демоверсии потрясающе полезны по многим причинам. Они:
- Подсказывают разработчикам правильное направление задолго до того, как будет пройдено какое-то значительное расстояние. Кто-то легко может сбиться с дороги в начале проекта.
- Объединяют комплексный опыт нашей команды, позволяя учесть широкий диапазон точек зрения и потребностей в каждой разработке какого-либо свойства.
- Обеспечивают регулярное «покапельное» поступательное движение разработок и помогают любому лучше понимать, чем заняты другие сотрудники.
- Сводят вместе людей, работающих в разных местах или находящихся в поездке.
- Предотвращают ненужную работу, когда речь идёт о представлении идей (например, создание слайд-шоу в PowerPoint вместо того, чтобы просто написать несколько пунктов маркированного списка).
- Выполняют роль некоторой функции принуждения, чтобы запустить материал в работу и продвигать его.
- Создают каждодневное ощущение успешности и перспективности работы.
Важно то, что обсуждение мини-демоверсий является продуктивным. Самые полезные комментарии являются весьма специфическими и основываются на каких-то данных или на опыте (например: «В прошлый раз мы выпустили интерфейс только на пиктограммах. Многие клиенты тратили массу времени, чтобы понять, что делает та или иная кнопка.» или «Наш торговый персонал проводит весь день в одном и том же окне. Мы могли бы заставить это окно помнить их предпочтения?»). Остерегайтесь «зацикливания на мелочах» – не позволяйте обсуждению уходить на второ- и третьестепенные направления с маловажными дебатами или критикой.
Так же как основатели компании первоначально отбиваются от быстрой выдачи продукта, так и все сотрудники сначала считают выдачу мини-демоверсии трудновыполнимой. Представление какой-то неряшливой, недоработанной части работы целой комнате людей, на которых хочется произвести хорошее впечатление, вызывает полный дискомфорт, особенно у новых сотрудников, которые только что присоединились к команде. Однако я обнаружил, что при спокойной поддержке и регулярном участии почти все влюбляются в этот способ работы.
Это работает и за пределами информационных технологий
Концепция «выдачи быстро» действует не только в технике. Успешно используя мини-демоверсии для технических продуктов, мы перенесли эту практику на всё в наших командах. Люди идут к проектору и представляют свою новую электронную таблицу оценки потенциальных покупателей, новую статью из раздела справки для клиентов, канал найма, самую последнюю интеграцию Zapier и т.п. Абсолютно любой вид работы может быть представлен и, действительно, представляется как мини-демоверсия.
Чтобы сам процесс представления мини-демоверсии не утонул в догмах или правилах, мы поддерживаем его гибкость. Мини-демоверсии не привязаны к какому-то определённому формату. Мы в шутку называем очень небольшие изменения «микро-демоверсиями»; иногда выдаются крупномасштабные «макро-демоверсии». Они могут быть представлены в любое время. Нередко за чашкой кофе несколько человек друг за другом подходят к проектору в течение нескольких минут и показывают наработанное по какому-то направлению сегодня утром. Перед отправкой готового продукта мы проводим завершающее представление мини-демоверсии с «любыми последними соображениями». Ключ в том, чтобы сделать это интересным и полезным для каждого.
Выдача всего «быстро и часто» является нашим наилучшим практическим приёмом в компании. Благодаря этим мини-демоверсиям мы работаем лучше и быстрее. Надеемся, что другие посчитают эту практику такой же привлекательной, как и мы.
Дэвид Мэк является соучредителем и техническим директором компании SketchDeck (YC W14), обеспечивающей заказные разработки и позволяющей компаниям передавать их презентационные материалы в работу «на сторону» профессиональным разработчикам. Он получил степень бакалавра по вычислительной технике в университете в Кембридже и степень магистра по математике и вычислительной технике в университете в Оксфорде.
Примечания
(1.) Если ситуация с успешностью проекта неясная, то три месяца без отчётливого роста количества пользователей являются обоснованным аварийным сигналом, что пора попробовать что-нибудь ещё.