Компании-разработчики программного обеспечения всегда сталкиваются с вопросом о том, стоит ли добавить еще одну функцию. Ответом, к которому они обычно приходят, является «да». Когда Вы – специалист в создании программного обеспечения, Вы хотите решить любую проблему в мире с помощью программного обеспечения.

В Intercom мы научились оценивать, где заканчиваются работы нашего продукта. Если Вы будете слишком неукоснительно следовать концепции РКДБВ, Вы можете в конечном итоге попытаться решить весь рабочий день своего клиента через Ваш продукт. Вы можете начать с приложения для учета и контроля времени, добавить выставление счетов, затем расчет заработной платы, и, прежде чем Вы это заметите, у Вас будет идеальное решение для очень небольшого набора пользователей. Вы должны узнать, где заканчивается Ваш продукт.

Самое главное, что делает менеджер по продуктам, это решает, где его продукт заканчивается, и начинается работа другого продукта.

Если Ваш продукт делает слишком мало, то он не стоит затрат на установку, не говоря уже о цене фактической покупки. Точно так же, если продукт делает слишком много, он вступит в конфронтацию с некоторыми другими ранее существующими программами или рабочим процессом, которыми пользователи уже удовлетворены. Это так называемая проблема «золотой середины» – Вам необходимо найти идеально подходящий продукт.

Понимание рабочего процесса Вашего продукта

В качестве примера возьмем продукт для учета и контроля времени. Как абсолютный минимум, учет времени – это просто сумма определенного перечня чисел. В общем, если бы это было все, что мог бы предложить программный продукт, он был бы бесполезен. Таблицы Excel или Google уже выполняют эту работу. Именно в этот момент мы понимаем, что простота переоценена. Даже наилучшим образом разработанный интерфейс не может помочь продукту, который себя не окупает.

Как максимум, учет и контроль времени может включать в себя управление проектами, бюджеты, подрядчиков, выставление счетов, отслеживание поступлений и мониторинг сотрудников. Приложения, включающие так много окружающих нас задач, наступают на ноги уже существующим продуктам – в этом случае Xero, Wrike, Basecamp, Teamwork и т.д.

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

Если Вы создаете приложение, которое помогает командам ежедневно заказывать обед, последовательность выполняемых операций может выглядеть следующим образом:

1. Кто-то проголодался.
2. Он или она сообщает это остальной части команды.
3. В результате начинаются дебаты на тему, стоит ли пойти куда-нибудь поесть или заказать еду в офис.
4. Вторая дискуссия о том, где заказывать.
5. Меню для разных ресторанов переходят от одного члена команды к другому.
6. Решение принимается быстро.
7. Один человек назначается для сбора заказов всех членов команды. 8. Затем этот человек размещает заказ.
8. Этот человек передает каждому информацию о времени доставки и стоимости.
9. Время проходит.
10. Заказ прибывает, и его съедают.
11. Заказчик проверяет, все ли заплатили полностью, и кто все еще должен деньги.
12. Вопрос с финансами урегулирован, или его урегулирование откладывается до завтра.
13. Некоторые поговорят о еде в Twitter или Facebook. Некоторые разместят фотографии в Instagram. Другие сделают обзор на Yelp.
14. Все возвращаются к работе.

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

С чего стоит начать?

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

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

И они сделали это, эффективно используя существующую инфраструктуру продуктовых магазинов, вместо того, чтобы пытаться построить решение с нуля.

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

Где Вам стоит остановиться?

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

Вашему продукту стоит остановиться, когда следующий шаг:

• Имеет четко определенных лидеров рынка, которые занимаются им (например, Apple, Netflix, Expedia), и Вы не намерены конкурировать.
• Выполняется множеством разных способов большим количеством различных типов пользователей (например, попытка обрабатывать зарплату в приложении для учета и контроля времени была бы сложным делом).
• Включает в себя различных конечных пользователей, в отличие от предыдущих этапов (например, менеджеры, бухгалтеры и т.д.).
• Является областью, в которой Вы не можете повысить эффективность.

Определить и устранить бессмысленные шаги

Если пользователь закончил с Вашим приложением, и следующий его шаг состоит в загрузке файла, чтобы его можно было отправить по электронной почте в любое другое место, это бессмысленный шаг. Если он будет экспортировать свои расходы в CSV-файл, чтобы тот можно было загрузить и повторно сохранить как XLS, а затем отправить по электронной почте своему бухгалтеру, это бессмысленный шаг. Если завершение проекта означает загрузку всех файлов, их архивирование и отправку по электронной почте клиенту для безопасного хранения, это бессмысленный шаг. Электронные сообщения почти всегда являются источником бессмысленных шагов: они редко содержат достаточную информацию («Кто-то разместил комментарий») или они не связывают очевидные действия (подтверждают, помечают как решенные и т.д.).

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

Будущие итерации

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

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

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

Такой подход к минимально жизнеспособному продукту рискует быть названным «точечным решением» или, что еще хуже, «функцией, но не продуктом».

Нацелившись на получение «простого продукта», будьте осторожны, когда обозначаете границу.