Срок службы цифрового продукта легко отследить. Он создается, запускается, развивается и поддерживается, а затем закрывается. Если у него есть долговечность, оно рождается заново — перестраивается, переосмысливается и модернизируется — но это новая жизнь со своим собственным началом и своим концом.
Срок службы относится к периоду жизненного цикла продукта, когда он сохраняет жизнеспособность или создает ценность для бизнеса. Healthspan гораздо более нечеткий и его трудно очертить.
Эта диаграмма грубо иллюстрирует продолжительность жизни и продолжительность жизни, а также нездоровые фазы, когда ценность продукта для бизнеса меньше, чем инвестиции в его разработку и поддержку.
Неработоспособные фазы могут возникать в любой момент жизненного цикла продукта, но обычно они возникают на ранней стадии (если вы не являетесь ChatGPT) и ближе к концу, до того, как продукт будет выведен из эксплуатации или перестроен.
Это нормально иметь некоторую отрицательную ценность на начальном этапе, пока продукт не встанет на ноги на рынке. Проблема возникает ближе к концу, когда существует значительная разница между инвестициями и ценностью, которую они возвращают, и если это продолжается слишком долго, это может иметь катастрофические последствия для бизнеса.
Когда это происходит, необходимо ответить на два вопроса:
- Почему мы не закрыли его раньше?
И
- Что мы могли сделать, чтобы продлить его ценность?
Чтобы ответить на эти вопросы, полезно провести аналогию с состоянием человека.
Как и в случае со здоровьем человека, выявление признаков нездоровья необходимо для раннего выявления проблем и принятия мер.
В цифровом контексте, на какие маркеры нам следует обращать внимание и какие диапазоны допусков мы должны установить, чтобы знать, когда нужно беспокоиться и принимать меры?
Вот простая структура, которая помогает исследовать состояние вашего продукта в четырех ключевых областях: бизнес-цели, опыт работы с клиентами (Cx), опыт сотрудников (Ex) и опыт разработчиков (Dx).
Бизнес-цели
Если ваше ценностное предложение цифровое, продукты, которые вы создаете, являются воплощением стратегических целей вашей компании. В этом быстро меняющемся мире жизненно важно оценить, насколько хорошо эти продукты функционируют как двигатель бизнеса. И делать это непрерывно.
Чтобы измерить это, необходимо связать производительность продукта и цели компании с показателями, которые помогут ответить на важные вопросы.
Некоторые важные вопросы, которые следует задать:
- Тратим ли мы больше денег на поддержку этой платформы, чем она генерирует?
- Существуют ли какие-либо прорывные технологии, которые могут негативно повлиять на наш продукт? Подумайте о генеративном ИИ.
- Как выглядит конкурентная среда и как ее сравнивать?
- Соответствует ли этот продукт нашей большой миссии?
Существует множество рамок измерения; тем не менее, структура OKR — одна из лучших. Просто рассчитывайте реализовать это как минимум дважды, прежде чем вы сделаете это правильно.
Опыт клиентов
Далее идет клиентский опыт. Сегодня Cx является VIP-членом клуба «нам действительно нужно наплевать» благодаря успеху крупных корпораций, таких как Apple и Amazon, которые сделали своей основной задачей удивлять своих клиентов.
Некоторые ключевые вопросы, которые следует задать в этой области:
- Рекламируют ли мои клиенты наш продукт другим?
- Дает ли мой продукт клиентам положительный опыт?
- Является ли мой продукт интуитивно понятным и простым в использовании?
- Адаптируется ли мой продукт к потребностям моих клиентов?
- Является ли мой продукт хорошим, если не лучше, чем Cx других ведущих цифровых продуктов?
Наиболее значимые KPI для отслеживания (IMO) включают:
- NPS (Net Promoter Score): NPS измеряет вероятность того, что клиенты порекомендуют ваш продукт или услугу другим.
- CSAT (удовлетворенность клиентов): CSAT измеряет удовлетворенность клиентов, предлагая им оценить свой опыт по шкале (обычно от 1 до 5).
Другие установленные рамки и ключевые показатели эффективности, заслуживающие изучения, включают CES (оценка усилий клиента); CLV (Пожизненная ценность клиента, Коэффициент оттока; Разрешение при первом контакте (FCR): Среднее время разрешения (ART)); и SERVQUAL. Отслеживание и измерение настроений в социальных сетях также имеют решающее значение.
Опыт сотрудников
Третье, но точно не в бронзовой категории – ваши дорогие сотрудники. Эти верные войска, которым приходится взаимодействовать с системами бэк-офиса, часто забывают, когда дело доходит до пользовательского опыта. Отрасль, наконец, осознает важность предоставления своим сотрудникам отличных цифровых инструментов. Дальновидные организации ставят критерии дизайна опыта сотрудников на тот же пьедестал, что и опыт клиентов.
Опыт разработчиков
И последнее, но не менее важное — это наши смелые разработчики, перед которыми стоит задача создавать функции и исправлять ошибки, а иногда и притворяться, что ошибка — это функция. Хороший опыт разработчика — это когда обе работы приятны и приятны.
В основе хорошего Dx лежит программная архитектура продукта, и архитекторы и инженеры должны ежедневно отвечать на эти вопросы в своем коде.
- Является ли мой продукт молниеносным в использовании?
- Может ли мой продукт масштабироваться за счет большего количества пользователей и использования?
- Безопасен ли мой продукт?
- Является ли мой продукт стабильным?
- Легко ли разработчикам поддерживать мой продукт и разрабатывать новые функции?
- Могу ли я выпускать обновления часто?
Существует множество фреймворков для метрик и ключевых показателей эффективности, но вот четыре моих лучших.
- Четыре ключевых показателя от DORA (DevOps Research and Assessment): частота развертывания, время подготовки изменений, среднее время восстановления и частота отказов изменений.
- Показатели производительности, включая время отклика, пропускную способность, емкость и масштабируемость.
- Показатели безопасности, такие как количество инцидентов безопасности, время обнаружения и время разрешения
- Показатели опыта разработки: время адаптации, качество документации, удобство использования API, удовлетворенность инструментами и платформой, время решения проблем, скорость разработки, время проверки кода, качество совместной работы и коммуникации, а также удержание разработчиков.
Теперь, когда вы следите за состоянием вашего продукта в сферах бизнеса, клиентов, технологий и сотрудников, что вы делаете, когда видите проблему?
Что ж, у вас есть два варианта: курс исправить или закрыть его. Когда это делать, выходит за рамки этого поста, но я оставлю вам несколько важных уроков, которые помогут увеличить долговечность вашего продукта, избегая того трудного момента, когда вам нужно щелкнуть выключателем на вашем любимом творении.
Протестируйте, прежде чем инвестировать
Убедиться, что вы делаете ставку на правильную руку, прежде чем идти ва-банк, — это наиболее очевидное руководство для разработки продукта. Это не обязательно должен быть восьмимесячный стратегический проект Makensie с колодой на 600 страниц, но крайне важно тщательно протестировать ваше предложение, прежде чем вы приступите к разработке. Думайте больше 8–12 недель, сервисный дизайн, исследования пользователей и рынка, а суперумные люди критичны, объективны и изобретательны.
Интеллектуальное измерение
Как только вы запустите, вы можете начать измерять все вещи. Выполнение измерений является обязательной функцией процесса разработки, а не попыткой прикрутить их в конце. Кроме того, не попадайтесь в ловушку измерения ради него. Убедитесь, что то, что вы измеряете, имеет смысл и не перегружает вас ненужными данными.
Создавайте масштабы или будьте готовы начать заново
Быстрый выход на рынок часто требует компромисса между масштабом и скоростью. Выбор скорости обычно означает принятие технологических решений, которые могут ограничить ваши возможности масштабирования. Выбор масштаба означает более длительное время разработки и более высокие затраты. Здесь нет правильного ответа, но совет — делайте выбор осознанно и будьте готовы к последствиям.
Поставьте клиента в центр всего, что вы делаете
Команды, работающие над продуктами, часто могут иметь разные задачи в зависимости от того, в каком отделе или подразделении они работают. Когда это происходит, все они должны переориентироваться на правильное обслуживание клиентов. И этот менталитет клиента должен исходить с самого верха и пронизывать умы всей организации.
Ориентируйтесь на данные
Принятие решений может быть сложным и часто зависит от предвзятости и HIPPO (мнения самого высокооплачиваемого человека) в комнате. Использование данных для принятия решений требует надежной стратегии данных и плана реализации, а также постоянных инвестиций и совершенствования. Цель состоит в том, чтобы получить представление о данных, которое не только объясняет, что произошло (задним числом), но и почему это произошло (предвидение), а также что делать (предвидение). Последний компонент станет в значительной степени управляемым искусственным интеллектом.
Наконец, объем поста вырос очень быстро, и я, возможно, пропустил кучу вещей, пытаясь осветить большую тему. Дайте мне знать в комментариях, если вы считаете, что мне нужно что-то добавить.
