Выбрать главу

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

— Сет Годин, автор/предприниматель, Be a Better Liar.
В чём ключевая проблема?

Один из быстрейших способов придумать проблем на свою голову — смотреть на то, что делают ваши конкуренты. Мы чуть не «нарвались» на это: когда мы начинали делать BlinkList уже существовало с десяток других сервисов хранения веб-закладок. Некоторые даже начали делать крупноформатные таблицы с детальными сравнениями особенностей.

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

— Майкл Рейнинг, соучредитель MindValley & Blinklist.

Никакой рутины

Ваша страсть или её нехватка будет ясно видна

Чем меньше в вашем приложении рутины — тем лучше.

Если рутинной работы немного и она управляема — вы можете наслаждаться.

Если ваше приложение не волнует — это плохо. Если вы делаете это только из-за денег — это проявится. И если вы обожаете свое приложение — это проникнет в конечный продукт. Люди умеют читать между строк.

Присутствие страсти

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

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

— Кой-Вин, Subtraction.com и соучредитель Behavior LCC.
Пекарня

Американский бизнес призывает к развитию идеи, к получению из этого выгоды, к последующей продаже, в то время как это становиться выгодным, а затем собирает доходы или диверсифицирует развитие. Это высасывает все. Моя идея: если вы печете хлеб, вкладывайте в него свою душу; людям это понравиться и вы продадите больше. Ваша пекарня будет процветать, потому что вкусный хлеб понравится всем.

— Ян Маккэй, член Fugazi и совладелец Dischord Records.

Оставайтесь небольшими

Меньше размеры

Чем вы беднее, тем проще это изменить

Чем больше объект, тем больше нужно энергии для его изменения. Это так же верно в деловом мире, как и в обычном.

В вебе изменения должны проходить легко и дешево. Если вы не можете меняться на лету, вы проиграете тому, кто может. Поэтому вы должны стремиться к меньшим размерам.

Размеры увеличивают:

* долгосрочные контракты

* большой штат сотрудников

* неизменные решения

* совещания о других совещаниях

* долгий процесс

* обширный инвентарь (физический или умственный)

* привязка к оборудованию или программам

* закрытые форматы данных

* управление будущим на основе прошлого

* долгосрочные цели

* офисная политика

Уменьшить размеры позволяют:

* решения, принимаемые по мере надобности

* многозадачность членов команды

* установка ограничений вместо попыток их преодолеть

* уменьшение программного обеспечения, меньше кода

* меньшее количество функций продукта

* маленькая команда

* простота

* открытые исходные коды

* открытые форматы данных

* свободная атмосфера, в которой легче признавать ошибки

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

К примеру, давайте представим одну маленькую компанию, которая выпустила продукт с небольшим набором функций, и компанию, у которой есть продукт с обширным функционалом. Далее возникает новая технология, например, AJAX, или новая идея, как, например, теги. Кто из них в состоянии быстрее приспособить эти технологии к своему продукту? Команда с огромным проектом, кучей функций и планом на год, или команда с маленьким продуктом и более органичным подходом, который гласит «давайте будем делать то, что нам нужно сделать прямо сейчас»?