Делайте что-то одно, но хорошо

Я люблю продукты со «всеми вещами»
В течение нескольких месяцев перед выпуском первого iPhone я был уверен, что не собирался его покупать.
Слухи, которых было несколько, были только скучными.
Там не будет простого способа сделать список избранных
Он бы не работал в моей корпоративной среде
Там не было опции «вырезать и вставить»
Я был давним пользователем телефонов-компьютеров, которые я часто менял — каждые 5-8 месяцев, когда выходил новый.
У меня была Nokia 9000 Communicator (засветившаяся в классическом фильме 1997 года «Святой» с Вэлом Килмером).

Nokia 9110
И у меня было множество других как до того момента, так и после него. От наладонных устройств до смартфонов Windows и телефонов Blackberry.
Все потому, что мне понравилось мощное устройство, у которого были все возможности. Не какой-нибудь сломанный Apple iPhone «не первой свежести».
Поэтому, когда я говорю вам, что трюк для создания продукта, который люди смогут принять и обожествлять — это делать одну вещь хорошо, я иногда чувствую себя неискренне. Я все это понимаю.
Появление минимального жизнеспособного продукта
Если вы были в Интернете в течение последних нескольких лет, вы уже видели, как тонны стартапов приходили и уходили.
С появлением The Lean Startup и концепции минимального жизнеспособного продукта (MVP), сотни людей разделили ту же концепцию — делать одну вещь хорошо.
И вы можете увидеть ее везде в Twitter и Facebook, ведь картинки на эту тему выкладываются регулярно. Вот одна из моих любимых.

MVP

Концепция проста. Вы строите свой MVP постепенно, но последовательно добавляете ценность. Не только «частично завершаете» его на протяжении долгого времени.
Это хорошо. Мне это и вправду нравится. Но когда речь идет о программных продуктах, часто бывает нужна каждая функция. И понятия скутеров, мотоциклов и мопедов не так четко определены на существующем рынке.
Кроме того, понятие MVP (в течение последних нескольких лет) часто оборачивается подходом «просто киньте это на рынок и посмотрите, что происходит».
Это привело к обилию дерьма, разочарований и множеству вредных привычек.
Ваша «Одна вещь» — не характеристика, а деятельность
Если вы возьмете интервью у 50 человек, которые хотят или уже планируют использовать ваш программный продукт, вы получите 50 «ключевых особенностей.» Да, это произойдет.
Иногда они будут совпадать, но поверьте мне, когда я говорю вам — на ранних этапах разработки продукта, каждый хочет, чтобы вы двигались в нужном ему направлении, и в каждом сценарии будут требоваться различные функции.
Так что лучше сделайте одну вещь, а не сосредотачивайтесь на особенностях. Концентрируйтесь на ключевой деятельности.
Это то, чему меня научил iPhone в своей первой версии.
В те дни одним из моих самых больших разочарований было отсутствие электронной почты, опции «вырезать и вставить», или чего угодно, связанного с приложениями. Проще говоря, мне приходилось использовать свой телефон, чтобы делать основные «телефонные» вещи — такие, как звонки и голосовая почта.
Если у меня было 40 голосовых сообщений (а это было обычным явлением), я понятия не имел, какое из них было самым важным. У меня не было никакого способа выбрать одно конкретное, чтобы прослушать его. Я должен был включать каждое из них, чтобы выяснить, были ли они критичны для меня и шли ли от важных людей.
Кроме того, если я слушал голосовую почту и хотел перезвонить, я должен был надеяться, что они оставили мне телефонный номер, или переходил обратно в список пропущенных вызовов.
И новый iPhone решил все эти проблемы с помощью своих «родных» функций в ОС, сделавших телефон гораздо лучше, чем любой другой, который я когда-либо имел (для звонков).
Все было из-за прослушивания голосовой почты и возвращения вызовов. Это была деятельность, которая двигала инновации.
Качество вызывается тестированием всех аспектов этой ключевой деятельности
Со времен появления подхода к развитию продуктов, базирующегося на данных, мы уже видели тонны инструментов. Тонны сбора данных. Тонны метрик.
Но мы не видели той же приверженности узким областям функций, работающим вместе, чтобы помочь нам в ключевых направлениях деятельности.
Что еще более важно, мы не видели тестов, которые должны проводиться при развитии продукта, ориентированного на деятельность.
Я не говорю о модульном тестировании или тестировании интеграции. Я говорю о приемочных испытаниях. О тестировании, проводящемся разнообразными способами, которыми пользуются клиенты в различных случаях в своей деятельности и для целей, которые они преследуют.
Как делать это правильно — мой любимый пример
Один из моих любимых примеров развития узкого круга харакертистик и критического тестирования — WordPress-плагин, который является расширением для WooCommerce. Он фокусируется на подписчиках.
Теперь некоторые мои знакомые разочарованы тем фактом, что они должны приобрести как расширение для подписки, так и и расширение для членства в WooCommerce, чтобы создать повторяющийся платеж для защиты контента. Они хотят, чтобы все это было совмещено в единое решение.
Но я не согласен — по всем причинам, перечисленным выше.
Для того, чтобы создать успешный продукт для подписки, вы должны сосредоточиться на ключевой деятельности.
Теперь, если вы никогда не думали об этом или о том, как это будет работать, это выглядит чересчур узко. Я понимаю это.
Но если вы присмотритесь повнимательнее, вы скоро обнаружите, что основной вид деятельности имеет множество различных функций, привязанных к этой конкретной деятельности.
Поручить человеку последовательную сумму с помощью Paypal
Поручить человеку последовательную сумму с помощью Stripe
Поручить человеку последовательную сумму, используя другой платежный шлюз
Разрешить конфигуратору сайта определить период времени между платежами
Разрешить конфигуратору сайта определить, распределится ли оплата пропорционально
Разрешить человеку изменить свой план, и распределить его оплату пропорционально
Разрешить конфигуратору сайта определить, может ли человек приостановить свою подписку
Дать человеку возможность приостановить свою подписку
И это не считая мелких деталей, относящихся к расчетам, задействованным в изменении подписки, когда ставки или периоды меняются.
Понимаете, я не говорю, что набор функций должен быть небольшим. Но я также не говорю, что он должен быть большим.
На самом деле он должен быть в самый раз. Но мы определяем, что такое «в самый раз» путем определения ключевых направлений деятельности, которая поможет клиенту почувствовать себя удовлетворенным и успешным.
Это критически важная работа. И она требует дополнительного акцента на тестировании и качестве.
Когда дело доходит до пропорционального распределения платы за подписку, это не просто работа. И есть множество возможностей:
Человек меняет месячный план на годовой
Человек меняет годовой план на месячный
Человек меняет план на другой по сумме оплаты
Каждый из этих путей должен быть проверен — строго. И он должен быть проверен на различных платежных шлюзах, в данном случае.
Но это касается не только расширений для подписки. Они — просто мой пример. Потому что я знаю, как много работы на них уходит. И я знаю ключевую деятельность и все зависимые от нее функции, необходимые, чтобы сделать эту работу.
Ваша ситуация может отличаться.
Но она все равно будет требовать, чтобы вы научились делать что-то одно, но хорошо.