Создавать новый продукт, который понравится людям, трудно, главным образом потому, что это сложный занимающий много времени процесс. Важная часть создания продукта - учиться на своих ошибках в условиях, когда нельзя просто взять и начать все заново.
В процессе создания чего-то великого вам потребуется как творчество , так и дисциплина. Многие продукты терпят неудачу, потому что эти две составляющие не просто сочетать: дисциплина ограничивает творчество, а творчество мешает дисциплине.
Когда над творчеством главенствуют строгие управленческие правила и рутина, создаваемый продукт будет скучным и бессмысленным. Опираясь только на творческий подход создателя, вы быстро завершите проект на 80% , но довести до ума важные детали вам так и не удастся.
За долгие годы я видел, как продукты терпят неудачу по причине эгоизма, кастрации творчества и отсутствия дисциплины. Спрос на качественные продукты сегодня слишком велик, чтобы тратить впустую время и талант.
Создавая продукты в Translated и Memopal и наблюдая за множеством отличных стартапов, я разработал метод, который призван обеспечить необходимый баланс творчества и дисциплины, быстрый и заранее утвержденный способ вернуться назад и исправить ошибки. Этот способ также включает в себя две составляющие успешных продуктов: видение и психологию.
Минимальная команда должна состоять из:
- Менеджер по продукту, на которого возложено руководство.
- Пользователи, перед которыми стоит задача сформулировать «болевые точки» и показать их важности. Под пользователями понимаются технологические первопроходцы, выразившие интерес к покупке/использованию вашего продукта.
- Разработчики, которым поручено найти решения для обозначенных пользователями «болевых точек» и оценить затраты на производство таких решений.
Если вы единственный учредитель, предлагаю вам взять на себя роль менеджера по продукту и по возможности привлечь в команду разработчика. Единственный учредитель может выступать одновременно и менеджером по продукту, и разработчиком, однако такой вариант не идеален, поскольку он приводит к естественному желанию оставаться в зоне комфорта - а именно этого мы и хотим избежать с описываемым методом.
Большинство людей начинают разработку продуктов, не привлекая пользователя на начальном этапе. Мне кажется, это плохая идея. Чтобы ваш продукт стал успешным без пользователей, вам должно очень сильно повезти. А пользователей найти намного проще, чем поймать удачу за хвост.
Определите “болевые точки”
Проведите несколько встреч по часу каждая. Пользователь будет рассказаывать о «болевой точке», которую он осознает и от которой он бы хотел избавиться. Менеджер по продукту будет задавать вопросы с целью четче очертить проблему и более глубоко взглянуть на ее истоки. Разработчики будут молчаливыми наблюдателями. Именно на этом этапе станет ясно, насколько хорош ваш менеджер по продукту: сможет ли он добраться до истинных первопричин “болевой точки”, не скатившись при этом до нахальства и не показав себя сволочью? Как правило, случается так, что желая угодить менеджеру по продукту пользователи начинают уверять его, что эта проблема очень важна для них и что они бы многое отдали за возможность избавиться от нее. Поэтому прозорливый менеджер по продукту должен не столько слышать, что пользователи говорят, сколько видеть, что они делают. Я обычно предлагаю представить, что продукт, устраняющий эту проблему, уже существует, он называется X и стоит Y. После чего спрашиваю: “Вы хотите купить Х прямо сейчас?” Если пользователь говорит «хочу» - вы определили осознаваемую им «болевую точку», можно действовать. Если же пользователь говорит «нет» или начинает выдвигать дополнительные требования или перечислять сложности, с которыми придется столкнуться, - придется начинать весь процесс по новой. Менеджер по продукту должен сделать из каждой «болевой точки» задачу.
Сформируйте собственное видение
Проведите несколько часовых обсуждений того, как в идеале продукт должен выглядеть в конечном итоге. Участвующие в обсуждении должны понимать, что их не просят создать этот идеальный продукт прямо сейчас, им нужно всего лишь высказать предположения относительно того, что может получиться однажды, в будущем. Менеджер по продукту будет спрашивать разработчиков, какими способами можно превзойти ожидания пользователя с учетом осознаваемых “болевых точек”. Разработчики должны рассказать, что существующие технологические средства потенциально позволяют сделать. Менеджер по продукту должен задать пользователю такой же вопрос, а в конце встречи изложить собственное мнение. Как правило, формировать собственное видение достается менеджеру по продукту, именно поэтому он высказывает мнение последним - чтобы по максимуму впитать идеи других участников обсуждения. Обсуждение можно закончить тогда, когда менеджер по продукту посчитает, что такой продукт технически возможно создать и он будет пользоваться успехом у пользователей. Затем менеджеру по продукту предстоит превратить идеи в задачи.
Добавьте страсти
Самые успешные продукты дают пользователям больше, чем просто решение конкретной проблемы. Многие великие продукты построены на потворстве тщеславию, лени или страстному желанию получить то, что получить нельзя. Чтобы извлечь максимальную пользу из таких встреч, они должны из себя представлять доверительную беседу между менеджером по продукту и пользователем - без посторонних. Менеджер по продукту должен побудить пользователя пуститься в обсуждение своей работы и жизни, забыв ненадолго о продукте, который вы собираетесь создать. Менеджеру необходимо узнать у пользователя, чем тот выделяется из массы своих “коллег по цеху”, что вызывает у него скуку и чего бы такого ему хотелось, что невозможно получить. Из ответов на эти вопросы следует сформулировать задачи.
Определите приоритеты и сроки выхода релизов
В итоге все задачи, сформулированные на основе “болевых точек”, собственного видения и психологии человека, надо внести в таблицу наподобие этой:
| Задача | Стоимость ($) | Эффект ($) | Приоритет |
|---|---|---|---|
| Заставить пользователей поделиться фотографиями, кликая правой кнопкой | 2,000 | 10,000 | 5.0 |
| Релиз 1 | |||
| Добавить функцию зума | 1,500 | 5,000 | 3.3 |
| Поддержка Android | 10,000 | 10,000 | 1.0 |
| Релиз 2 | |||
| Автоматическая группировка фото | 50,000 | 25,000 | 0.5 |
| Автоматическая отметка лучших фотографий звездочками | 20,000 | 5,000 | 0.2 |
| Релиз 3 | |||
Стоимость — это оценка общей стоимости выполнения задачи; заполнять эту колонку должны инженеры. Эффект - это балльный показатель или экономическая выгода эффекта выполнения данной задачи. Заполнять эту колонку должны пользователи, причем желательно, чтобы они не знали данных по стоимости задач. Главное тут - не сами числа, а соотношение задач друг с другом. Если стоимость одной задачи в два раза выше другой, значит и эффект от ее выполнения должен быть в два раза больше. Менеджеру по продукту следует критически воспринять полученные от инженеров и пользователей данные и убедиться, что их оценки похожи на правду. Менеджер рассчитывает приоритеты задач по формуле эффект ÷ стоимость и выстраивает их списком сообразно уменьшению приоритетности. Далее менеджер при посредстве инженеров и пользователей добавляет горизонтальные ряды в таблицу, составляя таким образом план релизов.
Группировка задач по релизам гарантирует максимальную ценность для пользователя при минимальных вложениях средств уже на этапе первого релиза. Это крайне важно для того, чтобы продукт был хорошо принят на рынке. Если нужная привлекательность предложения не очевидна на этапе первого релиза, менеджеру следует еще раз критически посмотреть на полученные ранее цифры и/или поработать над привлекательностью предложения. Бывает такое, что выясняется, что выбранная “болевая точка” на самом деле не стоит потраченного времени.
Проверка и доработка
Сделайте продукт в том объеме, в котором он будет существовать на этапе релиза 1, и попросите пользователя потестировать его. Предложите ему хорошую скидку на предзаказ - речь ведь идет только об альфа-версии продукта. Если пользователь соглашается на предзаказ, переходите к релизу 2 и повторите эту итерацию.
Если пользователь отказывается от предзаказа, поскольку такой продукт не устраняет “болевую точку”, вернитесь к началу и заново определите “болевые точки”. Если и после нескольких дополнительных итераций пользователь по-прежнему отказывается от предзаказа - придется избавиться от слабейшего из звеньев сцепки инженер-пользователь-менеджер по продукту, найти ему соответствующую замену и запустить весь процесс с начала.
Чтобы создать хороший продукт, кроме творчества и дисциплины, потребуется также готовность идти на серьезные жертвы - или полагаться на чистое везение. А для создания выдающегося продукта вам понадобится и то, и другое.