88. Как проверить идею

Published 6 Aug 2018 by Michael Dubakov

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

Дальше у вас единственный выход — начать делать продукт. Это самая эффективная стратегия. Почему? Выпуск продукта дает вам внешний фидбек. Начало разработки дает вам внутренний фидбек. Вы обнаруживаете технические ограничения, функциональные нестыковки, внутренние противоречия и накапливаете массу полезной информации. Вы лучше понимаете трудозатраты и сложность решения.

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

Декомпозиция на модули помогает. Мы внезапно можем сфокусироваться на отдельном куске системы, не заботясь о целом. Но и тут со временем нас поджидает разрыв связей и потеря целостности. Дамп всего в текстовые и графические формы тоже помогает. Мы внезапно имеем роскошь выкинуть что-то из головы, и потом загрузить обратно. Но на это требуется время, и с ростом сложности обратно уже все не залезет.

Гораздо проще думать о системе, когда её можно пощупать, потыкать, поставить на ней эксперименты и зафиксировать идеи в решении.

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

Увеличение информации после начала разработки продукта. Увеличение информации после начала разработки продукта.

Тут важно не утонуть в многообразии вариантов и мастерски лавировать. Никто не умеет лавировать идеально. Этому сложно научить, но можно научиться.

Реализуйте ключевое свойство. Нужно начинать разработку с ключевых свойств системы. Нет никакого смысла делать управление пользователями или лицензирование в самом начале — это тривиальные задачи. Если вы делаете новый крутой wiki с автоматическим интеллектуальным форматированием текста (хм, неплохая идея), то нужно начинать с решения задачи автоматического форматирования. Может это будет эвристический алгоритм, а может придётся попробовать нейросеть. Но без решения этой ключевой задачи система не имеет смысла. Если вы не можете легко выделить ключевую функцию, то у вас нет ничего стоящего на руках. Лучше вернуться к бумаге и подумать.

Когда ключевая функция реализована в каком-то виде, нужно выпустить систему в мир. Можно снабдить остальные функции затычками и не переживать. Нужно убить в себе перфекциониста, показывать систему людям и собирать информацию. Вы продаёте ключевую функцию. Если она не продаётся, то у системы большие проблемы с будущим. Придётся вновь вернуться к бумаге и подумать.

Единственный надежный способ проверить идею — начать делать продукт. На стадии концепции или прототипа вас могут послать все инвесторы, все потенциальные пользователи и все эксперты. Это, конечно, должно настораживать, но не обязательно должно останавливать. Если у вас и у команды есть вера, то продукт нужно выпускать.

С другой стороны, вы можете начать и через 2–3 месяца осознать, что продукта-то и нет. Ерунда какая-то получается, одним словом, а не продукт. Как заранее это узнать? Практически невозможно.

И последнее. Начинать делать продукт нужно тогда, когда вы не можете его не делать. Идея сверлит вам мозг, не даёт покоя, посещает вас даже через несколько мгновений после оргазма (а иногда и до). Идея заставляет вас пропускать нужные повороты, велит рассеянно кивать за обедом и отвлекает во время медитации. Вот если у вас есть такая идея — вперёд 🔥.


We create Fibery — work management platform that grows with your company. Go see for yourself: https://fibery.io 🎈