Product Management без ошибок. Гид по созданию, управлению и успешному запуску продукта

Этот раздел посвящен процессу выявления того, что нужно разработать. Обычно, когда мы думаем о процессах, мы сосредотачиваемся на разработке программного обеспечения, а не создании правильного программного обеспечения. Это и есть ловушка разработки. Из ловушки можно выбраться, поняв и применив методы решения проблем и проведя исследования, как это сделала команда Marquetly. Это и есть процесс управления продуктом, и начинается он с Product-Kata.

Глава 15

Product-Kata

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

The Product Kata

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

Таблица 15.1 Product Kata. Мелисса Перри

Мы проходим эти шаги, чтобы раскрыть инициативы и возможности продукта.

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

Существует много вариантов, которые помогут достичь инициативы, как мы видели на примере трех опций, используемых для создания контента в Marquetly. Один из них или все они могут привести к успешному результату инициативы, и это нормально. Чтобы определить, приближаемся ли мы к достижению инициативы, нам нужно разбить метрики успеха на то, что мы можем измерить в более коротком временном масштабе. Мы называем это командной целью, и именно так мы измеряем успех варианта. Хотя для достижения цели может потребоваться шесть месяцев или больше, саму цель мы можем измерить после каждого релиза. Так мы получаем обратную связь и понимаем, работает ли наш вариант так, как мы хотим. Мы устанавливаем цель команды с помощью того же процесса, что и для инициативы продукта.

Контекст имеет значение

С тех пор как появилась концепция «Бережливого стартапа», исследования превратились в жаркую тему для многих компаний-разработчиков программного обеспечения. Я вижу, как команды с готовностью бросаются в эксперименты, стремясь запустить A/B-тест или создать прототип. Но прежде чем приступать к работе, важно сделать шаг назад и понять, что необходимо на данном этапе. Именно здесь помогает Product-Kata.

После того как мы поставили цель, мы обращаемся к Product Kata и задаем себе следующие вопросы:

1. Какова цель?

2. На каком этапе мы находимся по отношению к этой цели?

3. Какая самая большая проблема или препятствие стоит на пути?

4. Как я буду решать эту проблему?

5. Что произойдет (гипотеза)?

6. Что произошло на самом деле, и что мы узнали?

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

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

Размышляя о том, стоит ли экспериментировать над конкретным решением, я вспоминаю слова моего друга Брайана Калма, бывшего руководителя UX в Zappos. Однажды он сказал: «Не тратьте свое время на чрезмерную разработку и создание инновационных решений, если они не являются ключевыми для вашего ценностного предложения. Если кто-то уже решил эту проблему с помощью передового опыта, изучите его, внедрите это решение, соберите данные, чтобы определить, насколько оно успешно в вашей ситуации, а затем проведите итерации. Берегите свое время и энергию на значимые вещи».