Lean Startup: Что Это Такое и для Чего Он Нужен
Прямой эфир про то, как мы запускаем новый продукт, оказался интересным для многих, поэтому начнем ;-)
Начну я, пожалуй, с рассказа о том, что такое вообще Lean Startup. Lean Startup - это методология создания, управления, и развития стартапов. Придумал ее Эрик Рис (Eric Ries), который очень хорошо описал ее в книжке The Lean Startup.
(Я заранее прошу прощения, если будет слишком много иностранных слов без перевода и англицизмов. Я не всегда знаю адекватный перевод на русский, но буду признателен, если вы мне подскажете.)
Для того, чтобы понять как эту методологию применять, приведу пример. Допустим, вам в голову пришла гениальная идея: создать автоматический зашнуровыватель ботинок. Вас самих задолбало каждый день зашнуровывать ботинки, ваших друзей задолбало, ваших знакомых задолбало, в общем, вы решили, что это общемировая проблема и ее надо решать. По мере того, как вы начинаете думать над реализацией вашей идеи, у вас начинает возникать куча вопросов. Например:
- Насколько серьезна эта проблема, и готовы ли люди будут платить вам деньги за ваш агрегат или предпочтут по прежнему завязывать шнурки руками
- Должен ли ваш автозашнуровыватель быть портативным (чтобы люди носили его с собой в кармане) или стационарным (чтобы он стоял дома)
- Должен ли автозашнуровыватель обязательно уметь еще и автоматически расшнуровывать ботинки
- Надо ли поддерживать все виды шнурков или можно обойтись только круглыми
... итд.
Опасность, которая здесь подстерегает, заключается в том, чтобы положившись на собственные предположения и допущения, потратить кучу времени, денег, и сил на создание продукта, который окажется никому не нужным (по крайней мере, в том виде, в котором вы его создали). Например, вы предположили, что автозашнуровыватель должен быть портативным, уметь расшнуровывать ботинки и выдавать прогноз погоды, а также самонастраиваться на любые виды обуви. Не сделав никаких ранних проверок своих предположений, Вы сразу вложили кучу денег, выпустили продукт, и тут оказалось, что (1) люди зашнуровывают обувь раз в день и поэтому автозашнуровыватель можеть быть стационарным; (2) расшнуровывание является гораздо меньшей проблемой, чем зашнуровывание, и поэтому такая фунцкия никому не нужна; (3) прогноз погоды люди узнают из интернета, и эта функциональность тоже никому не нужна; (4) 95% людей носит обувь с круглыми шнурками, и ваша самонастраиваемость малоактуальна.
(В книжке Эрик Рис рассказывает во что лично ему и коллегам по его собственному стартапу обошлось полагание на собственные предположения и отсутствие методики их проверить на раннем этапе. Очень советую почитать.)
Решение, которое может напрашиваться, - это проведение всяких опросов и исследований рынка до того, как вы начнете что-то делать. Проблема с опросами заключается в том, что когда вы задаете человеку чисто теоретические вопросы, человек и отвечает на них чисто теоретически. Возможно, что 99% людей на вопрос нужен ли им автозашнуровыватель ответят отрицательно. Но после того, как вы им дадите попользоваться реальным продуктом в реальных условиях, жизни больше себе смогут помыслить без вашего девайса. Я не к тому, чтобы всякие опросы и всякие фокус группы вообще не надо делать, но надо ясно понимать их ограничения.
Lean startup предлагает трехступенчатый процесс, который позволит вам снизить ненужные расходы и сделать процесс разработки более эффективным и управляемым:
- Выдвижение гипотезы
- Проверка гипотезы
- Выводы
Способ, которым вы проходите этот процесс - это выпуск так называемого minimum valuable product, или сокращенно MVP. MVP - это продукт, которым имеет ровно такой набор функциональностей (и не больше), которые вам позволяют проверить вашу гипотезу. Это то, на что пользовтель может дать вам отклик, позволяющий проверить вашу гипотезу и принять решение о дальнейших шагах - будь то макет, прототип, бета версия, или что-то подобное, что можно сделать быстро и с минимальными вложениями. Главное тут - начать получать отклик от реальных пользователей уже на ранних этапах. Иначе можно оказаться в ситуации, когда вы проделали огромный путь, вложили много сил, времени, и денег, только за тем, чтобы спустя месяцы тяжелой работы выяснить, что все это время вы двигались в неправильном направлении.
К слову сказать, MVP не обязан быть продуктом в привычном смысле этото слова. Приведу пример.
Наши пользователи неоднократно просили нас расширить функциональность нашего модуля для управления переводами (translation management) и добавить больше возможностей для поиска. Поскольку мы выпускаем коробочный продукт, а не кастомные решения, то вещи, которые мы делаем, должны удовлетворять всех. Мы придумали некое решение, но у нас не было уверенности, что оно будет работать для всех. Всегда оказываются какие-то сценарии, которые остались непокрытыми, либо люди пользуются функциональностями не так, как мы себе представляли. В общем, мы хотели каким-то образом потестировать идею, чтобы понять, в правильном ли направлении мы движемся.
Вместо того, чтобы вкладываться в серьезную разработку и потом, уже после выхода в свет версии, возможно, выяснить, что все это было сделано не так, мы сделали полуфейковый скриншот экрана с новой функциональностью, описали как все будет работать, и запостили это в нашем блоге типа "вот, смотрите, какая крутая новая штука будет в следующей версии". Практически сразу мы начали получать отклики, в целом позитивные. С их помощью мы выявили еще один очень важный сценарий работы, который мы не учли. В результате, мы немного поменяли пользовательский интерфейс, добавили еще один критерий поиска, и сделали изменения в алгоритме поиска. В результате, когда версия вышла, все оказались страшно довольны. С точки зрения пользователей, у нас было стопроцентное попадание в их потребности с первого раза.
В нашем случае, в роли MVP выступил скриншот экрана с еще не существующей в реальности функциональностью. Мы проверили нашу гипотезу, сделали выводы, и скорректировали курс с минимумом усилий. Если бы мы этого не сделали, мы бы узнали о недочетах уже после выхода версии, и переделка уже написанного настоящего кода вышла бы нам намного дороже.
Результатом проверки гипотезы может оказаться и менее обнадеживающий вывод. В экстремальном случае это может означать пивот (pivot) - принципиальное изменение направления развития. Изменение может казаться целевой аудитории, сегмента рынка, функциональности продукта, бизнес модели, итд. Например, вы со своей идеей автоматического зашнуровывателя, после серии проверок и экспериментов, можете осознать, что на самом деле то, что нужно людям, это специальный датчик, который устанавливается на ботинки маленьким детям и начинает пищать и посылать SMS родителям ребенка, когда у того развязались шнурки.
Про lean startup можно еще очень долго рассказывать, это самые основы. Понятное дело, что сам по себе метод еще ничего не гарантирует. Если вы, например, проверяете не ту гипотезу, которую надо было бы проверять (скажем, вам стоило бы проверить насколько то, чему вы предлагаете решение, вообще является проблемой, а вместо этого вы пытаетесь проверить техническую надежность вашего продукта) или проверяте ее не теми способами, ничто и никто не спасет вас от поражения. Но для того человеку и дана голова, в которую он ест, чтобы думать, как этот метод использовать в данной конкретной ситуации.
В следующем посте я, наверное, расскажу про сам продукт, который мы собирамеся запускать, чтобы был немного понятен наш рынок и почему мы принимаем те или иные решения.
Начну я, пожалуй, с рассказа о том, что такое вообще Lean Startup. Lean Startup - это методология создания, управления, и развития стартапов. Придумал ее Эрик Рис (Eric Ries), который очень хорошо описал ее в книжке The Lean Startup.
(Я заранее прошу прощения, если будет слишком много иностранных слов без перевода и англицизмов. Я не всегда знаю адекватный перевод на русский, но буду признателен, если вы мне подскажете.)
Для того, чтобы понять как эту методологию применять, приведу пример. Допустим, вам в голову пришла гениальная идея: создать автоматический зашнуровыватель ботинок. Вас самих задолбало каждый день зашнуровывать ботинки, ваших друзей задолбало, ваших знакомых задолбало, в общем, вы решили, что это общемировая проблема и ее надо решать. По мере того, как вы начинаете думать над реализацией вашей идеи, у вас начинает возникать куча вопросов. Например:
- Насколько серьезна эта проблема, и готовы ли люди будут платить вам деньги за ваш агрегат или предпочтут по прежнему завязывать шнурки руками
- Должен ли ваш автозашнуровыватель быть портативным (чтобы люди носили его с собой в кармане) или стационарным (чтобы он стоял дома)
- Должен ли автозашнуровыватель обязательно уметь еще и автоматически расшнуровывать ботинки
- Надо ли поддерживать все виды шнурков или можно обойтись только круглыми
... итд.
Опасность, которая здесь подстерегает, заключается в том, чтобы положившись на собственные предположения и допущения, потратить кучу времени, денег, и сил на создание продукта, который окажется никому не нужным (по крайней мере, в том виде, в котором вы его создали). Например, вы предположили, что автозашнуровыватель должен быть портативным, уметь расшнуровывать ботинки и выдавать прогноз погоды, а также самонастраиваться на любые виды обуви. Не сделав никаких ранних проверок своих предположений, Вы сразу вложили кучу денег, выпустили продукт, и тут оказалось, что (1) люди зашнуровывают обувь раз в день и поэтому автозашнуровыватель можеть быть стационарным; (2) расшнуровывание является гораздо меньшей проблемой, чем зашнуровывание, и поэтому такая фунцкия никому не нужна; (3) прогноз погоды люди узнают из интернета, и эта функциональность тоже никому не нужна; (4) 95% людей носит обувь с круглыми шнурками, и ваша самонастраиваемость малоактуальна.
(В книжке Эрик Рис рассказывает во что лично ему и коллегам по его собственному стартапу обошлось полагание на собственные предположения и отсутствие методики их проверить на раннем этапе. Очень советую почитать.)
Решение, которое может напрашиваться, - это проведение всяких опросов и исследований рынка до того, как вы начнете что-то делать. Проблема с опросами заключается в том, что когда вы задаете человеку чисто теоретические вопросы, человек и отвечает на них чисто теоретически. Возможно, что 99% людей на вопрос нужен ли им автозашнуровыватель ответят отрицательно. Но после того, как вы им дадите попользоваться реальным продуктом в реальных условиях, жизни больше себе смогут помыслить без вашего девайса. Я не к тому, чтобы всякие опросы и всякие фокус группы вообще не надо делать, но надо ясно понимать их ограничения.
Lean startup предлагает трехступенчатый процесс, который позволит вам снизить ненужные расходы и сделать процесс разработки более эффективным и управляемым:
- Выдвижение гипотезы
- Проверка гипотезы
- Выводы
Способ, которым вы проходите этот процесс - это выпуск так называемого minimum valuable product, или сокращенно MVP. MVP - это продукт, которым имеет ровно такой набор функциональностей (и не больше), которые вам позволяют проверить вашу гипотезу. Это то, на что пользовтель может дать вам отклик, позволяющий проверить вашу гипотезу и принять решение о дальнейших шагах - будь то макет, прототип, бета версия, или что-то подобное, что можно сделать быстро и с минимальными вложениями. Главное тут - начать получать отклик от реальных пользователей уже на ранних этапах. Иначе можно оказаться в ситуации, когда вы проделали огромный путь, вложили много сил, времени, и денег, только за тем, чтобы спустя месяцы тяжелой работы выяснить, что все это время вы двигались в неправильном направлении.
К слову сказать, MVP не обязан быть продуктом в привычном смысле этото слова. Приведу пример.
Наши пользователи неоднократно просили нас расширить функциональность нашего модуля для управления переводами (translation management) и добавить больше возможностей для поиска. Поскольку мы выпускаем коробочный продукт, а не кастомные решения, то вещи, которые мы делаем, должны удовлетворять всех. Мы придумали некое решение, но у нас не было уверенности, что оно будет работать для всех. Всегда оказываются какие-то сценарии, которые остались непокрытыми, либо люди пользуются функциональностями не так, как мы себе представляли. В общем, мы хотели каким-то образом потестировать идею, чтобы понять, в правильном ли направлении мы движемся.
Вместо того, чтобы вкладываться в серьезную разработку и потом, уже после выхода в свет версии, возможно, выяснить, что все это было сделано не так, мы сделали полуфейковый скриншот экрана с новой функциональностью, описали как все будет работать, и запостили это в нашем блоге типа "вот, смотрите, какая крутая новая штука будет в следующей версии". Практически сразу мы начали получать отклики, в целом позитивные. С их помощью мы выявили еще один очень важный сценарий работы, который мы не учли. В результате, мы немного поменяли пользовательский интерфейс, добавили еще один критерий поиска, и сделали изменения в алгоритме поиска. В результате, когда версия вышла, все оказались страшно довольны. С точки зрения пользователей, у нас было стопроцентное попадание в их потребности с первого раза.
В нашем случае, в роли MVP выступил скриншот экрана с еще не существующей в реальности функциональностью. Мы проверили нашу гипотезу, сделали выводы, и скорректировали курс с минимумом усилий. Если бы мы этого не сделали, мы бы узнали о недочетах уже после выхода версии, и переделка уже написанного настоящего кода вышла бы нам намного дороже.
Результатом проверки гипотезы может оказаться и менее обнадеживающий вывод. В экстремальном случае это может означать пивот (pivot) - принципиальное изменение направления развития. Изменение может казаться целевой аудитории, сегмента рынка, функциональности продукта, бизнес модели, итд. Например, вы со своей идеей автоматического зашнуровывателя, после серии проверок и экспериментов, можете осознать, что на самом деле то, что нужно людям, это специальный датчик, который устанавливается на ботинки маленьким детям и начинает пищать и посылать SMS родителям ребенка, когда у того развязались шнурки.
Про lean startup можно еще очень долго рассказывать, это самые основы. Понятное дело, что сам по себе метод еще ничего не гарантирует. Если вы, например, проверяете не ту гипотезу, которую надо было бы проверять (скажем, вам стоило бы проверить насколько то, чему вы предлагаете решение, вообще является проблемой, а вместо этого вы пытаетесь проверить техническую надежность вашего продукта) или проверяте ее не теми способами, ничто и никто не спасет вас от поражения. Но для того человеку и дана голова, в которую он ест, чтобы думать, как этот метод использовать в данной конкретной ситуации.
В следующем посте я, наверное, расскажу про сам продукт, который мы собирамеся запускать, чтобы был немного понятен наш рынок и почему мы принимаем те или иные решения.